As mentioned briefly in the last blog post, I’ve been working on smooth lighting. That’s now complete and working as well as I think I’ll get it to. Check out these comparison screenshots:
As I also mentioned in the last blog post, this was somewhat inspired by the Project Zomboid programmer adding smooth lighting to that game (and now I notice that they also posted some comparison screenshots just yesterday!). I believe he accomplished this by overlaying a multiplied and untextured polygon that completely matches the shape of each ground tile, with the vertices of that polygon set to color values that create a smooth transition. I tried this as well, but wasn’t quite able to get the same results, and switching the OpenGL blending between normal mode and the multiply mode each frame also added a bit of overhead, so I went for a simpler method where I just supply the smoothing color values to the vertices of the sprite itself, skipping the overlay entirely.
The Project Zomboid method results in much smoother lighting on the ground (there really aren’t any hard edges at all), while my method still retains some of the per tile lighting, which I kinda like. It’s sort of halfway between the old X-COM hard lighting and the completely smooth lighting of Project Zomboid. I’m adding a toggle to the options menu to turn smooth lighting off if you prefer the old school hard edges.
Light sources can now be added/edited in the map editor
Light sources can also be “baked” into the map to avoid having to calculate shadow casting for static light sources
Added the Remote Trigger
Integrated some more of the scripting language so that light sources and elevators can be toggled off/on
Added a briefcase with money to your inventory showing how much cash you’ve got
Work continues on the female character sprites for getting shot and killed, and I’m almost done with the doubling of male character aiming and shooting sprites. I also just today managed to improve the lighting engine to allow for more smooth lighting (partially inspired by the great work done by the Project Zomboid guys), but that’s still work-in-progress, which is why I’m not showing it in this video. I’ll put some screenshots up when it’s worth showing.
And then there’s the big elephant in the room: AI. It’s quite a daunting task, since so much of the game will be about manipulating NPCs, and I’ve only briefly jotted down some ideas. I recently finished Batman: Arkham Asylum (can’t wait to get my hands on Arkham City!), and the reactions of the NPCs in that game is somewhat of an inspiration – especially how the thugs would freak out the more of them you picked off. But I’ll probably write a separate blog post on AI at some point, so I won’t go more into that now.
Tied player actions to noise and suspicion generation
Particle effects to show characters growing suspicious
Added pauses to character dialogue
Resolution can now be changed in-game
Added small thumbnail images for saved games
I’ve also almost finished work on doubling the directions for the male aiming and shooting animations (from 8 to 16 directions). After that, I’ll make the missing sprites for female characters (aiming, shooting, hit, and fall/die). There’s also still a bunch of minor things, bug fixes, optimizations and tune-ups.
When all that’s done, I think I’ll begin working on the AI, since that’s the biggest component missing before I can really start playing around with actual gameplay — and not just building the surrounding framework. I’m really looking forward to create a simple mission where you have to sneak past patrolling guards or get in a firefight. That’s when all this stuff will hopefully come together and be an actual game! After that, a release of the first pre-alpha version shouldn’t be far behind. Stay tuned!
Even though it’s a bit too early in the development cycle to worry about them, I’ve been working on the game’s menus. When I get fed up with a particular part of the game that’s hard to figure out, instead of taking a break completely from the game, I just shift to something easier and more rewarding, which will eventually energize me to continue work on the original part. So that’s what caused me to make the menus, as they’re quite easy to program.
Here’s the main menu screen:
The smoke is animated, which you’ll see in the next development video I plan on releasing in a few days, and when I’ve scripted out the game’s story and universe in more detail, there will be fiction related stuff (newspaper clippings and photos) fading in and out where the logo currently is.
And this is what the load/save game menu looks like:
I always loved the little thumbnail images that each savegame had in Fallout, so I’ve borrowed that for Hostile Takeover. I’m currently working on the options menu (mostly screen resolution settings, fullscreen/window mode, toggling some visual effects off on older computers) and then I’ll return to the main game itself.
Anyway, I hope you all had a Merry Christmas and a Happy New Year! The past year saw excellent forward momentum on the development of Hostile Takeover and that will continue in the new year with the first playable pre-alpha demo being released sometime in 2012, preferably in the first half of the year.
I redid the stats bars in the upper right display to better fit with the overall style. And I’ve redone the combat mode border to fit the new interface elements. Finally, I made the blood splatters that will appear on the equipped item boxes when your arms are damaged (1-5 blood splatters on each to indicate amount of damage), as well as the splatters on the walk and run buttons when those selections are unavailable due to leg damage. The blood splatters shown here don’t actually match the damage to the player in the screenshot — it’s just to show what they look like.
So I’m now locking the look of the interface, except for any future features that may creep in. The minimap is quite buggy at the moment when the map is rotated and you can’t drag the minimap to examine the game world yet. So that’s next for me to do.
In between moving from our small two room apartment in Copenhagen to a larger and (almost) brand new three room apartment outside of Copenhagen, I’ve had a little time to finish up the interface for Hostile Takeover. Have a look see:
Starting in the upper left corner and going around clockwise, we first have the minimap with a simple outline of buildings and areas color coded green, yellow or red to show how restricted they are. There’s also buttons for rotating the map (and game world view) as well as for toggling on/off whether or not to keep the view centered on the player. You’ll also be able to drag the minimap around to examine the game world.
Next is the combat mode button and then the stats display. From top to button the stats are: Noise, Health and Suspicion. There are two noise bars; one showing the environment/background noise and one showing the noise you’re generating. If your noise level is below the environment’s, NPCs won’t hear you. The health bar is pretty self-explanatory with the character outline showing damage to specific body parts. Finally, the suspicion bar goes from 0 to 100 percent and shows how much attention you’ve drawn to yourself during a mission. That percentage will be deducted from your payout for completing the mission, so 50% suspicion raised during a mission means you’ll only get half pay.
We then have the movement buttons, which from top to bottom are: Kneel, Sneak, Walk and Run. Again, pretty self-explanatory, but damage to your legs will render movement options unselectable. I’m thinking 33% damage will remove run and 66% walk, or something to that effect.
I’m playing around with blood splatters on the buttons to show when an option cannot be selected because of damage. This will also work with damage to your arms. There’ll be blood splatters on the equipped item boxes, aiming will be more difficult and melee attacks will fail more often when your arms are damaged. I’ll slap up a screenshot when I have these blood splatters working properly.
Changed color of Combat Mode border from red to green
Added z-layers and multiple floors in buildings
Added elevators to move between layers
There are still some minor bug fixes and optimizations I need to do before I’ll consider the rendering engine done for now. Two of those bugs actually show up in the video — I didn’t notice them until I’d started editing the video.
I’ll be working on making more environment assets next to fill in those empty floors of the building. I’ll probably also be working some more on new GUI elements, such as a minimap in the upper left corner showing the various area types and the location of your target. For now, I’ve got three area types in mind that will be indicated with green, yellow and red and affect how suspicious characters will be when spotting you. Green areas are public areas where other characters’ suspicion level is just the default. Yellow areas are non-public, but also not restricted areas, for example the lobby of an office building. The suspicion level here will be double. Finally, red areas are restricted areas that you’re not supposed to have access to, so the suspicion level of other characters here will be 4x the default.
The point of most missions in the game is to be as stealthy as possible. Your stealth rating for a mission will decrease when characters spot you, or you otherwise draw attention to yourself. So I’ll also be making a Stealth bar for the GUI that shows your current Stealth level, as well as a Health bar and a Noise bar. The latter shows the level of noise you’re generating as well as the environment noise — so that you can set off environment noise such as fire alarms and car alarms to drown out your own noise.
I hope to have a new development video to show soon. I just need to finish work on elevators and some optimizations with the x-ray effect. In the meantime, here’s a screenshot showing the current state of Hostile Takeover:
I think I’ve come up with a solution for the floating wall problem. I’ll just make a shadow stripe that runs along the bottom of walls on the ground, so it looks like the shadow is cast on the ground and the wall, not on the ground below the wall. I haven’t quite implemented it yet, but it shouldn’t be too hard.
In other news, I’ve been making some cursor icons while finishing up the optimization stuff. These are the ones I’ve got so far that cover the player actions currently planned for the game:
I’m pleased with most of them, but I’m not sure if the middle one is clear enough. Can you tell what it is? And can you guess what action it signifies?
I’m currently optimizing the map drawing code for Hostile Takeover‘s isometric engine. It’s basically all about minimizing the amount of tiles and layers that the code has to loop through each frame to check for stuff to draw – and also trying to minimize the amount of texture bindings for OpenGL. Anyway, as part of this, I tried disabling the wall shadows (which I originally added to create an ambient occlusion effect) to see if they had any substantial impact on the time it takes to draw a frame. They don’t really, which didn’t surprise me much, but the test has left me with doubt as to whether or not wall shadows should even be in the game.
The image on the left is with wall shadows, the image on the right is without:
On one hand, I think the wall shadows make the structures pop a bit more and make everything feel less flat. On the other, I can’t shake the feeling that the wall shadows make it seem as if the walls are floating ever so slightly above the ground. So I can’t decide if I should keep them in or discard them. What do you think?
By the way, the shadow for the “Hensley International” sign is also missing in the right-hand image. That’s just because I completely disabled environment shadows for this test. Stuff like that sign will have shadows – that much I’ve decided on. Of course, it might just be weird if walls don’t have shadows when everything else does…
The world of Hostile Takeover has been pretty flat for a while. There’s been no z-layer, meaning that everything has been on the same level. That’s changed now. In the below images, you can see a building that’s currently 2 stories high (it’ll probably be 4 stories when done, but there’s really no limit to how many z-layers I can add). When you enter such a building, none of the layers above will be drawn, giving you an unhindered view of the level you’re on.
I’ve also added doors that automatically open and close when you need to pass through them, as well as windows. I’m currently working on adding elevators to transport you between the levels of a building (I really don’t want to make an animation for walking up/down stairs — at least not yet). You can already see the elevator doors on the first level of the building.
One final thing I’ve been working on is the map editor. It runs completely in the game engine, so I just press ‘D’ (for ‘developer mode’) when playing to move walls and stuff around. I’ll probably include the map editor with the game to allow players to make their own maps. Along with the scripting language, this will let players create missions for the game, so there will probably be two modes: the campaign with the full story and individual player made missions.
The map editor is still a bit buggy. It works fine for my own purposes as I’m aware of its limitations (such as placement of walls and stuff only working as intended when the map isn’t rotated), but I need to clean it up a bit before it can be used by other people. Look for it in the next development video, which I’ll probably make when I’ve got elevators working.
I’ve been working on assets for one of the environments encountered in the game’s first mission: the parking lot outside the building where your target is.
There isn’t much stuff yet, but it’s a start! If you look closely, you’ll notice a small red dot in the lower corner of the gray car’s windshield. This red dot blinks to indicate that the car has an alarm. Car alarms can be triggered and act as diversions to lure guards away from their post or drown out gunfire. That’s just one of the ways you’ll be using the environment to stealthily kill your target.
I wanted to write a blog post about some of the design ideas I have for Hostile Takeover. A lot of the stuff I’ve been adding to the engine so far has focused on shooting, which has probably given off the impression that Hostile Takeover will be a very action oriented game. It won’t.
While shooting and melee combat will certainly play a part (you are, after all, an assassin), the game will equally be about avoiding direct confrontations through sneaking, diversions and puzzle solving. And I don’t mean puzzle solving in the sense of sliding around tiles to open a door (watch that end up in the finished game now!), but more in the sense of figuring out how to use your environment to gain access to locked off areas or tricking guards into leaving their post.
Hitman: Contracts by IO Interactive
For each assassination job, there’s a maximum payout that you can earn for completing it. But the less stealthy you are and the more suspicion you raise in NPCs, the less you’ll get paid. Specifically, there will be a meter that tracks your level of Suspicion. Shooting characters that aren’t your target will raise your Suspicion, as will being spotted in restricted areas. Saying the wrong things to characters may also raise it (you might try telling a receptionist that you have an appointment with your target, but she checks the schedule and figures out that you’re lying).
Furthermore, all weapons will have two Suspicion ratings. One for when the weapon is concealed in your inventory, and one for when you’ve armed yourself with it and is carrying it openly (I imagine the latter will just be double the former). This means that while you could just take along your entire arsenal for a job and shoot everybody, your Suspicion rating will be sky-high and your payout will suffer – giving you less cash for buying more and new equipment for future jobs. Figuring out the least amount of equipment required to successfully complete a job will be key. I also hope that this will provide the game’s missions with some form of replayability in that even though you’ve managed to finish a job, there’s always the possibility that there might be a way to finish it with a smaller amount of Suspicion being generated.
Indiana Jones and the Fate of Atlantis by LucasArts
The Hitman series is obviously an inspiration, but I always felt those games (at least the earlier ones – I haven’t played through the later ones) were too cut up into completely separate missions. Sure, there was some semblance of an overarching plot, but that didn’t really come into play in the specific missions all that much. What I want to do is give the game somewhat of an old adventure game feel in that items or information you get from one location or job, or characters you meet earlier in the game, will come into play in later jobs. There might also be multiple jobs for you to chose from at some points, but finishing one before the other may give you certain benefits. It’ll still be somewhat linear, though. I’m not making an RPG with a branching storyline. As cool as that might be, I’ll still want the game finished at some point!
Hopefully this will have given you a better understanding of what the finished game will play like. But, of course, the game is in early development, so everything is still subject to change.
I wanted to post this three days ago, but my webhost’s servers got knocked out following massive downpour here in Copenhagen (two months’ worth of rain in two hours!), so the website’s been down for three days. Now it’s back up, however, so here’s a new development video for Hostile Takeover…
Left-clicking on an NPC will make the player follow him/her
When doing an aimed shot, the more the target is in shadow, the harder he/she will be to see and the more the crosshairs will shake
Added button that toggles Combat Mode on/off
When in Combat Mode, right-clicking will do an attack (fire a weapon if the target is far away or do a melee attack if the target is on an adjacent tile)
When Combat Mode is off, right-clicking does the default action for whatever you clicked on (talk to a character, open/close a door, search through a drawer, and so on…)
Started adding scripting support, which means that dialogues are now working
Added the interface for character dialogue
I think I’ll start working a bit more on environments now. I’ll probably start by adding functionality for doors, windows and line-of-sight. I may also do some of the environment art/objects that I know I’ll need for the game’s first mission — I’m getting a bit tired of looking at the crappy temp stuff.
In the video, you’ll probably notice that the sprite for the character I’m talking to (your contact for the first mission) doesn’t really match his portrait. So I’ll either make full unique sprites for him at some point, or just add his clothing sprites to the default pool of character sprites. I do plan to have unique character sprites for some main characters anyway, though, so they don’t all have the same age and body type as the default sprites.
This is the new stuff you’ll see in the above video:
The inventory bar is working
Item labels (appearing when holding down Shift) automatically spread out so they don’t overlap
Holding down the right mouse button instead of just clicking on a target will allow you to do an aimed shot
Characters can be shot in the head, torso, right and left arms and legs
There’s a one-shot kill area on the head and torso to simulate shots to the brain and heart
Redid the expanding blood pools
Added blood splatter to the ground when a character is hit
Also added a blood squib to show which body part was hit
I’m still working on the female hit and dying animations as well as the doubling of directions for the male aiming and firing animations. When doing the automatic shooting, the chance to miss and body part hit is currently just randomly selected, so I’ll still have to add some algorithms for that which take distance and level of light into consideration. I’ll also be adding effects of damage to arms and legs (harder to aim and walking/running slower). When a character gets shot in the arm, there should also be a chance of the character dropping items in hand. Also, there’s currently no line-of-sight check, so you can shoot at characters behind walls.
I’ve been playing around with making character portraits for dialogues. My current plan is that you can only engage in actual dialogue (i.e. the dialogue screen pops up) with secondary and main characters. Extras that fill the environment, hostile guards and similar characters will just brush you off with a quick remark written above their head. Otherwise I’d have to make hundreds of character portraits — and possibly figure out how to make random character portraits if some of the NPCs are randomly generated. I think it’ll also make it more intuitive which characters are actually important to the plot or mission at hand if you can’t just talk to everybody.
I also managed to implement recording functionality. This’ll record the mouse cursor position and keypresses each frame to a text file. It also records the initial seed for randomization. Using this seed and the recorded cursor positions and keypresses, I can get a playback of a play session. Being able to watch a recording of a tester’s session will really come in handy!
The crosshairs will jiggle to make aiming a challenge, and the size of the figure is based on the distance (but using a weapon with a scope will increase the size). The more the target is in darkness, the more the crosshairs will also jiggle. And some weapons will jiggle more than others — the gun will for example be harder to aim with than the rifle.
I’ll be making a video to demonstrate it all when I’ve got everything running smoothly.
The inventory is done. As mentioned in a previous blog post, I didn’t want a separate screen or menu for the inventory, as I want to keep as much of the game focused on the world map as possible. So I’ve made the inventory a bar across the bottom that you can scroll through and drag and drop items to and from.
If it isn’t obvious, all the environment art in the above screenshot is placeholder. Only the characters and the inventory interface is as it will be in the finished game (bar any unplanned changes!).
I’m currently working on the interface for the point-of-view aiming and shooting. All the coding related to that is done and working, so you can now hold down the right mouse button when hovering over an NPC and a small meter on the mouse cursor will fill up. When it’s all the way full, the point-of-view aiming screen pops up.
Here’s a quick list of the new stuff in the above video:
Guns and rifles can be fired at characters.
Characters can be killed by shooting at them.
Dead characters will drop carried items to the ground.
Dropped items can be picked up.
I’ve finally finished doing the most essential animations and sprites required for shooting and killing characters. I haven’t done any of the animations for female characters yet, which is why I’m only shooting guys in the video. Also, as talked about in a previous blog entry, I’ll have to double the number of directions for the shooting animations, as it very often seems like your character isn’t aiming at the target at all. So that’ll be increased from 8 to 16 directions. I also need to do animations for when characters get hit from behind and fall over forwards. And then of course all the shooting and getting hit and killed animations for the female characters. I might also redo the pools of blood — I’m not quite sure I like them. And I’ll definitely be adding a spray of blood to indicate hits and small splatters of blood on the floor around the hit character.
As you can see in the video, items are picked up from the ground by holding down Shift and then clicking on the appropriate item label. Why not just be able to click on the item sprite itself, you might ask? Well, sometimes the item sprites are pretty small (like the 9mm Pistol) and I don’t want players having a hard time picking stuff up. Also, when holding down Shift, only items that are within your range get the label, so you immediately know what you can and can’t pick up. And, also also, if there’s a stack of items or it’s very dark, seeing the actual item sprites on the ground can be difficult. I believe Diablo 2 had a similar system — at least, that’s where I think I got the idea.
I’m also starting to think about the inventory system. I want to keep it as simple as possible and I’m currently not too fond of having a separate screen for handling your inventory, as I want to keep as much of the game as possible focused on the world map. So, my current idea is to move the icons for the items in your hands to the bottom corners of the screen and have a ‘ribbon’ between these with the items in your inventory. You’ll be able to scroll through the items on this ribbon and drag and drop between your inventory and hands/ground.
And, finally, I’m working on first-person aiming. When you’ve selected a weapon in your hand, right-clicking on a character will have you automatically fire the weapon. Whether or not you hit is then calculated based on distance and the visibility of the tile the target is standing on (so characters in shadow will be harder to hit). But if you hold down the right mouse button instead of simply clicking, a meter will fill up on the mouse cursor. If you manage to keep the cursor over the target until the meter is full, a first-person targeting screen will pop up. This shows the silhouette of the target (in real-time, so it’ll move if the target is moving, and the size of the silhouette is based on your distance to the target) and you can then aim and fire your weapon manually. I’ve got the basics already implemented, but it’s not quite in a state to show yet. Look for it in upcoming videos!
That’s all for now. I’m very pleased with the results so far, everything is just taking a bit longer to implement than I had originally anticipated. But I’m moving steadily towards my first milestone: Releasing a version for download with the most basic gameplay elements in place (you can shoot at NPCs and they can shoot back at you).
It’s usually a bad idea to start optimizing your program too early, but I’d been running into some performance issues with my Hostile Takeover engine. The game would slow down considerably when there were many sprites to draw to the screen. The issue was most noticeable when there were many characters on the screen at once, since each character consists of about 14-16 subsprites that are all individually drawn to the screen:
Until now, the subsprites for a single character frame were mostly gathered on a single texture atlas, but there were still some instances where the subsprites were spread out over several atlases – the weapon subsprites, for instance. When a character carrying a weapon was drawn to the screen, the code would first draw all the subsprites “behind” the weapon subsprite, then switch over to the texture altas with the weapon and draw that, and then switching back to the original texture atlas to draw the remaining character subsprites “in front of” the weapon subsprite. Switching texture altases like that is expensive, as the GPU has to upload the new texture altas data.
I had originally just planned on gathering all the subsprites that make up a character frame on one texture atlas, so that the code wouldn’t need to switch back and forth between different atlases when drawing a single character. I did that, and I did get a slight performance increase, but it wasn’t enough. So, what I’ve done now is decrease the image quality of the sprites themselves.
Until now, the sprites were all RGBA8888. This means that for each color (RGB) and the alpha value (A), 8 bits of memory would be used, making the images 32-bit (8×4). This allows for 16,777,216 different colors. This also takes up a lot of memory, though, which again means that the GPU has to push a lot of data for each sprite that needs drawing.
The sprites are now instead 16-bit or RGBA4444. This immediately halves the amount of data and memory used, and provides a pretty significant performance boost. 16-bit “only” allows for 4,096 different colors, though. Compared to the 16,777,216 in 32-bit, you’d think that the difference in quality would be pretty severe. I don’t think it is, though. See for yourself:
At a quick glance, I almost can tell the difference. But if you look closely, you’ll notice that there’s a slight grain to the RGBA4444 image. This is because dithering is used to simulate a higher number of colors. I actually kinda like this grain effect. It adds a texture and feel to the images that I can’t quite put my finger on. So I think I’ll stick with this. Increased performance, lower memory use and a grain effect that I kinda like. It’s a win-win!
At last, the first development video of 2011. The new additions took much longer to implement than I had anticipated, but they were also the parts of the isometric engine that I had most feared programming, so it’s a relief that they’re now done and working as I had hoped.
Walls have been added, so I can now start thinking about buildings and other constructions.
When the player is behind a wall, it will become partly transparent to show the hidden area.
Walls will block light sources, so shadowcasting has been implemented.
Getting the wall sections to link up properly and implementing the transparency/x-ray effect was difficult, but not as difficult as I had feared. Shadowcasting was the opposite. My method is based on the recursive shadowcasting algorithm described here, but there were two major things that had to be changed for that algorithm to work in my engine… and those changes took about three weeks to get working.
First of all, the recursive shadowcasting algorithm is designed for a grid where an entire tile will cast a shadow – it’s often used in non-graphical roguelikes, for example, where a wall is represented by a ‘#’ that occupies a full tile. But in my engine, walls are thin and between the tiles. So the calculations for the shadows had to be redone.
The other major change is that I wanted the shadows to have a soft edge instead of the hard edge between shadow and non-shadow that the default algorithm results in. This meant that I had to keep track of how close a tile is to either a beginning or ending shadow edge and then calculate how much the shadow should affect the tile based on the tile’s proximity to the edge. There are still some minor kinks that need to be ironed out (in rare circumstances tiles that are completely in shadow will be lit), but they shouldn’t be a problem.
The extra time I had to spend on getting this working meant that progress on the shooting animations has been pretty much nil. I’m now back to making sprites for these animations, but some preliminary tests have shown that the 8 directions all the current animations are based on won’t be enough for the shooting animations. When shooting at a character that isn’t at an angle close to any of the 8 directions, it looks really odd – like the player character is shooting miles past the target. I will therefore be doubling the number of directions for the shooting animations from 8 to 16. This should be enough to ensure that it doesn’t look all too odd. But it also means I’ve just doubled the number of sprites required… and the amount of time it’ll take to make them. I’m making the original 8 directions first, though, so it shouldn’t be too long before I can make a video with some shooting going on.
Here’s a new development video with the latest additions to the Hostile Takeover engine. This’ll most likely be the last blog post of 2010. See you all in 2011!
Characters can now carry items (only weapons for now).
The player’s items in the left and right hand are displayed as icons in the top left and right corners of the screen, and the “active” item can be selected by clicking these icons. Right clicking with the mouse will use the currently selected item, so to fire a weapon, you will select it as your active item and right click on the character to shoot at.
Dynamic and colored lighting has been added, allowing for a whole bunch of nice lighting effects.
The searchlight effect in the video has made me think about sneaking in the game. My current idea is that enemy characters will have a harder time spotting you if you’re on a darker tile, so it’ll be a good idea to stay in the shadows when trying to sneak up on an unsuspecting victim or sniping a target from a distance.
The sneaking aspect of the game has also made me reconsider the turn-based combat I had originally planned for the game (and am using in Ascii Sector). Sneaking up on a target and trying to stay hidden in shadows will be a lot more interesting and intense if the entire game is real-time. So as I’m currently working on the gun and rifle shooting animations, I’ll first try to implement the combat in real-time and see how that works. If it’s not up to snuff, I can then always go turn-based, since the real-time combat won’t require much work as the engine is already real-time.
I’ve decided to make less videos and instead make longer videos with more content and more new features in them. So here’s a video with the latest developments on Hostile Takeover:
- Female clothing is done, so the female characters have been added to the game.
- I’ve added a “center map on player” function for when you’ve scrolled far away from your character (currently activated with a hotkey, as I haven’t begun work on the GUI yet).
- The game map can now be rotated in four directions, which I figure is going to be useful when walls and buildings get added to see obscured characters and plan your assassinations (again, currently activated with hotkeys).
Next up, I’ve started adding weapons. This is basically just making weapon sprites that fit into the existing walk and run animations so the characters will be carrying the weapons with them.
I also want to add colored lighting to the engine. It currently supports static light sources that are generated when the map is loaded, but I want light sources to be able to appear and disappear during play and have different colors. This’ll for example come in handy for when you blow something up that creates a fire. I’ll then be able to add an orange/yellow light source with a dynamic intensity at the middle of the fire that will light up the surroundings. Or I could have light sources that constantly change colors for use in a disco (maybe you have to kill some CEO sipping a few drinks there?).
I took a break from the never-ending stream of character sprite pieces and played around with doing some “cover art” for Hostile Takeover.
This was also a bit of a testing ground for making cutscene art. My current plan for cutscenes is that they will be a series of still images shown in quick succession – kinda like an animated comic book. Which is why I like the saturated colors and the general style of this image. I made it by rendering the scene in Blender and then applying various effects and filters in GIMP. I’m pretty satisfied with the result, though I’ll probably add more details at some point. It also remains to be seen how well this cutscene art style will work with the game’s isometric art style.
I’ve also implemented character selection with a green outline for the currently selected character. This will of course be used for selecting a character to attack, talk to, examine, and so on. I’ve begun work on the female characters next and am currently creating the clothing sprites for them.
The continuation of last month’s Part 1 is long overdue, but here it finally is. In Part 1, I described the process for creating the many subsprites that go into creating the full character sprites. In this blog post, I will focus on how the multiple subsprites are actually drawn to the screen to correctly form the complete character.
From:
To:
Two things need to happen for these subsprites to be drawn correctly. 1) The program needs to know where to bind the subsprite from, and 2) it needs to know where to blit it on the screen.
All these subsprites are pretty small in size and storing them all as individual images would not only result in a mess of thousands of image files, it would also present a problem for the game engine. The engine uses OpenGL for drawing stuff to the screen and OpenGL prefers its textures (the images to draw) to be power of 2 in size, meaning that the height and width of the image must be 16, 32, 64, 128, 256, 512 or 1024 pixels. Extensions exist for OpenGL that allow the usage of any size, but not all video cards support this extension, and there’s actually really no reason for using non-power of 2 textures. Why? Well, because even though the subsprites are all very small, they can be packed together in a so-called texture atlas, and this texture atlas can just be power of 2 sized:
This mean that the extension for non-power of 2 textures isn’t needed, but there’s also another benefit of packing subsprites together in one large image file. Whenever OpenGL has to bind (prepare for drawing to the screen) a texture, it takes time as the texture data must be moved to the GPU. If all the subsprites were in separate image files, I’d have to constantly bind new files, but when related subsprites are packed together on a texture atlas, I only have to bind this texture atlas once and can then just tell OpenGL which part of the texture atlas to blit to the screen.
Telling the program where to draw from
And that’s where we get to the first requirement: Telling the program on which texture atlas each subsprite can be found and what the individual subsprite’s coordinates are on this texture atlas. Thankfully, I don’t have to manually create a texture atlas and paste the subsprites onto it. A lot of free programs exist for doing this automatically. You just set the size of the texture atlas and select which files should be packed in it, and the program does it all for you – packing the subsprites together in the most efficient manner. Furthermore, these programs can then output the coordinates of each subsprite on the texture atlas in various formats. It’s then just a matter of getting this coordinate information into the program and creating a procedure for grabbing the correct information for each subsprite.
In code terms, I’ve created a procedure that gets called with the subsprite’s name and then returns the number of the texture atlas and the coordinates where the subsprite can be found. Here’s a snippet of the Pascal code that returns the subsprite positions of all the sprites that go into making the ten frames of a male character walking south:
PROCEDURE GetWalk1SpritePositionValues(SpriteName : String);
BEGIN
IF SpriteName = 'walk1-1malehair-1' THEN SetSpritePositionValues(walkmale1, 334, 257, 12, 11)
ELSE IF SpriteName = 'walk1-1malehair-2' THEN SetSpritePositionValues(walkmale1, 442, 257, 12, 11)
ELSE IF SpriteName = 'walk1-1malehat-1' THEN SetSpritePositionValues(walkmale1, 394, 257, 12, 11)
ELSE IF SpriteName = 'walk1-1malehat-2' THEN SetSpritePositionValues(walkmale1, 409, 209, 12, 16)
ELSE IF SpriteName = 'walk1-1malehat-3' THEN SetSpritePositionValues(walkmale1, 406, 232, 12, 14)
ELSE IF SpriteName = 'walk1-1malehat-4' THEN SetSpritePositionValues(walkmale1, 337, 209, 12, 16)
ELSE IF SpriteName = 'walk1-1malehat-5' THEN SetSpritePositionValues(walkmale1, 167, 392, 22, 17)
ELSE IF SpriteName = 'walk1-1malehat-6' THEN SetSpritePositionValues(walkmale1, 345, 162, 18, 15)
ELSE IF SpriteName = 'walk1-1malehead-1' THEN SetSpritePositionValues(walkmale1, 497, 162, 12, 17)
ELSE IF SpriteName = 'walk1-1maleleftarm-1' THEN SetSpritePositionValues(walkmale1, 327, 270, 8, 10)
ELSE IF SpriteName = 'walk1-1maleleftarm-2' THEN SetSpritePositionValues(walkmale1, 232, 488, 9, 24)
ELSE IF SpriteName = 'walk1-1maleleftarm-3' THEN SetSpritePositionValues(walkmale1, 286, 232, 9, 24)
*snip*
ELSE IF SpriteName = 'walk1-10malerightfoot' THEN SetSpritePositionValues(walkmale1, 351, 270, 7, 10)
ELSE IF SpriteName = 'walk1-10malerighthand' THEN SetSpritePositionValues(walkmale1, 202, 245, 9, 36)
ELSE IF SpriteName = 'walk1-10malerightshoe-1' THEN SetSpritePositionValues(walkmale1, 202, 499, 9, 13)
ELSE IF SpriteName = 'walk1-10malerightshoe-2' THEN SetSpritePositionValues(walkmale1, 494, 179, 11, 27)
ELSE IF SpriteName = 'walk1-10malerightshoe-3' THEN SetSpritePositionValues(walkmale1, 259, 484, 9, 13)
ELSE IF SpriteName = 'walk1-10maletorso-1' THEN SetSpritePositionValues(walkmale1, 410, 0, 35, 37)
ELSE IF SpriteName = 'walk1-10maletorso-2' THEN SetSpritePositionValues(walkmale1, 48, 409, 35, 36)
ELSE IF SpriteName = 'walk1-10maletorso-3' THEN SetSpritePositionValues(walkmale1, 460, 59, 35, 33)
ELSE IF SpriteName = 'walk1-10maletorso-4' THEN SetSpritePositionValues(walkmale1, 425, 59, 35, 33)
ELSE IF SpriteName = 'walk1-10maletorso-5' THEN SetSpritePositionValues(walkmale1, 390, 59, 35, 33);
END;
The SetSpritePositionValues procedure that gets called is just a simple procedure for passing on the values to a set of global variables that I then use when calling the OpenGL blitting procedure:
So the first value that gets passed is the number of the texture atlas (in this case, it is a constant value called ‘walkmale1′), then the X and Y coordinates, and then the width and height.
All these procedures fill up a lot of lines of code, but they are quickly made since it’s just a matter of formatting the coordinate information given from the image packing program. This is the quick and easy part. The program now knows where to draw from. It’s the second requirement that takes a lot of time.
Telling the program where to draw to
For everything related to drawing and placing of characters, it all starts with the character template sprite. This is just the basic character frame with no clothes on:
This sprite is actually never used in the game, since the character sprites are all drawn by using the subsprites to form a complete character sprite. But the height and width of this template sprite is what’s used for drawing the subsprites to the screen. The upper left corner of this template sprite has the coordinates (0,0). When I for example need to figure out what the coordinates of the character’s pants are in relation to this, I just go into GIMP, paste the pants onto this template sprite, move them to the upper left corner to ‘reset’ the coordinates, and then drag the pants to the correct position on the sprite and read how far the pants have been dragged along the X and Y axis:
This gives me the pants’ relative coordinates (relative to the template sprite’s (0,0) coordinates): (6,43). When the character is drawn to the screen, I already know what the character’s overall coordinates are. Let’s say the character’s coordinates are (201,750). To figure out where the pants subsprite should be drawn, I just add the pants’ relative coordinates to the character’s overall coordinates:
(201,750) + (6,43) = (207,793)
So I just tell OpenGL to blit from the coordinates of the texture atlas previously found and to the screen coordinates (207,793). This will draw the pants in the correct spot. It’s quick and easy when everything’s programmed correctly. What takes time is manually determining what each subsprites’ coordinates are relative to the template sprite. That takes a lot of patience and use of GIMP. So, again, I get to listen to a lot of podcasts while doing this stuff!
There’s still one thing left to do before the character sprite is ready to be drawn. As it consists of multiple subsprites, these all have to be drawn in the correct order or you risk having a character with his legs outside his pants, or his head over his hat. How this is managed will be the subject of Part 3.
In this blog post and the next one, I will try to describe the process that goes into creating the sprites that I use for semi-randomly generating character appearances. Part 1 (this blog post) will focus mostly on the making of the actual sprites, while Part 2 will explain how these sprites are blitted (drawn) to the screen at the correct positions and in the right order.
To create the sprites, I primarily use two programs: Poser and GIMP.
Poser is a 3D program focusing mainly on human characters. A few character models come with the program, and you can apply poses and animations to these character models a lot easier than in a full 3D program like Blender or 3D Studio MAX as Poser is designed specifically for manipulating human character models. Additional character models – as well as clothing and props for these models – can be bought at various websites, making it pretty much unnecessary for you to create assets on your own.
GIMP is an open source image manipulation program that is often considered the free alternative to Photoshop. It’s available for both Linux and Windows operating systems, but I’m using the Linux version as the Windows one was a bit unstable on my Windows XP laptop. (Poser, on the other hand, only exists for Mac OS X and Windows, so I’m using the Windows version of that program.)
Now, let’s take a single frame of a walk animation:
This character sprite is actually made up of no less than 14 subsprites – the hat, head, neck/chest, right arm, right sleeve, left arm, left sleeve, shirt, pants, legs, right foot, right shoe, left foot and left shoe:
You’ll probably notice that the clothing subsprites are all white. This is because that having the base sprites being white allows for them to be drawn to the screen in any color you want. I use OpenGL for blitting sprites to the screen, and when calling the procedure for doing that, you can tell OpenGL how high the red, green and blue values of the sprite should be when blitting. When the sprites are white, these values are all 100% at default, but if you want another color, you can for example tell OpenGL to only draw the sprite with a blue value of 50%, which would make the sprite more yellow. Likewise, when drawing the body parts, I can change the colors a bit to allow for different skin colors.
The character models are all rendered out to .png files from Poser, but I can’t just render a fully clothed character – the different body and clothes parts all have to be rendered separately. This would take a looooong time if I had to load and setup each body and clothing part manually. Thankfully Poser supports Python scripting. So I’ve written a bunch of scripts that make Poser (somewhat) automatically load, setup and render each body and clothing part for the various frames and directions that make up an animation.
That’s not the end of it though, as the rendered subsprites from Poser still have to be resized, cropped and cleaned up. For example, this is the shirt sprite that Poser renders:
As you can see, there’s a big margin on this image and blackness where the character’s neck should be visible. So using GIMP, the image is cropped to remove the margin and the black part is manually erased. Finally, the image is shrunk to half size and the subsprite is complete. Like I wrote in my last blog entry, the full walk animation uses ~2050 subsprites which have all been rendered from Poser and manually resized, cropped and cleaned up in GIMP. I’m currently working on completing all the subsprites for the run animation and am making good process. I certainly get to listen to a lot of podcasts while doing this work!
And that’s how the subsprites that make up the complete character sprite are created. They still need to be drawn to the screen, and for them to properly form a character sprite, they all need to be drawn at specific positions and in the correct order. I’ll look at how that’s accomplished in the next blog post.
The sprites that make up the clothes and body parts for the 8 directions of the walk cycle are now done. The below video shows 90 randomly generated characters walking at different speeds:
It’s been a bit more than a week since I posted the last video that showed off just one direction of the walk animation. This doesn’t mean that it only took that time to create the required sprites though, as I’d cheated a little and was already well into making the remaining sprites when I posted the last video. If I add up the time used, I think it’s probably taken about 14 days of full time sprite making to create these sprites (~2050 separate sprites in total), which isn’t too bad and makes me feel that the system I’ve set up is definitely viable. I can imagine that the final six months or so of working on the full game will be all about cranking out these kinds of sprites to allow for even greater variety in character appearances.
I’ve already started work on the sprites for the running animation (the neutral position is done) and am also looking at animation and body templates for female characters. A pity it’s just 3D models and not real models – would certainly have made the task slightly more interesting… Ahem…
Shooting and impact animations are also somewhat in the pipeline – as are weapons – but I want the walk and run animations to be done and implemented in the engine for both male and female characters before I move on to that.
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.
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.
While 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.
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.
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:
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:
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.
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:
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.
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!
Click to enlarge
While 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, 
