This past month, it’s been quiet on the update front, but that doesn’t mean I haven’t been coding away on Hostile Takeover. It just means that what I’ve been working on has proven to be a bigger and more complicated task than I anticipated. In the meantime, here are some work-in-progress screenshots from v0.1.5:
In the last blog post, I mentioned something I was working on that wasn’t quite ready to show yet. Well, it’s working now, so here it is:
I’ve added functionality for showing these power lines when hovering over something that’s connected to something else. Until now, you kinda had to guess or give it a try to figure out what shutting off a fuse box would do, for example, but now it should be a lot easier.
This also means that I can have multiple fuse boxes (or switches or other stuff in the future) that all affect different parts of a building – instead of just a single fuse box that shuts off all power. This really opens up the options for adding various puzzles to a map.
There are still bugs to be fixed in the game, but it seems that it’s stable enough now that I can focus on some stuff that will take a bit longer to implement – and that will also break save game and map file compatibility. I imagine that’s what the release schedule is going to look like for a while: work a bit longer on a release with some new features in it, then do a bunch of bug-fix releases.
Two often requested features will be added in the next release: If you click on or try to use something on an object that’s outside your characters reach, he will now go up to it instead of just complaining that it’s out of reach. I originally didn’t add this as I was afraid a miss-click could mean that you’d for example accidentally break cover. But the annoyance of your character not automatically walking up to stuff seems to outweigh that risk.
The other feature is something I’m not sure of, but will be adding as a test. It’s having floors above the one your currently on not being drawn for adjacent buildings either. This will make it a lot easier to snipe from an adjacent building – but I fear it may make some stuff too easy, unless I can just design the map to take this into account.
I’m also working on a third new feature that should make a certain aspect of the game a lot more intuitive and easier to use. I don’t have it up and running completely like I want yet, so I’ll reveal what it is in a later blog post.
Hostile Takeover was released into the wild last week, and so far the latest v0.1.2 has been downloaded almost 300 times in 2 days. So that’s awesome. I’ve also received a bunch of great feedback and fixed various bugs.
The most pressing issue seems to be the combat. Simply put, for an assassin, you get killed way too easily in a gunfight with guards. So I’ve made three changes to address this: Your shooting animation is no longer interrupted when you take damage, your chance to hit has been improved, and AIs can’t deal you a critical one-shot kill anymore. I’ve also added damage indicators that show how much damage is dealt. This will all be in v0.1.3, which I’ll probably release when I’ve also fixed a bug with an infinite loop that freezes the game.
In the long run, I’ll be adding melee combat. The current idea is that if you’re standing right next to a target, an attack will automatically be with melee combat, while if the target is further away, it’s a ranged attack (i.e. shooting). Melee combat will also be used for sneaking up behind a target and slitting his throat or administering a sedative. For stealthy ranged attacks, I’ll probably also be adding a pistol with a silencer.
Another week of programming done. I added a bunch more functionality to the scripting language, so I can now script the stuff needed for the test map. I also expanded the AI a bit, so that characters will now react to you carrying around a weapon in a restricted area, and when you shoot an NPC that is unarmed, he/she will either run off the map or try to hide – as well as cry out for help, which might attract the attention of nearby guards.
With regards to AI behavior, I also added character types. The most basic types are Guards and Civilians, but I can add whatever type I want (the test map, for example, also has a Receptionist and a CEO). Beyond affecting AI behavior to some degree, this is now also displayed when you hover over a character, along with the character’s name:
I also fixed some minor issues with the spawning of random characters and added random name generation for these spawning characters. It uses the same system from Ascii Sector – basically just picking a first and last name from a long list of names from various nationalities. I feel that each character having a name and type gives them a bit more personality, but it’s not all that important for the actual gameplay mechanics.
AI work continues this week. I’m almost at a point now where I can play through the test map. There’s just still some cases that aren’t covered by the current AI system, as well as stuff that needs polishing. The September release of pre-alpha demo version 0.1 still seems possible. The challenge with working freelance in addition to making a game, though, is that you never really know for sure how much time you’re going to have to work on the game.
Work continued on the AI last week. I’ve implemented sound checks for the noise you make, so NPCs can now react to your footsteps and gunfire if they’re within range of hearing you (the further away, the lower the risk of them hearing it). So sneaking is going to be very useful now for moving around without making too much noise. I only have the crouching animation done, so for now, crouching will be as silent as sneaking (in the finished game, crouching will be used for moving without being seen, and sneaking for moving without being heard).
I’m diving into the searching procedure now, which will be used if a guard hears you without being able to see you, or if an NPC for example finds a corpse and should check the nearby surroundings. It basically just sets some waypoints for the NPC to go to within a certain range of the corpse or where the sound came from. There are some complications to it, though, such as being able to check rooms lining a corridor, if the NPC last say the player run down said corridor, for example. I have some ideas that I’m currently trying out.
In other news, you may have noticed that I’ve set up a forum. Along with that, I’ve disabled blog comments and instead integrated the blog somewhat with the forum (blog posts are automatically posted to the forum, and the blog post displays how many comments have been made on the forum along with a link). I wasn’t able to migrate the WordPress users to SMF users, so I’m afraid you’ll have to register for the forum even though you previously registered for the blog. Anyway, see you on the forums!
I was out celebrating my one-year anniversary with my wife yesterday, so here’s the update for last week one day later than usual…
I’ve begun work on the map for the first pre-alpha release. This will not be a finished map in the game, but a map for testing various game mechanics. I’m basically going to try out various things to find out which is the most fun to play, so I’ll probably be iterating over different map designs to get a good sense of what makes a great map in this game before starting work on the maps used in the actual game. Anyway, I’ve compiled a list of art assets and world objects that I’m currently missing, so I’ll probably be spending a good deal of the coming week making those.
This past week, I also split the Remote Trigger device into two devices for various reasons. The primary being that I couldn’t really see much use for opening and closing doors remotely – the more interesting use is of course to lock them remotely, trapping guards and other NPCs in rooms. So that’s now a separate device: the Lock Override. The remote trigger has been renamed the Electric Surge and can only be used on electrical devices. I think this makes more sense.
And work still continues on the AI. I’m working on the search algorithm for when guards hear a gunshot or you escape their line of sight or they find a corpse. The idea is that the map tile where they heard the gunshot coming from or last saw you or found the corpse will act as the center for the search. But it takes a bit of work coming up with a good algorithm that works both in wide open spaces and inside a building with corridors. I’ve got some ideas that I’m testing out, though.
This past week I finally managed to squash a bug that would sometimes corrupt map files when I removed world objects in the map editor. I was basically just setting the object type to zero when saving the map, but when loading it, the code wasn’t expecting zero’ed object types, so it would try to place these non-existent objects. It was of course just a matter of not writing these objects to the map file at all. Seems simple, but still took a bit of time to figure out.
And, as always, work continues on the AI. This week I fiddled a bit more with AI shooting – primarily tweaking the checks so that there’s a pretty big chance of a hit when firing at a target right next to or very close to the shooter. My algorithms were working fine for shots at a distance, but the AI would often miss a target right in front of it, which seemed kinda silly at times.
I’ve also started work on characters detecting you from hearing you. My current framework is that characters will always react to gunfire (if they’re a guard that’s within range of hearing it) by going to the spot they think the sound came from and starting a search routine with that spot as the center. If you’re making noise in a yellow area, this can cause characters to turn to face you – and react with suspicion if you’re sneaking or crouching. And any noise made in a red area can cause a guard to start searching for you and attacking you if you don’t leave quickly enough (or if the guard is already hostile towards you).
That’s the basic framework, which I’ll then tweak so that civilians for example react differently than guards. For one, they shouldn’t always come running to investigate the sound of gunfire, but should instead most of the time run away from it in a panic. After that, I’ll start working on NPCs reacting to finding a corpse.
I was in France on holiday for most of last week, so I didn’t get all that much work done. I did manage to improve the aimed shooting, though.
Before, the crosshairs themselves would be jittering about on the screen, so you’d have to fight with the controls to line up a shot. This could be quite annoying sometimes – even more so on on a trackpad. I’ve now changed it so that the silhouette of your target will move instead. The movement is also more smooth. I’m considering having the silhouette move more when the target is walking/running to simulate the difficulty of hitting a moving target, but I’m not sure about that. I’ll do some testing.
I also improved the AI shooting and the player non-aimed shooting. Before, a random body part would be chosen to take damage. Now the AI just uses the same character masks that are used for an aimed shot to check for a hit – meaning that body parts can be hidden behind other body parts if the target character is standing with his side to the shooter, for example.
Work continued on the AI for Hostile Takeover this past week. I also ran into some issues with characters not getting drawn on the correct level if they’re in an elevator when a saved game is loaded. This almost took an entire day to figure out. A bit annoying, but it felt good when I finally figured out what was wrong (as is the case 99% of the time, it was all due to developer stupidity).
If a patrolling guard (and sometimes other types of NPCs) sees you crouching or sneaking around in a yellow area, he will stop and look at you, his hostility level will go to suspicious (making his dot on the map go from green to yellow), you will lose a bit of stealth and he’ll utter a line of dialogue.
If a guard spots you in a restricted (red) area, different things can happen. If he was already suspicious of you, he will attack you almost immediately. He will also attack you almost immediately if there isn’t a yellow area on the level you’re currently on. If there is a yellow area (such as an elevator going to an area that isn’t restricted), he’ll tell you to leave the restricted area. If you don’t leave quickly enough – or you start walking deeper into the restricted area – he’ll attack you. Attacking is still very much work in progress. For now, an attacker will just stand motionless and shoot at you. So I’m currently working on getting them to change position if line-of-sight is broken.
I also got damage to show correctly on the upper right display. And blood splatters on various interface elements to signify damage to arms and legs. Finally, I made damage to your legs affect mobility. If the health of your legs is less than 75%, you won’t be able to run, less than 50% and you can’t walk either, and at less than 25%, you’re unable to sneak as well. This automatically means that people will grow suspicious of you if you’re in a yellow area and your legs have received more than 50% damage, since you’ll only be able to sneak or crouch then.
Finally, I added checks for player death. There are three ways you can die from damage: If your total health reaches 0, if your head gets completely damaged or if your torso gets completely damaged. This will all sound very familiar to players of Ascii Sector.
This week, I’ll mostly continue with AI stuff, but there are also some minor interface quirks I’ve run into that I want to address.
I finally got the last big optimization working last week – well halfway. Explanation follows.
The way I do the x-ray effect in Hostile Takeover is to draw the area around the player character without drawing walls in front of him nor any other objects that you should be able to see through. This is drawn to the back buffer and never actually shown on screen. I then read this from the back buffer into a 128×128 pixel image and change the alpha value of the pixels so that the further they are from the image center, the more transparent they are. I then draw the screen as usual and finally draw this 128×128 image back on top of this.
The problem with this is the part where I read the pixels from the back buffer into the 128×128 texture. The whole rendering pipeline is optimized for writing/uploading information to the GPU and framebuffer, not reading/downloading. So on older systems, this can create a bit of a bottleneck. The solution is to use a framebuffer object (FBO) instead. FBOs were an extension to OpenGL that I believe now has become a core feature. Instead of writing to the back buffer and then reading back the information in order to apply the gradual transparency and writing the whole thing to a texture, I can use FBOs so that a texture can be set up to work like a framebuffer, meaning that I can draw everything directly to the texture – cutting out the bottleneck of reading pixel information from the back buffer.
It all works fine and dandy and quite a bit faster – at least when running in a window. I’m having an issue with the 16-bit depth of the game messing up the FBO in fullscreen. So for now, it’ll just fall back to the slower method when running in fullscreen, and I probably won’t be spending more time on this for the pre-alpha release. But if you’re running the game on a computer that isn’t more than 5 years old, you probably won’t have any issues with this anyway. And if you do, you can just run in window mode for now.
So that’s off my to-do list for now. Which means that I’m now finally fully into AI. The first thing I did was extending the pathfinding code to work across multiple layers, meaning that NPCs now know how to use elevators. Following that, I’m focusing on patrolling guards and how they’ll react to spotting you.
There are three types of areas, color coded green, yellow and red on the map. In a green area, your stealth level can’t decrease. In a yellow area, it’ll decrease if you get spotted doing anything you shouldn’t be doing. And in a red area, you’ll lose stealth as soon as you’re spotted – and if you don’t leave fast enough (of if the guards are already suspicious of you), you’ll get attacked. All that is working, except for the attacking part. So I’m currently teaching my little NPC dudes how to shoot guns. They’re slowly getting the hang of it.
Last week I managed to complete the saving and loading stuff. I also figured out how to use zlib compression, so map files are only about 10 kB in size (compared to more than 1 MB uncompressed) and save files just over a kilobyte. Right now, the entirety of Hostile Takeover is under 20 MB in size, in case you’re wondering. But that will of course grow as more maps and assets get added.
After the saving and loading stuff, I was planning on doing the last big optimization, but plans are made to be broken, so I instead added a ‘current objective’ button (that also provides tutorial hints), as well as a ‘mission restart’ button (won’t yet be fully implemented in the first pre-alpha release) and a timer.
Currently, there’s only one use for the timer: If your stealth level drops all the way down to zero, you’ll have a few minutes to complete your assassination and escape the map or you’ll fail the mission. In the finished game, I’d like for the mission to not just fail automatically when the timer runs out, but instead have extra police/security guards drive onto the map and surround the building. So you’ll still have a chance of completing your mission – getting out alive will just be very hard.
I’m now diving into that optimization thing. For real this time!
This past week I successfully expanded the line-of-sight code to support covers. Objects in the game now have height, meaning that you can hide behind high enough objects – but so can NPCs, so your line-of-sight to a target can be partially obscured when aiming.
It’s of course a lot easier to hide behind cover if you can crouch, so that’s now in as well. Kind of. I haven’t made the animations and sprites for the crouching player character yet, so it’s just a stand-in sprite for now. Look at that creepy naked guy hiding behind a wall (he actually kinda looks like a Terminator that’s just arrived from the future!):
I won’t be making the proper sprites for crouching until after the pre-alpha v0.1 release, meaning that this is also what your crouching guy will look like when you actually get to try it out. Hopefully suddenly being in your underwear won’t be all too immersive breaking…
The reason for this is that the crouching animation is a special animation that only the player character will do. The randomly generated NPCs won’t have this animation. For these kind of special player animations (as well as NPCs with unique looks), I’ll be using a spriting system that’s a bit different from the one used for the randomly generated NPCs. As those are randomly generated by combining various clothing sprites, all the various body and clothing parts have to be in separate sprites. But when I’m making the sprites for a character with a fixed look, I don’t have to separate them quite as much as they don’t have to be combined randomly. Whereas each frame of a randomly generated character currently requires about 40 separate sprites, I only need about 5 for the unique characters. However, as I haven’t decided on the final look of the player character, I won’t be making his special sprites quite yet. That’ll probably be in the second pre-alpha release.
I’ve also been adding tooltips, shortcut keys, finishing the female hit and die animations, and working a bit more on the map editor in the past week. But I’ve definitely been most excited about covers and crouching, as that immediately added some fun gameplay elements – even as bare bones as the actual game part of the game is as the moment. It feels like it’s really starting to become a game now, as I’m able to crouch behind a wall to avoid being seen by a guard, and the second I stand up, he spots me. The AI still needs a bunch of work, though, as he can’t yet shoot at me or otherwise react except for “SPOTTED!” appearing above his head.
I’ll have a new development video up next Monday showing all the stuff that’s been added since the last video.
For the past week, I’ve been doing a lot of behind the scenes work on Hostile Takeover. Some of this work has gone into refactoring the code to make it easier to add environmental sprites and data in the future. And a bunch of work has gone into making the map editor as usable and powerful as possible.
Until know, the information for each object making up the game’s environment has been spread out across multiple files, procedures and units. To draw a chair, for example, depending on whether the code was running in-game or in the map editor, information about which specific sprite to use (based on the map and/or object’s rotation), which texture atlas this sprite could be found on, where it should be drawn on the screen relative to the tile it’s on, whether or not the sprite should be flipped vertically or horizontally, and how the object will block line-of-sight – all this information was scattered around in the code. Not only was this highly inefficient from a coding point of view, as information would be duplicated across procedures and files, but adding new stuff to the game would’ve been a nightmare. I’ve now split everything into three highly structured files, ensuring that this process will be a lot simpler and quicker.
Adding the individual sprites and objects to the game is only the first part, though. I then have to build a map with them. Adding ground, walls, interactive objects, light sources and characters into a coherent whole can quickly become a messy process, so having a powerful and easy to use map editor is essential. I believe it takes a lot of iterations to make a good and challenging map – and the easier it is to build and modify a map, the more willing I’ll probably be to scrap something that simply isn’t working, or refine something that isn’t quite there yet.
So while my map editor may not look very flashy – and is probably very fiddly to work with if you don’t happen to be the guy that programmed it – it does everything I need it to do to build a map as comfortably and easily as possible.
When a map has been built, I’ll move to the scripting language to program the effect of the player’s interaction with the map, as well as dialogues (between the player and NPCs) and conversations (between NPCs).
Aaaaaand here’s the final look of the interface:
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.
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.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. 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.