As I write this, my Production 2 team and I are hurtling towards a major deadline, what we at Champlain College call "Midmortem." On Friday, we will present one of our prototypes from the previous weeks, with an extra weeks worth of work, to the entire Production 2 cohort. That's meant lots of meetings and design discussions.
As a programmer, I've learned those discussions often require consistent communication, and can sometimes result in shifting the goal posts for a feature. For me, the lead up to Midmortem has been all about iteration. For this post, I want to specifically discuss iterating on the movement in, Reboot, our game about a roller skating CRT.
For our initial prototype, the movement in Reboot was implemented using Unity's rigidbody physics system. Movement forwards and backwards was handled by adding force to the player object. Turning was handled in a similar way; the player could use the triggers to rotate the player model, and the rigidbody would lightly add force in that direction. These two player interactions, when coupled with a more realistic physics model, gave a more gradual sense of momentum, acceleration, and eventually speed. That was one of the issues with this first iteration of player movement. The sense of speed we envisioned was did mesh with the reality of moving through the game world.
So we went back to the drawing board. We came away from our initial pitch knowing we had some work to do build a better, faster, and more fun movement system for the player. Our first meeting after we decided to move forward with Reboot focused a lot on turning the QA feedback we received into a better, more fast-paced game. Based on our feedback from testers and our initial pitch in class, we decided to move our movement system in the opposite direction. We decided that realism should be a distant second to ease of play, a sense of speed, and above all fun.
With that decision, I began to iterate on the slower, more realistic version of our movement system. Unity's rigidbody system would still form the basis of our movement, and turning would feel relatively similar, but it was clear we wanted more immediate, snappy, and arcade-style movement. This meant moving away from using Unity's AddForce function and
towards simply adding values directly to the velocity of the player object. This resulted in movement that accelerated almost instantly. It also meant that the character was easier to control, as the immediacy of this type of physics interaction meant players could more reliably dictate the character's movement and direction. The process of building the movement system, testing it, and then reworking it was an invaluable experience. The power of iteration in game development is becoming much more clear to me. Through iteration, my team was able to continue building a game that strives to be engaging for players.