Posts

This is the second part of my series about Speedhacking. Last week I looked at the reasons why you should participate, now I’m going to give some tips for beginners.

Are you going to join a speedhack, or other type of game jam, for the first time? Here are some tips!

How to limit your scope

In my previous post, I wrote about how important it is to limit your scope. But how exactly do you do that?

If you’re really a beginner, keep it very simple. If you think an idea might be just doable, cut it in half. Make your own variant of Snake. Pacman. Tetris. These are the type of games that are feasible in a weekend.

Don’t invent everything new, but remake a game you already know. Is it bad to make a clone? Of course not, remaking famous old games is excellent practice. You won’t expect a beginning chef to create delicious new recipes – first they have to master the classic ones. Start with a remake, and if you find some extra time, you can always add your own flavour and twists to it.

It’s best to choose from the genres of arcade games or puzzle games. Arcade games are focused on reaction speed, and usually have just a single screen or a single mechanic that is repeated over and over again, with increasing difficulty. This provides an interesting challenge without requiring you to design lots of extra “content”.

By “content” in mean levels, graphics, storylines. Any genre that requires a lot of that is really tough to pull off in just 72 hours. Examples of these are platformers or RPGs. You may think that it should be possible to program a character like Super Mario in just a weekend. And you would be correct. The problem is that what makes Super Mario fun, are the levels. Designing levels takes time. And the amount of time you spend designing is directly proportional to how fun your entry will be. There is no way to speed up the process. And it eats away from your polishing time.

Schedule polishing time

It’s possible (although not very healthy) to spend a good 40 hours out of those 72 hours making games – that’s an entire work week compressed in 3 days! But working to the limit is a sign that you set the bar to high. With a lower bar and fewer hours of work, you can actually achieve better results.

I’ve seen it happen that participants could only work on their entry for one day instead of the weekend, for reasons (work, life, illness, whatever). And still ended up with a high-ranking little arcade game.

It’s usually not the case that you need a fantastic new idea to make a game work. Instead, what makes a game work is a decent idea with a lot of polish. Making a game fun means polishing it. The amount of time you set aside for polish determines the success.

What is meant by polish? Playtesting. Balancing the game. Take some time to actually play the game yourself. Let somebody else try it. Is it too difficult? Is it too hard? Is the goal of the game intuitive? Add finishing touches. Sound effects and music usually come in last but add a lot to the fun factor.

So instead of planning a game that takes 40 hours to implement, plan for a game that takes 20 hours to implement, then spend any remaining time adding as much polish as you can. The good thing is that usually, this is the most fun aspect of game development. In this phase, every tweak, every added line of code immediately improves your game in a visible way.

How to use the rules to your advantage

It’s easy to see the random rules as annoying barriers that stand in the way of the game you really wanted to make. For example, maybe you have decided that you wanted to remake Sim City. Then the rules are announced, and maybe one of the rules is that the theme must be “Gravity”. What do I do with gravity? How on earth do I combine Sim City with gravity? The trick is not to get too hung up on a single plan. Be opportunistic, not dogmatic. Keep your options open. Be willing to make any of a range of games – arcade games, puzzle games, etc. So maybe you can’t make Sim City. Is that really the only possible game you could ever make?

Another way to look at it is this: Don’t see the rules as limitations, but as stepping stones for your imagination. This is an opportunity to think out of the box. It would be so cool to play Sim City on the flying rocks of Pandoran!

I can’t do art

Worried you can’t do good art? Again, what may appear as a limitation is really a stepping stone for your imagination. Focus on what you do know. Make a game that is focused around patterns of geometric shapes – like for example Circles. Even better, just use only text. There are some really cool games made with just text, like Dwarf Fortress and Nethack.

Make a word puzzle game, or a text adventure. Focus on procedurally generated art. Or use a super-low resolution (but scale it up for modern screens). It’s much easier to generate a lot of art if sprites are only 8×8 pixels.

I’m not a good programmer

Worried that you’re not a good enough programmer? Well, the bad news is, you do need to know some basic programming. Actually, you need a combination of skills to make a good Speedhack game, but programming stands at the basis.

But then again, it’s just a matter of matching the scope with your skills. As long as you’re willing to learn, you can start really small. Can you write “Simon Says”? Can you write “Hang man”? Can you write “Higher, Lower”? These games can be programmed in Scratch! (Unfortunately I haven’t seen Allegro bindings for scratch yet, so that would make them inadmissible to TINS. But you get the point). Combined with the right art, design and sound, you can still make something cool. Perhaps you’re not going to win the competition with these games, but the challenge is purely your own: can you become a better programmer?

Teaming up

Another way around a skill gap is to team up with somebody else. Some competitions, including TINS, allow this. Is it really possible to let teams compete against individuals? How can that be a fair competition? Certainly I’ve seen some very good TINS entries in the past that were made by teams. But don’t underestimate the extra difficulties involved in teaming up. There won’t be enough time to do all the meetings and huddles that usually involve joint programming efforts. You need to be able to rely on each other, and find ways to remove interdependencies so that you’re not constantly waiting on each other.

I’m not saying you shouldn’t join a team. Just be aware of the complications. Teaming up may help you to work around a skills you lack, but requires all of you to have communication skills in abundance.

Here’s that promo bit again

So, did I convince you that it’s feasible? Do you think you can do it?

Why not give it a try? The next TINS competition will be held from October 20 to 23. Head over to tins.amarillion.org, register and sign up!

Speedhacks (a.k.a Game jams), are competitions where you design and implement a complete game, from scratch, in an extremely short time limit (typically one weekend, or 72 hours). I’m a frequent participant and organizer of these events for the Allegro community (including the upcoming TINS competition, more on that below). I found them to be incredibly educational and fulfilling, and they’ve allowed me to grow as a developer. Here is why you too should participate in one.

Getting things done

Making a whole game in 72 hours, how crazy is that? For those who ever tried, the prospect seems daunting.

Starting from early high school days, I’ve always wanted to make my own games. I was endlessly doodling level designs, and I had reams of elaborate technical notes. It was disheartening to look back at all those plans and aspirations, and see how little came of them.

That feeling changed after my first Speedhack. For the first time I realized that, yes, I actually can make all these ideas come to life. Of course there are limits to what you can do in a weekend, but actually making something playable, as opposed to lots of half-hearted attempts and interminable projects, is extremely gratifying and a very powerful motivator.

The problem is that you can’t really show off a stack of design notes. Maybe you get some props if you have some cool drawings, but more likely your peers will recognize it for what it is: vaporware. A short playable arcade game is a lot cooler than the epic game that merely exists on paper.

So how do you pull this off? You need developer skills, to be sure, but perhaps less than you think. What you need first and foremost, is to learn to limit your scope.

Limit your Scope

In Extra Credits, game designer James Portnow talks about scope as being one of the six skills that game designers should learn.

Every budding game developer is really a gamer who thinks: it would be so cool to play a game that is a role playing game combined with real-time strategy, with lots of mini-games and cowboys in space. And it should have dragons and magic and tons of weapons to choose from. You know what, I’m going to make that game myself! It’s so easy to fall into this trap. You design something grand and majestic that completely fails to see the light of day.

Where does it go wrong?

Know your limits. Even if you had all the skills required to pull off a grand project like that, it’s just so hard to stay focused on a single project for years on end. Work or school or other real-life obligations intervene. Instead, plan for just the amount of time that you can completely oversee. Speedhacks teach you to work with a short time horizon. You can shield yourself from distractions for 72 hours.

Constraints make the creative juices flow

Would you like to make games, but can’t come up with ideas? Are all the cool game mechanics already taken? There is nothing like an imminent deadline to get the creative juices flowing. In the words of Calvin: you can’t turn on creativity like a faucet. You have to be in the right mood. That mood being: last-minute panic.

At the start of Speedhack, random rules are drawn from a predetermined set. Your game has to adhere to these rules to be a valid entry. For example, a rule may say that it has to be a puzzle game. Or that it has to have snow in it. Or that you can only use hand-drawn assets. Theoretically, the rules are there to prevent false starts. The idea is that you can’t start on your game before the rules are known, so nobody can take an unfair advantage by starting early. But really, the rules just add to the fun.

Rules force you to come up with crazy ideas. For past Speedhacks, I’ve come up with a platform game set inside a laundry machine, a space shooter where you have to defend Mars against the attacking Earthlings, a puzzle game where you have to choose a matching outfit from a perilous walk-in closet, or a two-player co-op battle game inside a space cheese. Coming up with ideas is not a talent that you’re born with or not. Its a skill, that you can practice. And Speedhacks are a great way to practice.

Community

If Speedhacking is so great, why don’t you do it all the time? If you can make a game in a weekend, why don’t you make a new game every weekend?

You can’t without motivation. Here is where the community comes in. Locking yourself away for a weekend may not seem like a very social activity, but it is. During a competition you interact with fellow Speedhackers. Reading the progress reports from others is fun while you take a break from an intense hacking session, and creates a shared experience. The fact that others will be waiting after the deadline to play and review your game, motivates you to not let them down.

The community is your carrot and your stick. Failing to finish feels a bit like breaking a promise.

Oh, the things you will learn!

Speedhacks give you a chance to learn new algorithms, experiment with new techniques, or try out ideas with a prototype.

Have you never applied the A* algorithm? Here is your chance to try it out! Always done hand-pixeled art and want to try your hand at some vector graphics? Now you have the perfect opportunity to do so. Do a Speedhack every so often to broaden your skillset.

Even if the game you make never ends up being more than a prototype, more often than not you’ll find ways to apply the things you learn later on during your working life. I first used A* for a train routing game I did for speedhack, but later found a use for this technique in a project for work.

So where do I sign up?

Nowadays, there are plenty of Speedhacks and Game jams being organized all over the Internet. Some focus on particular retro systems or screen modes. Some are face-to-face. One of the oldest and most famous ones is Ludum Dare, and it attracts tons of participants every time.

Invitation to TINS

As mentioned before, I organize a Speedhack semi-anually, called TINS. It is going to be held again over the weekend from October 20 to 23. One thing you should know is that it’s organized by the allegro community, and therefore using allegro is a requirement. Allegro is one of the most widely portable libraries, ranging from android to Windows to Mac. Head over and sign up!

The idea is also called “Implicit tutorials”, and is an important concept in game design. There should be no need for a manual (nobody reads it anyway). The less explanation, the better. By gradually introducing game elements in a clever way, the game should just explain itself . Super Mario World 1-1 is a very famous example of this.

The first demo of the evening was by Jeroen Wimmers about the game “Circles” (See the screenshot above). It really drove home the point of implicit tutorials. Circles is what you may call an example of “Constraint-based game design”, the constraint being that everything, every single thing, is a circle. Start of the level: a circle. Goal of the level: a circle. Level select menu – a bunch of circles. In a relentless drive to eliminate shapes with corners, explanatory text has no place. How does the player know that you’re not supposed to touch certain circles? Jeroen showed how he went through dozens of iterations, trying different visual cues (trembling, disappearing, expanding), keeping this and reverting that, until the game was crystal clear. Circles is out on steam if you want to give it a try. (There is a free demo).

Another talk on a very similar topic was about Reggie, by Degoma games. Reggie is a tomato with the ability to reverse gravity, in a cool little platformer. This game similarly went through several design iterations, incorporating feedback from players at conventions, until finally the mechanics were universally understood. You can watch the entire talk on Youtube:

But there is a downside to implicit tutorials. A tutorial can slow down the pace and make players give up before they get to the good parts. I can think of a few recent games that suffer from this.

I myself was there to present Happy Usagi. There is no recording of the talk. But I showed this movie which is also on Youtube:

While showing this video I explained that the game has an “altitude-bonus” mechanic. It works as follows. When your bunnies are happy and well-fed, they jump more. For each jump, you get points. The points are multiplied by how high the bunny is. For a jump at floor level, you get 10 points. A jump on a stack of four blocks tall rewards you with 40 points. This mechanic encourages you to build. By building higher, you make each jump worth more.

The audience asked me this insightful question: “How does the player find out about this mechanic?” After all, how can a reward incentivise players to do something, if they don’t know that there is a reward? The truth is that this is an area where the game can be much improved. I did add a small hint: When a bunny jumps, a number appears at that spot to indicate that points were scored. But it’s very easy to miss the connection between score and altitude. To a casual observer, it seems the score is calculated pretty much at random. Here the player needs explicit explanation.

So that is some very useful feedback. And that’s what made this event so great – not only to have the chance to present our work, but also to get feedback from fellow game designers, and to learn more about game design.

Just a quick post to show what I’ve been working on. I finally managed to get Happy Usagi to run inside an android emulator:

This is a huge step! So far I’ve only made games for Windows and Linux. Getting them to run on Android has been a major goal when I started this journey. Unfortunately, it is not trivial to get C++ code to run on Android. That’s why I’m happy to show you this progress update even though it’s far from complete.

Wouldn’t you like to see the game on the Android App Store? I know I would 🙂 You have to be patient though. There is still a lot of work to do. Besides bugfixing, I also have to rework the game to a touch-based interface.

But when all that’s done, you can keep virtual bunnies in your pocket!

As I mentioned at the start of this blog, in the future I want to focus on creating educational games. The term ‘educational game’ means different things to different people, and it’s also somewhat of a buzzword nowadays. Here I want to explain what ‘educational’ means to me. What type of educational game would I like to make? I’ll try to answer that by comparing with a few examples.

Is Pacman a good educational game?

As a counter-example, let’s start with a well-known game that is not usually considered very educational. Pacman. If you think about it, there are many skills to be learned from playing Pacman. Timing and reaction speed. Hand-eye coordination. Basic spatial thinking. Pattern recognition. Each of the four ghosts moves according to predefined patterns, and recognizing those patterns is the key to mastering this old classic.

According to the book ‘a theory of fun for game design‘, humans play games to learn. Playing behavior arose during evolution so that we could practice life skills in a safe setting. Each time you escape a ghost or eat a power pill, you are preparing for an encounter with a lion on the prehistoric savannah. You learn, and your brain rewards you with a puff of endorphins. We call this fun, but really, biologically speaking it’s indistinguishable from learning.

So all games are educational in some way. The only problem is that many action games teach paleolithic skills. Reaction speed. Battle tactics. Aiming a weapon. Territorial dominance. We still get the fun from learning, but what we learn does not prepare us much better for life in the 21st century. Gaming is a waste of time, not because we don’t learn from it, but because we learn mostly outdated skills.

Is Portal a good educational game?

Yesterday at the Amsterdam game developer meetup, we discussed educational games. Portal, the 3D puzzle game with mind-bending physics, came up as an example of an educational game. One of the puzzle-mechanics in this game is conservation of momentum. Apparently Portal has been used in a classroom setting, to teach this physics principle to students.

I don’t think Portal is the kind of educational game I would like to make. To me, there are two problems with it:

First, conservation of momentum is only a small part of the game. Yes, there are a few puzzles that are incredibly hard to solve if you don’t apply this concept properly. But if you want to teach, then the other 90% of the game gets in the way a lot. Portal was never designed as an educational game. It was designed as a fun puzzle game that coincidentally happens to use a few classroom physics concepts.

Secondly, it’s a very limited use of the endless possibilities of games. Conservation of momentum means: an object in motion stays in motion until a force is applied to it. This is a concept close to daily experience, almost intuitively understandable. There is no need for expensive optical equipment to study it. There is no need to take the class on a field trip to a distant museum. Just a soccer ball is enough to demonstrate it. All the tools needed to make the concept insightful are already at the teachers disposal.

And we can do so much more than that! Games allow us to open up entirely new virtual worlds where we can shrink to microscopic size and move through the human body (biology), walk around in ancient Rome (history), simulate entire cities (geography).

That is not to say that teaching through games isn’t a great way to liven up a boring classroom. But then you’re reducing the gaming aspect to just a gimmick, a psychological trick to maintain attention. When I was in high school, in English class we were rewarded with five minutes of watching Mr. Bean at the end if we paid attention the rest of the time (I suppose the intention was to convey English culture, because Mr. Bean doesn’t convey much of the English language). There is nothing wrong with this approach per se, but it’s a relatively poor use of the possibilities of games, and not the type of educational game I want to aim for.

Niche

Let’s get to one of my favorite educational games of this moment: Niche.

In Niche you control a group of fictional mammals, and by properly selecting pairs of animals to breed, you can slowly improve the fitness of the population: stronger claws, better hearing and eyesight, better resistance to heat or cold. You make your group more resistant to predators and the environment. The more you play, the more you learn about genetics. The more you learn about genetics, the better you get at the game.

Niche teaches concepts from population genetics without being explicit, without being too teach-y. The students are just playing a fun game where you have to protect your tribe of cute furry animals. Slowly, as you get better at playing the game, you start to recognize the game mechanics. These happen to work by simulating real-life biological concepts. By getting good at the game, you slowly develop intuition for genetic principles, such as phenotype and genotype, recessive and dominant alleles, mutations, disease resistance, incest and inbreeding, natural and artificial selection, survival of the fittest.

Not only that, but it is plain fun to play! Don’t take my opinion for it, just take a look at the reception on Youtube. Both fun and educational, what more could you want?

Future work

In short, my “sekrit project”, my future educational game should have these features:

It is fun to play and not overly pedagogic.

It teaches advanced modern concepts that go beyond the reaction speed, the fighting and territorial dominance of action games.

And it makes use of the possibility of virtual worlds to visualize hard concepts, to take something that is not intuitive, that is remote from everyday experience and find a way to experience it.

By the way, I’m always looking for interesting examples of educational games. Know another good one? Leave a comment!

This Easter holiday I took a break from working on a game about bunnies, so that I could…. work on another game about bunnies. Apart from the bunny aspect though, it’s actually a very different kind of game. It’s a text adventure.

The game is called B.U.N. (Bunny’s unbelievable narrative), and it’s like a choose-your-own-adventure book. At every step, you’re presented with a situation and you have to choose where to go next. Here is a video demo (kindly created by Gideon Weems from the allegro community):

I expanded the storyline significantly since the initial release in 2015. The game is ready to be played now, and should prove a fairly challenging puzzle.

Text adventures are the oldest genre, the ‘silent picture’ of video game history. It’s a classic genre that is nowadays overtaken by much more flashy and glammy genres, such as the kill-everything-in-sight genre and the wage-war-against-the-whole-world-genre (I’m just kidding here, I love playing DOOM). Text adventures stem from the mini- and microcomputer age. It’s no wonder. A picture is worth a 1000 words, but 1000 pages of text use the same memory as 1 picture. This mattered very much in the days when it took about two noisy minutes to load a single picture from a cassette tape (notice how the colors are loaded separately from the b&w image in that video. It’s soooo slow!)

To spice things up, I did add some (very simple) graphics and graphics effects to B.U.N. The way text is mixed with graphics is directly inspired by the classic Hobbit adventure from my old ZX Spectrum.

“Hallway usability testing” means doing a quick usability test with somebody you found in the hallway, or in this context, my little nephews during a family visit. Let them play and observe how they cope with your software. Can they figure out the game without instructions? Do they get stuck somewhere? Are they struggling to make the user interface do what they want?

I did a whole bunch of informal testing like that with Happy Usagi, and one of the problems I observed most frequently was that players were struggling to place blocks in a 3D environment.

For example, you can place a block on top of another block, or behind one. The block cursor indicates where it is going to be placed after you click. This block cursor is always shown on top. After all, if it was drawn behind, you can’t see it and it’s not much of a cursor, is it? Behind or on top, the cursor looks exactly the same, and this caused a lot of confusion. I did add green guidelines to indicate the position of the block relative to the floor, but these indicators were almost universally misunderstood. So: big usability problem.

Hallway usability testing is a great way to check your assumptions. You may think that the green guidelines are obvious and that people will figure them out soon enough. Well no luck, after observing the same issue over and over again, it was time to stop blaming the user and think of a different solution

Lets take a step back. Why do we have a 3D environment in the first place? Maybe it’s an odd choice for a casual game. Happy Usagi was inspired by Neko Atsume. In that game you have to collect cats, and the user interface is simple and easy. You’ll have no difficulty at all controlling it on a tiny phone screen. But no wonder, the cats never move around and can only appear in certain predefined locations on the screen. The Neko Atsume world is a static image with cats stuck on them in fixed locations, a bit like an advent calendar for cats.

For Happy Usagi, I wanted the bunnies not just to sit there like lazy cats, but to do something; to hop, run, slide, and generally move about. And that means the game world should be an actual three dimensional model. This is a challenge.

I came up with the following solution for the block placement problem. I radically altered the block cursor. Instead of just a block, the cursor now has a bright beam that extends upwards. This way you can still (kind of) see the cursor even when the block itself is occluded. The video above should make the difference clear.

Does this actually help usability? First tests (done on Olivia) are hopeful. But again, you should check your assumptions. I really won’t be sure about this until my nephews have played it.

Well that makes a lot of sense! Usagi is simply the Japanese word for rabbit. Yuki means snow, and No is a possessive marker. As a Gaijin, I couldn’t tell you if that translates to “happy snow-rabbit fortress, or “happy rabbit of the snow-fortress”. I guess we’ll find that out after we conquered the Japanese market (yeah, right). But in the mean time, I hope the name conveys fun, cuteness and also a bit of silliness.

Why the Japanese angle, you ask? Apart from us being a big fan of all things Japanese (from Nintendo to Kawaii bento boxes), there is also serendipity. We created the game during a competition – one of the random requirements of this competition was to include bits of Unicode, i.e. non-English text. Like so: 幸せなウサギの雪要塞. Easiest requirement ever.

For the next version of Happy Usagi, we are giving each bunny its own look. I say “we”, but actually most of the hard work is done by Olivia, graphic designer and source of inspiration for many helixsoft games.

Would you like to hear details on how we draw the graphics? For Happy Usagi, the bunnies are drawn with the very cool aseprite editor. It has all the features you might expect from a pixel art tool. Especially useful for us is that you can export each layer as a separate spritesheet. I programmed the game to recolor and recombine the layers again in every possible way. For example, a layer for spots, a layer for droopy ears and a layer for upright ears can be recombined into a brown bunny with grey spots and droopy ears, or a white bunny with brown spots and upright ears.

NB, I’m experimenting with sharing on social media. Like I said in the first post, I’m trying to figure out the best way to do this. If things are not to your liking, let me know, I can tweak it for the next time.

Come and join me on my quest for the holy grail! Or in this case, my quest to develop and independently publish computer games! Ni!

Developing games is my passion. When I was a kid I already wrote my own version of tetris on a ZX spectrum. In more recent years I have written several small PC games. Most of these were created during weekend programming competitions, a.k.a. speedhacks. These are always fun to do, and the result is usually interesting and sometimes even entertaining! But they also tend to be somewhat simple and incomplete.

Now I want to take it to the next level. I don’t want to just make games that are “fun for five minutes”, after which you can lean back and appreciate “how cool that it was made in such a short time”. No, I want to turn these into games that are lasting fun, maybe even addictive, and certainly worth paying for.

With this blog, I want to show my progress. I want to document my inroads into the indie gaming business. And I want to use this blog as a way to gather feedback, to find out if I’m going in the right direction.

So what are my plans? At the start I’m going to be opportunistic, and work with what I’ve got. I’m expanding one of the most promising speedhack games: Happy Usagi No Yuki Fortress. So at first you can expect a lot of posts about this game.

My long-term plan is to shift to a particular niche, namely computer games that are “Educational”. That term may mean different things to different people, so I will definitely follow up in a future post to explain what the term means to me. And I’m working on a “sekrit project” that is going to be an educational game. In due time, you’ll hear all about it, right here on this blog.

I’m looking forward to comments! I’ll publish this blog on various social media, so you’ll know about it. But which social media would you like to see this on? And what would you find most interesting to read about? By the way, what do you think of the graphics in the header of this blog? I’m figuring this out as I go along, so please let me know!

Search

Search for:

About This Site

Hey! My name is Martijn van Iersel and I work as a part-time game developer. This blog documents my efforts to develop and publish games.