(Categories: Hidden Asset)
The Windows and Linux alpha versions of Hidden Asset are ready for testing!
If you want to be a tester, please go here:
(Categories: Hidden Asset)
The Windows and Linux alpha versions of Hidden Asset are ready for testing!
If you want to be a tester, please go here:
Alpha testing is so close that I can taste it! Tastes like chicken, by the way. I was actually hoping to have the game ready for closed alpha testing already, but issues that I needed/wanted to address kept popping up. In this video, I talk about two of the gameplay issues I’ve dealt with.
The first issue was how strict the game is in regards to guards hearing your footsteps. Before, they would always react to hearing your footsteps, but I’ve now made it a bit more lenient so that they won’t react to your footsteps if there are other NPCs near you, since the footsteps might as well have come from them. The game was just too unforgiving.
The second issue was aimed shooting. The whole gimmick of a screen popping up where you would see a first-person view of your target and had to aim manually just didn’t feel right when actually playing the game. It felt too involved and ruined the flow of the game. So I’ve simplified how all that works.
I also added a way for me to track play statistics for alpha testing. The game will keep track of various stats, such as total play time, deaths, kills, your stealth rating and so on, and write it to a plain txt file. Testers will then be able to just paste the contents of that txt file into a post on the forums, or upload the txt file itself, and I’ll be able to get a good overview of how hard certain parts of the game were in general.
For the game to be completely ready for alpha testing, though, I still need to fix some bugs and crashes. And then compile and test the Linux and Mac OS X versions of the game… and also setting up a forum for alpha testers where they can offer feedback and report bugs as well as download the test version of the game. My current idea is that if you want to be an alpha tester, just make a post in a forum thread I’ll set up for that purpose (and register for the forums first, if you aren’t already). I’ll then grant you “Tester” status on the forums, which will also give you access to a hidden forum post with the download link.
That’s the plan, at least.
I mostly did bug-fixing in the past two weeks, which isn’t all that interesting for a development video. So I instead show some of the new assets I’ve made. I also touch a bit upon how the 2D isometric rendering functions in Hidden Asset.
It’s a new year, and here’s a new development video! In this video, I show the improvements made to the gadget interface, and I also do a bit of scripting.
Last development video of the year. I demonstrate the traffic fully working and pedestrians stopping for red lights, but I also just play part of the first tutorial mission to show some gameplay.
I’ve expanded the code that handles arriving police cars to handle traffic in general, so in this video I go over what I did and demonstrate the traffic working (and also not working quite as well).
I wasn’t entirely pleased with the police arriving stuff shown in the last video, so I’ve polished that a bit more. I also made some new assets.
If the player’s stealth level drops to zero, police should arrive on the scene and take up positions outside the building entrance, so I add that in this video.
In this video, I take a small detour back to melee combat to fix some issues then sketch out the rest of the second map.
The executive office (as well as some additional assets) are now done, so I do a bit of NPC scripting.
In this video, I start working on the remaining art assets for the second map.
In this video, I mostly try to teach guards not to be stumped by a locked door. Will I be successful? Watch the video to find out! (Spoiler: I was)
Longer video than usual as I’m trying out a new format. In this video I implement low melee attacks/kicking. If you have any questions, comments or suggestions for stuff you’d like for me to cover in future videos, please let me know!
As teased in my screenshot for last Saturday’s #screenshotsaturday, the big news in the world of Hidden Asset is that the game is no longer in pre-alpha. There are quite a bit of different opinions on what pre-alpha, alpha and beta means in the world of videogames, but here’s how I use these terms:
So this means that all the core features and functionality of Hidden Asset are done. This is basically all the hardcore programming – a huge milestone! I can now focus almost all my dev time on designing levels, making assets and writing the full script for the game. As a result, the pace of development should also pick up a lot going forwards.
There’s just one thing I need to change code-wise before I can leave the heavy coding behind: switching from SDL 1.2 to SDL 2. This shouldn’t be that huge of a deal for Hidden Asset, since I only use SDL as a wrapper for OpenGL and for processing sound and inputs, which I believe hasn’t changed much from SDL 1.2 to SDL 2. I’m also switching Ascii Sector over to SDL 2, though, which should fix some problems with running that game on Mac OS X. Ascii Sector uses SDL for graphics rendering, which seems to have changed a lot from 1.2 to 2, so that may take up some dev time. We’ll see.
When I’ve switched everything over to SDL 2, I’ll build the last of the two introductory tutorial missions for Hidden Asset, and then this alpha version will be ready for closed testing, barring a few bugfixes and polishing. I’ll make an announcement when I’m looking for testers.
In addition to working on fixing and improving the AI, I’m currently working on adding carrying corpses. Beyond the programming involved with that, it also entails a new set of animations and a bunch of character sprites for these animations.
When I first started working on Hidden Asset, making these character sprites took a looooong time. At least a couple of weeks were spent making the thousands of sprites just for the walking animation. Since then, I’ve automated a lot of this process so it now only takes a few days. I thought I’d run through the process of making the sprites for a single animation set and how I’ve automated as much as I could to speed it all up…
Every character animation I make always starts in Poser. Here, I manually animate the default male Poser character. When I’m happy with the animation for him, I then also apply the animation to the female Poser character and correct any issues that crop up due to these two characters not being of the same size and proportions, so the animation from the male character doesn’t fit 100% on the female one.
For the ‘carrying a corpse’ animation I had to animate two characters at once: the player character and the poor guy/gal that’s dead and being carried. When this was done, I rendered out my template animation frames. For this specific animation, it resulted in these 10 frames of animation (here shown in 1 of the 8 movement directions):
These template frames are then animated in the actual game engine, meaning that each frame gets a set of coordinates that tell the game where the sprite should be drawn relative to the tile the character is on. I’m now ready to start rendering the actual sprites for use in game, since these template sprites are never used directly in the game — only for figuring out the relative coordinates for each frame.
Thankfully, Poser offers something called Poser Script, which is short scripts written in Python that can be used to basically automate anything you do in Poser. For my needs, these scripts are used to automatically load and apply clothes and hair and the like to the Poser characters, then rendering out each of these items separately and for each frame and direction of the animation. It doesn’t take much time to write such a script, especially now that I’ve already done this process a bunch of times and can just reuse old scripts. So I set a script to run in Poser and can usually leave the computer for half an hour or so — or work on something else while the sprites render in the background.
When this has been done for all the body parts, clothes, shoes, hairstyles and everything else for the characters, I usually have a few thousand separate sprite images in my folder. For this particular animation, I actually first rendered out the player character, since he’s just a single sprite:
When rendering the sprites for the character being carried, I applied a flat grey material to anything that wasn’t the specific sprite being rendered to mask out anything that’s obscured by the character itself or the player character carrying it. Let’s use a pants sprite as an example. Here’s one of the pants styles for the first frame of the animation:
Before I got clever about automating as much of this as possible, I only rendered the pants themselves, so I had to manually erase everything that was supposed to be obscured. If you have to do that for X thousands of sprites, you can probably imagine why this took so long for the first set of animations I made for the game. Now I’ve just written a small program that automatically reads all the image files in a folder and erases anything in the image with the exact gray color used for the mask. So I just copy this program into the folder containing the image files and run it. It chugs along for a couple of minutes and then everything has been erased just the way I want it:
There are sometimes still a few issues that need to be corrected manually. Sometimes the gray color was also present in another part of the image, so I have to restore the part that shouldn’t have been erased. Or parts of the character was clipping through the sprite and covering it, so I have to patch that area. But it’s negligible compared to the work needed before. I can probably quickly check and fix all the thousands of separate sprites over a day or two.
I do this in GIMP. But I do more than just fix any problem sprites in GIMP — I also shrink the sprites to half size. Whether drawing by hand or modelling and rendering through a 3D program such as Poser, Blender or 3ds Max, it’s always a good idea to make the original artwork in higher resolution than needed and then shrink it. You’ll get more detail in the final artwork/sprite like that. Also, in my particular case, the jagged edges left behind when the gray areas were deleted become more smooth when the image is shrunk:
In keeping with my attempt to automate as much as possible, I’ve written a small GIMP script that automatically shrinks all open images to half size and saves them. So I usually have 20-30 images open at a time in GIMP, then quickly check them for issues that need fixing and then just run my script. Quick and easy!
For each of these sprites to be drawn in the right place on screen when running the game, the engine needs to know the sprites’ coordinates relative to the template sprites. So when the game is running, these ‘sub-sprites’ (that are each a separate body part or clothing item) are drawn to screen relative to the original template sprites, which were drawn relative to the ingame tile.
To get the coordinates relative to the template sprites, I use another program that I wrote for this purpose. Just as I did with the program that erased all the masked parts, I copy this program into the image folder and run it. This program automatically crops each image and then writes the coordinates of the cropped image’s top left corner (what the coordinates of the cropped image’s top left corner were on the uncropped image) to a text file. This leaves me with thousands of cropped sprite images that are as small as they can possibly be — and a long list with the coordinates for each sprite:
Using a third program I wrote for this specific purpose, these coordinates are then converted into a format that I can copy/past directly into the game’s code. Voila!
All I need to do now is gather all these thousands of sprites into a few sprite sheets and feed the coordinate of each sprite on the sprite sheet into the game’s code. This is also done with my own program that spits out a text file with coordinates that are formatted so they can be copy/pasted directly into code.
And there you have it. There are quite a few steps involved, but automating as much as possible has made what was once the biggest bottleneck when developing Hidden Asset almost a breeze!
Finally got my hands on some new (second-hand) external hardware for recording videos:
I’ve finished the art assets for the last remaining area of the first map, which is this small homeless village right on the edge of the map. You won’t be interacting with this area, so it’s mostly there as world flavor, since this game’s world is in a deep economic crisis. I’ll also be scattering these assets across other maps, so most maps will have a few homeless people hanging out.
So beyond a final art pass to add a few missing details here and there (and additional frames of animation so that some of the homeless guys will be warming their hands against the fires or sitting on cardboard on the ground), this means that the first map of Hidden Asset is pretty much done.
Next, I’m going to work on fixing some AI issues. I’m thinking I’ll be doing a short series of development videos of this process with each video first demonstrating the issue and then the fix.
It started when I wanted to optimize frightened AIs searching for cover to hide behind. Before, they’d check all tiles in a given radius and see if they provided cover by doing line of sight checks for each and every tile. That was quite wasteful. A simple way to improve that system was to have each tile already hold information about the cover it provided — and just fill in this information when loading a map and update it accordingly when doors are opened or closed, and so on.
It also improved performance by not having to do as many line of sight checks in the rest of the code. Because with this improved system, if I’m on a tile that is designated as providing cover in direction X and the enemy I’m checking line of sight for is also in direction X, he doesn’t have line of sight and there’s no need to go through the more performance-heavy process of tracing his eyeline and checking if it intersects with any objects.
And now that I had information for a tile’s cover on hand, it was easy to visualize this information by borrowing XCOM’s shield indicators. The small difference being that in XCOM, your soldiers automatically crouch behind low cover, while in Hidden Asset you have to do that manually, so there’s a crouch icon that shows if you have to crouch behind the cover:
Combined with the shadowcasting from all characters, these cover indicators in Tactical Mode make it a lot easier to sneak around and avoid being spotted. So not only did I improve the AI cover finding, I also made it easier for the player to understand the cover system. Two birds with one stone!
I recently added another character with a unique look to Hidden Asset. Unlike the bouncer and Tony Vargas, however, this character will also show up later in the game. He’s what is referred to as a Contractor in the game’s world.
When a company needs someone killed, they don’t get in touch with the assassins, or Assets, directly. Instead, they contact a Contractor that deals with the company-end of the deal. This Contractor then gets in touch with another Contractor who deals with the Assets. This double-middleman arrangement ensures that nobody knows who hired who.
So in the above screenshot, that’s the company’s Contractor talking to you, which is unusual. But the company (or whoever it was that hired you) insisted that their Contractor witness the hit in person, since you’re a rookie in the assassination business and they wanted to make sure you were up for the task before hiring you for a second job.
This anonymity between employer and assassin is a core part of the game’s story. The plot kicks in when you’re forced to find out who hired you to carry out a specific hit.
I got back from vacation about a week ago but have only now had time to write a new blog post. First of all, I had an awesome week in Berlin. Germany won the World Cup the evening we arrived, so we just managed to catch Super Mario GÃ¶tze scoring the winning goal and then went out into the street to celebrate with the rest of Berlin. What a great way to kick of a vacation!
But anyway, one of the big reasons for this late blog post is that this site (and a few other of my sites) was hacked on one of the last days on vacation. So the first couple of days back was spent cleaning up this hack, which was a result of a security hole in the MailPoet newsletter plug-in for WordPress. This security hole has since been fixed in the plug-in, which is why I’m still using it, but it resulted in all php files across this and other of my sites being infected with some code that was most likely meant to redirect to less sober websites but just messed up WordPress completely and resulted in blank pages.
It took a couple of days to clean out all the injected code as well as a couple of backdoors — and reinstalling some parts of WordPress and the forums. Since the Ascii Sector site also got infected, I decided to use this as an opportunity to merge the forum over there with the Laserbrain forum, since the Ascii Sector forum was an old phpbb forum that’s no longer supported and could prove a risk in itself in the future.
With all that being said, I did manage to do a bit of work on Hidden Asset in the past weeks. Mainly bug fixing and minor things I could look at whenever I had an hour’s time in an airport or between sightseeing. I also managed to complete the nightclub on the first map of the game, so your first target is now chilling and celebrating his birthday in the nightclub’s lounge before he meets his untimely demise at your hand:
The sitting poses for the randomly generated characters are a bit stiff, but I’ll be adding some more relaxed poses in the future.
Next, I’ll be working on the final part of the map — some old train tracks that have become a small village for homeless people. In the opening cutscene, your character will be walking past this area as part of introducing the economic crisis that’s ravaging the game’s world. And when that’s done, I’ll be diving into fixing a bunch of A.I. jankiness.
Until now, NPCs in Hidden Asset didn’t care whether they walked on the road or sidewalk. When finding a path from one spot to another, they’d always choose the shortest path. But having NPCs walking in the middle of the road without a care in the world is pretty immersion-breaking. So I had to implement some kind of way of having NPCs prefer walking on the sidewalk. This turned out to be much simpler than I had anticipated.
A* pathfinding works by checking potential paths between nodes until the destination is reached. For each node, you store how far you’ve traveled to reach that node. When the destination is reached, you just backtrack through the nodes with the smallest ‘distance traveled’ value. This gives you the shortest path to the destination. For my purposes, each tile is a node.
The distance traveled can just be 1 for each tile. So if you move through 4 tiles to reach the destination, the distance traveled will of course be 4. But because the pathfinding will choose the shortest path, changing this 1 to some other value for specific tiles or situations can have huge effects on the final path found.
One example of this is that I don’t give the same value when moving diagonally as when moving straight. While moving straight results in the ‘distance traveled’ to be increased by 1, moving diagonally increases it by 1.4. This is quite simply because you’re moving further when moving diagonally across a tile that’s a rectangle than when you’re moving straight across it.
A Pascal code example:
IF MovingDirection IN Diagonal
THEN Tile[NextLayer, NextX, NextY].G := Tile[ThisLayer, ThisX, ThisY].G + 14
ELSE Tile[NextLayer, NextX, NextY].G := Tile[ThisLayer, ThisX, ThisY].G + 10;
This code snippet takes the ‘distance traveled’ value (G) of the current tile and applies it to the next tile while increasing it with either 14 or 10 depending on whether or not it’s a diagonal movement (I use 14 and 10 instead of 1.4 and 1 in order to stick to integers — the individual values don’t matter, they’re only important in relation to each other).
However, I can also say that moving across a road tile will increase the ‘distance traveled’ value by an additional 10. The result of this is that an NPC will only choose to move across a road tile if sticking to the sidewalk means that he’ll have to walk at least an extra 10 tiles. Furthermore, I can tell the pathfinding that if there’s a pedestrian crossing on the road tile, don’t add the road ‘penalty’ to the pathfinding.
So I add a function call to the above code. This function returns the ‘penalty value’ for a given tile.
IF MovingDirection IN Diagonal
THEN Tile[NextLayer, NextX, NextY].G := Tile[ThisLayer, ThisX, ThisY].G + 14
ELSE Tile[NextLayer, NextX, NextY].G := Tile[ThisLayer, ThisX, ThisY].G + 10;
IF WeightTiles THEN Tile[NextLayer, NextX, NextY].G := Tile[NextLayer, NextX, NextY].G + TilePathingWeight(NextLayer, NextX, NextY, MovingDirection IN Diagonal);
Note that I only add these tile ‘penalties’ if the pathfinding function was called with WeightTiles defined as TRUE. I don’t add this tile weighting when pathfinding for the player character, for example, as it should be up to the player to decide whether or not to use the sidewalk and pedestrian crossings.
The result of all this is that characters will stick to sidewalks and pedestrian crossings, but if they really need to cross the road and they’re far from a pedestrian crossing, they’ll still choose to cross the road instead of taking a long detour. Here’s my NPCs demonstrating safe traffic behavior (though they don’t care about red lights):
Another use for this would be to have characters walk around corpses instead of over them. If there’s a corpse on a tile, just add 100 (or some other large value) to that tile’s penalty.
This is something I’ve been considering doing for more than a year, and now I’ve finally decided to pull the trigger (pun intended). I’m changing the name of
Hostile Takeover to Hidden Asset.
There are two primary reasons for this name change:
There’s a lot of stuff out there already called “Hostile Takeover”. The Syndicate co-op, a board game, sci-fi books, movies, etc. It’s a name that’s used for a lot of entertainment products, and as such it’s just too generic.
The name also poorly describes the actual game I’m making. I’ve had people think that it’s either a corporate strategy/RTS game or an all-out action game. It’s neither. It’s a stealth game with a focus on puzzle-like level design. Having a name that suggests a different game than the one I’m actually making probably isn’t a good idea.
The name Hidden Asset is a much better fit. It still suggests a game that has something to do with corporations and businesses, but instead of making you think of an action game, it makes you think of secrets and stealth… and conspiracies, which the game will have its fair share of.
The corporate assassins in-game are also referred to as hidden assets, so the name makes sense from that perspective as well. Finally, I’ve been able to find practically no other entertainment products with this name, so that’s definitely also a plus!
So there you have it. Hope you like the new name as much as I do!
One of the big issues with the previous releases was melee combat. It just wasn’t very intuitive. The way it worked was that you could hold down the right mouse button to block at any time, but if you held it down for too long, you’d start building up ‘melee fatigue’ and wouldn’t be able to neither block nor attack until the fatigue had expired.
This system was meant to keep the player from holding down the right mouse button to block continuously, but it just wasn’t very intuitive. Why, for example, would you build up melee fatigue just by holding up your arms to block a potential attack? It didn’t make much sense. So I’ve completely scrapped the idea of melee fatigue, and instead implemented a more classic system where you can only block when an actual attack is incoming. So now it’s much more a matter of being able to react quickly when your opponent makes a move. I also added Arkham Asylum-styled indicators above an opponent’s head to indicate when an attacking is imminent and you can block.
It also wasn’t clear when you could attack an opponent without risking your attack being blocked and you being stunned for a while. The way it worked was that your opponent would be stunned for a while after you’d blocked his attack, and you could freely attack him while he’s stunned without fearing him blocking your attack. It still works like this, but now I’ve added animation frames to show when a character is stunned and open to an attack.
Here’s a low-quality gif animation to show the new system:
And now I just noticed that the attack indicators should probably be red when you’re stunned… Adding that to my to-do list. :)
Melee combat is pretty simple and that’s on purpose, since combat really isn’t the main focus of the game. It’ll be a lot more about puzzling out situations and using your equipment to avoid combat. But there still needs to be a combat system for when your stealthing fails and there’s no other way out.
One way I’ll be adding a bit of depth to the melee combat system is through weapons. Different weapons can work differently and have different effects. For example, in the above gif, I’m using a knife. This weapon’s special characteristic is that it still does damage (to the opponent’s arms instead of head) when the attack is blocked. There’s also a baton that when used and blocked makes the blocked character stunned for a shorter amount of time. Other weapons can for example deal splash damage to adjacent opponents, or maybe you have to click the right mouse button fast to build up to a single deadly blow? There’s a bunch of possibilities.
There have been a bunch of improvements to Hostile Takeover‘s visuals in the past year. I’ve upped the graphics from 24-bit to 32-bit, since it seemed more and more silly to sacrifice visuals for better performance on low-end computers. And I also abandoned the older, more retro UI in favor of a somewhat more modern and less obtrusive design.
But one of the changes that took the longest to implement was the new and improved lighting system. Not because it’s all that complex, but because it took some tinkering and experimentation to figure out how to do it right. So that’s what I want to talk about in this blog post.
In the below image, you can see the 3 levels of lighting quality that you can set in the game’s options menu. These 3 levels represent the lighting system as it has progressed since I first started working on the game. Instead of just using the highest quality in the game and scrapping the older versions of the system, I decided to allow players to set the lighting quality in the game, since on older computers, lowering the quality can improve frame rate slightly.
The quality 1 lighting just considers the lighting level of a single tile. The floor sprites have the level of lighting of the tile they’re on, and the wall sprites the tile they’re facing.
With quality 2 (which is what was available in the old releases of the game), the lighting is smoothed between adjacent floor and wall sprites. To achieve this smoothed effect, I use vertex coloring. In OpenGL, vertices are basically the corners of the texture you’re drawing to screen. So when drawing a floor or wall sprite to screen, they’re drawn as rectangles (‘quads’ in OpenGL) and therefor each have 4 vertices:
When drawing one of these sprites to screen, I can tell OpenGL how light or dark each corner of the sprite should be, and OpenGL then smoothes out the light level across the entire sprite and between the corners. To make adjacent floor and wall sprites blend more into each other, I set the light levels of the corners to be an average of the sprites that share that corner.
This works fairly well and certainly gives smoother lighting than for lighting quality 1. It’s not perfect, however, and as you can see in the comparison image, there are still some hard edges between the individual floor and wall sprites. The reason for this is that the corners of the actual floor and wall images don’t line up with the corners of the sprite. The floor is diamond shaped, while the texture is a rectangle. And because of the isometric perspective, the corners of the actual walls don’t line up with the corners of the sprites either. To fix this, I split the sprites into sub-sprites when drawing them to screen:
This gives me sprite corners that line up with (some) of the floor and wall corners. And since the floor and wall corners now line up with the sprite’s corners, the vertex coloring makes the smooth lighting match up better between adjacent floors and walls. As a result, the transition between adjacent floors and walls is practically seamless. Here’s how the corners of a wall’s sub-sprites matches up perfectly with the corners of an adjacent wall’s sub-sprites:
I’m really pleased with this system — not least because I’m now getting almost perfectly smooth lighting without any use of shaders or other more demanding methods.
For the last year and change, I’ve been pretty quiet. This isn’t because I’ve stopped developing Hostile Takeover, though. To the contrary, the game has come a long way in the past year. I just felt that I needed to go into stealth mode for a while until the game was up to snuff again and ready to be shown to the world.
At first, I just wanted to fix a few things here and there, but then I kept finding new things that I wanted to fix or improve before I showed the game again, and all of the sudden, more than a year has passed. But now the game is nearing a point where I feel confident in sharing it with the world again, so without further ado, here are some screenshots:
As you can (hopefully) tell, a lot has changed since the last updates. I’ll go over some of the changes and improvements in future blog posts.
I’ve removed the download links to the old version, since it was terribly out of date and this new version isn’t yet at a state where it’s fit for release. Speaking of, I’ll most likely be doing closed testing for this and coming versions until the demo is done (which I’ll then probably release as part of a Kickstarter campaign). The demo will include three missions, with the first two being tutorials. The above screenshots are of the work-in-progress first tutorial mission.
Finally, I’ve set up a mailing list that you can subscribe to if you want to be sure to know about any game/demo releases or future Kickstarter campaigns.
And that’s all for now. Hostile Takeover is back! (Though it was technically never gone…)
Here’s the latest version and a video demonstrating what’s new gameplay-wise:
– Fixed bug when changing movement type while shooting/aiming.
– Fixed bug that would make the player character disappear if movement set to sneak as the very first thing after game load/start.
– Fixed minor issue with double-clicking to run.
– Added melee combat.
– Added two additonal test maps (and a variation of the Hensley International map for when the assassination job has been completed).
– Added overworld map that’s accessed when walking to the edge of a map.
– Added ‘Restart this location’ functionality.
– Redid the entire save game system to save information about multiple maps.
– The game now asks for confirmation before overwriting an existing savegame.
Here’s a punch to kick off the weekend!
Wait, that doesn’t make any sense… Anyway, melee combat!
Here’s the latest version and a video demonstrating what’s new gameplay-wise:
– Fixed issue with light sources on a tile with a coffee table.
– Fixed minor graphical bug at some wall joints.
– Created the player character’s look and implemented the system for having characters with unique appearances.
– Made the animation and sprites for sneaking.
– Removed the planned separate sneaking movement mode (which was supposed to be more silent, while crouching would just hide you behind cover).
– Removed Combat Mode and just made it so that characters you need to talk to can’t be attacked.
– Added Tactical Mode in place of Combat Mode, which highlights stuff that can be interacted with, shows the restriction level of areas (green, yellow, red) and displays a color-coded field-of-view cone for NPCs (and a white field-of-view circle for the player).
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:
Update: There were a couple of bugs in v0.1.4, so the download links have now been updated to v0.1.4.1 that fixes these bugs.
Here’s the latest version and a video demonstrating what’s new gameplay-wise:
Please note that savegames from previous versions won’t work in this version.
– Fixed bug with saving open doors.
– Fixed issue that made NPCs react to seeing you with a weapon in another building.
– Fixed bug that made it impossible to do an aimed shot while crouching.
– Fixed minor issue with the opening and closing of some doors not affecting tile lighting.
– Fixed some issues with elevators that could severly mess up the pathfinding of NPCs.
– Fixed player and background noise levels getting stuck if sound files are missing for some reason.
– Fixed bug that would cause the player to still be alive after dying if he was following a character when killed (i.e. the player had clicked on a character and the player character was walking up to that character).
– Fixed issue that would make a character face in a different direction than he was moving when getting out of another character’s way.
– Fixed bug that would make a character choose an edge tile to walk to when getting out of another character’s way.
– Made level visibility also apply to other buildings.
– Added power lines overlay when hovering over fuse boxes (and other stuff that’s connected to something else via power lines).
– When clicking on a world object or using an item on it, the player character will now automatically walk up to it if it’s out of reach (but not if the player character is in one building and the object in another).
– You can now shoot at characters in an elevator, and they can shoot at you.
– Made sure the current objective screen is removed if you walk into an elevator and the elevator buttons are displayed or walk up to talk to a character.
– Added an arrow for when hovering over an edge tile to show that going there will make you leave the map.
– Integrated the current objective and restart location buttons better with the interface.
– Made placement of character dialogue take into account whether or not the character is in a moving elevator.
– Changed the name of the Electric Surge and Lock Override devices to Remote Power Surge and Remote Door Lock.
– Added functionality to the scripting language so that actions can be set to only occur after a dialogue has ended and the player has closed the dialogue screen (such as the receptionist only going to investigate the car alarm when the player closes the dialogue window).
– Some changes to the test map.
– Fixed bug that would potentially crash the game when drawing the selection outline around a shooting character whose line of sight is broken.
– Fixed an error in the level design that made it possible to shoot the CEO from the adjacent building without doing anything else (it wasn’t supposed to be that easy!).
I was hoping to have v0.1.4 out by now, but I’m constantly running into new issues and bugs that need fixing. One of the big causes for all this is allowing the player to shoot at characters in an elevator and being shot at while in an elevator. The actual shooting part isn’t a problem – it’s having a dead body in the elevator along with any dropped weapons.
For the dropped weapons, I just had to make sure that they’re ‘teleported’ to the new level whenever the elevator moves from one level to another. Not such a big issue, but it took some time to get working. With the actual dead bodies, I was experiencing that the bodies would sometimes come back to life and chase down the player that originally killed them. The NPC would basically get snapped out of his dead state for some reason and continue his gunfight with the player (the weirdness of which was exasperated by the fact that the NPC had dropped his gun when dying and would therefore just be firing his empty hand at the player!).
It took a few hours of staring at code and trying different things before I figured out what was going on: When an elevator moves from one level to another, the code runs through a loop and moves all characters in the elevator to this new level. In doing so, the tiles on the new level are set to being occupied by these characters. Except dead bodies shouldn’t occupy (and thus block) a tile. This meant that whenever another NPC tried to move onto this tile, it would tell the dead NPC to get out of the way – and voila, the dead guards would get back on their feet and move out of the way. Since they were now in a ‘walk’ animation instead of the ‘dead’ animation, they were quite literally reanimated.
Also, if you’ve ever wondered why killed characters in the original X-COM always dropped dead by pretty much just collapsing in on themselves, it’s because corpses that stretch across multiple tiles can create all sorts of graphical issues. Such as corpses clipping through walls or doors. This will only become more apparent in Hostile Takeover with corpses in elevators, as the elevators aren’t large enough for the corpse sprites. I will, however, be making more corpse sprites in the future to remedy this, as well as running various checks to make sure corpses aren’t clipping through walls. For now, just know that this isn’t a bug but just something further down on my to-do list.
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.
Here’s a quick bug-fix release I wanted out, as the next release will probably take a week or two to get out:
– Fixed bug that crashed the game when placing a device.
– Fixed bug with item labels (for picking up stuff from the ground or placed devices) not being positioned correctly if resolution changed.
– Fixed issue with attacking guards constantly opening and closing a door if the target is right on the other side.
If you’ve previously downloaded v0.1.3, you can just download the new executables and replace the v0.1.3 ones:
– Fixed bug that would freeze the game when loading a new objective from the script file (temporary script file wasn’t created when loading a game, only when starting new game).
– Fixed rare crashing bug when drawing the character selection border.
– Fixed patrolling AIs being stopped indefinitely by a locked door.
– Fixed issue that would make inventory items disappear if you tried to use them on something they can’t be used on.
– Higher chance of player hitting target when shooting (non-aimed).
– Player aiming/shooting animations won’t get interrupted when taking damage.
– Balancing of damage given when shooting.
– Damage dealt shown.
– You can now also rotate the map with Q and E.
If you’ve previously downloaded v0.1.2, you can just download the new executables and replace the v0.1.2 ones:
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.
Here’s a new version with a couple of fixes – and native Linux compiles.
– Fixed issue with rendering of character shadows that would potentially crash the game.
– Fixed bug that allowed you to access objects through walls.
– You can now also scroll the map with W, A, S, D.
And here, at long last, is the release of the first pre-alpha demo of Hostile Takeover!
There are two executables. The debug version may run a bit slower on older systems as it’s doing range checks on variables and such. If you’re getting slow-downs, try running the non-debug version. But if you can, please use the debug version, as this will provide valuable information in case of a crash. Pressing F1 in either version will display the current rendering speed (if the number goes below 0, it means there are slow-downs). A Linux version is in the works, and I hope to release that in a week or so.
Hope you enjoy this test map! Please share on the forums how it ran on your computer and what you thought of it. And see if you can complete the assassination job with 100% stealth!
(Categories: Hidden Asset)
Just a quick update this week. Everything’s implemented for the test level, so I’m currently doing the final bit of testing and fixing any critical issues that crop up. I’m sure there are still a hundred bugs left in the code, so don’t expect everything to be 100% smooth.
There’ll be two executables in the zip file I’m releasing: a release version and a debug version. The debug version might run a bit slower on older systems, as it’s constantly doing range checks on variables and so on, but it’s also got error tracking, so if you experience a crash, you can tell me exactly where it occurred in code. But I’ll go into more detail on that with the actual release.
I spent the entirety of yesterday tracking down a tough bug. Through casual testing, I had discovered that if characters were trying to run through a door, but their path was blocked, they’d run through the wall next to the door instead. And seeing as those characters were neither ghosts nor X-Men, that wouldn’t do.
At first, I thought their paths were getting out of whack. The pathfinding works by instantaneously finding a path from start to end, then having the character store the directions of this path (move forward, move left, move left, move down – you get the picture). But if for some reason these directions went out of sync with where the character actually was, that would account for weird pathfinding, such as running through walls. So I spent a great deal of time searching for places in the code that could potentially push a character out of sync with his pathfinding. I wasn’t able to find any.
So with that theory abandoned, I started running through the actual pathfinding code. Outputting some debug info revealed that the pathfinding did indeed path its way through a wall. So the issue arose from the pathfinding itself. And that’s when the fact that this was always happening next to a door lit a lightbulb above my head (I quickly turned off that lightbulb, as the glare on the screen was distracting). There was a problem with how doors was handled in pathfinding. The process of pathfinding is a 3 step process in my code. First, a path is attempted while respecting locked doors. If no path is found, a path is attempted while ignoring doors completely (since the character will be stopped anyway when trying to move through a locked door). If a path still can’t be achieved, the code will find the closest reachable spot to the destination and find a path to this spot instead.
The issue was with the second step: ignoring locked doors. The code didn’t check properly that the door to ignore was actually in the direction the character was moving, just that the door was associated with the tile the character was currently on. So if a character was trying to run left, through a wall, and there was a door to the right that was associated with this tile, the game would think that the wall obstructing the character on the left was a door as well – and since the second pathfinding step ignores doors, the wall would be ignored. The fix was just to make sure that the door was actually in the direction the character was moving from this tile. 6 hours spent finding a bug, 2 minutes spent fixing it once found. That’s programming, I guess.
Anyway, there’s currently only one AI thing left to do: characters reacting to finding a corpse. After that, I need to polish some minor things, do a bunch of testing, fixing the bugs that are bound to reveal themselves from this testing, and then packing up everything I’ve got so far for release. This is the home stretch!
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.
Here’s the last development video before the first pre-alpha release of the demo:
Shown in this video:
There’s still a bit of AI work left to do before the test level is fully playable. As is evident in the video, shooting at close range is still a bit wonky, for example. Kinda reminds me of that Naked Gun scene. I also need to add some more features to the scripting language to have characters in the level react the way I want to certain events.
Last week I decided to take a day off from working on the AI and get the basic sound framework implemented. That one day ended up becoming the entire week, and I now have both music and sound completed for the demo. There are currently 20 sound effects in the game. They’re all what I call functional sound effects – such as footsteps, doors opening and closing, gunshots and so on – and I still need to add mood effects – for example wind blowing, the hum of traffic or dogs barking in the distance. There are only 3 pieces of music in the game for now, one of which is the main menu music. The other two will play when the action in the game calls for it: sneaking around or being under attack. So it’s basically situational background music.
I was planning to do a video this week, but my computer can’t record internal sound. So I’ve ordered a minijack to minijack cable that will allow me to plug the computer’s sound output from the headphone port right into the mic port. I’ve also ordered a better microphone for recording my voice. Hopefully this arrives this week so I can do a video for next week’s update. For now, it’s back to AI programming…
I got two big AI algorithms implemented this week. Originally, I had planned to have the searching and chasing algorithms combined in one, but it turned out to be easier to do if split into two separate algorithms.
With the chasing algorithm, the AI will remember where the target was last seen and which direction it was moving in. The AI will then move to this tile and continue chasing in the direction the target was last seen escaping in. If no new visible contact is made with the target, the AI can start checking doors or side corridors it moves past, while continuing to chase in the direction it suspects the target may have run off in (if the target could have escaped in two different directions, for example, and one of these directions was outside of the AI’s line-of-sight at the last ‘waypoint’, the AI will continue on in this direction, as the target would likely already have been spotted if escaping in the direction that wasn’t hidden from the AI).
The searching algorithm is a bit simpler: the AI will just choose some random waypoints within a certain distance from the central search tile, then go to these in turn, stand there for a moment and look in different directions before moving onto the next waypoint.
With both of these algorithms, I ran into an issue when the AI’s path was blocked by a locked door. The AI character would just stand there indefinitely. So I also implemented a procedure for checking if an AI’s path is blocked by a locked door or non-moving character – and then abandoning the chase or moving to the next search waypoint if blocked.
The overall structure that governs each AI character’s behavior is made up of separate orders. A character will usually start off with just 1 order, for example patrolling an area, standing at a counter or just walking across the map. Certain events can cause a character to get a new order, such as when a patrolling guard spots the player. Instead of overwriting the old order, this new order is just stacked on top so the character now has 2 orders (the orders for each character are just stored in a dynamic array). When executing orders, the code always executes the last order in a character’s order stack. And when the current order is done (if the guard has lost track of the target he was chasing, for example), this order is just removed and the previous order becomes top of the stack again – meaning that the guard just returns to his previous order and goes back to patrolling.
It works really well and isn’t all that complex coding-wise, so I’m pretty happy with this solution. I haven’t really read up on AI programming theory, so this may all be pretty basic or incredibly stupid, but hey, it works for me!
I’ll probably be making a new development video demonstrating the new AI stuff in a week or so. Stay tuned for that.
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 spent most of last week making the sprite assets I was missing for the test map. So I bunched them all up in the parking lot, just ’cause…
The new assets are:
Now it’s back to AI and map design!
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!
Last week was off to a crazy start when I suddenly found Hostile Takeover adorning the front page of Rock, Paper, Shotgun. As you can probably imagine, this brought in a whole bunch of traffic, so a quick welcome to the game’s many new followers is in order! It was also quite the motivational boost – not that my motivation to work on the game really needed boosting, though, but it’s always nice when people seem excited about the thing you’re working on.
Anyway, I’ve mostly been working on saving and loading during the past week. Until now, everything would just be saved in the map file itself (and some stuff, like your inventory, wouldn’t be saved at all) whenever I quit the game. This was fine for developing and testing maps and such, but of course wouldn’t at all be suitable for the actual game. So I’ve had to decide which information should go in the map file and which should be saved in the savegame file. It’s basically boiled down to all static information (such as tiles, walls and most world objects) being in the map file, and everything else being in the savegame file.
This means, however, that the map files are 1+ MB in size, while the savegame files are only 10+ kB. The latter is fine, the former really isn’t. So I’m reading up on the Free Pascal zlib unit to be able to compress the map files with libz – with WinZip, a 1+ MB map file gets shrunk to about the same size as a savegame file. I’m not sure if libz can get the same results, but the more important side effect of compressing the map and savegame files is that they won’t just be plain text that’ll be easy to mess up or screw around with.
I also changed the load/save menu ever so slightly. When you save a game, it’s now optional if you want to type in a savegame description. If you don’t, it’ll just state the location you’re at in the game as well as the real-word time at which the savegame was created.
When I’m done with the save/load stuff, I’ll probably be moving on to an important optimization that I’ve been putting off for some time now. It has to do with how the x-ray effect is created. But I’ll save that for a later post. And after that, it’ll probably be all about AI and level building.
Here’s the new development video:
Shown in this video:
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).
I was considering just writing an “I’m still alive” blog post to let everyone know that I’m, well, still alive and still very much working on Hostile Takeover. But that’s a pretty short and boring topic, so here’s a completely different blog post instead…
I’ve been working on the AI for Hostile Takeover. I like having a clear goal with the stuff I’m doing, so right now I’m putting the final touches on having a guard patrolling an area (by passing through designated waypoints) and being able to spot and attack you. To determine whether or not the guard can see the player, three factors have to be taken into account: field of view, distance and line-of-sight.
Field of view is simple to implement. You just calculate the angle from the guard to the player and check if it’s within the guard’s field of view (95Â° to either side). And distance is applied by having the chance of the guard spotting you decrease as the distance increases. But line-of-sight can be a bit more difficult to implement – especially for a 2D game. With a 3D game, you’ve already got the geometry set up in the game world, so you can “just” send of a ray from the guard to the player and check if it intersects with any world geometry. But the geometry of my 2D isometric world is a bit more abstracted.
Walls don’t automatically have volume, for example. Everything plays out on a flat map with just two dimensions, X and Y. There’s no height. No Z-axis. So when a character stops in front of a wall, it’s not because that character’s hitbox was intersecting with the wall’s geometry, as would probably be the case in a 3D game. Instead, the 2D map tells the character that he can’t move from tile A to tile B because there’s a wall in between.
At first, I tried doing line-of-sight by drawing a Bresenham line from the guard to the player with each point on the line being a whole tile. If this line didn’t intersect any walls, there was line-of-sight. The problem with this solution was that it wasn’t very precise. Characters are often moving between tiles and are sometimes only partially obscured by a wall, and using an entire tile as a point on the Bresenham line was too low resolution:
So the solution was quite simply to increase the resolution by dividing each tile into subtiles and occupying these subtiles with whatever could break line-of-sight. I decided that a 10x resolution would be sufficient (primarily because characters have 10 frames of animation when moving from one tile to another, so they can occupy 10 different spots in between tiles, which can be represented by dividing each tile into 10×10 tiles). I’m now just drawing the Bresenham line by using these subtiles as points on the line. Whenever a subtile is plotted, the game checks whether or not this subtile is empty or not. If not, line-of-sight has been broken:
I don’t have to create subtiles for the entire map, just the single tile that the Bresenham line is currently passing through, so it’s neither memory nor processor intensive. To occupy the subtiles, I have a procedure that starts off by setting all 10×10 subtiles as empty, then checking for character, walls and other world objects on that tile. If any are there, the relevant subtiles are filled in.
I believe good ol’ X-COM did something similar, but also had a Z-axis for individual tiles, so it in essence had subcubes that the ray was passing through. This, for example, allowed a bullet to pass through an open window. I’m considering expanding my own system to that as well, since I’ll most likely be adding functionality for shooting at characters on different levels of the map. But I’ll wait and see if it actually ends up being necessary.
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.
New stuff in this video:
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.
It’s video time again!
New stuff in this video:
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!
It’s a new year, so here’s a new blog post!
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.
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.
Here, at long last, is the new development video for Hostile Takeover, now featuring my fabulous radio voice!
New stuff in this video:
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.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.
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…
New stuff in this video:
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.
The latest development video is almost twice as long as the previous videos. But there’s also a lot of new stuff to show!
This is the new stuff you’ll see in the above video:
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!
Here’s a quick look at the interface for the point-of-view aiming:
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.
Time for another development video with the latest updates to the Hostile Takeover engine:
Here’s a quick list of the new stuff in the above video:
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!
What do you think?
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.
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!
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.
Run, women, run.
So, yeah, I’ve got the female run animation and clothing done:
Working on the walk animation next.
The clothing sprites for the male characters’ walking and running animations are now done:
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.
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:
PROCEDURE SetSpritePositionValues(TextureMap, X, Y, Width, Height : Word); BEGIN GetSpriteMap := TextureReference[TextureMap]; GetSpriteXPosition := X; GetSpriteYPosition := Y; GetSpriteWidth := Width; GetSpriteHeight := Height; END;
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.
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.
Time for another video update on the progress of the game engine:
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:
Image borrowed from this site
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!