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.