Project #2: Mars Commander

The game mechanic in Humongous Entertainment’s Moonbase Commander is great. It is a fantastic hybrid of strategy and timing-based skill that has sadly not been explored further. Let’s fix that.

Mars Commander

Definition

Each player controls a hub that can launch out new hubs or any number of other units and projectiles. When launching a new unit from a hub the player is given a rising power meter and needs to press “Launch” when they think the power meter is at a good spot. Moonbase Commander was a relatively long turn-based game for 1-8 players on a local network. This project is a fast-paced real-time head-to-head implementation of a the unit throwing mechanic.

To throttle each player’s abilities, each action will take a certain amount of energy with energy recharging at a standard rate. Players can speed up the recharge rate by deploying certain types of units.

Previous Work

I did some searching around to anything else (besides Moonbase Commander) that had this kind of mechanic in an strategy context with no avail. That’s either good news or something like passing a shrunken head on a stake as I walk onto ancient tribal lands.

Designs and Mockups

I went through the major design themes (Moon, Earth, Water, Space, Living Room) and, quite obviously at this point, landed on Mars. Though, should this go beyond the project, I should reconsider “Living Room Commander”. I’ll be trying out the cross-platform MonoGame  which is an implementation of the Microsoft XNA 4 API. A couple friends and I used XNA 4 to implement Pendulous and I thought it would be good to have some experience in the toolset for this one.

I really like the idea of a head-to-head real-time, so I’m going to set this up sit-down arcade style.

Commander Mockup

Each players sits at opposite ends of the tablet. At the bottom of the screen is their controls with their view of the world in the rest of their half of the screen. To the bottom right the launch button and power meter with the rest of the bottom of the screen showing the selected unit’s status and controls.

Tasks

This list, now that I look at it, is a little intimidating for the 24-hour limit. Bah, games are fun to write anyway.

  1. Render simple ground tiles
  2. 2-player camera with split
  3. Touch-based camera movement
  4. Rendering layers (ground, units, projectiles, overlay)
  5. HUD overlay
    1. Launch button
    2. Aim rotation
    3. Unit status and actions
  6. Units
    1. HUB
    2. Solar array (energy collection)
    3. Anti-air
    4. Shield
  7. Projectiles
    1. Bomb
    2. Missile
    3. EMP/Jolt (EMP off cord, Jolt on cord)
    4. Crawler
  8. Unified command queue (prep for network play)
  9. Fog-of-war
  10. Sounds
  11. Music (optional)
  12. Welcome screen

Future Work

Again, the “future work” category is more to remind myself what I should not be doing with my time even though it would super cool and super fun.

  1. More unit types and projectile types
  2. Multiple elevations
  3. Network play with more players (3+)
  4. AI opponents

Project #1: Who Goes First?

I have spent the last couple weeks on the first Hello, Program project and thought it was time for a status update. In preparing to implement a project, I currently go through five steps in planning:

  • Definition – Document what is my application trying to accomplish and, equally important, what is it not trying to accomplish.
  • Previous work – Someone has already done what you are trying to do. Consider contributing to an existing project if something already comes close.
  • Design & mockups – Choose a theme, both visually and functionally, then open up a paint program to get an idea of what the thing might look like.
  • Implementation tasks – My task list is less about understanding what needs to be done and more about managing my time. Being able to visualize how much work is left does wonders for keeping me from spending an hour doing something that probably doesn’t really matter in the end.
  • Future work – This is my parking lot for what to extend and possible next-steps. This lets me write these types of things down and get back to what I’m supposed to be focusing on.

Here they are for project #1: Who Goes First?.

Definition

The first project idea comes straight from my close friend and talented game designer, Matthew Moore. The pitch is to put a touch device (tablet/phone) in the middle of a table before a board game. Everyone touches the tablet and the application does some fancy randomization animation and picks who goes first. That’s it!

design

Previous Work

For this project I did searches for “who goes first”, “pick player”, and “random select”. I searched the web, Google Play, Windows Stores, and the iOS marketplaces and found five or six applications that try to accomplish the same thing, all of them ranging from tolerable to terrible. No where to go but up!

Designs and Mockups

For games and the entertainment applications, I find it insanely useful to define a theme and make sure everything you do can be related back to that theme. For Who Goes First, I chose a game show theme. I put together a few mockups to see if what I was thinking would translate to the screen.

Who Goes First prompt mockup

Who Goes First selection screen

Who Goes First reset screen

I also include explicitly deciding on the tools and platforms as part of design to keep myself from jumping around in toolsets just because its fun to play with those things. For this project, I decided to use Construct2 for development and target HTML5, Windows 8, and whatever else I can convince it to export to (i.e. iOS, Android, …Blackberry? Really?).

Tasks

Taking a page from agile development practices, I don’t go too far beyond a list in notepad or OneNote.  Here is what my Who Goes First task list looks like today:

Future Work

I have always found keeping the future work list invaluable. Again, I can write it down somewhere and then get back to what I should be doing.

futurework

You can see from the task list that I’m almost halfway through my implementation and each one seems to be taking an average of 1-2 hours. I should be able to have a usable something soon and I’ll see if I can figure out how to post HTML5 here.

–Adrian