The power of limits - How Restrictions can lead to Game Innovations

Perhaps one of the most prevalent views in game development, especially among newbies, is that our current technological state limits our capability in creating expressive video games. The general idea is that we simply need more innovation to reach what games are (and should) be aspiring for.

This is also perhaps one of the most inaccurate things I have ever read.

The Paradox of Choice

You've probably heard of the phrase "More is Less, and Less is More".

Let's start out with a concrete example. If you're a programmer, and I told you to program in either C++ or Java, it would probably be easy for you to pick what language to use, considering that you know both of them.

But if I told you it's a free-for-all, and you can choose to program your game in C, C++, Java, C#, F#, Fortran, Objective-C, Ocaml, Javascript, Actionscript, Python, etc. etc., and considering that you also know all of them, I'd figure you'd have a much tougher choice ahead of you.

Inventing a Genre

Metal Gear is an incredibly popular franchise. If you're not familiar with it, you're not a real gamer it's a game where you stealthily maneuver against numerous, and generally more well equipped soldiers.

Kept you waiting, huh?

But did you know that the game managed to popularize an entire genre specifically because of hardware limitations?

The game was originally planned as an average action title, but the developers didn't have the luxury of incredibly powerful computers back then. The processing power of machines were so weak that they couldn't get any more than a few enemies on screen until the game flashed epileptically. 

This is when Kojima-san realized that the game, in its current state, simply won't sell - an action game with 2 enemies and 6 bullets is going to be incredibly boring to say the least. So did he just give up on the game entirely, opting to wait for technological innovations until the game can be made?

Nope. He considered the limitations, and decided to make the game work with it. If the game couldn't have a lot of enemies, then maybe he can design a game where the goal was to avoid enemies?

After that, as they say, the rest is history: the franchise has sold 30 million copies at the time that this article is written, and Metal Gear Solid is one of the most amazing games in my book.

Hiding Limits

What I'm trying to say here is that you don't need

Another game where hardware limitations worked for the game instead of against it was Silent Hill. 

Silent Hill is a horror title, and the game has you play Harry Mason, an everyman, searching for his adopted daughter in the eponymous town. 

Ooh, Spooky!

Now what was particularly unique in this game was that the player traverses through real-time 3d environments. For such early titles, fully 3d environments were quite heavy. If you look at Resident Evil, Silent Hill's primary rival, you'll see that instead of opting for real time 3d, it used fake 'baked' pre-rendered environments.

In Silent Hill however, the developers got more creative and instead opted to use Fog and Darkness to lower the visibility, limiting the polygons seen by the player. This not only helped mask the hardware limitations while still keeping a real time 3d environment for the player to explore, it also worked incredibly well for the game, creating a more 'scary' and 'gloomy' environment.

The lesson?

We can make do with what we have. Any excuse against current technological limitations, is just that - an excuse. Recounting game-changing technological innovations in the 21st century, only a few games actually uniquely utilized them: Alone, L.A. Noire, and various Wii games. On the other hand, great games that was considered innovative (along with lucrative sales), could have been done so even in more limited technological environments, such as Limbo, Braid, Journey and of course, Minecraft.

Gameplay trumps Graphics

Remember, better books weren't made because of better words, so better games won't be made just because of better tools.

[Read more]

Big Issues - Our entry for the Charity Game Jam

McFunkyPants, the guy responsible for OGAM and all around nice guy, is holding a Charity Game Jam this 23-30th of November. The requirement is to have a donate button to charity in the game, and I really think it's a great idea specially with recent events such as Typhoon Haiyan.

The genesis of the game we worked on came from Bradley Smith, someone I met on the tigsource forums. He is an awesome guy, and I seriously hope I can continue to collaborate with him in the future.

Big Issues is a simple time management begging game. The mechanics are simple - click on civilians to beg. However we have a pretty solid theme that we think we can really expand upon.

You can play the game directly from your browser here.

[Read more]

Writing Fast Code: Introduction to Algorithms and Big-O

Did you know computers are stupid machines? They are actually so stupid that they don't know how to multiply; instead, they add - whenever you say 2*5, the computer is really doing 2+2+2+2+2!

What computers can, and have always been capable of, is executing things incredibly quickly. So even if it uses repeated addition, it adds so quickly that you don't even feel it adds repeatedly, it just spits out the answer as if it used its memory like you would have.

However, fast as computers are, sometimes, you need it to be faster, and that's what we're going to tackle in this article.

But first, let's consider this:

Here are 7 doors, and behind them are numbers, one of which contains a 36. If I asked you to find it, how would you do it?

Well, what we'd do is open the doors, and hope we're lucky to get the number.

Here we open 4 doors, and find 36. Of course, in the worst case scenario, if we were unlucky, we might have ended up opening all 7 doors before finally finding 36.

Now suppose I give you a clue. This time, I tell you the numbers are sorted, from lowest to highest. You can instantly see that we can work on opening the doors more systematically:

If we open the door in the middle, we know which half the number we are looking for is. In this case we see 24, and we can then tell that 36 should be in the latter half.

We can take the concept even further, and -quite literally- divide our problem in half:

In the picture above, instead of worrying about 6 more doors, we now only worry about 3.

We again open the middle, and find 36 in it.

In the worst case scenario, if we opened the doors wildly, or linearly, opening doors one by one without a care, we would have to open all doors to find what we are looking for.

In our new systematized approach, we would have to open a significantly lower number of doors - even in the worst case scenario.
This approach is logarithmic in running time, because we always divide our number of doors by half.

Here is a graph of the doors we have to open, relative to the number of doors.

See how much faster log n is, even on incredibly large input. On the worst case scenario, if we had 1000 doors and we opened them linearly, we would have to open all of them. If we leverage the fact that the numbers are sorted however, we could continually divide the problem in half, and drastically lower that number.

An Algorithm is a step by step procedure for solving a problem, and here we have two basic algorithms.

As you have already seen, our second algorithm is faster than our first in the worst case scenario. We could classify them by running time, the time it needs to take to complete the problem, which we equated here by the numbers of doors opened (since you take time to open doors).

The first algorithm, which is a linear search algorithm, would have to open ALL doors, so we say it's running time is O(n), (pronounced Big-Oh-of-n) where n is the number of doors (input).

The second algorithm, which is a binary search algorithm, would have to open a logarithmic amount of doors, so we say it's running time is O(log n).

In the so called O-Notation, O represents the time it needs to take for your algorithm to complete the task in the worst case scenario.

We haven't looked at the other side of the coin however. What about the best case scenario?

In both of our algorithms, the best case scenario would be to find the what we're looking for in the very first door of course! So, in both our cases, the best case running time would be 1. In O-Notation, theta (Ω) represents the best case scenario. So in notation, we say Ω(1)

Here is a table so far of our algorithms:

	$$Ω	O
Linear Search	1	n
Binary Search	1	log n

Now unless all you're going to write in your life are door problems the style of Monty Hall, then we need to study more interesting algorithms.

Sorting - Case Study

Let's say I'm making an RTS, and I needed to sort out units by their health.

As you can see here, the positions of our units are a mess!

A human being can sort this out very easily - one can instantly 'see' that it should be arranged like so:

The brain makes some pretty interesting calculations, and in a snap, it sees how the problem can be solved, as if in one step.

In reality though, it actually does a series of steps, an algorithm, to sort out these pigs. Let's try to solve this problem programmatically.

One very straight forward way to solve this problem is walk through our input, and if they are not sorted, we swap them:

Are the first two pigs sorted? Yes, so we leave them be.

Are the next two pigs sorted?

No, so we swap them.

We will continually do this recursively, until we walk through our input and see that we have in fact sorted it out.

To save you some bandwidth, here is our sorting algorithm in an animation, courtesy of Wikipedia:

(The animation is pretty long, so you might want to refresh the page to start over)

The algorithm we have described here is a Bubble Sort. Let's define it's running time shall we?

How many steps do we take to fully sort it out?

First we walk through our input. If our input is n, that is a total of n steps.

But how many times do we start over and walk again? Well, in the worst case scenario, that is, when the numbers are arranged largest to lowest, then we would have to walk through it n times too.

So n steps per walk, and n walks, then that is a total of n².

In the best case scenario, we would only need to walk through it once (and see it's already sorted). In that case, n steps per walk, and 1 walk, then that is a total of n.

Now you might have noticed this, but n² is a pretty bad number to have. If we had to sort 100 elements, then that means we have to take 100² steps, that is 10,000 steps for a 100 elements!

Selection Sort

Let's use another approach. This time, we walk through the input left to right, keeping track of the smallest number we find.

After each walkthrough, we swap the smallest number with the leftmost one that is not in the correct place yet.

To again save you some bandwidth, here is an animation, again courtesy of Wikipedia:

The red item is the current lowest number that we save, presumably in a variable. After the walk, we put this lowest number to the top of the list, and we know that this is sorted already (yellow).

But what is the running time?

In the worst case scenario, we would have to do n walks. The steps per walk decreases. Since we know that the first few numbers are already sorted, we can skip it. So our walks then become n, n-1, n-2... and so on.

The total running time of this is (n(n-1))/2. However, computers are so fast that a division is negligible, so we can say that this is n² still.

But what about the best case scenario? If you think about it, we would still need to walk through the input, even if it is already arranged! So our best case scenario is also n².

Insertion sort

Okay, so all of our examples so far has been n² which we know is bad. Let's take a look at another algorithm shall we?

Imagine you're sorting a deck of cards. Now I don't know about you, but most would do is walk through the deck, and insert the card in front of them to its right position in another deck.

This might help you visualize it:

This is awesome! We only need to walk through the list once! So the running time is n right?

Not quite. What if we needed to insert 1 to our sorted list? We would have to move every single one of them to make room. If you consider this, the worst case running time is actually n².

Let's table them shall we:

	$$Ω	O
Bubble Sort	n	n2
Selection Sort	n2	n2
Insertion Sort	n	n2

Are we screwed? Do we have no choice but n² running time for sorts? Of course not! If you've been vigilant, you'll realize that none of the algorithms introduced so far uses the same 'divide-and-conquer' approach of binary search.

You might want to take a look at this visualization to see just how fast merge sort is to bubble, selection, and insertion sorts.

Note: That little tidbit about computers doing repeated addition is a bit of a lie.

Credits

- Running Time Graph Image taken from: CS50, taught by David J. Malan from Harvard University
- Visualization Animations from Wikipedia.

[Read more]

How To Reverse Time - Introduction to Git, Cloud Computing, and Version Control

"Are you telling me I need to rework my entire game from scratch!?"
"If you want to pass, then yes."

This is how a conversation went down with one of my university friends and his professor. My friend had the unfortunate luck of his laptop dying on him, along with all its data, the day his final project is due.

Now, while I love my friend, the professor should have failed him. Or it may even be the case that it's the professor who failed, since he didn't teach one very important thing.

In the era of cloud computing, there's no excuse for lost data anymore. Having a backup of your data, and even sharing with others has become trivially easy.

Perhaps you've heard of Git, or maybe GitHub. People treat it like it's the best thing since sliced bread, and you're left wondering, "What the hell are this things". If you want a (beginner-friendly) introduction, read on!

But first...

The easy - Cloud file hosting

Cloud hosting services are easy ways to backup your data. All you do is install a program, and you'll have a folder that gets instantly 'synced' with your account. That way, if you lost your local copy, you can always download the data from your account. Neat huh?

These 'free' cloud hosting services are perhaps the most popular:

Dropbox - is the most popular. It starts out with 2 GB, but you can earn up to 20 GB for free quite easily! (It also helps to have connections to a senior VP architect there *grin*)

SkyDrive - Microsoft's Skydrive generously offers 7GB upfront! There's no way to make it bigger though (unless you want to pay).

GoogleDrive - Offers 5 GB upfront, but like Skydrive, you're stuck on that much unless you want to give some cash.

The 'big three' is enough of a list to get you started. Pick one, and when you're ready, go ahead.

The trivial - Version Control

This happens all too often. Let's say you're working on a game, and after hours of work, you may have some of the solid mechanics down. 'Alpha' you call it.

You continue working on your game for hours, adding new features and stuff. But compiling it, you realize a drastic mistake with your code. After fiddling with the code a few hours more, you realize how much of a mess you're code now is. You bang your head on the wall - if only you could go back reverse time to when everything worked, to your precious 'Alpha'.

This is where version control comes in. True to its name, a version control system, *ahem* 'controls' your versions so you can easily "reverse time"when you need to. Instead of something akin to cloud file hosting, where your files get synced every time you make an update, here, you save your file every 'version'.

This is a HUGE saver, since if you want to 'revert' back changes, you could easily do it with a click of a button! (or pedantically, typing a few words)

There are lots of Version Control Systems (VCS) but Git is probably the most relevant right now. There are still people who use SVN though, and knowing two VCS can't hurt right?

The Idea

In it's most simple form, here is a Version Control project.

Every little box above is a "version", which we call a "commit". Every "commit" gets saved on what's called the "repository" which is just a fancy word for "the box that contains all your saved data".

Whenever you want to go 'back in time', you "revert" your changes. If we were midway through 'alpha' to 'gold', but we realize there's a mistake, we can easily revert our changes back to 'alpha'.

Collaboration

VCS are more sophisticated than that though, and they are VERY HELPFUL in collaborations, not only because you can revert mistakes of your team, but also because you can have very real boundaries and division of labor.

Let's say your team decides what to work on. We decide that Member A will work on the mechanics of the game. The physics engine is horrendously slow, so we assign Member B, to rework the physics engine.

If we used what we did above, blindly committing changes of your team will get ugly real quickly

What we could do is set up what's called "branches". 

In the above, instead of committing in the main line, otherwise called 'trunk', we create a 'branch', specifically for physics. Note the first commit in the physics branch. There is a 'commit message' aptly named 'buggy physics'. This does not at all affect the main line (containing alpha) and Member A can still work on the mechanics of the game, completely oblivious to the buggy physics.

Member B then manages to get the physics right, and finally 'merges' it. Member A, who at this point did not even see the changes by B, is delighted to see the new, fast physics engine.

Here we see a more complicated VCS, but note that it simply has the concepts above.

That's great, but how do you use it!

SVN

If you're using windows, TortoiseSVN is an absolutely fantastic tool to work with SVN.

TortoiseSVN, right click menu

Here we see some of the options of Tortoise SVN. They are self explanatory, 'SVN Commit' commits your files, while 'Revert' rolls back changes. 'SVN Update' updates your 'local working copy', so that if your teammates made a new commit, you can see the changes.(your files get synced)

SmartSVN is a good alternative if you're not in windows.

GIT

First of, Github != Git.

Git, like SVN, is the 'real' Version Control System. Github is a web-based hosting service. Think of it as facebook for Git.

Now that we have that out of the way, let's look at our options for Git. Go ahead and get Git first.

The best option I have found so far for GUI-based git is TortoiseGit, a port of the above TortoiseSVN. There is also GitX for all you Mac lovers out there.

So what's github?

Github is a like a social network that uses Git. You can commit your games/files there and people can take a look at it and play with your code, copying your repository and working on it on their own (called forking).

There's a private repository option, but that requires payment.

If you want to have a private git repository for free, try bitbucket.

Good VCS practices

• Keep your commit messages short but punchy.
• Always, always use good commit messages. Tell everyone what you did with your commit, so they can track your changes. There's nothing more scary than 'fix bug' or 'updated game' so you have no idea what was changed.
• Note the side effects of your changes. If you edited the GUI, which in turn changed how the levels work, make sure to note it.
• Branch your code when necessary.
• Test your code before you commit on the main trunk. Seriously.

Git - Something special for real programmers

You ask "Why did you give me Git Gui Options! Tell me how to use git on the terminal!"

If you consider yourself a real programmer, who can't be bothered to use GUI Crap, please read my article, Why your games are unfinished, and what to do about it.

If you still want to learn Git through terminal, make sure you're not doing it because you're being an elitist. The above tools are more than enough to get you started on git. Ask yourself 'Will there be any practical gains for me by learning how to use Git through terminal?'.

If the answer to the above is yes, and a real definitive YES, then read on.

I'm not going to lie. I use Git through the terminal and there are real practical gains from doing so. One of which is that you don't get to use GUI crap (heh), and therefore you can be more productive. This is because you minimize clicks. Ideally you would never even need to touch the mouse (some IDEs and even text editors have built in terminals, and you can also Alt -Tab if you need to.)

Here are the very basics of git terminal (some lines taken from git-scm, because they had nice colors):

$ git init

The above initializes your repository in your current directory. This creates an empty git repository.

$ git add *.c $ git commit -m 'initial project version'

git add *.c adds all the files that has '.c' as an extension in the repository. The commit command accepts a '-m' flag, and what follows is your commit message.

Note that git commit will only commit on your local repository. If you're working with a team / using a remote repository, you also need to push your commits there.

$ git push origin master

If you want to clone a repository, then use the clone command:

$ git clone git://github.com/schacon/grit.git 

You can configure your identity by using:

$ git config --global user.name "Your Name"
$ git config --global user.email "username@domain.com"

And that's the basics of git!

Note: There are other good VCS like Mercurial, but space lacks and this is a good introduction to those who want to get started with VCS.

[Read more]

Why your Games are Unfinished, and What To Do About It

So, you've got a new game idea, and it's going to change what everyone knows about the genre! Great!

After making a Game Design Document, you proceed to make some art, or maybe a prototype. You even got that fancy gimp program, or started using a new 'multi-platform' library.

Time went on and you hit a wall. Maybe it's that annoying bug in the second level. Your plan's aren't panning that well. It's just too much work.

You start making excuses. The game idea wasn't that great. It might actually be a bit boring. The art looks crappy.

You abandon the project. There are better ideas you say.

If the above sounds like you, then the bad news is with the way things are going, you might not release any games at all and just lock them inside your head!

The good news is, you're not alone. Almost every game developer lose interest in projects they are working on.

Coming from my personal experience, and interviewing a few other successful game developers, I've compiled a list of things to do when you find yourself killing off your own games.

1. Stop Editing

When writing, authors typically have one rule when making their first draft, and that is to kill the 'infernal internal editor'. "Don't edit, just write!"

This actually carries over to a lot of other creative industries, including game development. When developing a game, always make it so it just barely passes, and move on. The more you work on other parts of the project, the more motivated you will be. Don't try to perfect your game on the first run, remember, you can always edit it later on.

2. Make A Deadline

This goes hand in hand with Number one. Enforce a time constraint, do your best to stick to it, and you'll find  yourself working on the essential game aspects.

There are lots of events with this in mind, such as OGAM (One Game A Month), and Ludum Dare.

3. Go For Small Games - if you're just starting

When you're just starting, start small. Making a fun solid game/minigame is a HUGE leap for a game developer, and having at least one released game already puts you ahead many of your contemporaries.

 "But that super awesome MMORPG with that unique mechanic is going to be huge" you say. That sort of enthusiasm will go a long way, but if you haven't even been able to create one small game, do you really have what it takes to commit yourself to such a big project?

If you're game idea simply and absolutely cannot wait, then try creating what's called a 'Vertical Slice'. Instead of creating your entire game, why not try creating one scene, one battle, or one encounter? This nets a plus on all components, because you can instantly:

• Test out your idea
• See if it's actually fun
• And actually have something to show for your effort

4. Make it a Habit

Whether you're someone who makes games as a hobby, or someone who really wants to get into the industry, then make it a habit. Do one part of your game, everyday. It doesn't matter how much you can do in a day, the important part is that you work on the game.

You can even get yourself a to do list. Ticking something as done gets a nice feeling to your stomach!

5. Don't worry about the technology

Your salivating over that new libgdx library that can compile to every platform known to mankind. You want to use Haxe because it's fast, multiplatform, and l33t. Microsoft killed XNA, and you avoid it like a plague.

The thing is, Don't Care! Remember, you're making a game, and it doesn't matter what language you use.

If you're game is boring, no one will play it, even if you used the newest, shiniest language to have ever existed.

The next tip is also an inherent flaw of game programmers, but can be applied to game developing in general.

6. Keep It Simple Stupid!

If you're a programmer, just code, don't edit (slightly bringing us back to tip #1). 

Design Patterns? Throw 'em away. Component Based Systems? So last year. Event Listener's inefficient? Leave them be.

Keep it Simple Stupid (KiSS) is an actual programming methodology. It's what it says on the tin, just keep your code simple. Don't get fancy with design patterns, component based systems, or making your loop run in the most efficient way possible. Pre-Optimization is the root of all evil.

Take pride in doing what you did, even if it was bad code. You might have a game with bad code, but at least you're not the other guy who has no game but good code.

7. Public Beta Tests

When loosing motivation, try being public! Share what you have so far, be it a doodle, a screenshot, or maybe even a demo. Get a friend to play your game, and with the internet, you can't have excuses for not finding anyone.

The feedback you'll get for your game is priceless, outlining what's fun and what's not, and it may even be the push you need to make it big.

8. Flow

If there was ever a point in your life where you've done something that you didn't even realize time passing, then you've undergone flow (which is what hypnosis puts you in). When you're in this state, you're so focused on what you're doing that you won't even notice a plane crashing next door (okay, maybe that was an over statement).

The point is, we can be totally immersed in one activity, and this is what you want to happen when developing your game. Close out your browser, and focus, have fun, and don't think of any thing else. Throw out coding practices, optimizations, and don't perfect stuff. Just do it.

9. It's Dead Jim

Maybe the game really didn't pan out as you've hoped to be. The gameplay was really flawed and it's not fun.

Sometimes, we need to quit when it's simply not working. (Seth Godin tackles it in his book, The Dip: A Little Book That Teaches You When to Quit (and When to Stick))

Remember, there is nothing wrong with making a game and just leaving it at that. You've gained experience, and that's always a plus. But don't just leave your game in the back of your hard drive, going back to tip #7, be Public! Share it on forums, saying it was a game you did in your free time that was left unfinished.

What do you know, maybe someone even gives you valuable feedback that turns out to be all that you needed...

[Read more]

Hello [GameDev] World!

O~hai!

I'm Secretmapper, a game developer interested in engaging, meta gaming experiences.

I try not to pigeonhole myself to any one genre. Expanding horizons and always going out of comfort zones is my mantra.

As I'm writing this post I have already worked on 2 solid games. The first of which is, JourneyEast, a free-to-play web based MMORPG featuring crafting, raids and a dynamic turn based battle system. The other one is a stereotypical overhead RPG named Orb Knight - which I consider my first "finished" game.

This blog is aimed to be a development blog, so expect it to be messy! While my outlook in game making have aged considerably well if I may say so myself, my mindset is to write-as-I-go so you might see a few posts where I work on a game, only to see it being abandoned at a later date. Hopefully when anyone rereads this in the future, they can see a clear growth in my experience as time went on.

Thanks for reading and hopefully you'll have a good time browsing through my devblog.

[Read more]