next »

[Christian Knudsen]

Cover art
November 27th, 2010

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.

[Christian Knudsen]

Development Video #8
December 6th

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:

Watch the video on YouTube!

- 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?).

[Christian Knudsen]

Development Video #9
December 22nd

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!

Watch the video on YouTube!

    * Characters can now carry items (only weapons for now).
    * The player’s items in the left and right hand are displayed as icons in the top left and right corners of the screen, and the “active” item can be selected by clicking these icons. Right clicking with the mouse will use the currently selected item, so to fire a weapon, you will select it as your active item and right click on the character to shoot at.
    * Dynamic and colored lighting has been added, allowing for a whole bunch of nice lighting effects.

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.

[allen]

haha I was sad when there was no dance animations

made me think of this: http://www.youtube.com/watch?v=rx49_arkMdc&t=1m50s

[Christian Knudsen]

Argh! That clip should come with an epilepsy warning!

[Christian Knudsen]

Development Video #10
February 1st

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.

Watch the video on YouTube!

    * Walls have been added, so I can now start thinking about buildings and other constructions.
    * When the player is behind a wall, it will become partly transparent to show the hidden area.
    * Walls will block light sources, so shadowcasting has been implemented.

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.

[Mush.]

I've always wanted to make an isometric game like this!

The game is looking very promising, I can't wait to play it!

[Christian Knudsen]

You should definitely try making an isometric game! It feels very rewarding in some strange way to take flat 2D sprites and creating a (somewhat) three dimensional world from them.

[allen]

where's Hal???

anyways, the game is looking wonderful lately. but only 20% done? makes me a sad panda  

[Christian Knudsen]

Yeah, I thought it made more sense to have my company logo as my avatar.

And I'm actually not sure if the game is even 20% done. I'm still just working on the engine -- game logic, level design and most art assets are still waiting. I might be about 20% done with the demo, though.

Why can't I just make a small Flash game or something?

[Christian Knudsen]

Image optimizations
February 22nd

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 (8x4). 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:

RGBA8888 (click to enlarge)


RGBA4444 (click to enlarge)

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?

[eclectocrat]

This is awesome, right up my alley. Sadly, you remind me of how crappy my efforts are in comparison.

PS. I love the dithering effect, gives me a kind of Terry Gilliam Brazil vibe  (don't ask me why).

[lowpoly]

But the trade off is you have to run the entire game at 16 bit color, right?
I actually think the grain is pretty cool, especially if you can make it work with the overall aesthetic of the game. I guess I'd be worried about how the static, larger tiles are going to look dithered. When things are moving around it's not as noticeable but what about on larger environment pieces?

gotta say, this is one of my favorite devlogs on this site. I love all the complicated details involved in making an old school game like this.

[Christian Knudsen]

This is awesome, right up my alley. Sadly, you remind me of how crappy my efforts are in comparison.

PS. I love the dithering effect, gives me a kind of Terry Gilliam Brazil vibe   (don't ask me why).

Why?

It's been awhile since I've seen Brazil. I can't remember if it has a similar grainy feel to it. Maybe it's just the industrial environment that most of the film takes place in?

But the trade off is you have to run the entire game at 16 bit color, right?

Yeah, exactly. The screen surface is set to 16-bit, so I assume that if I try to blit a 32-bit image to it, it'll either just crash or downscale the quality on the fly. I haven't actually tried it, though.

As an example of a larger, static image, here's the logo thingy from the top of this page in 16-bit:


It's really only the white gradient that gives it away. But even that's not too bad, I think.

gotta say, this is one of my favorite devlogs on this site. I love all the complicated details involved in making an old school game like this.

Thanks!

[allen]

your devblog along with the frictional games devblog, the witness, and overgrowth blogs are my absolute favorite to read. always get a smile when I see that little (1) in google reader for any of these. always informational and interesting to read