Simoroshka & games

Nov
30

My first game

I was supposed to start my blog with this game post. But I didn’t and now it is time to fix it.
This project is important, because it is the first game that I have finished. After making this I was absolutely sure that this is what I want to do with my life. Games. Also for the first time in my life I knew that it is what I can do, and not something from a parallel universe where awesome people create new worlds with some sort of magic. I had my preconceptions about the whole game development thing, I admit.

But back to the game. Take two nerdy girls with a shared love for Doctor Who, put them in a game project course, and let them do whatever they want. Advise them to use Unity or something similar. And leave them for a few weeks. By the set deadline you might get this.

Nana, my project partner, was a game-designer. She proposed the initial design, made the 3D models, got sounds, wrote texts and came up with a name.
For me it was easier to play with code and game logic, and I did just that, solving problems one by one. I never opened Unity or any other game engine before. With a help of some official video-tutorials I have put together something that resembled the idea we had in mind and on paper. It wasn’t all too easy and I spent days and evenings and a weekend during the last week, but it definitely was fun.
The game is a collection of tiny and big bugs and problems but it does what we wanted, at least partly. We had so much more in mind, but simply didn’t know how to do it, nor did we have the time with all other courses and exams. But we loved it. It was ours. It was the first.

One awesome thing that we did was the progress log. We couldn’t meet too often and had to work separately, so it was easier to track our progress this way. And it the end it was much easier to reflect and write the required postmortem. I still love to re-read it. It is inspiring to see how we went from “we have no idea how to do anything” to “I’ve done these things and am doing these”.

I look at our game, see all the imperfections and you know what? I have a sudden but a very strong urge to re-make this game with my newly acquired knowledge about game physics and unity. I will make a separate post with an analysis and plans. Aah, excited!

Oct
30

October game!

It was a very busy month for me, with a challenging last course and exam (passed!), work still going on and thesis starting along (I will write about computational creativity and game jams!). But nevertheless I managed to make another game. It’s written in Javascript, so it should work in any browser (I haven’t tested it though. I probably should). It is a simple tennis game with a twist.

portalTennis

Play Portal Tennis in the browser!

It was a good exercise. I grew rather fond of Javascript during my summer internship, so I wanted to use it to make a game. And not having all the powers of a ready-made game engine makes you think more about small things. I didn’t particularly like this part though, I like to program things like game logic and mechanics, without worrying about asset loading, collision detection, frames and things. But again, it was a good exercise.

Speaking of collisions. There are bugs left in the game that are the result of the fact that I don’t really like trigonometry. Writing the AI for the second player was difficult enough on that part, and I didn’t have any mental power left to get those pesky collision problems resolved. Next time I would rather use an engine or a library of some sort and save my time for more fun things.

Takeaways

  • It is not that difficult to find time to make a game even in the most scrambled schedule.
  • I like programming interfaces, inputs and user interactions, but I don’t like designing graphical elements. So much time lost, such poor results…
  • I like implementing game logic, AI, and balancing things for a better experience. But I don’t like dealing with small things like asset loading, collision detection and other things that are usually automatized. They are just in the way!
  • In order to finish a game on time, you probably should kill your inner perfectionist. Or at least knock him unconscious for a while. This was the biggest struggle of them all.
Sep
30

Quantum Cat – patched

While making a game prototype can be done in 16 hours of pure team focus, fixing all the tiny fixes took more than 2 weeks. Thereby I announce the project completed and case closed. All planned changes are done: you get a random level, everything falls where it should fall, game pauses and exits like a normal game, timers go, and even most of the grammar mistakes are eliminated. There is even a secret feature of row deleting.

qcat-logo-patched
The game can be played online (no Chrome though) and on Windows.
Web | Windows

Takeaways and postmortem

  • Don’t name gameObjects and scripts the same in Unity. At some point I managed to make the whole editor to crash on play without explanation, and only careful renaming solved the issue.
  • If you want some text in your 2d game to appear at an exact place on the screen, don’t use 2d-text, use 3d. Counterintuitive.
  • One needs to think more about game balance. It appears that opening the color of the block is always a better strategy and the other option goes unused. I added the normal tetris mechanics starting from the second row (although it goes unmentioned anywhere in the game), but anyway, it feels quite pointless most of the time.
  • I love finishing things and to call them done.
  • Chrome doesn’t do all the things and therefore cannot be considered a superior browser anymore.
Sep
22

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

Takeaways

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