First round of playtesting

Today was fun. I put together 5 levels, waited for a lunch break and ambushed several co-workers. I watched them closely as they suffered through the finger-breaking challenges.

The purpose of this test was to determine if my core feature – the controls system – has the right to exist or it should be revised.

The first victim was discouraging. He had lots of problems as he could not see the basic logic behind what defines the jump. And even if he did try to do the right thing he failed miserably. It was a torture, not only for his fingers and ego, but for my eyes and confidence as a game designer. Not really surprising, considering that he’s not into platformers, but still demoralizing.

He said that it was kinda fun, but I know, for him it was not.


The metaphorical effect of my game on people.
Pic source: 

I approached my second victim with bad expectation, but there was still hope – I knew he’s a masochistic Super Meat Boy-and-like fan. Right away he started to experiment muttering “oh, I see” every 2 seconds. In just 15 seconds he got more understanding of the game than my first prey. He was good. Not in a way “he does stuff the way I expect him to do” but rather in a “I have a plan and I will stick to it and I will improve my skill” way. Yes, he chose actions I’d never say are obvious (and they are like 5 times tougher to pull off than the “optimal route” I planned), but he never got discouraged (despite or because of swearing A LOT). He obviously had fun during those 5 levels, and I had fun watching him suffer \ play.

When he was done with what I had to throw at him I showed him “the supposed way to pass some challenges” and we shared a laugh. “I love to come up with absurd solutions and succeed with them”, he said not without pride.

The good news is that as soon as he grasped the principle the controls work, he became pretty excited about it and totally made my day.

The third playtest was not planned, but my colleague saw us playing and got curious (poor fella), so I decided to collect more data. Well, he did weird. He struggled with the most basic moves, but easily completed several rather hard chains of moves. The internal logic of the controls was a mystery for quite some time and by the 3rd level I thought he would quit. But at the level 4 there was some sort of “eureka” moment and I could feel the enjoyment (and understanding) level rise. In terms of positive (for game, not my ego) feedback he was the most helpful one – I spotted several places to improve level design and to better convey the basic controls principle (and yes, I want players to experiment and find stuff “on their own” rather than to feed them info with a tutorial).

Slide 2014-01-21 21-23-21-65 png

This violet thingie says “experiment”, but noone seems to understand / care / try to do so. On a side note – on this picture you can see like 60% of the level and it really takes practice to complete it.

Oh, by the way, this last dude is no stranger to platformers, but not as hardcore as Super Meat Boy. So that means I’m pretty much in the place I wanted to be, as I was making a game inspired by Team Meat’s SMB.

Anyway, my worst fear that the core feature would not be understood, to some degree, was confirmed. Good news is that the problem seems to be not in the system itself, but in the fact that I do poor job at giving players right hints. As long as I find the way to better communicate it, I should be fine.

Also, what I’ve found out is that people choose anything but what expected them to. Of course I knew it would be so, but I could not imagine in what ways this phenomenon would translate to an SMB-like platformer. And I did design most of the levels in a way that allow some deviations, I just thought they were smaller.

Another fun observation – even if there is an explicit directive to experiment, people tend to think of one plan and stick with it even if it obviously does not work until it starts to work.

Also, it seems to have little to no use to watch someone else play. That third tester observed the second one for some time, but he made lots of the same mistakes (and lots of his own) regardless. Just a fun observation. =)

This game is supposed to be difficult. I want players to jump right at the edge of the cliff. And I expect them to time their actions. It is not simple and it was usually the reason my testers died. However not all deaths were resulted in their inability to do so – obviously I made several mistakes in level design. It’s a good thing I now know them now and I will fix them ASAP (probably today).

Although the game IS supposed to be challenging and I expect players to die like 10 times on each level, I looks like that ATM I’ve made it a bit too tough.

Slide 2014-01-21 21-16-09-54 png

“WTF am I supposed to do?!?!?!? and HOW did I just do it?!?!?” seems like the most natural reaction in this situation. FYU you can’t just run under those spikes and you cant just jump over that small spike-hill…

So what’s next?

Fix the levels, think of a better way to explain the controls without actual explaining, and test again. Sadly I won’t be able to use the same people (unless I test new levels), so I’ll have to find someone else, like you. But I feel wrong showing only 5 levels, so it might take some time. Also there are some things I am uncomfortable with (like the fact that the game still has no name), so they need to be fixed.

On a side note, if you wonder how big\small  one level is, think of SMB. They are approximately the same.

Anyway, if you like challenging platformers you might consider warming up your fingers and prepping extra keyboard.


Tweet, share, comment. You now how it works =)

BG2MVG 07: Quick update on what we’ve been up to

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.

Last time I’ve published a short demonstration of the gameplay we have. Today  I will not be covering any specific topic. instead I’ll just bring you up to date with what we’ve been up to lately. I know, I promised an article about the story but it proved to be slightly more challenging than I’ve anticipated. Nevertheless it will be published soon.

OK, for the past couple of weeks we have been working on two major systems of our platformer game (man, we really need to come up with the name) and now we have a potent system of moving anything the way we want from platforms to…well… platforms ;). Second major system we’ve implemented is the “gun” system. No, your avatar shall not use it. It’s the environment that will do the shooting. And this means 2 things:

  1. Chances are there will be an article about those two systems, (if I come up with enough interesting stuff about them)
  2. Moving stuff and shooting stuff (besides stuff that does not move) is enough to make a decent platformer game. If course we do want not to play it safe and are will add more mechanics, but it will be enough to make first chapter of the game (think of the first world in Super Meat Boy or even first 1.5 worlds). And this first chapter is what we want to be completed before we launch a Greenlight campaign as well as the IndieGoGo campaign.

All that’s left is to take those mechanics and make first 25-30 levels out of them.

Secondly, we’ve reached the point of “no more hindsight” as I have discussed everything we’ve already done, so from now on it’s “currently in active development” stuff I’ll be writing about.

Thirdly, last couple of days I’ve been revising all the levels I’ve created so far. There are 2 reasons for doing that:

  1. Due to technical constraints the size of the player ans level geometry had to be altered, which led to necessity of alterations of the levels
  2. As we’ve created our object movement system and “guns” they were to be weaved into the levels without breaking the learning curve.

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!


We are looking for a 2d artist who would help us determine the visual style of the game (our thoughts on this matter will be discussed in the next article) and aid in prepping crowdfunding campaign.

If interested, please, contact me!

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

Motions map

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

test level

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!

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!

Stuff’n’Stuff 05: A Week of Nonsense

Only two things are infinite, the universe and human stupidity, and I’m not sure about the former.

Albert Einstein (or not)

Asking a question is like painting a target. Answering a question is like shooting an arrow at a target. Your goal in painting the target is to get an arrow quivering dead smack in the center of the target you just painted. If you (the advice seeker) don’t paint a clear target with a nice crisp center, or if your target is obscured by fog or distance, you run the danger of not having the advice giver hit the target for you. Ever asked somebody a question and gotten totally the wrong answer? Maybe you didn’t paint a clear enough target.

– Tom Sloper @

Last time I was discussing toxic work environment a project leader could have. Now, as I have no team, I’ll share some nonsense that happened to me and my colleagues – the usual employees.  My faith in humanity was shattered. Again.

Nonsense 1: Use your head and I’m not telling you.

This Monday my boss told me:

I have thought it through already. I know what to do. But I’m not telling you. Go do it yourself.”

This is his all-time favorite manner to give an assignment.

Its close competitor is “Do the thing. You know, with the stuff. How should I know what thing? You should know it. Now do it.”

I can’t help to remember Tom Sloper’s notes on “How to ask questions”.

Which leads to two options of failure:

  1. You walk away, do something, report the results. They are incorrect because apparently “YOU DID NOT USE YOUR HEAD!
  2. You walk away, start doing something, but cannot do anything due to the way a task was assigned, try to get some more information but get yelled at because “WHY CAN’T YOU USE YOUR HEAD!

The second scenario has its variations. Just this Tuesday (and basically every other week before that) I witnessed a situation when he would assign a task in his trademark manner and then criticize an employee:

Boss: You’ve done it all wrong. Redo EVERYTHING!

Employee (with a hint of hope): How do you want me to do it?

Boss: USE YOUR HEAD. I know how it should be done, but I won’t tell you!

This Wednesday my boss asked me to revisit one of our pop-up windows and sketch a better one. I should note that I design core mechanics, not interfaces. But I did what he asked. I showed the sketch to boss and he gave it a green light. Now an actual designer took my sketch an produced a window the way it would look in the game. After that I had a lovely conversation with my boss:

Boss: It sucks!

Me: Could you be more constructive?

Boss: No.


Nonsense 2: One boss bad, two bosses are &^$#ing crazy

(especially if one of them is a dick and the other one is a pussy).

This same boss (boss1) has another cool feature – he changes his mind all the time.

This Tuesday was really demonstrative.

I was asked to design a feature. I did what I was asked to do. I several times approached boss1 to discuss it, but he was busy. At 17:30 he decided that he was ready so we began our small 2ppl meeting. It was surprisingly productive – he was mostly happy about the concept but we have changed some of the details. At 18:40 (40 minutes of overtime, but who’s counting, right?) he said “I like it. Let’s do it this way. But I have one more question…” and at this point boss2 entered the room. 10 seconds later he claimed that I am an idiot (hey!), that there is no point of arguing with me (we were not arguing) and that both of us were wrong (huh…). The boss1 immediately agreed that the concept was awful and that he has seen all the flaws but did not tell me, because ‘he wanted me to see them by myself’. For the next 80 minutes boss2 was describing the said feature the way he’d do it.

I get it, they are the bosses and they are the smartest people in the universe. But why the fuck do they hire us, idiots? I’ll just assume that they are so generous and altruistic and god-like.

And they have no fucken clue that they have no fucken clue they are not.

This situation happens all the time with every employee. Sometimes even without boss2. Boss1 can change his mind on the fly.

If you are a boss and your employees are too happy, motivated and productive, apply this technique. It’s really irritating!

BTW, anyone knows where to buy a mind-reading device or some sort of a magical crystal ball?

Nonsense 3: Interface vs design.

This argument has nothing to do with bosses.

The premise is so moronic on itself, that the argument can be omitted.

The leader of a project (I’m so glad I work on another game) claimed, that the interface is the only thing that affects usability of a game or site, while the design is only responsible for visual attractiveness.

A clarification is needed: in his world interface means the relative position of various elements and their size. According to him, design is the way said elements are visualized (for example color).

His salary is much bigger than mine. I should become an idiot.

Nonsense 4: Talking about the salaries.

Some time ago the game I was working on was cancelled and my team transferred on other projects. When bosses announced this, they also said that my team members will have a raise of the salary. “You can tell them”, bosses said. I delivered the news and after that had a 2 weeks of a long-awaited vacation.

The vacation ended and I asked my ex-teammates whether the bosses raised their salaries. Turned out they have not. I addressed the bosses and they said that “They’ll have their raise. You can tell them.” And again I did.

Office manager has to know about that stuff, and bosses usually forget to inform her, so employees do it. I informed her and she said that she never heard about my ex-teammates raise. She promised to talk to the boss. In 2 days she delivered the news – no raise will be granted.

Good job at keeping your word and keeping your employees motivated!

I have again addressed bosses and they claim that the raise will happen. But I have a feeling it’s not over yet. We’ll see what happens next.