Unity Couch Game Prototype Part 1 (Hauler)

This is the first of my discussions on recent Unity prototype experiments.

THE IDEA

Up until Spring 2014 I had been tinkering with a couple different prototypes, including one that I had put a lot of time into and really enjoyed (developing and playing). But I came to the realization that these games were too complicated for me to pull off on my own (at least for now). I need to expand my working knowledge of Unity first. I decided instead to work on a simpler game and push it all the way to release -- even if it turned out to be a not-for-profit sort of activity. I had about 10 hours a month to devote to this. I went through my idea file and picked up on a concept that I had been thinking about for a while (really just a variation on an old game that I'm sure some of you will remember). I wanted a game that:

So the game design tagline became: "Each player controls a craft and smashes said craft into other player's crafts. The person who gets hit least, wins. Maybe."

TIMELINE

You should always set some sort of timeline for your final deliverable even if you never tell anybody about it. You need to know this, to help you build all the milestones leading to release. Sadly, I did not set such a date. Only recently did I make the decision that I would like to have the release version of the game out by year's end (so I could start work on the next couch game). Which (giving estimate inflation), means probably in February 2015.

PROTOTYPE 0

Prototype 0 features:

You can go play Prototype Zero here on the web. I realize it might be super duper engrossing and consume hours of your time, but please do try to return here to read the rest of the discussion.

ISSUES

Hey... you're back. What's not to love about that prototype, eh?

Despite its glaring flaws, the prototype does demonstrate my initial demands: a simple game concept that players could play against each other on a television screen. But let's delve into some of those glaring flaws.

Movement Controls

The rotation and "always moving" controls are fairly natural for this type of game but my kids were immediately turned off by them. They wanted the up arrow to move them up, the down arrow to move them down, et cetera. They found it hard to control their craft (yeah, I know, that was the point!) Additionally the "tail" logic was wonky -- you sometimes hit invisible trails and other times no collision is detected. Still I figured I could make this more fun by changing up the controls. You can also press the spacebar key (or 'z' for player 2) to "jump" your craft... right out of the arena (this was probably the most entertaining part of the prototype).

Instant Death

There isn't actually instant death -- or any death in this version -- but I did play with the idea. But it really wasn't fun to have 2 second long matches and constantly restarting. I wanted prolonged games that were about basing the score on some objective. This will factor in, with later builds.

Boring

Again, this was merely a prototype, but it was clear here that I needed to start thinking about a gameplay angle for the game. It might seem weird not to have a more concrete idea of what this would be, from the start, but I approached this entire project kind of sideways. As I tinkered, the core gameplay emerged -- but not in this build or the next. You'll have to keep reading to figure it out (though I suppose the game's placeholder title might give it away a bit).

Visuals

Hey, I'll say it so you don't have to. The not-really-art sucks. And it still sucks, in the current build I'm working on today -- several prototypes past the one I'm showing you. (Though I think it sucks significantly less; I'll leave that to you decide later in this series). But right now my goal is to focus on gameplay and refine what I have, till I think it is as fun as possible given other constraints. If I felt this game could be successful (and I don't) I would invest in a complete art redo. We'll talk about this more, in later posts. When prototyping, don't hinder yourself (or waste time) by developing awesome assets. In all likelihood when you change core direction (as I did) said assets will only be tossed. Only with later stage prototypes that might influence whether you get funding, should you really start worrying about things like this, or in art-heavy projects, where part of the prototype process involves understanding how expensive the art assets are going to be to produce.

Spoiler Alerts

In the next post I'll delve into the many changes I made, but it should be clear from what I wrote above that I ended up gutting everything. This prototype really became an example of what I didn't want to do -- despite my initial thoughts. The biggest changes coming up involve the control systems.

Summary

Well that's it for now. The next post will be available shortly, along with an improved prototype to play around with.

If you have any questions (about this or game design in general) please post comments. I look forward to hearing from you! Again, here is the link to the web demo.

A PC version standalone can be downloaded by using the link from the original post, on my blog (scroll to the bottom).