We all know games, everyone plays games, but do we really know what defines a game? Before we can create a good game we need some sort of definition of it. So what is it? Sure, everything with rules can be defined as a sort of game. But let’s define it a bit better than that. So let’s try!

What would be the most simplistic game you can think of? The first game that comes to my mind is the child’s game “Tagging”. It has two very basic rules: One player is “it” and if you’re being tagged by “it”, you become it. Remembering my years on the primary school’s playground the game had different additional rules all the time. An often used additional rule was “You can’t tag the old “it” back”. Although these were set by us, additional constants where there too. For example the teachers didn’t allow you to leave the playground or trip others. Not a rule set by us, the players, but by our superiors.

The summary of the game? There’s conflict, no-one wants to be “it”. It would be boring if someone wanted to be “it” because of the lack of conflict. The rules define boundaries in the game. The outcome of the game was clear too, the child being “it” at the moment of the school bell lost the game. Katie Salen, a veteran game developer, her description of a game comes to my mind:

“A game is a system in which players engage in an artificial conflict, defined by rules, that result in a quantifiable outcome” (Katie Salen, Game Design Fundamentals, page 80)

If I apply this logic to one of my previous Ludum Dare games, for example, “You only get one” we could describe it like this:

Conflict: the player wants to get home without being eaten while the dragon keeps advancing.

Rules: the player is constraint in a 2D world, there’s gravity, the game is lost when touching the dragon, his fire or falling out of the screen.

Outcome: the player wins when he enters his house (time constraint).

That is quite clear, but how does this apply to popular games like Minecraft? Is it a real game? Let’s try:

Conflict: the player needs to stay alive (retain its hearts)

Rules: the player loses hearts when hungry, the player receives damage from mobs, the game is lost when its hearts are depleted, the player can eat food, can create weapons and armor etc.

Outcome: is there any? What about defeating the ender dragon?

Is the ender dragon really a quantifiable outcome? After defeating the dragon the conflict itself remains, nothing is resolved. The main conflict centers around staying alive, not on the dragon roaming a different realm. Thus, I wouldn’t describe it as an outcome or a game, but more of a sandbox or toy. Though open world games like Oblivion feature some kind of the same freedom as Minecraft, in the end you resolve the main conflict, defeat the bad guy and establishes peace. That’s a clear quantifiable outcome with rules and conflicts.

This is my first of a series of blogs on “What makes a good game”.

What’s your take on the definition? Does it fit mine?

NOTE: So this right here turned out to be way more than I thought I’d be writing, sorry for it not being a 100% Ludum Dare topic. I will be using this language and my game library for future Ludum Dare events, though, so it applies well enough I guess.

This past Ludum Dare I got to use some very fun tools to create my game: A game library I wrote, Artifakt, with bindings to a scripting language that I also wrote, Score. Actually building something like a game using tools I’ve created, especially a whole language, is something I never thought I’d be doing. The event was fun, but not without struggle, so I’m glad I already had upgrades planned for the future.

I’ve been working most on the language, rewritten completely from scratch it’s a lot more efficient when it comes to maintaining proper control of the program and has more flexibility when it comes to the more complicated features I’ve wanted. While the new Score lacks it’s own proper class system like the old one had, the current functionality is actually far greater. Functions, for example, are much more useful and manageable than before.

Here’s a quick example of some of the fun things Score can do, because why not.

This might be a little confusing at first glance, so I’ll go ahead and walk through it.

• Lines 1 and 2 import classes from Java for this script to use.
• Line 4 starts defining a table value. A table in Score is similar to a table in Lua, it stores data in key/value pairs. By default a table doesn’t care about the type of an object.
• Line 5 sets the key in to a new Java Scanner object in the table.
• Line 6 sets the key Input to a lambda function, more on that in a second.
• Line 12 defines two values as the return values of the Input function.
• Line 13 prints stuff. The string concatenation is pretty standard, and the comma separation concatenates the values with a space between them.

So more on that lambda, there. For reference that could just as easily be written as a standard function, putting Input right before the parameter list. Anyway, there’s a lot going on there.

First of it’s defined with the keyword “func” and followed by a list of variables in brackets. This first list is optional and defines specific return values for this function. If no return list is given any number of any type of object may be returned. If a list is given with no names for the values then only values of those types can be returned. here we have types and names, so the state of those variables is what gets returned whenever the function terminates. In this case the function terminates at the end with no early break. These return types, if given names, can have default values. Those work how you’d think they do, they’re initialized to that value rather than null or a type-specific default value (i.e.zero for an int.)

After the return type list comes the parameters, which functions just about how any other parameter list would. You define values separated by commas and have the option of giving them defaults. What’s good to note is that Score will automatically default parameter values if no argument is passed for them, so default assignments have no restrictions on where they can be used.

After the parameters we have the function body. A neat thing that Score allows is that for single line functions the curly braces are optional: func PrintValue(var value) println value; is valid syntax. Functions can also use a fat-arrow to bypass the return statement: func Add(int a, int b) => a + b; will return the sum of a and b. Moving on from things not in the example, this function will first print the given message (or “Input: ” if no message is specified) and then request input through Java’s Scanner class and assign that input to the res return value. When the function returns after that, the value of res and code are returned.

Notice how in is a part of the table but Input can access it without having to reference the same table. In Score, when a function is assigned to an object (or a part of a class, but we don’t have classes yet…) that function has access to it’s container through a this parameter. Access to this is also delegated automatically as if its contents were local variables. Because of this the Input function has direct access to in.


I’ve long been wanting to get this up and I’m very happy to finally present to you the diary of the making of our team’s entry Bionic Bliss!

Friday 8 Dec

After a frantic day at work, I make my way through to Free Lives HQ; the awesome new dev house that the Broforce creators have just moved into. They’ve graciously invited members of the Make Games SA community to invade the house during Ludum Dare 31. By the time I arrive, the house is already packed with friendly faces from the MGSA’s Cape Town contingent, plus a few devs who’ve gone so far as traversing the 2000 kilometers down from Johannesburg to be there. I find and high-five Richard, the man I’ll land up making a cyber-punk customer-support game with over the next three days.

By now, the theme for LD is only going to be announced in 8 hours (4AM on Saturday morning, South Africa time). Richard and I take this as an opportunity to talk about the sort of game we might like to make once the jam starts. The obvious way to do this seems to be with beer, in a jacuzzi, overlooking the distant lights of Cape Town city.

In between a bunch of silly ideas involving a hot-tub-hot-air-balloon, we set up a loose collection of attributes we’d our LD entry to have. We want to do something small; a simple idea that we can quickly complete within the first 48 hours and then polish for the last 24. We want to do something with a significant written aspect. If the concept allows, we’d like to fit in some recorded dialogue. We’re hardly out to win anything, but if our game should do well in any of the jam’s categories, we want to focus on humour.

I have a gig to play. I jump out the jacuzzi, dry myself, get dressed, grab my keytar, high-five my partner adieu and hit the road.

Saturday 9 Dec

I only make it back to Free Lives by mid-day on Saturday. By the time I arrive the house is already buzzing with the energy of 20 or so devs excitedly laying the foundations of their jams.

I discover the theme Entire Game on One Screen, which (as one of my favourite options) makes me pretty happy. Now 8 hours behind (so that our 72 hour game will in fact be made in 64), Richard and I head out into the garden with a pad of paper and an adorable pup in tow. In the next 45 minutes or so, the concept of Bionic Bliss will be born.

To try get the ball rolling, we start by listing some game genres that we’d might like to work within (or smash apart). Dating sim? Single button 4 player co-op? Service game? The ideas that come out of this last option get us so excited that we don’t bother putting forward any more suggestions. Our idea is perfectly in line with the simple rules we set up in the hot-tub the night before. What’s more, the concept has us in stitches, perfectly satisfying the absurd sense of humour Richard and I share.

Our take on the theme will be that the player will experience the game from the point of view of a customer-support chat-center employee, looking at their desktop. You’ll receive a series of complaints from people; it’s up to you whether you chose to help them, or mess with them to get through your boring day at work. Each caller will have a profile pic and mood bar that’s affected by your responses. We’ll have some other supporting details worked into the UI. We’ll set the game in a cyberpunk future. You’ll deal with robotic implant recipients. We’ll have multiple endings based on how you treat people. The endings will play out in the “real world”, beyond the space of the screen. There will be blood.

Some more crazy ideas are thrown around. Your boss will check in on you from via the chat window. He’ll be a dick. You can surf the net. It will be entirely made of cats. Ultimately we choose to narrow the scope of the game down only to the customer interactions and head back into the house with a simple, clear idea of the game we’re about to make.

I fire up Photoshop and start working on designing what our player’s desktop will look like. The result is pretty close to the original sketch we laid out in the garden. Characters are done with pixel art. Text is similarly chunky. I finish things off with some scan-lines and distortion for classic cyberpunk, lo-fi, sci-fi goodness.

Richard gets to work in Unity, building a set of tools that I’ll be able to use in putting together the customer interactions. Primarily, we need to set up something that can input lines of dialogue from our customers and from there link up to multiple response options from the player. Past that, each response needs to lead to new customer dialogue as well as have an effect on the mood bar and possibly activate specific endings.

Next Richard jumps onto working in the UI I designed, integrating this with our dialogue-tree tools. I jump onto laying out and writing our first chat; an absurd interaction with a 300 year old man and his malfunctioning junk. I do this in illustrator, complete with scribbly arrows connecting things up and colour-coded numbers indicating effect on mood. Responses options are generally helpful, bored or mean. I work in a path were you can be a dick up to a point, then help the poor guy out. Given his age, there’s also the possibility of leading the old man around in circles, getting him to keep repeating his problem as you toy with him. I read Richard what I wrote. We laugh.

I get going with the rest of the interactions, but I can feel my wits dulling as time ticks by. We call it a day at somewhere around 3 AM. I pack up and head home. Richard lands up coding till the sun rises.

Sunday 10 Dec

I get back to Free Lives at 2PM. Richard has recently jumped out of bed and proudly shows me that, since we parted, he worked in the text of our first dialogue and we now have some sort of playable experience. A good place to be in, given that we’re just short of halfway through the 72 hours we have.

Jason (the third part of Team Lazerbeam) makes it through as well. He gets to work making the game’s music with his iPad, as he hangs out in a deck chair next to the pool.

I settle back into crafting dialogue. Since I left I’ve had an epiphany; there should be a character who (rather than looking for help) wants you to joke around with them. She’ll be a cyberpunk babe, bored and looking for someone to amuse her. If you do well, she’ll ask you out on a date.

Writing the dialogue for the girl that will become Kiki Kilobyte is a turning point in the game’s development. Creating this dialogue tree, the game goes from a silly extended joke to something much more. Somehow, through Kiki’s responses to options where the player is a helpful , this game becomes a reflection on society turning us into robots. Not physical machines, but machines in mind and spirit. Model employees that do and say as they’re told while faceless corperations strips away our humanity, mind-numbing day by mind-numbing day.

I’m pretty absurdly excited about the game by this point. Music is sounding awesome, we’re making great progress on Richard’s side and Kiki (beyond brining forward some heart-felt thematic weight) has also thrown things in a new direction. There’s now the idea that the “right” response may not be right at all. We also now have two potential endings, one where you get yourself killed and one where you get taken out on a date. We factor in a potential third ending; your terminal is hacked by someone you made fun of. If the player doesn’t qualify for either of these three, we write two more endings in, one where you’re commended for being helpful or one where you loose your job. I’m not sure which of these would be better in this strange dystopian future.

We now have an outline of the 6 characters the player will engage with; the ancient senior citizen, the grammar-nazi, the distressed-mom, the cyber-babe, the juvenile brat and the aggressive “tech-neck”. I bounce between fleshing these character out in writing and working on a logo for our company. Jason has neatly dubbed your employer “Bionic Bitz”.

This in turn finally gives us a name for our game. It will be ironically called “Bionic Bliss”.

As Richard and I power on, we see our friends one by one each break away from their own exciting games and head home or too bed. In the end Team Lazerbeam are the last men standing. By the time I call it a day, I’m almost done with the last dialogue tree; the surprising tricky grammer-nazi. The two of us leave from our workstations to quickly draw up a list of what’s left to be finished before the end of the jam, which is now less than 24 hours away.

I find myself bursting with joy, taking the long walk down the Free Lives driveway as a watch see the first rays of light breaking through the trees above me.

Monday 11 Dec

I work from home for the first bit of the day. I’ve started working on the pixel art for our customer portraits, something I’ve eagerly looked forward to. Jason’s busy on sound effects, and sends me along to Free Lives armed with a flashdrive with most all of our audio on it.

Richard shows me the first build featuring the system booting up and coming to life. It’s looking awesome. I jump onto finishing the last dialogue tree. From there I script the voiceover we’ll need for the terminals interactions with the player as well as the dialogue for our two off-screen endings. I send these along to Jason, who (with the help of our friends Kyle, Limpho & Anja) records these scripts and starts creating a little soundscape for each.

All writing finally in the bag, I fully settle into the portraits. I’m glad I’ve left these for the end. This is not only because it means I can’t afford to spend too long on them (which I knew was a danger) but also because, having written heaps of dialogue for each of them, I can draw on some pretty well established personalities when figuring out how each of our customers should look.

10PM: everyone has a face. I’d have liked to do some shading, but we’re happy with everyone and I need to jump into Unity to start working in these profiles along with connecting up the dialogue trees. I push these over to Richard while he’s furiously racing to incorporate audio and work in all the endings. My last contributions on an art front are an off-screen (for before your terminal is switched on) and a blood splatter to get on said screen if you rub the tech-neck up the wrong way.

1AM: we have (in some form) got our game done. It’s relatively solid, but so very rough around the edges. Endings are half-baked, bits of audio are missing, mood impacts are unclear and we can’t get full screen working. Richard powers through these issues. I spend the last few hours bouncing between preparing our submission and play testing. Because of the multitude of options, this is rather a tall order and I have to play through the game over and over again. I make notes of issues; which of them call for me to head back to Unity and which of them Richard will need to magically fix alongside the mountain of things already on his to do list.

4AM: I send through a submission with a mostly finished (though patchy) Bionic Bliss. After that we realize there’s an hour set aside for submissions, so we spend this time putting a few finishing touches on this bizarre little baby we’ve brought into the world.

5AM: our submission is done and the two of us are feeling on top of The World! Somehow, in 64 hours, Richard and I have made a functional game, that’s relatively polished, funny, weird and amusing. Bionic Bliss exists and it’s something that we’re both really proud of. We head out into the garden, dogs in hand, and take a set of portraits to capture the moment.

I find myself driving home just before 8AM, the morning light falling across my face as all around me people are racing off to yet another day at work. For me, I’ll be crawling into bed, so happy it hurts, looking back on 3 of the best days of my life.

You can play Bionic Bliss here!

I’ve made a new wallpaper for Ludum Dare 31 – feel free to use it! I remembered my first Ludum Dare I felt like participating was like being confronted with a insurmountable mountain, and afterwards I felt like I was on top of that mountain

Just click through to the 1920×1080 version!