Sponsored By

Beginner's guide to making a video game: Let's Make a Prototype!

In this series of articles I'm describing the way I'm developing a platformer. The topic of this article is the first, most simple prototype of the game.

Arseniy Shved, Blogger

August 4, 2013

6 Min Read
Game Developer logo in a gray background | Game Developer

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 previous article we’ve discussed the basics: what kind of game we’re about to make, its main feature and gameplay element (which is jumping), and what devices it is targeted for. Now it’s time to finally do something!

Just a quick intro. My brother’s name is Daniil (his blog). He is a very experienced programmer, though he has never been developing games or working with Unity he's the best colleague I've ever had. I approached him on the 14th of July and pitched the idea to make a game. He did agree to help me, however he has a science paper to write, so it’s possible he will be unavailable at times. So he's in charge of coding.

Anyway, in 2 days of getting to know Unity, we decided to actually get started. Some people tend to start from graphics. After all that’s what the players will see, right? So they start drawing some objects they expect to be in the game, units and stuff (again, sad personal experience). Of course sketching is a very appropriate thing to do during the early stages of development, but no visual asset you create will be in the release. I like to feel the game as soon as possible (and neither of us can draw a straight line with a ruler). Our first scene looked like this:

01 - prototype

Not very exciting, but better than nothing (please, do not forget that this blog is intended to shed some light on game development for those who are curious what’s it like, but have never been working in the area. And it's not Gamasutra exclusive=) ).

The way I see it, the single most important thing for a game on hand-eye coordination is it’s controls. So that’s what we will focus on and that’s what I will be working on and tuning until I am completely satisfied with it. Having a ball primitive to jump over gaps must be fun, even without any juice. I cannot stress this enough - CONTROLS ARE THE MOST IMPORTANT THING we need to do.

OK, controls. What should they do? Well, avatar can run and jump. And it uses only X and Y axes to do so.  And of course we cannot do everything at once, so we need to move in small baby-steps. That’s what our avatar should be able to do – walk. Or run. Or whatever.

This seems fairly simple, but there are always options:

  • How fast should it move?

  • Should it have inertia (Mario-style) or not (VVVVVV-style)?

  • Should avatar’s acceleration rate be same as its deceleration rate?

We decided that avatar should move with a constant speed as long as movement button is pressed and instantly stop if it is released, because this option is the most intuitive for the player. We played a bit with movement speed, and when we were OK with the result (of course we knew it will be a subject of many tweaks and slight changes, and most probably it’s not over yet), switched to jumps.

The most basic jump there can be is an upwards vertical jump. Thanks to Unity’s built in physics we got a basic jump very quickly. Fast-forward couple of hours, I had a system that allows me at any given time of the jump to alter its velocity (actually it’s “gravity”).

With its help I've created several variants of this jump.


In case you cannot see the GIF properly, click here to see the comparison.

1st and 3rd variants are the basic Newton jumps, but they differ in time, required for the avatar to reach its peak position (0.6 sec and 0.45 sec respectively) 2nd and 4th variants actually change their gravity on the fly. The initial acceleration is the same, but at about 85% way up 2nd and 4th variants significantly slow down. They spend a little longer “on the top” and fall faster.

OK, in a vertical jump 3rd and 4th variants do not differ THAT much to make it worth a trouble. However, we were forced to implement this system because the second most basic jump there is – a long “horizontal” jump was just awful. It felt like avatar was swimming through jelly. Now it looks cool and natural – at first avatar flashes forwards and a bit upwards, then it hovers close to peak height and gently falls down.

By the end of that day we would have a system, which allows me to specify basic jump parameters (initial angle, peak height, time to reach top position, changes of gravitation force) and 3 jumps to apply said system to (avatar however didn't even know how to fall at that time) and avatar could run=)

02 - jump editor

But there were 2 problems:

  • Avatar was constantly running from camera’s line of sight (quick copy-paste of some script from the Internet fixed this problem nicely. Of course one day we will create our custom camera behavior, but the most simple tracking script is sufficient at least for now).

  • When the script was ready, in was hard to say if the avatar was running or not, because the floor had no texture. It was my time to shine and demonstrate my awesome drawing skills:

t_Floor

Let’s recap:

  • Start with the most basic mechanic, like running.

  • Do not try to do everything at once. Our avatar was taught to fall down if there is no floor under its... erm… feet only by the end of the first week of development.

  • Fine-tune existing controls until they are perfect. Yes, as new features will appear, controls’ preferences will most probably change, but at any given time they must be perfect (considering, of course, available functions).

  • Although sketching is a good idea, do not build “perfect” assets. Whatever is done at this point will never be in the final build. Ever.

  • Small things matter. That tiny part of a second at the peak of a jump really can make a difference, even if you can’t tell it at once.

  • There are always options. Even if something seems as simple as running, it never is.

  • My drawing skills are awesome!

In the next article we will talk about iterating our jump system as I will be creating about 100 jumps. Yeah.

So if you think this series could be interesting and have not yet subscribed to my blog – feel free to do so. Do not forget to share this post to your friends who are interested in trying to make their first video game and please leave your comments!

And we’ll see what happens next!

Read more about:

Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like