When I'm not tooling around on the Internet or making my indie games (see my earlier blog entries), I study computer science with an emphasis on game development and more specifically interactive storytelling. The Walking Dead was my favourite game of the year and in my opinion one of the best examples of how games can tell uniquely effective and gripping stories in a way other mediums can't touch.

I was so impressed with the game that I wrote a 10+ page essay on why and how The Walking Dead does such a great job. The essay was originally for a university course on interactive storytelling, so it can get a bit academical but I tried to keep the tone light and readable. That's just how I roll.

Anyway, great game, and if someone gets something out of this essay, great. Either way, let me know what you thought! Read it at: http://haxor.fi/~ml/published/ACaseStudyTheWalkingDead.pdf

I was listening to the Tested Oktoberkast again, and ran across Will and the others discussing programming, and how they'd tried it in college but ended up getting frustrated and quitting. They lamented the fact that you had to know so much math and other difficult stuff, and it bummed me out. Then it made me a bit angry. Not because they were wrong (they were), but because I remember thinking the same way three years ago, as I was applying to a university to study computer science. I thought to myself I could never really do it, because I've always sucked at math and you had to know a lot of math and other difficult shit, right? WRONG!

Three years later my indie games development team and I have released six games, five of which were coded in part or fully by me. I've coded up several tools to help me in my daily tasks, both on my desktop computer and mobile devices. I'm fluent in Javascript, Python, Java, C# and a bunch of other languages. Sounds impressive and difficult, right? Well it's not difficult! First off, let's bust some programming myths.

MYTH 1: You have to be REALLY good at math.

Bullshit. True, if you want to be the next John Carmack and code up 3D engines, you have to be fucking awesome at math. If not, it's really not that important. You have to understand the concepts, especially if you want to get into games development, but here's the fun thing: you don't have to do the actual math. That's what we have computers for! True, you have to understand what vectors and quaternions are, but you don't have to know those things NOW. You'll look them up when you need them, and surprisingly you'll be able to learn the concepts really quickly, because you have an immediate and fun application for those skills.

MYTH 2: Learning to program is really hard

Bullshit. Learning to program is easy as piss. The difficult part is learning to THINK like a programmer. This is called algorithmic thinking, and it's a fancy way of saying "you need to know how to break down abstract concepts into simple logical steps a computer can follow". And to be perfectly honest, this is not something everyone can do. I've seen people who just can't bend their brains to this kind of thinking, and it will always trip them up. But if you can do it -- and chances are you can -- the next step is surprisingly simple.

I know programming seems really hard on the surface. Code isn't always easily readable, there's lots of strange terms and words everywhere and the syntax seems crazy. But it's not as bad as all that. Most modern programming languages follow the same general rules, so once you learn one object-oriented language, you can learn the syntax for others pretty quickly. And remembering the thousands of different commands? Don't worry about it: you're not meant to know it all by heart. That's why we have big libraries full of API references. The idea is that you look up precisely how what you need works, and then after a couple of uses, you'll remember it. It's like learning any other language: nobody knows all the words at first without using a dictionary!

MYTH 3: Even if I learn to program, I can't make games

Bullshit. Making games has NEVER been as easy as it is now. Freely distributed tools like Unity and XNA take the tough part -- the engine -- out of your hands and leave you with the fun stuff: coding up your actual game. XNA only supports my favourite language, C#, but you can code games in Unity with a variety of languages, including Javascript, which is the coding equivalent of a kiddie bike with training wheels on, riding a rail.

Of course someone will have to make the 3D models or paint the sprites your game will use, but that's not your problem: you're the coder. And trust me, because many people believe that coding is something only geniuses or madmen can do, people will be tearing your underwear off trying to get you to join their teams.

Here's how to do it:

So now that we know coding is actually something you could realistically probably do, how do you actually go about it? Well, here's how I did it: I went to university. Imagine sad trombones here going "womp womp", right? Don't be too hasty. About 90% of what I've learned is stuff you don't have to worry about unless you actually want to code shit for a living, and possibly not even then. You can learn the important stuff yourself, and really easily.

The Internet is full of guides, manuals, courses, exercises and other tools which will help you learn the actual art of programming. The big tip is not getting discouraged too easily. It will seem daunting at first, but if you pace yourself, you'll get it in no time. If I had to do it all over again, here's how I'd do it:

1. Learn a simple language, like Javascript or Python. They are both extremely easy as far as syntax goes but still allow you to do all kinds of fun stuff. The idea is to use these languages to get used to thinking like a programmer. Taking a task, breaking it down to logical steps and then executing these steps. The net is full of fun guides you can use to learn what methods, arguments, return values and other such things are.

The additional benefit is that both languages are VERY useful. Python is a widely used scripting language, Javascript is used in literally hundreds of thousands of websites AND is one of the languages Unity uses! So you can take what you learn here and start making games!

2. Once you feel comfortable, stretch your wings a bit. Look into a more structured, strongly typed language like Java or C#. The fun thing here is that both are EXTREMELY similar as far as syntax so once you know one, you can learn the other in literally a day. These languages are hugely powerful and extremely useful: Android phones use Java natively, Windows Phone 7 (and anything Windows related, and Unity) uses C#, so you'll have a whole new world ahead of you. C# also gives you a good launching off point to learning Objective-C, which is what Apple devices use, and C++, which is what the gaming world uses.

I wouldn't recommend starting off with either of these languages, as they are a lot more formal than Python or Javascript. Mastering them is essential later on, but if you try to jump into them immediately, chances are you'll get frustrated and walk away.

3. Always do something fun. Programming is a skill like any other. You won't learn it unless you use it, so always be coding. You'll learn the basics really quickly, and after that only your imagination is the limit. Try to think of fun applications you could use yourself. Not only will you constantly learn new things, but you'll keep yourself interested, because what you're doing is fun.

I coded up my first game, a simple text-based hockey manager game, in Java after a couple of months of learning, and I could've done it earlier if I'd believed in myself more. The secret to programming is that you're not supposed to know everything ahead of time. When you come across something you don't know, look it up and learn. Don't get bummed about what you don't know, get excited because you're about to learn something new!

This blog post is long as shit, and I applaud you if you made it all the way to the bottom. I could've condensed this all down to this: if someone tells you that programming is too hard for you, call them a lying piece of shit, because that's what they are. It's a skill you can learn if you apply yourself, and it's a skill you absolutely SHOULD learn. Even if you don't make a profession out of it, you'll find no end of uses for your new skills. If you think playing games is fun, you should try making them. And I really mean that: you really, really should.

On the off chance that someone actually read all the way to the bottom, if you have any questions at all, I'll be happy to answer them. I'm not John Carmack, but I am a guy who learned to program after thinking for most of his life that he couldn't.

Remember our game about typing at a bunch of annoying kids? No? Well, you're joining us at a great time, seeing as the game just updated earlier this morning. Version 1.2 brings about a bunch of adjustments and a whole mess of tuning, most of which isn't immediately obvious. What will be immediately obvious, though, is what happens when you complete a campaign level. I don't want to spoil the whole thing, so I'll just leave you with this.

Yes, in case it wasn't already bleedingly obvious, The Typing of the Dead was a huge inspiration on both the concept and the gameplay.

In case you're too lazy to check out the other post, the game's at http://typehard.haxor.fi

And there's a trailer too, made by fellow Giant Bomb user Firehawk!

http://www.youtube.com/watch?v=hlssmnPo_F4

The results are in! The Assembly 2011 gamedev compo is over, and we placed 3rd out of 16 entries! Very happy about this!

It's summer again and that means the Finnish indie development scene had something to aim for: the game dev competition at Assembly 2011, one of the biggest demo scene events / LAN parties in the world. We participated last year, and we're doing it again. Only this time our game's a bit different.

Our initial idea was that we wanted to incorporate the style of The Typing of the Dead, where you have to type words at a rapid pace to make something happen. The original plan was to make a sort of interactive movie (bear with me!) where you were an actor doing various action scenes and had to type in action catchphrases and stuff like that to make your guy dive through windows, shoot down helicopters etc. As fun as this seemed, we also quickly realized we'd need far too many assets (graphics, animations etc) to make the game work.

So we settled on something else. One of the long-standing traditions at Assembly is the schism between gamers and demo scene guys. The various competitions are a big part of the party and everything is screened on the big screen. Which is in the same area as most of the people with their computers. So every time a competition starts, there's a long battle where people from the stands yell obscenities at kids who just can't turn off their fucking WoW raids for 10 minutes to watch short films, demos and what have you. And that's our game.

You're the head of security at Assembly and a compo is about to begin, but the power of "Guage" (a reference to Quake, which used to be the game of choice for these morons to play) is too strong, and kids are going hyper in their seats. You have to yell increasingly difficult words at them to make them turn off their machines, before the organizers lose patience and shut down the party forever.

We bolted on some leaderboards, achievements and start tracking and called it 1.0. Version 1.1 is coming this Sunday with some fresh twists that will, I think, warrant the last the tag I chose for this post.

So anyway, try it out and let us know what you think!

EDIT: We just updated! Version 1.1 brings a whole mess of changes, some visible and some less so. There's now a lot more visible feedback when typing in words and completing them, plus the game should run a bit snappier than before. Give it another shot!

Up until very recently, I've only been coding up stuff for PCs. Mostly in C#, but also in Java, Python and the like.  
 
Recently it dawned on me that I'd bought an HTC Desire phone last summer with the intention of developing software for it. I've been interested in mobile development for ages, but never just bothered learning the tools used by Nokia, Ericsson etc. Android was supposed to change all that, but I never just got around to it. Until recently. I realized that I'm finishing my third year of school and will soon have a bachelor's degree in computer science.  It would probably improve my chances of getting employed, if I could whip out a mobile portfolio in addition to the full-fledged games I've developed. 
 
So, last Saturday I downloaded the necessary software, configured Eclipse (eurgh, why'd it have to be Eclipse? Why couldn't Google design their SDK plugins for Netbeans) and got to work. A couple of hours later I had a simple program which displayed cat pictures. When you press a button, a new cat is shown. Simple. It also demonstrated that mobile development is extremely easy. On Android phones it's just Java with a couple of funny terms thrown in. Of course that is just a tiny part of development in any system. Syntax is syntax, but you have to understand the APIs and the system's limitations. 
 
Step by step I'm improving my skills. The first thing I wanted to focus on was UI design, as that is the part of the process that was the most alien. On Android you don't just say "put a button at 100x, 150y", and as it turns out, for good reason. 100x, 150y won't be in the same place on different phones, for instance. Instead you basically create layouts, which are more dynamically laid out pieces of UI that get anchored to, say, the top left corner of the screen. And then everything is laid out in relation to the parent element. Designing more complex UIs in this form was a bit of a puzzler, but I figured it out once I stopped thinging of layouts and started thinking of trees. No, not the ones with green on them. The ones you learn about in algorithms and data structures.  
 
And so. Here is my second app ever. The Munchkin Battle Counter: 
 

As those who have ready my blog posts before might know, I'm an indie game developer. We're currently putting the finishing touches on our fourth game, so I've been thinking a lot about game design. One of the things my thoughts keep returning to is how the different media of games are best suited for different kinds of games. When I say different media, I talk about board games, tabletop games, computer games etc. 
 
It might be easy to think that video games are pretty much the number one choice for almost any kind of game. After all, graphics bring the vision to life, the interaction is concrete and if you so desire, you can multiplay with people from all across the world. But is it really always so? 
 
The thing that really prompted this line of thinking was the book "The Defence of Duffer's Drift", by    Major General Sir Ernest Dunlop Swinton.  He wrote it while serving as a young captain serving in the Boer Wars. The gist of the book is that Lieutenant Backsight Forethought has been tasked to lead a company of 50 men to defend Duffer's Drift, a small and remote river crossing in South Africa during the Boer Wars, so it's obviously based on some lessons Swinton himself learned and intended as a learning tool for other young officers.
 
The book opens up with the Lieutenant laying out what he considers to be a good camp near the river and then turning in for the night. When he wakes up, a group of Boer soldiers has ambushed the camp and are slaughtering his men. As he's taken captive, he thinks about what just happens and distills his failure down to a couple of key lessons, like "always assign sentries" and "always complete the defensive earthworks immediately, even if your men are tired". Then he's transported back to the beginning of the story with these lessons in mind, and tries again, getting slightly ahead each time and repeating over and over, always with a bit more knowledge. 
 
I discovered the book through the excellent Three Moves Ahead podcast after one of the hosts had participated in a gaming session inspired by the book. A game master ran a combination of a miniature wargame and RPG for a group of 15 or so players. The first player went into a Duffer's Drift scenario with no information. Of course he died quickly. But then he had a chance to pass some information to the next player, like "beware the friendly farmer, he'll betray you to the enemy". Then the second player would give it a go before passing what he'd learned on to the next player. 
 
This was one of the coolest things I've heard and something I really want to try some day. But it also made me think of how poorly such a clever game idea could be translated to a video game. Of course it could be done. Design and present a scripted scenario on a multiplayer server, where one player at a time gets to play. After he dies, he has a bit of time to pass on his lessons to the second player, who then jumps in to play.  
 
It could be done. But should it? Due to the nature of the game, the non-playing players shouldn't be able to spectate or the game becomes trivial. After all, a key part of the challenge is for the dead player to decide what information he needs to pass on in a limited amount of time. So how do they pass the time? By staring at some information? By chatting to each other?   
 
Beyond this, how would the actual game work? As a light wargame? Or a simple puzzle game, where figuring out what to do step after step is the challenge? If you really wanted to give it as much atmosphere and depth as a well-narrated RPG could have, the layers and layers of different gameplay elements and styles required would make the process hugely complicated and would almost guarantee that some parts of the game would fall flat.
 
No, I think this is a clear case where just because we COULD make the game into a video game, we shouldn't. The game would work a lot better as it was presented to the Three Moves Ahead host, a unique blend of two different ways of playing games. Just like a Madden tabletop RPG wouldn't really work, this is a game concept that doesn't really lend itself to video games. 
 
Or does it? Maybe I just haven't figured out a cool way to do it yet.

The relative disappointment of finishing fifth out of 19 games at Assembly 2010 has worn off, so we're back in the saddle with another game. First let me preface this blog post by saying I HATE the expression "... but with a twist". If you have to describe whatever it is you're making as that, chances are you're not creating anything worth creating. 
 
But still... That's pretty much all I can say about our game right now. It's a tower defence game ... but with a twist! Actually it's more of a tower defence game crossed with a tamagotchi, some light adventure game elements and a whole bunch of humor. The game is called "My Little Sentry Gun" and we're in our last stages of pre-production right now. 
 
As the de-facto lead coder on the project I've been busy knocking up a playable prototype that has some of the elements we want to include in our final game. Right now that means our pretty nifty and very cute sentry model, a whole hell of a lot of cubes and a low res grass texture I pilfered off the Internet. It'll get better, we've still got weeks to go before our deadline. 
 
I know last time around I promised to keep a journal of my trials and tribulations with Unity 3D, but that kind of fell by the wayside. Maybe this time I'll actually stick to my guns and get it done. Unity 3 is out and we switched over to that, and while we were switching things around we jumped from JavaScript to C# for our code, because we love object-oriented programming and always have to do things the hard way (not that C# is hard, but there are syntactical differences that make it a learning experience all over again).
 
Anyway, this spawning system isn't going to code itself so I guess it's back to Unity 3's pretty excellent IDE for some more code. I'll leave you with this, our first promo image.
 

To spend 3,5 months of your life pouring your heart into a game only for nobody to care. 
 
Well, that's not entirely accurate, but I will say that I suddenly have a lot more sympathy for game developers. As a game reviewer I long ago learned to keep in mind that the games I review, no matter how terrible, were usually created by people who were doing their best. Sometimes they get screwed by the situation surrounding them (no funds, rushed schedule), sometimes they just take a bite they can't swallow and get overwhelmed. This is why I try to be courteous and offer feedback and honest critique in my reviews. But I digress. 
 
On the 25th of July we shipped our second game, "Dr. Funkenstein's Bad Ass Rocket Jump Challenge". It's a physics based platformer where you rocket jump around an alternate dimension London, fighting aliens. It's set in a kind of cheesy, tongue in cheek 70s world of funk. We like it, everyone who played it really likes it and after our polish rounds we received pretty much only positive feedback (but there was a long period where that wasn't the case! The last 10% of the game really does take 90% of your time if you do it right). 
 
 The end result? The game participated in the 2010 Assembly Game Development competition. And few people cared. Now, to be fair it seems that the current crop of Assembly attendees care more about World of Warcraft, Counter Strike and watching porn behind mom's back than they do about the scene, but it really bums me out. There were a lot of good games in the competition and from what we've seen walking around the main floor, very few people are playing them. 
 
This is only a half-truth, though. Dr. Funkenstein has an online scoreboard component where your best times are stored in our SQL database and scores are retrieved for comparison after each run. This is a fun feature, but it also allows us to keep tabs on how many people have played the game. Between the 25th of July (when the Game Dev entries were officially published) and the 5th of this month (when the party began) we had roughly 80 unique IP addresses and 1,100 recorded run times. This number peaked higher at times but after we did significant changes to tracks we purged the times so the various exploits wouldn't stand.  Right now, on the third morning of Assembly? 282 unique IP addresses and 2,582 recorded run times.  
 
I'm pretty happy about this, considering our last game ever got played by roughly 30 people and the data shows that once someone does play the game, they stick around for a while. Still, I was honestly hoping for more. I think our game is good. It's not perfect, but I still have fun playing it and I've been testing it daily since early May. 
 
Want to give it a shot? http://funkenstein.haxor.fi 
Want to be the 31st guy to play our humorous space adventure, "Space? Sheeeit"? haxor.fi/~ml/sheeeit  
 
Oh, and also check out our competition! These guys worked hard on their games too!  http://www.assembly.org/summer10/news/gamedev-entries-published
 
If you do try either game, drop me a line and let me know how it went, even if you didn't like the game. We want our every game to be better than our last, so feedback is invaluable.

So much for my regular blog updates, I guess. Long story short: game got hell of made, deadline is tomorrow at 6 PM GMT+2 and we're in the middle of crunch mode. Spent ~18 hours on the game yesterday, coding up new features we realized we desperately needed (like online leaderboards and syncing scores), then debugging shit and polishing parts of the game. 
 
Woke up today at 7 AM, grabbed a handful of off brand pain pills for my horrendous headache and started working on the game again! The help screens I created earlier are frankly shit and needed replacing. And also since we don't own the rights for the Rich Gallup pimp picture I used as a placeholder in the info screens, that had to be redone too. Now I think I've got all the photoshopping out of the way, so I guess it's time to zoom on out to the lab and start another marathon session of amateur game development.  
 
I hope it will be all worth it tomorrow.