How games got me into programming

And a post-mortem of my recent Ludum Dare entries

Christian Silver

--

We’ve all got those moments in our lives when we make an important decision that changes everything. Sometimes we understand that when we’re making them and sometimes we don’t.

One such scenario when I wasn’t aware was when I decided that I’d give making computer games an honest. That would be my first exposure to programming, an experience that led me to know what I wanted to do with my life. I was 11 at the time and I had no idea what I was doing but I did know that this software called Game Maker (now Game Maker Studio). I downloaded it, and a few example games and it wasn’t too long before I got hooked.

Square’s Legacy, my first game

My first game was Square’s Legacy and it was a masterpiece of modern game design. It was a platformer that followed the plight of a red, hovering square. It was a long time in the making and I just put everything I had into it. As I developed the game from beginning to end, in order, I got better at designing and developing deeper into the game. As a result, it progressively got better and more fun to play as you went through it. I’ve lost the actual game since, but I recall revisiting it and thinking “hey, there are some interesting game design elements in this” but then I realised that those were all stolen from other games. Some will notice how similar the screenshot is above to Jumper 2.

I got really stuck into the community around Game Maker. I practically lived on their forums and enjoyed answering questions there. I’d post a game from time to time and always had a mixed response but the people there were usually constructive with their negative feedback. I managed to find someone else designing games, one Ethan Saffron, there and we joined forces — he’d do graphics and I’d do code and we’d both design. A lot of our games are available on our (very old) website.

My favourite game I made in that era of my life would have to be Ruined. It was made for a competition that had a set screen resolution and limited button usage so the winner could potentially be ported to PSP. Ruined was a 2d metroidvania platformer and it was a big undertaking for us. The world was big, there were a lot of gameplay elements and a confusing backstory to wrap our heads around.

Alec, our protagonist, in an ancient temple

As time went on other commitments steadily got in the way. Ironically, I wouldn’t have found myself with these commitments if I hadn’t fallen in love with technology as a result of starting game development.

Ambitious projects for games simply never eventualised because the time to make them wasn’t there. Our last game we made together was an arcade game on mobile. Something simple like that should have been turned around in a month but it was in development for 12. That game was released in 2012, and I didn’t make any more for a long time.

Throughout my entire game development life, I’d looked fondly at Ludum Dare, this 48 hour game making competition. For those who don’t know, here are some quick-fire facts about Ludum Dare:

  • It runs 3 times a year, and every competition is themed
  • The theme is announced at the start of every competition
  • You either do the 48 hour “compo” where you have to make every component of the game yourself or the 72 hour “jam” where you can work in teams and use assets on the web.
  • Afterwards, there is a 3 week voting period where the entrants play and rate other people’s games.

Somehow, I’d never found myself involved in one. Whenever I heard the event was happening it was either after it had started (where joining in becomes difficult) or shortly after it had finished. I never made the effort to know when one was happening.

Last year in December I found myself finishing school and all of a sudden I had some spare time to spend. Ludum Dare 31 was just around the corner (I had signed up to their mailing list at that point) and I decided that this time I was going to do it.

Leading up to the event, I had to decide how I was going to make a game. What technology was I going to use? Towards the end of my last game making era I had grown quite fond of AS3 (of Flash) and FlashPunk but I knew that its days were numbered. A remembered someone mentioning this thing called OpenFL to me and it looked really cool. It was the Flash standard library re-implemented in Haxe and made cross-platform. What’s Haxe? I had the same question. It’s a language that is very similar to AS3, but compiles to other languages for cross-platform goodness. FlashPunk had even been ported under the moniker of HaxePunk.

I was ready to go for LD31 (or so I thought). I eagerly awaited the theme announcement, counting down the hours, and then minutes until it became known to everyone. I was ready to make a platformer, just like the games I used to make, with good story telling elements and cute graphics. And then came the announcement:

Entire Game on One Screen? It wasn’t what I was hoping for, and it doesn’t lend itself to adventure games. That wasn’t going to stop me, though. After a good few hours of brainstorming, I came up with an idea of a game where the world was falling apart except for one safe haven (the size of the screen), and you had to get the entire game into this haven. I set to work but I knew I had to find a level editor to put this together.

Ogmo Editor used to be my port of call but I had switched to a Mac a few months earlier and Ogmo is Windows only. After tinkering around with the alternatives I discovered pretty quickly that there are no really good 2D, generic, level editors available on Mac (I’ve since started a project that tries to remedy that but more on that one another time).

This quickly put a stop to my efforts to make an adventure game. If I couldn’t design levels quickly and easily then it just wasn’t going to happen. I went back to the drawing board with several hours wasted. This time I attacked it with the plan of making an arcade game. The concept of an level that evolved came to mind — you’d overcome some obstacles to reach a goal and then the level around you would morph, the goal would move and you’d have to do the same again.

And so, Blocked came about. A game where you (a square) try to get to a goal (another square) while avoiding/interacting with the environment around you (other squares). There is a bank of 36 environment blocks and every time you reach the goal, another comes out of that bank to make the environment more complex. Let the gif below explain this visually:

There were four different modes that you could end up in, and the controls change from mode to mode so you have to adapt quite quickly.

Working with Haxe for this game was pretty fun. Getting some kind of dev environment going on was a bit of a pain though — no editors had great Haxe integration (let alone with OpenFL) so I was jumping around the whole time trying to find something that I was comfortable with. In terms of graphics, the game ended up being quite vector based, which was a bit difficult to adapt to HaxePunk’s very raster based way of working with graphics.

I would rather submit a more polished game than a game with more features, so I made sure to reserve a good amount of time to make the experience solid and seamless. It’s that seamless part I spent a while on as I endeavoured to animate all the things. I spent a great deal time working with tweens to make the transitions between states look good. One of the more complicated parts of this were moving the blocks around. The blocks could split into four smaller blocks and then join back together, and they may be spinning around while doing this. I think the effect of splitting and joining ended up looking really neat.

The music was a rushed effort, something I put together in Logic in about 10 minutes with some of their automated tools but people seemed to like it. I think it did end up suiting the part quite well.

I polished until I could polish no more and the end of the 48 hours came around quite quickly. I created my final swf (after all that, still publishing in Flash!) and submitted to the Ludum Dare website.

It was then when I first experience Ludum Dare’s voting system. You’re given a page with a selection of games to play and rate. As you do so, they’re replaced with other games. The catch is, the ranking of games in this list means that games with less votes and authors that have voted more are more likely to be seen. This way all games should get at least some votes but more importantly, authors are incentivised to vote as it means people will likely see their game. It worked really well — I’d go and play and vote a few games and then all of a sudden there would be a new comment on my game. This has to be one of the best peer-based voting systems I have seen.

Blocked was received surprisingly well. People thought the idea was really novel and liked my implementation of it (polishing until I could polish no more!). The biggest complaint was that the game was too difficult. This is something that I have always had trouble with, I find my own games far too easy.

Skip ahead three weeks (I played a lot of games) and the results were announced. Blocked came 40th overall. For a first time entrant, for someone who hadn’t made games in a long time, I was stoked with this result. I was really looking forward to the next one.

You can play Blocked on the LD website and have a look through the source code on GitHub.

Fast forward 4 months and we arrive in April. Ludum Dare 32 is just around the corner and I’m excited to get started. This time around, I knew I couldn’t make an adventure game and I should stick to an arcade game. I was ready to make a really abstract geometric game and I had even forked HaxePunk to make it vector based instead of raster based. And then the theme was announced.

An Unconventional Weapon? Weapons aren’t typically abstract and geometric. The concept of weapons suit games with identifiable characters and I was not in the mood to make a game like that. Well not so much not in the mood, more like it was really difficult to do that without a level editor.

After hours of frustrated brainstorming I came to a concept: gravity could be your weapon. You can manipulate gravity to get objects to interact with each other. I thought there could be a number of objects and certain rules as to how these objects have to interact with each other.

  • There is the player object, you can only manipulate gravity a certain distance away from it. This must not leave the screen
  • There are circles. Circles must be consumed by the player.
  • There are squares. Squares must go into square holes. Squares must not touch other squares. Anything else must not fall into square holes.
  • There are triangles. Triangles must not touch anything but other triangles.

I wanted to have unlockable levels and more objects and an interesting environment with walls for the objects to bounce off but time got the best of me and I had to compromise. Like Blocked, I valued having a polished game over more features.

What came out interestingly was the physics itself. Firstly, gravity when implemented physically correctly can seem really weird. It follows an inverse square law which means it gets weak very quickly the further you are from the source and that can be difficult to take control of. In testing, I would click and hold (that’s how you manipulated gravity) and would quickly lose control of objects as they flew off the screen and I proceeded to lose the game.

I added some small attractive/repulsive forces between certain objects to make it more difficult/easier in certain circumstances. For example, squares repel other squares to make it less likely that they’ll collide. This also meant that you couldn’t just do nothing as the forces at play will move everything around and you would eventually lose.

This game was more rushed than my last and less feature rich because I didn’t use my time as well as I could have. However I did produce something in the end that I was happy with: something that I thought was fun to play. This game does have scope for expansion and I still think it would work really well as a mobile game.

This one wasn’t received as well as the last one (rightfully so). I think this was especially due to the fact that I didn’t have time to include instructions in-game so people would have no idea what was going on. Confusion leads to frustration leads to bad ratings. That and gravity may not be seen as a weapon by some. That and (yet again) it was quite difficult. You can play Gravity on its LD page and browse through its source code on GitHub.

I really enjoyed coming back to game development. While I’m doing a lot of other stuff in the coding world I will always have a soft spot for games because it’s games that brought me to the place where I am now. I’m really looking forward to the next chance I have to participate in a Ludum Dare. The community there is so supportive and they’re rebuilding the platform from scratch to make the competition as easy as possible to get involved in.

Developing games in Haxe was straight forward and fun but I’m still not convinced by the cross-platform aspect. OpenFL has a lot of quirks when exporting to anything other than Flash but they’re getting better. I have been toying with Cocos2D recently, though. I’d much rather be writing games in JavaScript.

Links again

--

--