Emergent behavior and why game devs should care about it

I like to describe “emergent behavior” as this: “1+1=3″. To describe using words: emergent behavior means that something “bigger/unique/different” is born from simpler building blocks, or that some kind of new behavior appears when you combine 2 (or more) other things.

A few days ago, I asked my daughter (1 year 6 months) a question. I pointed my finger at something and asked “what’s that?”. She said “brrrmrrrm”, which totally delighted me positively. I was pointing my finger at a picture of a car.

Why was I positively surprised? Answer: emergent behavior.

Some days earlier, we had taught our daughter that “car says vrmmmm”. To her it was “brrrmrrrm”. When we asked “what car says”, she would delightedly reply “brrrmrrrm”. Now, when asked “what is that”, she saw a picture of a car and said “brrrmrrrm”. It was surprising, since usually she mentions the name of the objects (like “kukka!” – flower that is).

I must point out that if that didn’t sound fun… then please just take my word for it. It was fun moment for me!

So, by combining two different things (action: “car says vrrrrm” and object:”that’s a car”), a new behavior emerged “that’s vrrrrm”), which caught me off guard.

Similar things happen in games all the time. And when you put effort in thinking about the smallest building blocks and actions player can do with them, a new odd and fun combinations might arise.

And that’s fun.

Illustrated newbie’s guide to isometric game development

Out of cat-killing curiosity, I searched some information about isometric game development. I’ve listed bunch of resources to the end of this blog post, although I start the blog post with my own thoughts, code sample with bunch of images from me.

My own views about Isometric
Please notice that my experience about isometric worlds is limited to about 2 hour time I spent during this weekend checking stuff and coding. I’m total newbie on this subject, but since I have some background on programming I feel have a thing or two to say that might help.

So, use these with a caution – and feel free to correct what I say.

Isometric game development principle #1: it’s just a VIEW
I have one principle which greatly helped me to understand isometric view. And here it is: isometric view is just that, a VIEW (in a way). Let’s take a simple example: think of chess board. Chess board has grid size of 8×8. We could say that there’s X-axis and Y-axis. If you say that Queen is in location X=1 and Y=5, then she sits there.

Here’s the point: Whether our game is basic square 2D, 3D or Isometric doesn’t change a thing in terms of gameplay: Queen is still located in X=1, Y=5. Isometric view only means that we look the board bit differently.

The bottom line is: your game can very well run “normal” 2D grids and whatnot in the background, it’s only the VIEW – the REPRESENTATION – that we change when we have isometric view. First code your chess game code – without thinking isometric view – and only after you’ve finished all the game logic, you could add View methods and functions that ensure things look fine.

Isometric game development principle #2: use “levels” (or “layers”) to help think
In this following I assume that all objects in the game reserve “one block” (you may think of Minecraft if it helps: (almost) all blocks have width, height, depth that all reserve 1x1x1 space).

In some isometric articles, you are recommended to create multidimensional arrays that contain 3 parameters (grid[x][y][z]), and then you are given (somewhat) complex systems for drawing the stuff on screen. I think this is somewhat okay, although it might be also bit complex. Therefore, some games can benefit from this other type of thinking:

With this in mind… let’s get back to our Chess board example.

Let’s say you’d want not to have 2 dimensional board, but also 3rd. Instead of using multidimensional arrays, I would just pile one board on top of another.

So, instead of having “board[x][y][z]“, I would have this:
- class Board, containing “grid[x][y]”
- then I would simply add more boards on top of each (board1, board2, board3… boardN). And when I need to draw something, I’d keep track on boards, and draw them from bottom to up, by saying “loop boards > board.draw”

For example, I’ve written code to draw one layer to see something like this:

And by just adding new boards, I can get this (without need to mess with additional dimension pretty much at all)

This way I can keep calculations bit simpler in one level, without need to worry about upper levels. I say again why this is important: it’s because the drawing order becomes very simple since I just need first draw bottom layer, then layer above that, then the next and so on.

I know this method is closely the slowest possible way to draw each tile always, but if you want to get started, I think it’s okay starting point and helps understand. Also, I do realize that this works when all block sizes are the same. If for example you’d have a Dragon that is 3 blocks tall, then something else would be needed (I leave that for you to ponder).

Bear in mind, this is my very first piece of isometric code, so I don’t claim it to be the best/fastest/most optimized (quite the contrary), but I do get some credit for having somewhat easy to understand code.

Isometric game development principle #3: Sun should shine from some angle…
Isometric is fun that it can produce visual oddness that nobody’s perception cannot properly resolve, sometimes at all. That’s why it’s good if some side’s of the blocks are highlighted (bit like if Sun would be shining from certain side)

Here’s example image:

I’ve highlighted some sections using white, and look at those sections… it’s quite hard to say which block is next to which block.

The solution is to change the block style a bit, as done here:

With this tiny change, we’ll get results something like here:

It’s not perfect yet, but this small change alone solved some problems (especially for the topmost layer as in some cases “holes” were difficult to spot). It’s not complete yet, so see the next principle.

Isometric game development principle #4: In Isometric view, consider changing brightness of the tiles
If you need to pile several levels in one screen, you might want to consider using brightness

The previous picture still gives us headache on some locations, and one way to handle the issue is to change brightness of the tiles, depending on which level they are.

Now, this is much better. There are still some blocks that create visual oddness (see blocks in the very left corner, highest layer: one of them looks bit odd), but much of the problems were solved merely introducing change in darkness.

Code example:
I wrote a small isometric drawing “engine”, which is not perfect, but here you have it: (comes with .bmx file including code, 3 different cubes to test things, and .exe to run in case you are curious to see how it looks)

ZIP file including art etc.
isometric.zip (678kB)

TXT file, with just the code syntax:
isometriccode.txt (2kB)

Basically, this example produces image as you saw a few paragraphs earlier.

If you want more commented examples (although my variable naming is pretty ok), then check some of the resources I’m going to list right about now.

Here’s some resources:

Introduction to Isometric Engines (1999). While “bit” old, I found this article informative stepping stone into isometric worlds. In fact, I used mainly this article to do brief sample code on my own.

Isometric pixel art tutorial – This tutorial shows you how to draw a box. Yes, that’s correct. Isometric box. While this might sound bit silly, I found this article definitely a must-read for newbies (such as me) to understand how isometric worlds work.

Isometric view – This tutorial is part of several other tutorials (see menu in the left for some “Iso” topics). Similarly to previous pixel art article, this tutorial helps get idea on how isometric view works. Illustrated images helped me.

The Complete Guide to Isometric Pixel Art (2004) – I received this article after reading any other articles (or before wrote any code) and I must say this article alone very well covers the aspects of isometric view. Most recommended.

Designing Isometric Game Environments (1996) – This article was pretty good, although I disliked chapter long links. If you can get through the visual “clutter” this article gives some fine points about isometric worlds.

Then two other resources:

GameDev forums: Isometric land – several topics about isometric stuff. Dig deeper if you want.

Making Isometric Social Real-Time Games with HTML5, CSS3 and JavaScript (book, 2011) – I didn’t read this and have no idea how good this book is. Nevertheless, it seems to be almost the only book on isometric worlds and costs $15-20 so not too pricey to give it a test drive. If you do, feel free to tell how you liked it.

That’s it folks.

One last word: please notice that I’m like the newbies newbie when it comes to isometric handling. Use with caution.

Also, if you have some ideas/comments on obvious things I’ve missed, please feel free to share.

Thanks to @icosahedron, @apgamesdev, @triptych and @Borundin for helpful iso links

Here’s some things we all can steal from Minecraft game

Besides Notch’s hat, we all can consider stealing some elements that Minecraft is using:

#1 – the art style
Just think about how genius it is. Just blocks! How difficult it is to model bunch of blocks, yet animate them. Super easy. And even if you don’t know how to animate, you can go to a site like FPS creator site, spend a few bucks to a model pack AND (this is important) export only model BONES and ANIMATIONS. Then in your own programming SDK, you can create cubes and attach the cubes to the animated bones.

And voila, you’ve just got animated box man to appear on your screen.

Don’t necessarily steal the idea of “world is made of blocks”, since you can have other shapes too, such as a terrain. Just ensure using blocky style in all the art, and it’ll be consistent.

It doesn’t matter whether you are doing an RPG, FPS, RTS or whatnot – the main idea is that you can steal this simple style and save humongous amount of gold in art assets.

#2 – Actually, that’s it
I see quite zero sense in trying to clone Minecraft. Terraria isn’t Minecraft clone, Terraria just happens to have digging and blocks, but it’s hugely different gaming experience. Cloning Minecraft would mean spending some years building a game where you have blocks that you can use to build anything. But who would buy it? Everybody and their mom already has Minecraft so it’s pretty pointless (unless you target different platforms, then it might have some sense) as there would be zero reason to buy your clone.

I feel that stealing the art style would make tons of sense for lots of indie developers. By using block style to build whatever game they are building, they would make a huge leap in terms of getting game ready faster.

You already doing this?

Are there roguelike games without (so much) fighting?

Ultima 4+5+6 appeared on GOG.com and for some unknown reason I’ve read bit about roguelike games development out of pure curiosity.

While possibly one certain element of roguelike games is fighting, leveling up and all that… one important part is also exploration. I’m wondering if there are roguelike games (dungeon crawlers or others) where the game is not so much focussed on combat?

I started new secret side project few months ago, hint here…

This is again one of the biggest development processes I’ve been involved. Here’s a screenshot:

It’s bit on the small side, so I can zoom a bit: (2x and 4x zoom)

Still not clear enuf? Here’s the 8x zoom:
(click to open in new window)

We’ll expect to have more detailed information around the end of January 2012.

This also means my card game is most definitely being released during the last quarter of 2011.

9 common elements of a successful (indie) game project

By checking my own games projects and games created by other developers, I spotted 9 common elements that many of these projects had (or should have had…). Here’s my list of 9 items, in no particular order. If you cover 7-9 of these, I think you greatly improve your odds of a creating a fine product, in comparison to having only 5-6.

#1 – Scope
Indie game devs need to think about the scope of the project. I know all game projects start small, and they then have the danger of growing into huge gigantic several year taking projects. Watching the scope is important. Splitting the game into episodes, using procedural content, user generated content, not getting too attached to creating huge asset piles (artwise, graphicwise) all need to be considered. Scope is important. Too small, and game is too simple. Too much and it’ll becomes too big mess to handle.

#2 – Money
Money can fix many things. I wasn’t too thrilled about having budgets, but at later age I think it might be good idea to have some sense about what range you are willing to take. Is it 10 bucks, 100 bucks, 10 000 bucks or 100 000 bucks gives some rough idea what will be possible and what won’t be possible, saving you precious time when you need to consider different features.

Money can also be used to cover areas you are not good at, which in return might save you a lot of time.

As a sidenote: it’s perfectly okay to go with zero budget too. The worse the graphics, the greater the story when your game becomes the next hit…

#3 – Time
Very important. If you don’t have time to make games, then your chances of making games drop to zero. Here’s a post about 100 ways to be more productive. It’s from year 2008 and still pretty valid if I may say so.

#4 – Skill
You need to be skilled in something. I’ve always thought that being a skilled in programming is the most important part, as I believe programming is most work. With new and easier to use tools, I see that graphically talented folks have more opportunities to create fine games.

Besides these, a solid understanding of game design is a pretty good idea in case you plan to make the game any fun. Understanding some fundamentals just simply makes decision simpler, when you have some more understanding on why something is or isn’t fun. (Book of Lenses is a good starting point by the way).

#5 – Motivation
If you are not motivated to create your game, it shows. Motivation is hard thing to have. One simply gotta be willing to spend countless hours doing something, working in the dark. It’s persistance.

If the work you do is fun, no matter what is the final result, then you probably are in the right track on this.

#6 – Momentum
I’ve noticed that if I don’t work on my game for some time (let’s say 2 weeks, for example when having bit of summer holiday), it’s always harder to come back. When I eventually come back and continue, things are fine again. It’s just that keeping up the momentum is important. You don’t finish a marathon by sitting down every few hundred meters. You gotta keep pushing, keep going and keep the momentum going.

#7 – Twist
I like to believe that fine indie games also need something unique, something different. Some sort of twist that makes them different from what we’ve seen earlier. I don’t know what that might be, but if there’s something special in the game, it makes a good story. And who knows, maybe even a fun experience too.

#8 – Release
Second most important part of the puzzle (#9 being perhaps most important). By releasing your game, you’ve reached something truly important. Continuing from here gets easier. If you plan to do multiple releases, that’s fine (and recommended too).

By doing release (or releases) you make your dream come more true.

#9 – Polish
Perhaps the most important part of a successful indie game: polishing. It’s the hardest part: fixing nasty bugs, adding features, honing features, changing things, getting rid of some of the bad stuff, getting better art, getting better sounds, spending tons of hours into very many things…

… and then you really have something great in your hands. And perhaps others see it too.

If you have some items to add to this list, please feel free to comment the blog post.