1. novel: it had to have a non-clone play mechanic and game goal with extensible game play. In other words, start small and allow further improvement, modification, new levels, etc. at a later date
2. original: all art assets had to be not only original but distinct
3. digestible: easy to jump in and play but allow evolution of play and some sense of mastery
4. consumable: the essence of the game could be grasped quickly and shared with friends
5. non-intrusive: well-placed ads that explicitly did NOT interrupt the flow of the game
I gave myself one month to go from initial idea to final published product.
So I sat with an artist friend* and we ping-ponged ideas back and forth until we created a set of ideas. Then I chose one and got to work. Not interested in pigeon-holing myself as "just a coder" I got in on the art action too. I sketched out what the game logo would be, the playable character's main poses for a sprite sheet, and the game environment. You can see the original pencil work directly below.
We then split the art workload between the two of us. I created the logo, menus animated game background and sound assets while he created the character, items and special effects sprite sheets. Below was our initial rough pass at quickly converting the above into actual art assets.
Then it was time to code. I had not done any mobile development at this point and hadn't touched Java since university so it was time for a crash course into the Android SDK, API and IDE, a Java refresher and research into graphics frameworks for mobile apps. But with any technical project, proper research requires surveying the entire landscape in order to make informed decisions and prevent wasting precious hours, days, months learning a faulty, badly designed or poorly supported framework. Questions considered included: is it cross-platform, what is the state of cross-platform tools, is it even necessary to be cross-platform, have any apps been made with this framework, how long has it been around, is it being actively maintained, how much and how helpful is the documentation, is there an active community, what sort of abstractions does it provide, is it open-source, and can I use it in a commercial project? I ended up settling on a framework called libGDX; the code was clear, well-commented, open-source and it implemented custom versions of common Java data structures in order to avoid excessive garbage collection and improve performance.
Time was ticking and coding now began in honest. The main screens-- splash page, main menu, gameplay, high score --of the game were laid out and coded. The Android application lifecyle (create, resume, resize, pause, exit) was handled for each screen. Then came the meat of the project, implementing the actual gameplay.
Asset loading and preventing memory leaks is important to consider as your app moves through different stages of the lifecycle (e.g. interrupted by an incoming phone call). The main game loop must properly separate input handling from game logic processing. Typical coding considerations emerged: how to share input states with game logic, how to update game state from input state and game logic in a clear and consistent manner, in order to save memory should a tile map editor be considered, should simple U.I. widgets be created and tossed in a sprite sheet or dynamically generated at runtime, how to manage sound effect triggering and stopping, debugging incompatible sound file formats, interrupting and transitioning between character states and matching sprite frames, etc.
After alternately zipping and slogging through all of the above, the month was nearly over and the game was basically finished so it was time to step back, soak it in and play it as "a game". My impression after can be summed up as:
Honestly? it was ok.
I felt it needed a little 'something more' to mix things up and keep play fresh so I decided to add power-ups. This ended up being more work than I initially thought; for example, a speed increase power-up messed with the basic physics code, a time-extended power-up messed with all of the timer-syncing logic, a screen-filling cloud mode required a tiling algorithm and so forth. All of these extensions proved to be a good thing because it forced some necessary refactoring of the code.
Even after the refactoring I still wasn't thrilled with the overall state of the code but it was nearing a week over a month and it was time to publish.
*https://www.deviantart.com/megamastero
Even after the refactoring I still wasn't thrilled with the overall state of the code but it was nearing a week over a month and it was time to publish.
*https://www.deviantart.com/megamastero
Next.