Ok, finally, we're talking about the core of app development, the coding!
First, I must emphasize that it is probably in your best interest to consider using an app library, or writing your own. This will substantially cut down on the time needed to make a game (or probably any app for that matter). Of course the trade off is learning the external library, figuring out its limitations, and making new products with it, which translates to more initial time involvement, but could pay out in the end.
As for us, we developed a small game library that has some very basic code all wrapped up in to a tiny, neat package. It mostly allows us to mangle with time functions, "button" code, random numbers, and some other graphical utility functions (like getting the current display orientation, the density of the screen, the screen dimensions, etc).
If you make your own library, like we did, I highly recommend putting any and all code that you think is generic enough that *all* projects of yours in the future could want.
If you didn't already know, you will have to have some way of writing code. We recommend using Eclipse with the Android SDK, it's free, works, and packs various useful conveniences while developing. You will also need someone versed in Java and able to use the Android SDK.
If your person doing the development is new to Android, Java, or both, we highly recommend making some test projects first, before attempting to make your dream game/app.
It is our intention for this to not be a tutorial on how to make an app in detail, but rather talk about designs and coding specifics instead, more or less from a management perspective/process.
Ok, so once we have our IDE all set up, we can look over our game design and start plotting how we want to design the software itself.
Different software process methodologies deviate greatly in this area, our studio essentially identifies major topics/nouns used in the design of the product and USUALLY makes an assumption that those will be Java classes. I mentioned *usually* because this isn't always the case and we also do not use any automated tools or UML or anything goofy like that.
Instead, we look at the major concepts of the design and turn those in to classes first. Specifically, we know that we will need a PlayingField where by all "game playing" will take place. That becomes a class (and a very useful one at that).
Because of how Android works, we must have an Activity class. From there, we also must have our own SurfaceView class (we implement a GameView class that inherits from SurfaceView), and a class which encapsulates the main processing of the game. We make a GameThread class that inherits from Thread so that all our game processing can take place on its own.
So, without really getting in to picking apart our design, we know we have the following classes already:
GameActivity
GameView
GameThread
PlayingField
While we pick apart our design and start coding, the blog will be inactive for the next couple of days.
No comments:
Post a Comment