2018: the year of jams

Game jams are truly amazing. They force you to focus on making a game quick, focus on game core, and not polish. If you did not participate in one yet: what are you waiting for?

Ludum Dare

I’ve learned about game jams in the winter of 2016. It happened so to be that Ludum Dare 37 was around the corner. At that point, I finished just 1 small SDL2 game. And my mind was full with text roguelikes and Terraria, so I went with the toolset I was familiar with: Java and super slow library, that provided a simple way to render a text grid.

So here is what I ended up with:

Escape the Room

I’m still pretty happy with how my first jam went. Using simple graphics allowed me to not open a sprite editor at all and spend all my time in code. Looking back at the code, it’s totally not perfect. I still used if( and not if ( syntax at that time, most classes are pretty big and complex, and the game doesn’t work anymore for some reason… (it stops working after picking up a stone)

Anyway. I just got hooked up onto ldjams. I didn’t miss a single one yet. After ldjam 38 I always used PICO-8, but I’m hoping to go with Voxatron for the next one 😉

And as you know, ldjam happens 3 times a year. Well, it used to. Now it will happen only twice a year :/ But anyway. Soon after ldjam 38 I saw someone tweet about Remake Jam – a game jam where you remake your first game. So I joined and remade my first game – Tanks. And that’s how I found about about an awesome website called itch.io. Today it’s a home for 100k+ games and thousands of game jams every year. They aren’t as big as ldjam, yet some of them are pretty big and have a nice idea/twist on them.

And then… FC jam â„–1, Click click click jam, LOWREZJAM 2017, ldjam 39, FC jam â„–2, ldjam 40… And then 2018 came.

2018: the year of big things

A few days before 2018 become a thing I met FailPositive, a composer, who we decided to make a small commercial game and sell it on itch.io. I went with love2d as the engine, and quickly sketched a puzzle-platformer game:

First ever screenshot of COTA

The game evolved really quickly, here it is after just a few days:

First ever screenshot of COTA

The development of the game took a bit more than 1 month, and for the most part, I was just designing levels. The current version of the game includes 120+ levels. They all are hand-made. FailPositive made a good soundtrack, and on January 30th, we released the game. It didn’t go as well as we expected it to go, but it was my first "big" project that I managed to finish, so I was happy with it.

After the release of COTA, I started feeling pretty badly without a project to work on all the time, so I started researching another idea: a multiplayer dungeon battle arena game. For the engine I picked LibGDX (I should’ve gone with monogame), and in March, I started developing my next huge project, that is still not done by this point, The Burning Knight. I recently wrote about why it took so long for me to even get the game into the alpha stage, and when I plan on releasing it.

And that’s kind of everything I made this year… Except for the jam games!

2018: the year of big things and jams

Besides COTA, I made 19 games this year, and most of them are jam games. I will be honest, looking back most of them are pretty meh. But I’m really happy with Milt and another secret game, that I will be releasing soon. And what I’ve been noticing for myself, is that I get the most fun developing games, that take the least time to make. Milt was made under 6 hours. A secret game was made under 3 hours. And I proud of these two.

I’ve been talking to my gamedev friends, most of them also feel, that when they work in short bursts, they get the best results. I’m more than sure, that this rule does not apply to everyone, but it’s an interesting fact. Next year I’m considering to make an experiment: I will make at least 12 games with development time of max 12 hours. If all goes well with my theory, I should be happy with 90% of them.

What I learned this year

Sometimes you stop making progress in learning and think, that you know everything. Turns out you are just not pushing enough, or you are totally ignoring something. I’ve learned a lot this year, due finishing a lot of projects and working in big code bases. So here are a few things I noted for myself:

  • Clean code matters! Yeah, this might sound banal and boring, but, hear me out: spending one day cleaning up your work helps so much with maintaining the code later. This is especially important with gamedev. Adding new features, mechanics, just items or any other content becomes harder and harder, as your codebase grows. Simple copy-paste is your worst enemy. Changing the code in one place won’t change it in another place, most likely resulting in huge bugs. And just agree: working with clean code is much more pleasing, than digging in dirty mess and adding more to it. I feel really good when I manage to write code that is elegant. This is a huge topic, I plan to write more on it soon 😉
  • Git is must have! Version control is a super powerful tool, yet it’s so simple to use. It allows you to quickly look at the stable code after introducing a bug with a change in the codebase, tracking your work, just backing up and making collaboration super easy (except when you get super huge merge conflicts :x). COTA was written without git, and that’s really sad. Everything I code now is tracked with git.

And also, here are a few things I learned this year:

  • I grew to love pixel-perfect aesthetics. This is really personal, but most pixel art games are not pixel perfect. What does that mean? It means you constantly get mixels and rotated pixels everywhere, and in reality, everything looks much messier than on the mockup. Why? Because the mockup is pixel-perfect, but the game is not. Also, rendering a game to a texture and then drawing the texture first, saves you a lot of GPU work, and second, it allows to be lazy sometimes: it really makes simple circle shapes look amazing.
  • I finally understood what type of magic shaders are. Nothing magic really happened, one summer day I was sitting and trying to wrap my head around how they work. I’m surprised it took me so long to realize how shaders work, after spending so much with PICO-8. Now I can’t make a thing without them, they are SO powerful.
  • Using debugger. Yeah, I feel ashamed for not using it before. I have excuses, tho: I did not work in big enough projects before, and I worked with languages, that have a pretty bad debugger. But now, once I’m in Java and C# field, it’s one of my favorite tools.
  • Hot swap is lovely. With debugger, a lot of times comes another really helpful feature: hot swap! (or hot reload). It really shows what it’s capable of doing when you have a huge project open and running, that takes ages to get back to the state where it currently is. For example, you are fighting a boss, and you need to quickly test out a speed change on him, etc. I’m currently trying to get hot swap working with MonoGame. C# doesn’t like it out of the box, but Java and IntellijIDEA makes it too easy not to use. You just debug your app, then press Build... and boom.

Things that I WILL do differently next year

It’s a really nice and old tradition, to write down things, that you promise to do in the next year. It gives you a goal, and motivates you, especially if you put it out somewhere in the public. I’ve been keeping up with my goals so far, for example, for this year I wanted to release 12 games. I ended up with 20. So here are the things, that I promise to do in 2019:

  • Care about making my code clean. I will spend each Friday refactoring it up.
  • Try out monogame with next big project. I have some cool plans for a game, but I need to finish Burning Knight first.
  • Finish Burning Knight. I’m hoping to get done with it untill the summer comes. Will see how this one goes.
  • Write. I’m going to be constantly blogging about different things.
  • Open source more things. Currently, most of my projects are closed source. I have a few reasons for that: most of them are games, and if I want to sell them, fully opening the code is not the best idea, because you can just compile the game for yourself. I’m going to open source some parts of the game, like engine, game logic, but game assets will stay closed source. Why do I want to make my games open source? Well, first, it forces me to care even more about code quality, because I know, that other programmers will see it. That also opens space for contribution, mods, a nice bug tracker, etc. Plus y’all can track my progress with the game 😉
  • Making a PICO-8 cart a week. I was doing that for a bit longer than a year, but the I stopped. Now, once I posted all of these carts, I understood how much I miss making them now.
  • Make Voxatron carts Voxatron is a bigger brother of PICO-8, you can describe it as 64 PICO-8’s stacked together. It just received a huge update, and now the time has come, when I should consider doing things with it too. I’m planning to use it for Global Game Jam 2019. Maybe one day I will also write a blog post about it. Right now, sadly, it lacks tutorials, and I really think that should be fixed.

And to wrap this up, I want to say, that this year went really great for me. I see tons of things that I could’ve changed, but you know, things take time, and you can’t always manage it. I’m really looking forward to 2019, I feel like it will be another great year, with a lot of progress, and hopefully, my first Steam release 🙂

I wish you to have a great celebration and a great next year!

You might also find interesting

Join the discussion!

conquerer 5 years ago
Ӏ'm truly enjoying tһe design and layout of yoᥙr blog. It's a very easy on thе еyes which makes it much more enjoyable for me to come һere and visit more often. Did you hire out a desiɡner to create yⲟur theme? Outstanding work!
Reply
egordorichev 5 years ago
No, I designed it myself, yet I'm not super happy with it, I yet have to optimize it for mobile, and I don't really like it being so bright, so I will work on it more in the future.
Reply