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: Post-mortem

For the project post-mortems I will start with a template of two questions (“What went well?” and “What was terrible?”) and at least three actions (“Start”, “Stop”, and “Continue”). That was easy – on to it!


What went well?

Guiding Principles – The 24-hour cap was just about perfect for this project and did a great job in keeping me from rat-holing on inevitably unimportant details. I was fully expecting to rev the Guiding Principles in the first few projects, but I think I’ll keep them as-is for now since I they worked very well for Project #1.

Construct 2 – Construct 2 was a great 2D simplified development environment. Since I wasn’t making a game there were a lot of things I didn’t dive into. But! For coming into the system mostly cold, I was able to get up a going and making something that didn’t totally suck in not very much time. Self-hi-fives.

Releasing – I learned a ton about how the Windows, Android, and iOS independent publishing works.

  • Windows kind-of cares about what you publish and that you’re not an techno a-hole. Also, they very much care about your application having a somewhat real privacy policy, even if your application doesn’t use anything on the device except for local storage and the screen. Some one (a person!) told me this a number of times as I was submitting package updates to publish.
  • Android does not give a shit what you publish.
  • iOS will let you do everything you need to publish from not-a-Mac, except upload the binary. You can MAKE the binary, TEST the binary, and PACKAGE the binary all on a PC. Oh, do you want to upload the binary? You’ll need to buy a Mac and download XCode because we hate kittens. I’ll be bitter about this until I borrow a friend’s Mac and upload the stupid thing. I realize I’m complaining in the “What went well” section, which means I realize this is mostly a personal issue.

Work/LifeWork Balance – A hole I have dug on more than one occasion is overcommitting myself resulting in my internal thread scheduler thrashing like an angry monkey on speed. In this case, since I have deliverables and a time frame and a freaking blog, it is easier to say “no” to other projects so far. Or even better, I put the potential project on the backlog for Hello Program and will prioritize it so that I am only actively working on one moonlight project at a time. This kids, is what I’ve been told is called “growing up.”

What was terrible?

Cross-platform Performance – Something between Construct 2’s HTML5 exporting to Windows Phone and Windows Phone 8 HTML5 rendering resulted in garbage performance. I’m not sure if this was something in Construct 2’s inefficiencies or in Windows Phone’s IE JavaScript engine. Since I have no intention on diving into either, I will leave it at that. It seems to work okay if you point your Windows Phone to the web version…sometimes. Sad face since I generally love everything about Windows Phone otherwise.

Art Assets for Publishing – Forty-five is the number of individual icons, logos, and splash screens I had to make to publish into each of the marketplaces. Forty-five! In the worst offense, I had to make icons that were 70×70, 71×71, and 72×72. It’s not like a super big deal but I definitely spent a solid our of the time spent in publishing resizing and adjusting and aligning all the stuff for these assets.

I can't even...I mean honestly.
I can’t even…I mean honestly.

 

Start Stop Continue

START using VisualStudio.com, because it is great. OneNote is also great, which is what I used for work tracking in the first project. The theory was to have as minimal as possible project management overhead, which worked out alright. But even for a single-person constrained project as this, I was wanting for some straight-up work item tracking, bug tracking, and a scrum or agile task board. I ask and technology shall provide.

STOP using Construct2. Don’t get me wrong, Construct 2 is great and I will sing all the praises for it. But! I am a software developer and there were a number of things I had do weird things for because the coding interface is basically super-good pseudo-code. I will return to my C/C++/C# roots for the next project.

CONTINUE using the time log. I originally started the time log just to make sure I didn’t go over the 24 hours. What ended up being more useful was looking back at how much time I’ve spent doing items such as design, planning, implementation, bugs, redesigns, what-have-you (I posted a near-final time log here). If the 24-hour constraint abstractly kept me on-task, the time log is a concrete implementation of the idea. Each day I could look back on how I was spending my time and quickly figure out if I felt comfortable continuing on something or if I needed to move on.


Ideas for project #2 are in the cupboard, now it’s just time to decide what’s for dinner.

 

Project #1: RELEASE

Who Goes First?

“Before starting any game, you need to answer the burning question: who goes first? Use this app to cut through the bickering, the bribery, and the brouhaha. It doesn’t care who is youngest, who shouts loudest, or who won last. Turn it on, touch the screen, and leave the hard decisions to us.”
Who Goes First?
Save yourself the trouble of deciding who goes first, and leave that determination to the experts.

(touch screen highly recommended)

Windows 8 Store

Google Play

Web

Direct downloads (.ZIP files):
Windows
OSX (untested)
Linux 64-bit, Linux 32-bit (both untested)

(Thanks and appreciation to Matthew Moore for the mechanic design, wordsmithing the descriptions, and constant invaluable support.)

Project #1: Complete! Mostly!

Who Goes First is complete! On-time, all major features are in, I feel there’s a pretty good end-to-end story to at least publish to the website here. After showing it to the Principle Quality Analyst (i.e. wife), I should improve the info text explaining how to dumb thing works and some of the other texts before publishing it out to any marketplaces.

In the coming week I’ll run through a post-mortem on Project #1 before diving into Project #2. For now, and not that this is particularly interesting, but for posterity here is what the time log, task list, and future work lists ended up looking like:

Time Log

Who Goes First Time Log

Task Lists

Who Goes First Task List

Who Goes First Future Work

 

Project #1: Eighty-Twenty

The last 20% of a project takes 80% of the effort. In the case of project #1, I have completed 19 hours with 5 hours remaining leaving me at the last potential 20%. The effort necessary here is not technical or even availability driven, it simply hard to prioritize and just do. It is an 80% of a spiritual effort that must be conquered in order to get past what marathon runners call “The Wall.”

Twenty-four hours is hardly a marathon. Who Goes First has shown me that, no matter how small the project, the spiritual wall is there. It is the design.

Do we shelve the git repo and put it on proverbial shelf? NO! Do we start something new and come back to it…”later”. NO! We take our laptop to the motorcycle rally and after 400 miles a day of iron-butt riding we pile up back-support pillows on the hotel bed, open the IDE, and finish the damn thing by the end of the week. I write this here and now as a promise forged in electrons to myself and to belief in a world where sanity may prevail.

 

(7/28/2014) UPDATE: Success!