Hey guys! Welcome back to part II of our design to development discussion! We have our lead developer Philip, here to discuss implementing the design into development!

So, we’ve talked about design and now we’re on to development.

Since being able to move is probably the most important part of a racing game, that was one of the first things we needed to get done.

While that may sound simple if you’ve never made a game before you’d be surprised to hear just how many different ways there are to do that. Now, they’ve all got their own fancy, technical names so I won’t bore you with the details but we tried out one or two early on just to see things moving on the screen.

Eventually, we settled on a physics-based movement that would allow for controlled movement while also reacting the best to different obstacles. After that, we made the first (technically) playable version of the game. Though really that just meant we could move and didn’t fall through the floor or pass through walls, but it was a start!

Next up, jumping! 

Little known fact: the best part of a physics engine is that you don’t have to write your own calculations and code for gravity, because the engine will handle that for you. With gravity out of the way, the focus went to getting the jumping to work which turned out to be an easy enough task after we settled on a method for movement.

Since we didn’t have to worry about how things would get back down (that’s where gravity comes in) we just needed to get them up, and all that was needed was applying an upward force. Specifically, an upward force that depends on how long the jump was charged up for.

For our players, all that means is holding the button longer for a bigger jump. Easy. For design and development, it’s a little more involved. Someone has to decide all the little details (what’s the lowest and highest you should be able to jump? How long should it take to charge? etc) and someone needs to make it work like that (changing little numbers here and there and writing different calculations until everything works just so). Eventually, we got something we were happy with (and easy to adjust in case we change our minds).

That just about covers how design leads into development, but how about the times where development feeds back into design?

Sometimes no matter how much you brainstorm you’re just not sure how something should work, or which option would be better. At times like these, it can be useful to make a quick and simple demo version to get a feel for the situation and see what works and what needs improving. We call these little demos ‘prototypes’.

So, for example, if we’re not sure exactly how high you should jump, or just can’t decide if the camera should be at a 45 or 25-degree angle, just make a few prototypes and compare them.

That's all for this week as we prepare for our prototype, which you might get a glimpse of so keep an eye on our socials!

Out of context quote of the week: That's an array, isn't it? Yeah? See, I speak code - Olivia, 2021