It is at this point where I most came to realize the truth of every game I could think of making being too big. There were several features that weren’t entirely required that I didn’t get a chance to add (though I plan to discuss them), and some required ones that didn’t quite work in time for submission.
For this demo, I went for ‘strong and aggressive’ and ‘weak and exhausted’. Yes, I know ‘exhausted’ isn’t one of the states from list one, but I felt this worked better with the general idea conveyed by the single avatar. On the general level, the avatar is a somewhat bulky figure with a battering ram, and the action performed by space is charging forward. Understandably, this makes turning much harder, and only allows forward movement. If you play around with this one issue in implementation becomes obvious: decay animation curves can start before attacks have fully finished ending, which, due to the decay starting at a value that matches the end of the attack curve, results in an awkward lurch forward. The intent is simply for the avatar to take some time to build up momentum to show its bulkiness. If a walking animation (another thing I didn’t have time to figure out to comfortable levels) with the legs had been implemented, the avatar would run forward in a manner akin to a quarterback.
The avatar yells (despite my attempts finding a better yell for charging, this is all I got) and causes dust behind him as he begins to charge. If he hits a wall, he stops, but the screen shakes to show the power of the impact. If he hits a block, the screen also shakes, and despite the block’s size it’s pushed back by the force. It also takes a considerable time to stop charging, which would have been skidding to a stop to display momentum. The blocks glow red while in the aggressive state to show that they’re a viable target. Even holding the spacebar down without moving causes the avatar to prepare to charge, bending forward and pushing the ram forward.
The other state is weak and exhausted. The blocks still glow, but do so less, and the avatar doesn’t hold the ram or his own body up. He doesn’t take as long to build up, but this is partly because he never gets that fast, and pants heavily with movement. Space attempts to charge in this state, but needless to say, it doesn’t really work: the avatar is too tired and just stumbles forward in the attempt. The intended feel here was something akin to a stamina bar connected to the more aggressive state – if you run out of power from charging and ramming things, you end up like this until you rest temporarily. I never had any intention of actually implementing this into the demo, admittedly, but that was the initial idea that spurred making it this way.
There is an admitted lack of polish (only the blocks glowing display this). This is largely due to the fact that I couldn’t bring myself to use the music I was planning to in good conscience. The initial plan was to use two parts of the same song; one a more bassy and powerful part, and the other quieter. This plan was utterly ruined when I realized what Unity’s compression does to songs (in other words, it sounded too terrible for me to put in). While the code is present for swapping tracks or turning it off, I didn’t put the song in. For those curious, it’s https://www.youtube.com/watch?v=q8SFNeuY8K0 , with the loops being from 1:48 to around 3:03 for the aggressive state, and 5:44 to the end for the tired state. Anyone familiar with audio compression can probably easily tell what went wrong when trying to use this with Unity.
In short, the main missing features were the leg movements, keeping Decay curves from starting before Attack curves are done, and the background track. There are no textures either, but I couldn’t think of any real way to implement them that provided what could possibly be called an improvement in this blocky of an environment.
Continue reading Thisisaname – P1 →