next »

[Gregg Williams]

Ungh, yeah I can believe you on the whole "clean" bit, mine is reaching over 1000 lines already for map rendering, and it doesn't do half the stuff it probably needs to do yet.

[Christian Knudsen]

Made the first unique-looking NPC. This bouncer is the first character you'll interact with in Hostile Takeover.

[Christian Knudsen]

New melee combat and weapons
June 16th, 2014

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.

[Christian Knudsen]

Every dystopian future needs burning barrels!

[Christian Knudsen]

New name, same game
June 23rd, 2014

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!

[Christian Knudsen]

Party time!



Currently working on the night club on the floor above the restaurant. Your first assassination target is throwing a private party there to celebrate his birthday. Guess it'll be his last.

[Christian Knudsen]

A* pathfinding with weighted tiles
June 30th, 2014

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:

Code:

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.

Code:

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.

[Christian Knudsen]

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.

[Christian Knudsen]

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.

[Christian Knudsen]

You may or may not have seen the screenshot I posted on Twitter and Facebook last Saturday for Screenshot Saturday. But it showed the new cover system I've been working on.

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!

[Gregg Williams]

Looking good, do you depth sort the shield overlays and so forth, or just top most/foreground them?

[Christian Knudsen]

Hey, I didn't get a notification about a reply to this thread! Sorry about the late answer...

Yeah, they're depth sorted in the sense that they're drawn along with the walls. In the second image, you can see that the full shield is drawn behind the wall.

[Christian Knudsen]

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.

[Christian Knudsen]

Finally got my hands on some new (second-hand) external hardware for recording videos:

[Christian Knudsen]

Working on this game sometimes weirds me the fuck out:

[Christian Knudsen]

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!

[Christian Knudsen]

Complete first (tutorial) map for Hidden Asset. Download the fullsize version (4.2MB 5650x2953) here: https://www.dropbox.com/s/jwqv4j1gi7uev2k/fullmap.jpg?dl=1

[Christian Knudsen]

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:

• Pre-alpha: Missing core features and functionality.
• Alpha: Core features and functionality done - missing content.
• Beta: All content done - missing bugfixes and balancing.

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.

[Christian Knudsen]

Migrating from SDL 1.2 to SDL 2 was a lot smoother than I had feared. Though I ran into an issue with the game leaking memory when switching resolutions or between fullscreen/windowed mode. With SDL 1.2, I had to completely destroy the OpenGL context and the SDL window and delete all loaded textures, then create the SDL window with the new settings and reload all the textures. This worked fine with no memory leaks. But for some reason, in SDL 2, this creates a memory leak. It seems that even though I delete the OpenGL textures, the RAM wasn't freed, so whenever I changed the game resolution or switched between fullscreen/window, I could see the memory footprint increase in the Windows task manager. Weird. Using heaptrc in FreePascal also confirmed these memory leaks.

However, it turns out that I don't really need to go through the process of deleting the OpenGL context, SDL window and loaded textures (and then recreating everything) to change window resolution or switch between fullscreen/window in SDL 2, since there are dedicated calls to do this that don't destroy the already created SDL window and OpenGL context (this may also have been possible in SDL 1.2 and I just weren't aware of it). So now all that is a lot simpler and quicker. Nice! I love it when a bug/issue results in a solution that's better than what was used before!

[Christian Knudsen]

Made a mission score screen. Keeping it simple.