BG2MAVG 06: Early Prototype Gameplay Footage

We really need an artist!
Contact us!
skype: arseny1987

BG2MVG 05: Level Design

In this series of posts, I describe the process of me making a brand new 2d platformer 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 iterating: that you do not need (in fact it is impossible) to create everything at once. We have created all types of movements for our avatar, and now it’s time to put them in the context of the levels.

Level design is the SECOND MOST IMPORTANT thing for a platformer, after controls. It’s not just the environment – it’s half of the gameplay and 100% of challenges and therefore difficulty curve. There are 2 aspects to the levels: visual representation and “gameplay” they can deliver. At this point visual representation is out of the picture , so we will concentrate on what our levels have to deliver gameplay-wise.

We do not have dynamic objects yet (besides the avatar, who cannot die yet), but we’ll start with the earlier levels, where they are not really needed. And we’ll concentrate on ideology of level design rather than on hands-on approach. I will emulate deadly stuff with red squares, and will build the level with the white cubes. Here are all the “assets” I‘m currently using.

assets list Small

Now, I have to confess – I’ve never done level design before. Ever. So I thought a Google search would help find some advice – and it did.

These articles are helpful, but they seem to ignore one important thing – the thought behind the level design.

The baseline

So, let’s think, what do we want from our levels?

  • We want our levels to be challenging. Players will have to die several times, before succeeding. This means our levels should be rather short (or have lots of checkpoints). Additionally we do not want to put the most hard challenges in the end of the level – it would be frustrating to be forced to pass the whole level, just to be able to practice on that last challenge.
  • We do not want tutorial levels (instead, we want players to experiment) for 2 reasons.
    • As soon as we start telling players what to do, they will stop thinking.
    • There is no gratification in doing what is told. It is much more gratifying to figure out stuff by yourself.
  • While we do not want tutorial levels, we still want players to constantly learn new stuff or improve skills.
  • We never want players to be guessing where to go next. The challenge is in the “how” to get there.

Having said that levels need not to be trivial and than there will be no tutorial, it’s important not to go too harsh on players on the first couple of levels.

Now, I can think of 4 types of levels:

1)     “Tutoring” levels. Levels where we introduce new mechanics to players. They have got to be designed in a way that immediately suggests how to be passed.  Obviously very first levels are “tutoring” ones.

2)     “WTF/A-HA” levels. Levels, where already known mechanics are presented in a new context, sometimes unexpected. These levels are actually the ones, when players will “get” the mechanic.

3)     “Mastering” levels. Levels, which are designed in a rather obvious way, and players know what to do, but due, most usually, to time constraint, such levels prove to be challenging. If “a-ha” levels focus on teaching players to know what to use in a particular situation, “mastering” levels will help to develop reflexes necessary to overcome challenges without even thinking, automatically.

4)     “I RULE” levels. Levels where players face already mastered challenges, designed to make players feel good about their set of skills.

Do I need to say, that one should be very cautious when mixing those types of levels in one? And of course it seems like a good idea to have some sort of rotation of those level types.

And of course all of these have limitations. You cannot have more “tutoring” levels that there are mechanics. There are only so much “a-ha” moments you can generate for a limited set of mechanics. “Mastering” levels are the most durable – there is always a possibility to impose harder time constraints or to “chain” more jumps together, but still, if there are no new mechanics, players will master anything and get bored.


Difficulty comes from various places. Some of this stuff came as a surprise for me, when I was playing in my “sandbox” level.

1. New context.

Let’s say there is a challenge, like this “spike hill”

Spike Hill

It’s a really easy one – all you need to do is jump right before the red “spikes”

Now, let’s say you need to do exact same jump but in a slightly different context.

Spike Hill 2

The jump is exactly the same, but this challenge is harder, because you do not know when to initiate the jump.

This simple example represents a rather useful technique which is perfect for “a-ha” levels.

2. Time  constraints

This one is pretty straightforward. Even most simple actions prove to be challenging, if they need to be done quickly.

3. Input context

This one is interesting. Pressing buttons is not that hard, right? Turns out it really depends on what you were pressing before, and what is your controller.

For example you need to perform a series of wall jumps. To do a wall jump, you need to press [jump]+[direction away from the wall] just as you hit the wall. So it’s a chain of [left+jump], [right+jump], [left+jump], [right+jump] etc. This is a lot easier to do on a keyboard than on a gamepad (no matter what you use – arrows or analogue stick). For at least 2 reasons:

  1. When pressing those buttons on keyboard, you have a dedicated finger for the [left] and [right] button, whereas on a gamepad one can use only a thumb
  2. It’s close to impossible to hit wrong direction, but it’s really easy to press [left+up\down] on a gamepad.

Of course there are cases when gamepads are better=)

It can blow one’s mind to perform such chain of jumps on a keyboard, but is really easy on gamepad.


Our game is targeted for PC so we will keep that in mind.

The flow

Flow is this magic thing happening when you fly through the levels and you feel that nothing can stop you even if you die a lot=). I’m not sure if it really exists, but I think there are things which can help to achieve that.

The way I see it, when players fail, they feel frustration. But this frustration can have different origins: himself or the game. My job is to eliminate elements “frustration with the game”.

Here’s the example: let’s say you need to hold and release “jump” button for some time (like ¼ of a second) to perform a strong jump.  And there are 3 platforms to jump through (Upon? Over? Arrrrgh!!!!).

3 vars of jumps

Most players will press and hold “jump” button after they have already landed, and will keep on running unless they are at the edge and v01 is perfect for that case. If we were to implement v02 most players would be frustrated, because they would have to stop running in order to “charge” their jump (or will concentrate on holding the “jump” button and run from the platform). Of course, players can “charge” a new jump in the mid-air, but we have to teach them that, right?

So, v03 is a soft way to tell players they can optimize their jumping. A more strict way would be to destroy those platforms in some time after being touched by the player. And then we can finally implement v02 and maintain that flow.

Another thing to be aware of is dynamic objects. As of this writing we’re only beginning to design them, but they have got to be timed perfectly. There absolutely must not be a situation, when the player reaches some sort of a cliff, has no idea where to go, jumps down, and sees that there was a platform going towards him.

If there are moving “saws” or shooting objects, they’d better be “passable” at once (not saying it should be easy though). But coming to an obstacle and waiting for a window of opportunity for a long time is not fun. Especially if there is planned a “time run” feature…

OK, armed with these principles, I will create 4 first and really simple levels of our game. Here they are:

4 levels

Let’s recap:

  • “Tutoring” levels are better (at least for our game) than “tutorial” levels.
  • Levels should be built in a way that allows players to know where to go, but doing that should be challenging.
  • On every level players have got to become better at the game, learn new skills or improve old ones.
  • Each level should have a purpose in its core. Making players jump just for the sake of jumping is not what we want.
  • Most challenges fit only limited set of “purposes”.
  • Difficulty comes from unexpected places – the very same challenge can be easier on one controller and harder on another.
  • Players should not be frustrated with the game. If they fail they ought to feel that it’s because they are yet to get better, and more importantly give clues on how to improve.

Simple right? =)

This is it for today. In the next article I will show you current gameplay and we will talk about the story and how it can affect gameplay. Stay tuned!

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 and comment on it, we really could use some publicity. Thanks!

Good bye and we’ll see what happens next!

BG2MVG 03: Let’s Put Together the Prototype!

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).

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. 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:


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 this 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!

BG2MVG 02: Setting the Scope of the Game

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 they are described here. It could potentially be used as a guideline by someone who has never been developing games. Or you might be better off doing just the opposite of what I say=).

Hello everyone!

I have a confession to make – I promised there will be no hindsight, but there will be just a little bit of it. Truth be told, I came up with the initial idea for the game on 9th of July, 3 weeks ago (as of this writing). And the decision to publicly develop a game was made several hours ago.

So several first articles will be published every day and will cover first 3 weeks of development, and after that – no more hindsight, I promise.

OK, first things first – we need something to start with, right?

I can only guess how other people start developing games. Having read forums I am sure lots of designers tend to heavily rely on the story or setting and allow it to dictate mechanics (or just synonymize game and story, which is most usually wrong).

I know for sure, that one particular company prefers to pick a genre (in the most broad possible sense, like let’s make a game, where you have to kill enemies) and design an interface first. I kid you not – one of my first games was actually incepted like this: bosses told me “we need a brawler and we already have an interface ready, now make us a game to fit it”. As I am writing this article they are doing it again. Needless to say I strongly believe it’s as crazy as painting bricks and then building a house with them, so that a nice unicorn would emerge in the kids’ room.

And of course there is an option to start with the mechanics and allow them to be the basis of the game. I like this approach, because… you know…  games… gameplay=). Luckily I have something in mind.

Not that long ago (not until the day of this writing, actually) I was working on a clone of famous Transformice. I was bothered by the lack of mechanics it had (the clone), and having just read an awesome article “Designing An Awesome Video Game” by James Marsden (which is now my Bible), I decided to come up with a “toy”. It seemed to me that double jumps would fit nicely into a game about well… jumping and would complement existing set of mechanics and add to the gameplay, but my bosses did not agree. That happened on the 9th of July.

Still, I could not stop thinking about a game, built around this mechanic. My thoughts were approximately as follows:

  • Double jumps are fun!
  • But still, on their own they do not seem to have lots of variety…
  • What if avatar has 2 types of jumps? First one is easy to perform, but not very strong. Second is harder to perform, but is stronger. And players are free to chain them as they like. This should give some variety.
  • If avatars can jump off the air (aka double jump), they can jump off the walls or ceiling.
  • It seems logical, that jumping off the air is weaker, that jumping off the floor. Or wall. Or whatever.
  • And if avatars can jump off the air, players should have control over the initial vector of avatar’s movement, otherwise players will not have lots of control.
  • And if, let’s say, player presses DOWN+LEFT+JUMP in the air it totally makes sense to make some sort of a downward diagonal jump, but what should happen, if the avatar is near the wall? Or is standing on the floor?
  • What if that initial input contextually defines the “type” of the jump? As long as it makes sense to the players, it should be OK.

So here’s what I’m going to explore with this game – contextual jumps of various strength. No big surprise, it’s going to be a 2d platformer!

Now, the mobile market seems hot, but I have no idea what tablet games look like, let alone how they work (can you imagine – my phone still has buttons and I have had iPad in my hands no more than 5 times). And it does not seem very suitable for our mechanics (well we could define movement vector by performing swiping motions, and stuff, but the timings of said jumps would be REALLY different from what I imagine. And of course there is running and there are 2 types of jumps and screen != keyboard…)

I’ve played PC games for the better part of my life. I know keyboard and mouse. So I shall design for that. Of course, I’ll do my best to adapt the game to gamepads or even touchscreens, but they are not what I focus on.

Now, about difficulty of the game and its audience. Well… lots of people say “you are not making a game for yourself” and I agree. Others advise just the opposite, and I agree as well. So I will be making a game I’d like to play (like most indies, right?) but constantly aware that it should be attractive for adult male experienced gamers. Just like SMB (which is a huge inspiration, BTW).

And I’ve been playing with Unity for a long time, and it’s free  and friendly and has all the necessary stuff under the hood  and UDK is a complete overkill so that’s what will be used to make this game =)

Let’s recap:

  • We (I mean all of you and I) are making a 2d platformer
  • There will be no killing enemies
  • There will be lots of jumping
  • We target PC, Mac and Linux. Because of the keyboard=)
  • It will not be a casual game. It will involve dying and learning not to.
  • It will be powered by Unity
  • I have no idea what the setting will be. I hope that mechanics will tell me the story. They usually do.

In the next article you will meet this game’s programmer, who happens to be my brother (so far only 2 of us are actually involved in making this game… besides you of course) and we will create first prototype of the game!

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!

BG2MVG 01: A New Start

Hello everyone.

It’s been only couple of hours since I quit my game-designer job in a successful company which develops games for social networks.

So, I’m here to make an announcement – I’m going to make a game. My guess is that you are not excited, are you? Well if I were Cliffy B or Phil Fish or someone remotely famous you might care, but since nobody knows me, why would you, right? Here’s the catch – I will walk you through the whole development process, from start to finish (regardless of what kind of finish it is going to be).

Together we will discuss everything (yay, transparency) – idea, core mechanics, prototyping, iterating; we’ll settle on the “feel” of the game, it’s story, visual presentation; I’m going to submit it on Steam and create an IndieGoGo campaign and share this experience with you; I will try to talk to you, to press, or maybe even to Team Meat (if I have the stones to do so) in an attempt to build a community, and you will be watching and participating, if you wish to do so. And the best part – no hindsight (maybe just a little bit, but not for long).

I will be doing lots of things I’ve never done before. Like all of the stuff after the “visual presentation” part. So there will be mistakes – and therefore lessons.  It’s like a reality show, but about games. Of course I do not want to tell everything – some things are boring, and some will spoil the fun of playing the game. So I will try to be transparent, but avoid spoilers.

Interested now? Subscribe to this blog to be the first to know about new posts.

In the next post we will come up with an idea, choose a suitable genre for it, define the target platform and audience and pick the engine (spoiler – it’s going to be Unity). If you have not yet subscribed to my blog, now would be a good time. Also, feel free to comment on this post, and do not forget to share it to your peers=)

Stay tuned and we’ll see what happens next!

Black Cat Project 02: Postmortem.

As you might be aware several days ago I have launched the Black Cat Project. It was a huge success – Windows version was downloaded  4 times (including one time by myself). Linux version performed a little bit less impressive with only 2 downloads (again one of them was mine). Hardly a surprise as Linux is yet to become popular gaming platform. Anyway great success requires a postmortem so here it is!

But first a short list of Frequently Asked Questions!

Q: Really? Someone asked questions?
A: No.

Q: Are you an idiot?
A: God, I hope not!

Q: Are you serious?
A: About being an idiot – yes. About the game – no. It’s a joke.

Now, that it’s out of the way, to the postmortem.

It’s kinda fun to look at the project and remember that distant past when it was merely an idea and everything could have become completely different.

Some people create game based on the gameplay idea, some prefer to make the story to become game’s foundation. Of course the best way is in between but I based Black Cat on the core mechanic. Funny story, though I instantly settled on the mechanic, it could be a game of completely another genre. It could be a tamagochi-like digital pet. It could be an illustration of quantum entanglement nature, commonly known thanks to the famous Schrödinger’s cat. I chose the “find hidden object” genre though, mostly because I’m fairly familiar with its premise for every morning I have to look for my socks in a poorly lit room.

I figured that a game about my socks would not be an interesting one. Moreover I do not know any ancient Chinese quotes about socks so I went with cats. And this is how the Black Cat was born!

If for some reason you are interested here are some links:

Thanks for reading and have fun!