Semi-random character appearance

August 30th, 2010 - 5:54 pm

In the last video update, we had multiple NPCs randomly walking around, which was a big step towards the initial engine for the demo. They all looked the same though, like a bunch of clones, twins or ‘Malkoviches’. The latest work on the engine remedies that by creating the look of the characters by semi-randomly combining and coloring different body parts.

Watch it in HD!

As you can see, none of the characters look exactly the same. Some of them look a bit similar, though, but that’s just because this test only has 2 types of shirts, 2 pants, 2 shoes, 2 hair styles and 6 hats to choose from (the guard uniforms aren’t combined with the other clothing types, so I’m not counting the uniform pants, shirts and shoes in this). Imagine the level of variety that can be produced with 10 types of each clothing part instead of just 2!

It does take quite some time to prepare all the various sprites for this – each character frame consists of about 15 sprites and there are 10 frames in this animation and a bunch of different sprites for each body part, so if you do the math, it really adds up – but I think the results are definitely worth it. I’ve also optimized my work flow in creating these sprites, so I can knock them out pretty quickly now.

I’m currently working on creating the sprites for the other seven directions (well, actually just 4, as three of them are just existing sprites mirrored), as well as for the running animation and the neutral position. This’ll probably take considerable time, so it might be awhile before the next video update – unless I do some work on other parts of the engine that are worth sharing. We’ll see.

The game plan

August 22nd, 2010 - 2:51 pm

Game planWhile the finished game is still far off into the future, I’d still like to be able to release something for you blog readers to download and play around with – and provide feedback on. I’ve received invaluable feedback and bug reports from players of my freeware game, Ascii Sector, and while Hostile Takeover won’t be freeware (and I’d thus be shooting myself in the foot by releasing the entire in-development game for free), I’d still love to be able to release something once in awhile.

My plan is to make the in-development versions of the game’s demo available for download when the game engine is running fairly stable and there’s actually something to do in the demo (mostly shooting people, I imagine!). I’m still working on the most basic stuff (currently making hundreds of sprite pieces in order to have characters not all look alike) but after that I’ll probably start working on adding some features that aren’t just about the game engine, but also about gameplay.

The full demo of the game will contain a few of the game’s starting missions and that’s what I’m currently working towards. So while the demo will function primarily as a gameplay demo for potential buyers, for me it’ll also function as a milestone in that I want the engine to be pretty much feature complete for the demo. It’ll then “just” be a matter of adding missions and assets for the full game.

It’s still a bit too early to say how far off the first alpha release of the demo is, but I hope to be able to release something at least within the next six months, hopefully sooner rather than later.

Multiple characters

August 17th, 2010 - 7:57 am

Time for another video update on the progress of the game engine:

Watch it in HD!

There are now a bunch of NPCs running around besides the player’s character. They all still look the same, though, as I haven’t started working on different looks for characters, so I needed something to tell my character from the others, which led me to adding the destination tile marker, and then the tile over marker. The character AI is still very simple; they’ll just select a random destination tile and find a path to it. If their path gets blocked by another character, they’ll just stop, which is why you’ll see them eventually ending up in big groups. The current AI is just for testing purposes to actually have the characters move, so it will of course be improved considerably for the finished game.

Another new addition in this video is dialogue being displayed above the NPCs. Again, the dialogue in the video is just for testing purposes. Can anybody guess which movie the dialogue is referring to? :)

I’ll be working on having the characters all look somewhat different next. I’ve devised a system where the engine can randomly mix different clothing sprites and give them different colors. Characters’ skin can also be colored differently, as can their hair. So instead of making 10 different looking character sprites, I’ve split a character sprite up into different parts that can be combined and colored in a multitude of different ways. This should provide considerable variety in how characters look – if I make enough clothes/hair/hat sprites, no two characters should look completely alike.

My interpretation of Inception’s ending

August 13th, 2010 - 4:08 pm

This doesn’t really have anything to do with Hostile Takeover or game making in general, but this is the only blog I own and I wanted to share this. If you haven’t seen the movie Inception, stop reading this blog post right now as it will completely spoil the film!


There have been a lot of theories and interpretations of what the final moments of Christopher Nolan’s film Inception really mean. Does Cobb really get home to his kids or is he still in a dream? Will the spinning top fall over? Some argue that he’s in a dream world and that the top will never fall over, while others believe he’s in the real world and the top will fall. As most probably agree on, though, the point at the end is that it doesn’t matter to Cobb. He’s come to accept the world he’s in as his reality. I agree with that. However, I come to that conclusion in a manner I haven’t seen proposed anywhere else, so that’s what I’ll present here.

Let’s get my conclusion out of the way and then I’ll explain how I come to it: Cobb is in a dream at the end. And he knows this. He doesn’t set the top spinning to test his reality or to show the audience that he doesn’t care about it’s outcome anymore – he sets the top to constantly spin as a reminder to him that he’s in a dream, so he won’t get lost in it. Just like he used the constantly spinning top to incept the idea in Mal’s mind that the limbo they’d shared for 50 years wasn’t real. So, yes, the top will continue to spin because that’s what Cobb has set it to do. He’s almost doing an inception on himself in the end!

Now, how do I come to this conclusion? The seed of this idea (you might call it it’s inception) is that the top doesn’t really make sense as a totem for Cobb – or is at least somewhat confused. The point of a totem is to check the reality status of the world you’re in. You do this by making sure that nobody else knows exactly what your totem feels like or how it will fall (like Ariadne’s chess piece and Arthur’s dice). If somebody else knows this, they’d be able to recreate your totem so realistically that you wouldn’t be able to tell if you were in a dream or the real world. The spinning top originally belonged to Mal and was her totem. That’s not a problem since she’s dead and thus won’t be able to create the dream Cobb experiences. But how does the top work as a totem for Cobb?

I first thought that it works by always constantly spinning when in a dream and eventually falling over when in the real world. But that doesn’t work as a reliable totem. If someone was to try to recreate the top in a dream world to fool Cobb, they’d likely make it as an ordinary top – one that doesn’t continue to spin forever. Which would mean that the recreated top in the dream world would eventually topple over and Cobb would believe he’s in the real world. So maybe it’s just that Cobb knows the top so well that he knows exactly how long it’ll spin in the real world, but that doesn’t really make much sense either. Just think of all the factors that determine how long the top will spin. He’d have to spin it exactly the same way every time – even a faint gust of wind would change the outcome. It’d be like spinning a roulette wheel and getting the ball to fall on the same number every time. It’s virtually impossible.

So if the top doesn’t make sense as a totem, what is Cobb’s totem? Some have presented the idea that his wedding ring is his totem. He wears the ring in the dream world, while it isn’t on his hand in the real world. But that presents the same problems as with the spinning top: Everybody he’s ever shared a dream with knows that he’s got his wedding ring on his finger in the dream world, so it’d be easy to fool him by simply not recreating the ring in the dream world. So why then does he wear a ring in the dream world and not in the real world? Because he’s basically still married in the dream world. Mal still exists in the dream world. That’s his entire problem. The ring merely symbolizes that he hasn’t come to peace with his wife and that her presence still exists in the dream world.

Well then, if the top doesn’t make sense as Cobb’s totem, and the ring doesn’t either, then what exactly is Cobb’s totem? Think about it. What’s the one thing he can be sure will happen in the dream world that will remind him he’s in a dream? His dead wife showing up. He knows that his wife is dead in the real world. So, in a way, Mal is Cobb’s totem. It’s not something Cobb intended, but the fact remains that she works just like a totem: She reminds him he’s in a dream.

Now, let’s back up a bit. What does Cobb want in the movie? To get home. To be with his kids again. Alright, why doesn’t he just recreate them in a dream then to be with them? Because he knows they wouldn’t be his real kids? That’s probably part of the explanation, but the most simple explanation is that he can’t. He doesn’t have enough control over his subconscious. That’s why Ariadne gets involved, remember? Cobb can’t be the architect of the dream world, because if he builds it, Mal will probably run completely amok in it (which she still does to some degree, but I imagine her influence is smaller when Cobb didn’t build the dream). That’s why Ariadne gets hired to be the architect. So, Cobb can’t make a dream world in which he can be together with his kids because Mal won’t let him.

And now we’re getting to the end of the film. Cobb confronts Mal in the limbo. He finally comes to grips with what he did and can forgive himself (or something to that effect). The point is that he finds peace with himself and thus with the Mal in his subconscious. He makes sure she won’t show up and ruin his dreams anymore. Which means that he can now build a dream for himself in which he can be with his kids. That’s how he gets home in the end. By going into limbo after Saito and then staying there to build his own world with his kids. Because now he can. Now Mal won’t screw up his dream anymore. So Cobb knows it’s a dream in the end because he himself built it! But he doesn’t want to get completely lost in it like Mal did when they spent 50 years in limbo together. So he makes sure he won’t forget that he’s in a dream by using the exact same method he used on Mal to convince her that their limbo wasn’t real. He sets the top to constantly spin on the table in his living room, just like he placed the constantly spinning top in Mal’s “safe”.

In that final scene of the film, Cobb is basically doing an inception on himself: He’s planting the idea in his own mind that the world he’s in isn’t real to make sure he won’t get completely lost in the dream he’s created.

Addendum: Actually, my theory still holds true even if the top is Cobb’s totem. Then the top just has two functions in the film: It’s used to check the reality status of the world and it’s used to do the inception of first Mal and then Cobb himself. The gist of my interpretation is that Cobb was finally able to build his dream world at the end because Mal would no longer mess it up for him. And he uses the constantly spinning top to remind him that it is indeed a dream world.

Why isometric?

August 12th, 2010 - 3:34 pm

I’ve often been asked why I chose to go for an isometric art style instead of the more modern proper 3D (actually, no one has asked me this yet, but I’m just going to pretend that somebody has as an excuse to write a blog entry about it!). In this day and age, true isometric games are a rarity and pretty much completely extinct when it comes to big AAA games. Games like Dragon Age: Origins and StarCraft II that can at first glance appear to be isometric are actually proper 3D with the camera placed at an angle above the playing field. To find new isometric games today, you’ll usually have to turn to browser based games or games from smaller independent developers like Spiderweb Software and Basilisk Games.

So why choose an art style that only browser based games and a few indie studios use today? Why not make a real 3D game like the big AAA studios? Well, precisely because that’s what big AAA studios do. As a small one-man game studio with a very limited budget, there’s no way I’d be able to make a game that can compete with those big blockbuster games. I have neither the manpower nor the knowledge to do so. However, I believe I’ll be able to make a game that can compete with the other isometric games out there. The advice that’s most often given by existing indie studios to new indie studios is to find a niche and make the best game within that niche. It’s better to be a big fish in a small pond than a small fish in a big pond. I hope to become a big fish in the small isometric pond. That’s the business reason for going isometric.

The technical reason for going isometric is two-fold. There’s the development side, and then there’s the end-user side. On the development side, it’s a lot easier and faster to make an isometric game as it’s still basically 2D. There’s no need to build, import and display 3D meshes (something I have pretty much no experience with), I just blit the 2D sprites to the screen in the correct order and at the correct coordinates. And a lot of those sprites can be created with a relatively cheap and easy to use program like Poser, instead of having to build them from scratch in a program that’s a lot more complicated, like for example Blender. I’ll probably still use Blender for making sprites that aren’t characters, but if I don’t improve my 3D modeling skills to an acceptable level, there’s always the option to buy finished 3D models. For a program like Poser, you can get a lot of quality models for a cheap price – the only catch is that you’re not allowed to use the model meshes themselves in a game, but you are allowed to use 2D sprites rendered from those models.

As to the end-user side of the technical reason for going isometric, a 2D isometric game requires a lot less system resources than a full 3D game. I’m using my netbook as the target platform for Hostile Takeover – a computer that only has the most basic integrated graphics chipset. I’m already making a niche game, and there’s no need to make it even more niche by having high system requirements.

Finally, there’s the personal reason for going with an isometric art style. As I’ve probably made very clear in previous blog entires, I love that particular art style. I’m sure a big part of that love is nostalgia, but I also have a fascination with miniature things (hence why I have a netbook!), and to me the isometric art style gives the impression of a miniature world. It’s not realistic like 3D is, and you’ll probably never mistake an isometric game for reality as you almost can with a pixel-porn game like Crysis, but I feel it’s exactly this feeling of artificiality that gives isometric games their special style and mood. You’re looking down at this artificial, isometric world and can move your character around in it – almost like when you were a kid, sitting on the floor in the middle of the living room and playing with your action figures. In many ways, the viewpoint the player has on the world of an isometric game is the same this kid has on his action figures. The action figures have just been replaced with 2D sprites.

Basically, this is me working on Hostile Takeover:

Kid playing with action figuresImage borrowed from this site

Shadow and light

August 8th, 2010 - 7:41 pm

I’ve been playing around with doing some lighting effects for the isometric Hostile Takeover engine. Your character has a shadow now, and I can designate an overall degree of lighting as well as spots of permanently lighted areas:

Watch it in HD!

One of the things I loved in X-COM were the night missions. There’s just so much mood and atmosphere in those night scenes – beyond the simple dread in X-COM of an alien hiding in the dark right around the next corner. I’m not sure how this will be used in Hostile Takeover, though. I may have missions taking place outside, or I may just have missions that take place in an office building at night. A mission where you have to assassinate a couple of CEOs having a secret meeting at night would be pretty cool too. But I’m getting ahead of myself now…

Of other new stuff in the above video is map scrolling and some furniture I threw in to test draw order, so that sprites can be placed in front of and behind other sprites. Everything seems to be working fine, so I’ll move on to working on having multiple NPCs walk around as well.

The basics of isometric programming

August 6th, 2010 - 12:21 pm

When I started work on Hostile Takeover, I had only admired existing isometric games and never thought about programming one myself. So when I decided that isometric would be the graphical style I’d go for, I had to do a lot of reading up on the subject and wrap my head around this way of “faking” a 3D presentation with 2D graphics. I thought I might as well share some of the basics I’ve come to understand – maybe you’re gearing up for your own isometric game, but if not, I hope you still find this somewhat interesting.

There were two main issues I had to figure out to get the most basic stuff up and running: drawing the tile sprites in an isometric grid and calculating which tile the mouse cursor is over. As with pretty much everything in programming, the answers to both issues were some surprisingly simple mathematical formulas.

Drawing an isometric grid
An isometric tile is basically a square tile rotated 45 degress around the z-axis and tilted around the x-axis so it’s twice as wide as it is high:

Rectangular tile to isometric tile

When drawing a grid made up of non-isometric tiles, it’s pretty easy as all the tiles on the same row have the same y-value, but with an isometric grid all tiles are offset half a tile both vertically and horizontally:

Non-isometric and isometric grid
Image borrowed from this article

This is where basic math came to the rescue. The algorithm I use for drawing tiles is:

   FOR Y := 1 TO SizeY DO BEGIN
      FOR X := 1 TO SizeX DO BEGIN
         DrawX := ((X - Y) * 38) + 400;
         DrawY := (X + Y) * 19;

My tiles are 76 pixels wide and 38 pixels high, which is why I multiple with 38 (half of 76) and 19 (half of 38). I add 400 to the x-value to keep the left half of the grid from being drawn at negative x-coordinates (i.e. beyond the left edge of my computer screen). This gives me the x and y coordinates for blitting the tile sprite to the screen. Simple!

Calculating tile mouse over
When it comes to figuring out which tile the mouse is over (so that the game will know which tile the player character should move to when the player clicks the mouse button!), it was slightly harder to figure out, but, again, some simple math came to the rescue.

I already knew what the screen coordinates of the mouse cursor is, since I used that for actually drawing the mouse cursor. The screen coordinate is just which pixel on the screen the mouse cursor is currently at. My screen resolution is 1280×800, so the mouse cursor’s x-coordinate will be 1 – 1280 and the y-coordinate 1 – 800. I also already know where my tiles are on the screen, since I just previously figured out the algorithm for drawing them to the screen. Combining this, I can make an algorithm for translating the mouse cursor’s screen coordinates to an isometric tile coordinate:

   ScreenX := ScreenX - 438;
   TileX := Trunc((ScreenY / 38) + (ScreenX / 76));
   TileY := Trunc((ScreenY / 38) - (ScreenX / 76));

So if I know that my mouse is at, say, [410, 235] on the screen, calculating which tile the mouse is over is as easy as:

TileX = (235 / 38) + (-28 / 76) = 5 (rounded down)
TileY = (235 / 38) – (-28 / 76) = 6 (rounded down)

You’ll notice that I start with subtracting 438 from the mouse cursor’s x-coordinate. This is because I added 400 to the x-coordinate when drawing the tiles, so I have to subtract this again (as well as half a tile width) before calculating which tile the mouse is over.

Scrolling map
Now, this is all well and good for a map that isn’t larger than the computer monitor’s resolution. What do you do if you want a map that’s larger than that and want to allow the player to scroll the map? Easy, you just add an offset x and y value to the algorithms:

   FOR Y := 1 TO SizeY DO BEGIN
      FOR X := 1 TO SizeX DO BEGIN
         DrawX := (((X - Y) * 38) + 400) - OffsetX;
         DrawY := ((X + Y) * 19) - OffsetY;


   ScreenX := (ScreenX - 438) + OffsetY;
   ScreenY := ScreenY + OffsetY;
   TileX := Trunc((ScreenY / 38) + (ScreenX / 76));
   TileY := Trunc((ScreenY / 38) - (ScreenX / 76));

When the player scrolls the map horizontally, just increase or decrease the OffsetX value accordingly, and do the same with the OffsetY value when the player scrolls vertically.

And there you have it. The basics of drawing and interacting with an isometric map. I had to play around with the values a bit, though, so when I for example add 400 to the DrawX value, that number is just something I arrived at with trial and error. It would differ for different monitor resolutions and depending on where you want the default map position to be at (i.e. before the player does any scrolling).

If you want to read more about isometric programming theory, there’s a bunch of enlightening articles over at GameDev.Net.

Oh, and in case you’re wondering, the code snippets are Pascal. I program in FreePascal with SDL and OpenGL for cross-platform development.

First steps

August 4th, 2010 - 9:32 am

Whenever you begin work on a new game, the first question is always: Where do I start? I’ve decided to start with you. Well, with the character you’ll be controlling in the game. So here’s the very first Hostile Takeover development video:

Watch it in HD!

As you can probably tell, it’s all very basic and only the very first baby steps towards a fully featured isometric engine. When clicking on a tile, your character will find a path there and walk towards it. Double-clicking will set him running. He’s currently running around in his underwear, as this is just a basic test of having an isometric sprite animation, but he will of course get properly dressed at some point.

Pleased to meet you!

August 2nd, 2010 - 8:23 am

Welcome to my little corner of the Internet. Let’s get the introductions out of the way…

My name is Christian Knudsen. I’m 31 years old and live in Copenhagen, Denmark. I’ve been making computer games for the past 8 or so years in my pastime. My most well known game is probably Ascii Sector, a freeware textmode space game. I recently decided to take the plunge and try my hand at commercial game development, and Laserbrain Studios and this website and blog are the first tangible results of that decision. Programming and game making is still not a full-time job for me as I still need bread on the table and a roof over my head, but I hope to one day live off the games I make.

Hostile Takeover is the title of what I hope will be my first commercial game of many. It’s somewhat of a sci-fi game as I’m a sci-fi geek, and it’ll be in good ol’ 2D isometric graphics as I’ve always had a soft spot for that style. Maybe it’s just nostalgia for the games of yore, but I feel something often gets lots in the realism of 3D.

My two all-time favorite games are without a doubt the original X-COM (or UFO: Enemy Unknown as it was called here in Europe) and Wing Commander: Privateer. As I’m a fan of isometric graphics, I of course also enjoyed games like Fallout 1 and 2 and the Syndicate series. I hope to make original games that’ll have a feel of their own, but as with any artistic output, I’m sure my influences will shine through, so if you like the games I like, chances are you’ll probably also like the games I plan to make.

Anyway, that’ll have to do for introductions for now. As to this website, I hope to update it often with development news on Hostile Takeover and probably some off-topic blog entries once in a while if a subject catches my eye or there’s something I want to share.

That’s me. Let me know in the comments who you are and what games you enjoy, so we can all get to know each other!