MockUp, Design and Progress

February 13, 2011

So I’m finally done (for now) with my personal website so I can commit more time to my project! Joy! This week I plan on completing the first basic tutorial in my book, a simple Breakout clone, and starting work on my own game. Thankfully I don’t think my game will require some of the more sophisticated aspects of the SDK. If I could get as far as incorporating all my libraries, such as the physics library and such previous posted, I’ll be on track to present a basic level of my game with dynamics incorporated for the end of the month alpha.

In the meanwhile, did some quick prototyping of what the final game might look like, as far away as that is at the moment. This design was fairly intuitive and off hand. I’d like to explore some alternate layouts with some basic wireframe mockups as the week progresses. I really like the idea of there being a radar view and a “real” view but for now I’ve restricted my aims to just one. This mockup shows what the “real” view might look like.

Initial Annotated Mockup

The radar view would be accessed through a gesture, probably a two finger swipe across as the design sketch shows. The radar view would essentially be an overall look at the level so the player can see all planets at once in order to set up combos and chain reactions. As seen in this mock-up, the amount of planets that could be on screen a be identifiable is rather limited. Granted, some pinch actions and single finger slides could be implemented to zoom and pan the camera respectively. Again, however, I’m trying to keep it simple for now.

Note, I’ve included four tools/weapons and I feel this will be the extent of the options in the final game. I’ll post a design document later detailing these interactions but for now I’ve settled on Tether, Frag, Slow and Split. Tether attaches two planets together thus causing them to interact, spin out of control and generally cause havoc on the system. This tool is the one I’m most skeptical of since how it will affect the planets in a dynamic physical system is impossible to know till implementing it. I feel it may just lead to one tethered planet immediately crashing into the central sun, causing the other to spin off into space which would be undesirable. In fact, many elements of the game may ultimately need to be changed as their actual dynamic behavior is unpredictable. Perhaps making a simple dynamic system to simulate these interactions in a environment I can do so quickly in will be called for. Another possible solution would be for tether to slowly draw the two involved planets together, leading to their eventual collision along with any other poor orbiting bodies in the way.

Besides Thether, there are the surer three. Frag fragments a planet into many smaller parts. This tool will only work, however, on the inner solid planets. Obviously a gas planet, such as the outer blue one in the mock-up, could not be fragmented. Slow slows down a planets orbital velocity causing it to careen towards the central system star. And lastly Split splits a planet into two large chunks along its orbital path such that it forms to projectiles with a more eccentric orbit. To solve the mock-up’s puzzle above, we could use any one of these tools or multiple if necessary. We could use Slow on the gas planet and with proper timing cause it to crash into the smaller planet. We could tether the two together causing them to spin out of control and eventually crash into the star. We could use Frag on the smaller planet, timing it such that the fragments crashed into the gas planet thus destroying it. Or we could similarly use split in like manner.

This brings me to a primary concern: the tools must be different and unique. Split and Frag are a bit too similar for my tastes. While there are ways of differentiating them, for instance perhaps split causes the two halves to jettison in opposite directions, such efforts seem contrived and unrealistic. Clearly, more time thinking upon the player’s tools is demanded. I must simultaneously begin implementing the dynamic orbiting systems.

I’ll try and post a radar view mockup this week as well. It would essentially be a neon digital version a la the tools menu on the bottom of the mockup. This pix elated view would allow for greater vision and control while requiring little no additions to the game engine itself as its simply displaying the game state information in a different fashion.

I’ve also included my initial, though meager, sketch of the game and the working sketches for the above mock-up. Ah how far we’ve come.

Leave a Reply

Your email address will not be published. Required fields are marked *