If you want to play the latest build before reading the commentary then scroll down to the end of this post.
PROTOTYPE 4 (BUILD# 0.0.5.0)
This time around I’m lumping a couple releases and discussing them together.
In the previous post I highlighted a few issues that I wanted to address next. These included a better feedback system for picking up and depositing energy and improved level design. However, as I hinted in that post, I changed my mind (though I partly address the latter issue still).
Mainly, I ended up increasing the number of players from two to four and putting in the rudiments of a proper “player/control” selection system. Effectively we see the emergence of the “Ugly But Functional Start Screen”, as I like to call it.
The New Start Screen
This control scheme allows the four players to set themselves up as they want. It indicates when game controllers are connected and players can decide which player slot has control of which of the two available keyboard control schemes. The “gears” icon allows a player to turn an opponent into an AI-controlled entity (though only placeholder AI at this point).
I went with this system because having it obvious to the players how many can participate, right from the beginning, is something I appreciate in the couch games I play. For a proper game I’d want this to look better and the icons I’m using are not very helpful. There’s also no tooltips or other instruction on how to set the game up. But the core functionality I would want, with a quick and dirty start screen, is all present.
The stock Unity controller system does not allow me to poll which controllers are active, so I kept it simple. If, on the start screen, there were four controllers “checking in” then four players will be spawned into the game.
As noted, if the gears icon on the start screen is “turned on”, then that opponent slot will be AI controlled. This first pass implementation only uses a wandering-AI however, so it does not attempt to compete with you. The AI improves a bit in later builds, though never becomes “shippable”.
After the first level is completed the player is spawned to a second level with some geometry. I have three or four level designs in place, as the player progresses.
I wanted to add a bit more interest into the actual levels and so I created a simple system that allowed me to spawn blocks in, on a grid. I actually created an area editor in Microsoft Excel, that generates the code required for the blocks. So a very simple system, but adequate to demonstrate a design feature that would heighten the player’s experience. In a proper game significantly more time would be spent designing proper levels, that encourage particular types of play, between the players, but these are just the test levels I whipped up.
Immediately though I started noticing some major problems… problems that would persist throughout the remaining prototypes. For one, the player can get caught on level geometry; a situation much heightened for the AI. Worse, the “energy balls”, once they start moving in later levels, often hang out under the geometry.
I managed a few other, minor tweaks.
For this build I took my first unofficial stab at balancing the point distribution. I had already implemented a fairly simple system that allowed me to tweak scoring parameters, but I had neglected it. During this phase, I appreciated the initial design and implementation work I had put into the system, because it made it fairly trivial to tweak point values.
Overall, powerups matter less now. I added them in a previous prototype but with the introduction of the energy-hauling mechanic, their importance is now diminished. (In many ways they should actually be cut, or radically redesigned, but I never do do that).
So, most of the point scoring comes from the “Hauler” system, itself, now.
To fine-tine this in a later build I really should run some simulations and start comparing results of “poor play” versus “perfect play”.
You will notice that if you are playing through several games, each time you return to the start menu, your level count resets. (That is, if you made it to level 5 and then return to the start screen, and play another game, you are back on level 1).
This was an intentional design decision.
I decided that a return to the start screen meant that new players were coming into the game or an old player was leaving or the group had decided to add an AI opponent. So I made a decision to reset scoring and level progress, to level the playing field. Everybody was starting off fresh, making it easier to compare scores and progress.
I could have given players the control of this, but decided I wanted to keep the interface simpler without adding confusing options.
Again, improved sound and graphics are top concerns for later iterations. In addition, I know I must improve how entities interact with the newly added level geometry. I want AI to avoid the walls, for example. In general, there’s a lot that needs to be improved with the AI and that will become a top priority for the next build.
As is usually the case, newly added features from one build need clean up and refinement in the next build.
At this point in development I was starting to run out of time to work on Hauler (busy with a new novel), so the number of hours spent on it each month became significantly reduced. I had also lost interest and did consider abandoning this prototyping exercise. But I feel it is generally important to finish what you start and though I knew I wasn’t intending to ship a proper game, I did want to have enough material to write a reasonably informative “design summary” (i.e., these blog posts). So I stuck with it.
Or play in browser.
Please let me know if you have any questions about the prototype, or suggestions for it.
From time to time I’ll be releasing these “Hauler” updates and other design goodies to my newsletter a few weeks prior to publishing them on my blog, so if you want to stay up to date with the latest and greatest, I encourage you to sign up for the newsletter.