BG2MVG 04: Two Weeks of Iterations

In this series of posts, I describe the process of me making a brand new video game from scratch. You can read the intro to this series here.

Also, this series is called a “guide” but it does not mean anyone should do things the way I am, it’s just the description of my action, which can be used as a guideline for someone who has never been developing games. Or you might be better off doing just the opposite of what I say=).

Hello everyone!

In the previous article we’ve discussed prototyping: that you do not need (in fact it is impossible) to create everything at once and taught our avatar to run and do some jumps. Now it’s time to stuff our prototype with more stuff – all the motions we’ll have in the game… but, of course, in small steps!

To make those steps we need a plan – the clearer – the better. So let’s stop and think (and that is what I was doing for a couple of days – thinking, planning and writing an exhaustive document, specifying all the jumps, states, and transitions between those states).

Of course I cannot fit a long document into this post, but I can really brieafly summarize it:

• Player can press [up], [down], [left] and [right] and any combination of those buttons when performing a jump, and this will set the initial movement vector (we call it “type” of jump).
• Avatar can be either on the floor, at the wall, near the ceiling or in the air (we call it “proximity”). Every “proximity” has its own set of jump “types”.
• There are 2 “strengths” of any jump – weak and strong, and it depends on the button pressed by the player.
• At the very top spot of a jump, there is a small zone of “perfect timing” – if double jump is performed at this moment, the jump well be extra-strong.
• Players have limited control over avatar’s movement in the air.
• Avatar can be at various states: run, jump, fall, attached to a wall or ceiling, and all transitions between those states.
• And there are “conditional movements” like a small lunge after avatar hits the wall.

In order not to make my life a living hell, Dan created a “motion map”, which is an awesome asset to plug in other assets. It contains slots for 190 movements and when empty it looks like this.

It might seem like a very complex thing that cannot even fit into one screen, but it really is not. Even though I thought every motion would be a pain in the ass, after like 3 or 4, I could clearly see a “guideline” system and all the planets did align without me forcing all those jumps into a system. This is a good thing – every jump is logical. You can easily guess which jump should be stronger, and which one should be faster, and they really are intuitive (at least for me… ah, playtesting will tell).

As I gradually started filling in those slots, I was creating a level, to test the motions and make sure they felt good both individually and together with other jumps. I tried to find the limits of every jump and find some unexpected ways to use them (sometimes I did, sometimes – not).

What I did find out is that our “run” motion is no good, despite the fact it felt OK before. The thing is, our running speed was not really slow and it felt good. But it was close to impossible to travel small distances. So we had to make avatar accelerate, in order to allow small precise steps. Which led to a small problem – when avatar lands from a jump, and has some speed, it should have kept its speed and keep on running. But since “run” is a different state from ‘fall”, avatar would stop and that speed up. Of course it was easily fixed, but the point is, chain reactions happen all the time.

Now, coders use debugging tools all the time. To properly evaluate my jumps I had to construct my own debugging tool (which is really easy to do). A simple trail can be done in like 40 seconds, and is EXTREMELY useful. It makes it extremely easy to see the path of the avatar, and compare jumps or create levels.

It took me 2 days to create initial jumps. And another week (6 hours a day, after daily job) I was tweaking their parameters but as a result I am really happy with the better part of the motions available to the avatar. And that was our first main goal – to have a good responsive controls.

Let’s recap:

• Before diving into iterations you need to have a clear vision (on paper) of at least relevant features, or better off whole game. Iterating without a plan is like walking in a mine-field.
• Iterations are your friend. You cannot do 10 days of tweaking in just one go.
• Even a good plan does not mean you will not have to alter something you thought was ready and working. Do not be afraid to change stuff that does not work. But be cautions – the more features you have, the harder it will be to re-do stuff.
• Not really the “iteration” –related but still important – play with your mechanics. Try to break them. Try unexpected things. You might stumble upon gold this way.

This is it for today. In the next article we will talk about level design.

If you think this series could be interesting and have not yet subscribed to this blog – feel free to do so. Do not forget to share this post to your peers and comment on it.

And we’ll see what happens next!