Finally, let's talk about how the code should be set up.
We mentioned earlier that we took the game design, analyzed it, and figured that nouns become classes and verbs become methods. This sounds good on paper, and there are even tools available to help this process. We could sit around and chart UML all day, every day in regards to the design, but is it necessary? That depends.
Because our product isn't an enterprise solution, our team is small, and one guy is basically doing everything, a massive UML chart isn't really necessary. Of course, we could never discount the idea that someday in the future these things could become useful (like if we sold our products off to another company, as an example).
Regardless, the best way forward for us is to pick apart the major components of the design and start designing what logic should go where and what it should be called.
Honestly, because of our development methodology (or lack there of, depending on who you ask), we take more of an extreme programming measure in this regard. We make classes as we need them. We start with a basic skeleton framework, then start adding new classes as they are needed in the code itself as we program the meat and bones of the product.
We start with the largest classes in the skeleton. Specifically, for Android programming, we start with the GameActivity class. This class acts, more or less, as the "starting point" for the program and interfaces with the OS. Because of how Android itself is designed, we must make a GameThread class that contains the top level logic for the flow of the game itself. We also will need an extension of a View class so that we can interact with the screen and display stuff.
Right away we have:
GameActivity
GameThread
GameView
Without really even going further, based on the game design, we know we already have 2 major components to the product, a Marble, and a Bubble. These playing pieces are what are the basic, interactable things in the game itself. Because both things follow the same physics, we decided that it is best they share a common parent class; PlayingPiece. This parent class defines movement vectors, collision information, the abstract methods of how the pieces are updated and that each child class should know how to draw itself to the screen.
At the same time, we can't really play the game without some sort of logical thing to interact with and where the playing pieces do their magic. Enter the PlayingField, a logical container that contains everything the player can interact with and see.
The game design indicates the need for persistent data over game launches, so we made another class Gamedata that is our "middle man" that handles data saved and loaded between game sessions.
We also ended up needing a class called MarbleSlot, a place where players can touch and interact with the playing field in which marbles can be spawned from.
All that said we now have:
Bubble
Gamedata
GameThread
GameView
Marble
MarbleSlot
PlayingField
PlayingPiece
There are one or two utility classes that are used to assist in the passing of data and messages between classes, but those are fairly technical and don't have anything to do with the direct design of the content of the game. Suffice to say, those can take a while to design and program as well. Just because a game design is "simple" doesn't mean the work behind it will take a set number of hours based on the relative ease of that design. Lots of "stuff" can go on behind the scenes that can take days or even weeks to implement that have no actual, obvious visual effect on the product itself.
For example, a programmer could spend a month just drawing some graphics on a display. They are very proud of this accomplishment, but to non-programmers they usually have the attitude of "you spent a month on this, and only have this to show for it?!". Get used to scenarios like this because it happens more often than not.
Anyways, now that we have our basic classes determined, the essentials are fleshed out.
Tune in next time for elaboration of the class designs and the overall flow of the logic for some of them.
No comments:
Post a Comment