Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
This post examines the reasons behind a major design change I made in my Unity Prototype and how I used an old dice game to decide how that change should be implemented.
When I started building my prototype I had a general idea of where I wanted to go with it. Unfortunately my initial ideas didn't pan out into anything I thought I could make fun. With this prototype I began the process of developing a rather different sort of core gameplay.
The components of the game remain similar to the previous prototype (placeholder-art spaceships with deadly trails) but the core gameplay mechanic has evolved changed completely. Overall, adding a point/scoring system in the last prototype provided some incentives for players to play. But I noted that these incentives were hardly sufficient (or fun) on their own. What I needed was something interesting for the ships to do. A better reason to compete. I needed a gameplay mechanic. At this point I could have moved in any direction. Here's two I considered:
Shooter. I could add enemy ships and utilize a hunt-and-destroy mechanic (or a "survive the onslaught" mechanic). Players could compete for the most kills.
Exploration. A non-combat element might be used that encourages the player to fly around and compete with the other player, in regards to finding point-based items. We have this to a degree with the existing powerup system, but an expansion of that across a map of some kind could be a possible solution.
Both of these I rejected because they:
a. Really strayed from my original objectives.
b. Would likely require split-screen play. As much as possible I wanted to stick with all gameplay happening on a single screen.
Additionally I added another constraint: I wanted to make use of the trails. Now logically there was no reason I couldn't just discard the idea but I thought the trails had the potential to add fun and flavor to the gameplay mechanic I selected. Given the limited amount of time I had to work on Hauler each month I had plenty of time between sprints to consider my options. Along the way I started playing some dice games with my kids....
One of the games was Pig (http://en.wikipedia.org/wiki/Pig_(dice_game)). This is a simple game involving a single die. Players take turns rolling the die and accumulating a turn score. At any time they can stop rolling the die and "bank" their score. The first with a total score of 100 or more, wins. However, if the player rolls a 1, they lose their current turn score.
So the strategy involves knowing when to bank a turn score. I always carry dice with me now so we can play the game while waiting in restaurants and the like; the kids really enjoy it. I even entertained my nephews and nieces one afternoon by playing it with them. It was fascinating to watch them evolve various strategies. They might see me gamble and win and then on the next turn all the kids really gamble... rolling long streaks. Some of them set turn totals that they aimed towards and once they were reached, they banked. Others just kept rolling and rolling and rolling and never banked (these kids never won).
When you play such a simple game, it lets you really focus on the gameplay mechanic and how different player types interact with it. I've used this banking concept in all the games I worked on but it was always buried and made more complex by its interactions to other gameplay systems. Seeing it on its own, made me realize how powerful the concept could be. Could I add banking to Hauler?
Indeed I could. If you have played the latest prototype you will notice a glowing green energy orb. Fly your ship over that and it will siphon some energy from the orb. Now you can deliver it back to your home port (the one the same color as your ship). When you do this you score points. As energy is removed from the orb, it will get smaller and smaller. Once the final load is removed, it disappears and once that load is delivered, the round ends and a new round begins.
The banking concept, as described in the Pig section, above, comes into play in the following way: The more energy you absorb BEFORE delivering it to the port, the higher your score will be. You score much higher if you have drained the orb completely and are delivering all its energy at once to the port. However, if you take any damage at all (including hitting your own tail) the energy pops out of your ship and becomes an energy orb again that an enemy can now steal.
I found that it was a bit too easy for a poacher to swirl around the energy source and just steal all the energy so I put a time delay into place. Once energy is taken from the orb, it deactivates for a few seconds* before more energy can be taken from it. This, I feel, enhanced the banking mechanic as well because the player was now given another incentive to deposit early (instead of saving up for a larger pay-out). Braver players ,who are able to survive a few seconds until the energy returns, score more points. *The delay is random. I like a bit of randomness in things like this because it keeps players from falling into routine.
Because I was not certain whether my "haul it" idea would pan out, I kept the original gameplay in. Players can start a "classic" version of the game from the main menu where they just attack each other. The Health system that I added in the last prototype has been removed from the "haul it" version but left in for classic mode.
The gameplay change was the largest feature introduced in this build but I also added:
Music. I found some music tracks that are free to use (with attribution). I hooked these up with the Dark Tonic -> Master Audio. This system made it fairly easy to set up playlists and whatnot. I only added a couple tracks (which turned out to be a good thing because music certainly bloats the file size of a small game like this... a fact that causes me some headaches in a later prototype).
Those of you who have been reading this series since the beginning are probably wondering at my approach to the design for this game. Why didn't I plan my core gameplay from the beginning and then stick to it? The truth is that when you set out to build an unfamiliar game you need to be cautious about adhering too rigidly to your original idea. (This is not true when building a sequel or creating a game based in large part on a previous game's mechanics.) A new gameplay element makes it harder to design for all the repercussions of that feature.
A robust design document, attempting to anticipate all the consequences, would likely be invalidated after the first prototype. And in this case I did have a core gameplay element I wanted to build upon... and it failed. At that point I could have abandoned the concept entirely but I decided to stick with it and the last couple prototypes were experimental as I worked my way towards a proper gameplay solution. A flexible production schedule, a small team, and realistic management expectations, allows a team to prototype in this way.
Again, the obvious stuff like final art and sound is missing. But in addition to that, after a few minutes playing to refresh myself with this build, I noted the following:
The game lacks feedback. The user should understand clearly when they have picked up more energy or deposited it. I tackle these issues in later sprints and it makes the game a lot more enjoyable.
The current level design is boring.
SPOILER ALERT! In the next sprint I don't actually fix many (any?) of the issues I noticed in this sprint. Instead, I add a new feature. I have two kids. They were constantly getting annoyed at me when I would playtest this game with one or the other. One kid always felt left out (and yeah, I'm not going to give up my turn at the controls!) So... I wanted to increase the number of possible players from two to four. In the next update I'll explain how that went.
You can download the PC version here. Or you can play it here, in the browser.
If you play the prototype and have some thoughts regarding it, let me know via the comments and we can discuss them (or I can incorporate the discussion into a later post).
Also if you are the impatient sort and want to see the latest (still pre-release build) I have posted the alpha on Kongreate.
Read more about:
Featured BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
