Different levels on unity game - android

I am planning to make a android game using unity game engine. I would like to include different levels as we see in angry birds and some other games. My question is whether I have to build different scenes for each levels. I am completely new to this platform.

The answer is yes and no. It's possible to use just one scene and manage levels on your own, but this will add a lot of complexity, will be hard to manage and is generally not recommended. Though, this might be a viable option in some circumstances: for example, if you generate your levels procedurally.
That being said - you should use scenes to manage your levels, and Unity will take care of a lot of details, such as editing, loading, releasing unused assets when switching levels, etc, that otherwise you'd have to implement yourself.
You also shouldn't worry about scenes bloating your game, because they are quite small compared to game assets. They only contain information about what objects are in the scene and their properties. Also scenes include only references to assets (textures, meshes, sounds, prefabs, scripts and so on), and actual data is stored separately and shared between them.

If you have complex objects like you know a lot of variations of enemies and objects then it is good to make different scenes for different levels.
On the otherhand if your levels have a little changes like enemy behavior changes movement changes etc then u can easily do it in one scene by passing variables of different object.
But first approach is easy to use.
here is a example of a game with SECOND APPROACH :
https://play.google.com/store/apps/details?id=com.batterylowgames.killyourbloodyfriends&hl=en
Thank you :)

Related

Android UI vs Opengl ES 2 UI

this question is more for looking advices
I've developed an almost full user interface in pure c++ and opengl es 2, currently I'm developing that the click/touch events be propagate as in HTML, I can't remember why I decided do a UI in opengl, but now I realize that I'm reinventing the wheel.
so currently I have many "elements", buttons, containers, scrolls, pictures, animated pictures, borders, text, drag-drop's, I can set easily where I want each element, set sounds, and I really don't know how fast and effective it is right now, but I've maked all the fast and memory effective that I can, and I planning to use multi-threading in the future. And my goal is to approach a system like html.
And now that I'm looking for how to implement my UI in native Android (java), I realized that I was in the correct way, all the properties and methods all the structure I'm implementing in c++ and opengl is almost the same as in android, even I think my implementation is easier to use the images and sounds because I've automatized all and I can put it in the assets folder, and in the code only put the name of the file and the program returns it, with and effective memory managment.
the current elements are elements that I need for a game interface, so if I need other kind of element I'd have to write it, but right now, I have all elements that I need, I think so.
maybe my code in c++ is faster than java.
but even with all this, I know I have a lot to do to have a full UI, so can you give some advices or experience, advantages, disadvantages, it worth to continue with the UI, or better learn (beacuse I just know a llitle bit of UI Android) UI Android, modify all my game for use the new arquitecture/system, What do you think?

How do I create an android AIR app with more than one page or doc using Flash (Professional CS6)

I'm learning creating mobile android AIR apps using Flash Professional CS6.
I want to try and create a game where first there is a title screen, and then when you press play you go to the game screen.
But I can't figure out how to create an app where there are such multiple pages/docs/screens allowing you to navigate from one to the next.
If you create one .fla file then everything seems to be on the one page. Maybe the way is to create multiple .fla files, one for each screen and then in some way navigate between them? (No idea how.) Or should you have one .fla file and create the different pages as points in the timeline (sounds cumbersome and awful!).
My question is how would you achieve the above, and what is the recommended and simplest way of doing it?
There seem to be very little resources and tutorials about creating AIR apps.
There's a lot of ways to do that, it depends a bit on the scale of your project and your knowledge level.
In 'basic' flash you simply could jump to a new frame or scene containing your animations.
I'm not recommending this for a game project, as a lot of things normally change in the making and adusting all the gotoFrame() calls can be a a pain in the ... , ah well, you know where.
A cleaner approach would be to make your animations/ screens into separate .swf files or pack them all into an .swc, where you can instantiate them from, when you need them. Don't do any scripting in here, but use a centralized controller instead, that will coordinate loading and displaying the screens. E.g., you may add a Loader() in your root to load and add new scene contained in an .swf or instantiate a class from the .swc.
Especially when writing a (2D) game, you should definately check out the Starling Framework for Flash. It requires some basic knowledge of object oriented programming, though. A lot of resources can be found at the big G using "starling framework tutorial" as search term.
It's using Stage3D as basis and this way is a lot faster than rendering your content the normal flash way. The api is using very similar concepts as 'original' flash, but is a bit different in the detail. If you are starting to learn OOP, you could start here as well and get used to Starling right from the beginning.
The scope of this question is a bit broad to be answered in a post, though.
I'd suggest you get going, and ask more questions, when you encounter a specific problem :-)
Good luck!

Android platform game level editor

I'm trying my hand at making a platform game and have been thinking about what I would use to design levels.
I was thinking of using a tile palette that would contain the graphic tiles and their properties. And a similar palette that would contain sprites.
This way I could drag and drop tiles/sprites onto a grid and specify property values. This could all be saved to some kind of file that would be read by the game.
Without getting too into the details, is this a sound overall strategy? Is there anything major that I'm forgetting? Or perhaps there's a better method?
This is a rather open-ended question, but I don't think there is anything wrong with your approach. You might have to try a few things to find out what works for you.
When I make platform games I find it useful to be able to edit levels while I'm playing them, by adding in code to the game which allows me to select a graphic tile from a palette and paint it onto the screen. The behaviour is usually linked to the graphic for my games but you could paint behaviour as well. You then need code for your game to save levels as well as load them. Obviously, you would probably want to remove the editor before releasing the game.
I don't know how much experience you have with game dev, but if you're thinking about making a tile-based platform game then your best bet is leveraging existing libraries/tools to avoid "re-inventing the wheel". I highly suggest looking into open source libraries/tools because you can modify them to your liking. I've had some good experience with libgdx and AndEngine in which case both have TMX support which is a file format that can be used in conjunction with Tiled map editor. I personally like libgdx because it has javadoc and very actively developed, and also that it's a framework rather than engine which gives you more flexibility (although more coding in some aspects).

Rendering Maya animation on Android?

I've been able to import 3D models from Maya into OBJ files, which in turn, are read by my Android app. This model can now be displayed and I can apply transformations on them as well, even on high-polygon count objects, which is nice.
The next step is to figure out if there's any reasonable way to display animation defined within Maya. I really have no clue how to approach this and my initial research on this essentially came up empty.
Has anyone attempted this before? If so, how would this work?
I think it's worth noting that this question has little or nothing to do with Maya. Maya's file formats are proprietary and opaque; you will NOT find a way to directly display them on Android (or anywhere else, come to that). But you can export data from Maya to (basically) any format, which is what you actually want to do.
So, here's the process:
Figure out how you're going to display 3D models and animations on Android
Figure out how to get stuff from Maya into the format your answer from step 1 requires.
There's a lot of ways to do step 1. For sheer ease of use I'd probably go for Unity myself. Basically it's game development tool that can create 3D apps and games that run on Android (and iOS, OSX, Windows, etc.) It's not free - the Android addon costs $400 - but if you're actually planning on doing anything serious with Android, you'll find it worthwhile. With it, it's actually pretty trivial to make a little Android app in Unity that displays an animated model (and a LOT of 3D Android and iOS games are made in Unity). Unity also wants models and animations in FBX format, which is a widely supported interchange format - you'll have no problems getting stuff out of Maya into FBX.
If you've gone with Unity in step 1, then step 2 is trivial: Export your models from Maya as FBXes, and you're done. If you've decided to roll your own Android rendering app, well, good luck. :)
Anyhow, the point is that what you want to do is find a generic solution for rendering animated models on Android, and only then figure out how to get your content out of Maya.
Instead of outputting each individual frame to a separate obj file like spicyweenie suggests, why not export just keyframes to obj files. Implement interpolation in your code in order to fill in the missing frames. If your models are complex, you'll probably want to cache the interpolated models in memory, but at least you don't have to load them all from files too.
Unlike Cody Hatch's answer, I'm interested in this too. This is my theory as to come about animating a model:
Lets say your model has 30 frames. One way would be to export each frame as an individual OBJ model. From there, you can possible make a folder for those 30 OBJs. So now you have 31 files total. If the person hits a button, the trick would be to load each OBJ in order according to the length of time the button (or whatever action) is valid. and if it lasts over 1 second (30 frames), loop back to the beginning.
The only problem with this theory is that it would most-likely be resource and power intensive, not to mention, a space hog if you try to load a lot of things into one scene.

How can different android apps work together?

In games like Oblivion there is a thriving 3rd party mod/plugin world. You can get mods for practically every aspect of the game.
How could I write an android game so that I could support additional content written by 3rd parties (which they could charge for in the app store)?
Basically there'd have to be someplace that mods registered their existence and the game would have to check it and then somehow either load data from them (for purely data based add-ons) or execute them (for behavior changing add-ons).
To start with I think I'd mostly be interested in having add-ons which are data (it'd be safest), but I'd like to keep an eye toward executable add-ons.
In a sense you could have all your addons be data addons.
Consider if you wanted to add a new area in Oblivion. You could define a terrain dataset, some static objects as a dataset (trees, rocks, etc), connections as a dataset (doors to houses).
The easiest way is to make your engine just an engine, and the 'game' itself just an addon that you distribute with your engine. Your game is nothing more than a well tested, well thought out dataset.
It gets more difficult when you want to simulate something like a trading card game. Any special mechanics on cards would be limited by what calls you have available in your API. But, depending on how much you open up, the community at large will come up with excellent things!

Categories

Resources