In this video, I start working on the remaining art assets for the second map.
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!
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.
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!
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…)
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:
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:
- Hand dryer
- Toilet paper
- Water cooler
- Coffee table
- Conference table (in sections so it can be any length)
- Cardboard boxes (2×2 and 2×1 tiles in size)
- Various new walls and windows
Now it’s back to AI and map design!
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.
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.
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.
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.
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?
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.
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.