Simoroshka & games


How I failed my first Global Game Jam

The most important thing about failures is that you learn from you mistakes. And you get a more accurate vision of reality and how things work. So it doesn’t make sense to put memories about failures aside without first reflecting on them.

Why I failed? Well, when there is no game that you can share and maybe even mention in your portfolio, and when you had no fun whatsoever, I consider a game jam failed. It was stressful and result sucks. What else there is to say? Let’s better go to the details and my learnings.

Clinching to an idea

When the theme was announced, I instantly knew what I have to do. “Ritual” was exactly what our autumn game idea was about, it fit perfectly, it already had the design document and all logic written down, and it was certainly, definitely going to be THE chance to make it happen. Because game jams are great and powerful. I didn’t change my mind when I haven’t got any artists on my team. “It is the game I want to make and if needed, I will make it alone”. Oh how wrong I was.

You need to be flexible. If there is not enough resources, maybe you should put your perfect idea aside and join another team and have fun doing something crazy. The point is not making the game, the point is making something, learning new things and having fun.

Making a content driven game

Let’s face it, point-and-click puzzle games are not good for game jams. It is not the sort of game where you can quickly make a prototype and then just improve it. Every logical connection has to be programmed separately, every object drawn in a certain way and placed carefully, every puzzle has to be programmed from scratch. It is also very easy to make a point-and-click unplayable if your visual clues are not refined enough. Graphics were paramount, and they don’t come quick.

Next time, if I am alone or in a small team, I’d rather focus on a mechanics-driven game. Or just something very small, but fun.

Not using an engine

I never made a point-and-click adventure before. But I thought: “okay, I’ve done Grow Christmas in javascript, it was easy, I can reuse code, it will be faster than trying to use Unity for this, or an entirely new tool”. As a result, I was trapped with trivialities of programming interface, scene changes, causalities and other things that would be much easier with a proper tool. There was no time left to improve interactions, puzzles, animations and graphics, and the game-feel in general. In other words, there was no time left to do things I actually enjoy.

From now on I am going to make use of engines, tools, and libraries. Using what you know might make life easier, but learning new things during a game jam is also the positive part of the experience. Tools should be appropriate for your goals.

Stressing too much

The world is not going to end if you don’t make a perfect game in time. But I felt like that and translated this message to my 1.5 team-mates. I also could not sleep properly and exhausted myself completely. Looking back I know that it was not worth it. I love making games, and there is no reason to make it feel like cramming before an exam. Takes the fun out and reduces creativity and productivity.

This is it. Live and learn, that’s gotta be my life motto.

The game can be actually tried to play here. Despite us cutting at least one-third of the original idea, the end can be reached. Although it can be quite impossible with the impressionistic graphics like that.


I am back

I have been silent. The winter wasn’t that easy on me. Let me make a recap of what was going on.

C++ wasn’t that difficult to pick up again. After all, it was my first programming language and I used it for quite a while during my undergraduate studies. The most difficult part was to find the right IDE, install a proper compiler and learn how to use external libraries. Never before a working “Hello World” program was that exciting and rewarding! I experimented with SDL graphic outputs, tried out a couple of tutorials, wrote a flocking simulation, and got a very useful code review from a good friend.

blurred flock 2

I participated in Global Game Jam and made way too many mistakes for one weekend. So I have no project to show. But maybe I will write about this experience later. Reflecting always helps to learn from your own mistakes, and sometimes you learn more from bad experiences than from good ones.

I am volunteering in media team at the local IGDA branch (one of the biggest ones, and probably the coolest). I like being useful instead of just trying to casually hang out and feeling out of place. I am not very good at networking, but I have my ways of connecting with people. Like actually doing things together.

Also, I am trying to write my master’s thesis, which is coming along way too slowly and which I have to submit in 7 weeks or so. The topic is quite interesting, I am just not a fan of academic writing. And I thought that I might try something different to boost my work and to give this blog a bit of life back.

Soon(ish) I am going to write a post about co-creative game design, using the materials for my first chapter.
And if there will be time and inspiration, I’ll also tell why I think my first GGJ was a failure.


Ludum Dare!

After all the hype has faded I guess it is time to finally write a huge post about my first Ludum Dare experience. All in all: it was unexpectedly good, and pleasant, and I like what I have done. And people seem to like it too, all the comments on the entry submission page warm my heart and make me smile.


I wanted to participate in Compo, not in Jam. First of all, it is more challenging and challenges make me work better and achieve more. Second, I didn’t have a team. Third, I had other plans on Monday anyway. And I already had a game jam experience that lasted less than 2 days, and I knew how it works for me.

I woke up at 6 am on Saturday and read the theme. IT’S A TIE! Hmm, strange theme, what can I do about it, a game about ties?.. After 30 minutes of trying to come up with something sensible I read the email again and this time got it. We had 2 themes! Growing and 2 Button Controls. I personally don’t think that the last one is a good one, too many people took it as a simple restriction of controls available to the player, not a proper theme for a game. But I was determined to, first, make both of the themes into a gameplay, and second, make a complete and nice to play game that I can actually finish alone during the weekend.

I finished brainstorming by 8 in the morning. The idea was a perfect fit for both themes and I decided to go with it, despite the fact that it was more about art than programming. But hey, games are not just programming!

However, I decided to start with a prototype, so I could be sure that all code things work and I have everything I need before I could jump into design. And also at 8 in the morning after 5 hours of sleep I cannot come up with ideas and art, but I certainly can code in javascript. By lunch I had my super ugly but working prototype. Most importantly, I made sure I could easily plug in all assets and add logic parts, so later I didn’t spend much time on coding or any on debugging.


My next challenge was to come up with game choices. And this is where I had to scope the initial thinking down. Having even one line of depth 10 would be impossible to implement in a weekend (and probably too much for a player to get through). After trying to manage the logic on paper sheets and spreadsheets I got a working solution that helped to finally fill the blanks and understand the scope:


I was drawing in parallel with designing the game logic. Nicola suggested that I could use the huge blackboard in his room and I thought – why not? Otherwise, I would use paper and pencil because there was no way I could do so much digital drawing with the mouse I have. The blackboard idea turned out super well and gave my game a certain distinct style, and I just love the final look.


I expected sounds and especially music to be the most frustrating part with the worst outcome since I had no experience whatsoever, but it went very smoothly. For three sound effects I recorded chalk sounds and a “poof”, which I edited a bit in Audacity. I also came up with a very simple music loop, using basic rhythm logic and my own intuition.

I finished at 8 in the Sunday evening, 7 hours before the deadline. There was nothing to add, nothing else to polish. I was happy and content.

What went right

  • Scoping. I knew how much I can do in a weekend with this kind of project. First I made a working prototype, then the main line, then I added other ideas in the time that was left. And I was working in cycles, making sure that the end product looks like I wanted and I can make it fast enough. The last bit is the reason why I have just one animation piece – it would be possible to have more, but it was time consuming and everything apart the one I have was not essential.
  • I decided to go for quality over quantity. It is a very simple and small game, but it is nice and people enjoy it.
  • I was relaxed, had walks and didn’t cram. You can probably see my mood in the game.
  • Using Javascript and keeping things as simple as possible. It’s a tiny browser game, one shouldn’t use Unity for things like this and it’s good to have a choice of tools.

What went wrong

  • I tried to save edited pictures in PNG, because I thought transparency will make things easier. Well, PNG is bad for photographs, they were so heavy, that I decided to redo them into JPG by fusing with a piece of the background, and spent at least another hour on that. But imaging working in a team and discovering an asset problem in the last moment.
  • I tried to keep it nice and tidy and in different files, but in the end my code was all scrambled and I was too worried about drawings to do anything about it. Code works, but it doesn’t look nice. The game does, though.
  • I forgot to make an opening screen. It didn’t even occurred to me! It would be nice to have one.


  • Sometimes it is not about advanced programming at all. It doesn’t mean that it’s not worth it. I had a moment when I though that I am wasting my time because game is too simple and even stupid.
  • Making something that you can finish and polish in the given time frame is extremely rewarding. Reading comments of people who enjoyed your game is the icing on the cake.
  • It is nice to have the code base or prototype done and checked as soon as possible, so you can be sure that the game is working. Then you can have all the time left to make it look great.

Jupiter Hadley plays my games

Jupiter Hadley plays a lot of indie games, game jam games and other stuff like that. I must say, it feels pretty good everytime to unexpectedly get this sort of player feedback. She records video compilations, and here are the video parts with 3 recent games of mine being played.

Quantum Cat

Well, I do agree, there is too much text in this one, and the game mechanics are too strange (so are quantum physics).

Portal Tennis

This seems to be more enjoyable to play, and it makes me a little bit proud. All those hours fiddling with AI and balance were not in vain. =)

The Endless Maze

Jupiter likes my game more than I do! I will probably take her suggestions about timer and other stats into consideration before posting it on


ProcJam 2015

ProcJam is an online game jam which is all about procedural generation. It is organized by Michael Cook, who is an awesome researcher and who accidentally inspired me to choose a particular topic for my thesis. Since I am now all about computational creativity in games, I couldn’t miss this event.
The tagline that is supposed to guide people through this relaxed 1-week long game jam says “make something that makes something”. Participants were to create a game or a tool that would make use of any procedural generation algorithm. No other theme, no constraints.
For me, it was yet another chance to try something new. I didn’t have much time and the week was rough, so I ended up implementing in Unity3D a depth first search algorithm for labyrinth generation. Very simple and the result is not very exciting, but still it is a new experience.

My inner game designer is not happy with the game and refuses to call it such. There is no winning condition, just endlessly generated labyrinths of increasing size. The controls are not very responsive and the ball player annoyingly bumps into walls. The labyrinth itself is not very suitable for a labyrinth game: of course, it is a proper labyrinth with no loops and closed rooms, but going through it is very straightforward and poses no challenges. Maybe it would be better if the labyrinth weren’t visible from above.
It would be cool to add collectables, or enemies, or both. Or to make it first-person and add a possibility to leave marks on walls. Or inverting the labyrinth and moving the ball on top of the walls. Or tilting the board instead of controlling the ball. Or making the labyrinth transformable with walls appearing and disappearing here and there. Or adding portals (I like portals). So many options, so little time…

As for the jam experience… I find it more difficult to be completely on my own. I like constraints: a particular place where you have to be, a theme, a team, a strict time frame. I like to be all in the project, without juggling it with studies, theater rehearsals, home errands and other very important things. I really want to participate in Ludum Dare, but I need to think how to organize my life around those dates (like finding a local event place and saying no to everything else).


We made a game in 16 hours!

So, quantum game jam, hah? It was borderline awesome!

Apparently, it is not so impossible to make a game in such a limited period of time, even without much of experience. Game Jams are said to be 48 hours in general, but ours started very late on Friday, and we had to postpone actual work till Saturday morning because everyone was too tired. And the deadline was at 15 sharp on Sunday.

We had four people on the team, only myself being capable of making things in Unity. So I became the coder (all bugs are on me). My awesome friends Nicola and Ir did graphic design and other things. Much of which was discarded in the process due to the communication or technical problems… Mikko the quantum physicist was basically designing the game around our initial idea and coming up with quantum ideas. And bringing us chocolates. What would we do without him?

We wasted some of the time due to the lack of experience, but still managed to finish the game. Well, what exactly do I mean by finishing?

  • The game has a story and motivation.
  • It has instructions.
  • It has a gameplay with specific mechanics. The jam theme was “Quantum Rules”, so we have some of those.
  • It has pretty design.
  • It has nice sound.
  • There is a goal and clear win and lose conditions. And an ending.

Of course, it has bugs. And sure, it is my fault. Just like sprite animations Nicola spent so much time on, but we couldn’t use because I didn’t know the process and there was no time to learn. But still, come on, first game jam ever, the second finished game. It is finished and it is a win!

The gamejam version with source and executable files can be found on the official page.
Here is the video of the game.

Future improvements

As I mentioned, the game has bugs, some of them are quite critical, some of them are said to be features while they are really not. I am now working on the post-jam patched version of the game. Here is the list of things I want to fix, change or implement, in order of priority.

  • Quantum timer doesn’t show decreasing probability. This is quite bizarre, because inside Unity it works, but freezes in the build. I have to go through the scripts and make sure there is nothing fishy.
  • Particles don’t fall. At first we didn’t think about it. I started with classic tetris mechanics, this is where it comes from. Then we decided that it doesn’t make much sense in combination with color/shape “quantum” uncertainty, since in tetris color doesn’t matter. And so we added match-3 logic. At which point particles should start always falling instead of hanging in the air. There was not enough time, of course.
  • Collision bug. Like in tetris, when pieces reach the upper border, you lose. It worked until some moment in the development, now it is very much broken and crazy things happen.
  • Slower particle elimination. I mean, now they just pop. I actually have a piece of code that adds a delay so you can see what is going on there. But it caused some very crazy bugs we couldn’t ignore, so I commented it for later testing.
  • Random level initialization. Yep, the one we have there is very much predefined. I couldn’t make the GameObjects to instantiate properly and there wasn’t much time, so I just placed things in the level manually. Anything for finishing the game.
  • UI things and sounds. Minor adjustments like slow music change, in-game text messages (hurry up, you still can save her!), bonus sounds, pause, reset, proper exit (are you sure you want to leave Mu here?).


At some points I was thinking that we really lack a producer who could go and check what exactly everyone’s doing, stop them and tell what is necessary to do right now. But probably next time we can do it better ourselves. It is important to ask yourself and each other what is the most crucial part of the work and what are the priorities. What must we do and what can we go without if we don’t have enough time? I had to say no many times, because I knew that I won’t be able to implement this particular thing in a reasonable time. I had to remind people, that we don’t need perfect, we need something right now. But otherwise my team was perfect and I could just dive into coding (and even get help when my brain stopped working).

  • Stick to the minimum, especially when it comes to coding or trying new things. There will be no time to get all those awesome ideas done and tested. Take one, maximum two and build around them.
  • Dirty hacks and playable game are better than clean code and an unfinished thing. Do whatever it takes.
  • Have all the tools ready. You don’t want to spend precious time installing software. Especially if it is video recording/editting app and you have one hour left to make the demo and upload all the things.
  • Everyone should do what they can do best. If you have an all-rounder, it’s better if he/she fills a gap and doesn’t try to do everything else as well. Multitasking isn’t very efficient.

It was a great test for our newly formed team. We decided to continue making games together. Three of us have all the basic skills that are needed to make a game and nothing can stop us. =)


Let’s jam!

There was another takeaway from the conference that I haven’t mentioned.
I signed up for my first game jam!

For some reason I always thought that (a) you need a team ready (b) you need to be super good. I was wrong. Apparently, you can come without a team or great gamedev experience (if any). Maybe those beliefs are not entirely incorrect and one gets more out of a game jam this way. But you need to start somewhere. And a small game jam for 30 people tops sounds like a perfect occasion to expand your comfort zone.


However, I did what I usually do when I don’t know what to do and what to expect.
I googled “how to game jam”.

Apparently, one of the biggest problems is making the game small enough and cutting off all the brilliant ideas that you came up with. I am not new to this. I actually consider myself to be rather good with abandoning anything that cannot be achieved.

Another thing that got my attention is the impact of adding music and sounds to the game. They say that perceived quality of a game with sounds is much higher than of one without. It makes sense to me, and I intend to allocate some jamming time to basic sound design. Right after having the very first working toy prototype.

And, of course, the point is having fun. I am bringing two of my great nerd friends with me, and the place is a cool science museum, so I don’t think we will have any problems with fun. =)

I am going to post quite a bit on twitter and instagram in the process. You can follow me there if you are interested.