next »

[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.

[deathtotheweird]

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!

[deathtotheweird]

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

[Christian Knudsen]

How have I missed the Frictional Games blog?! I've been to their site a couple of times, but I've never visited their blog before. It's really awesome. I think I have a bit of reading to do!

[Christian Knudsen]

Development Video #11
April 29th

Time for another development video with the latest updates to the Hostile Takeover engine:

Here's a quick list of the new stuff in the above video:

  * Guns and rifles can be fired at characters.
  * Characters can be killed by shooting at them.
  * Dead characters will drop carried items to the ground.
  * Dropped items can be picked up.

I've finally finished doing the most essential animations and sprites required for shooting and killing characters. I haven't done any of the animations for female characters yet, which is why I'm only shooting guys in the video. Also, as talked about in a previous blog entry, I'll have to double the number of directions for the shooting animations, as it very often seems like your character isn't aiming at the target at all. So that'll be increased from 8 to 16 directions. I also need to do animations for when characters get hit from behind and fall over forwards. And then of course all the shooting and getting hit and killed animations for the female characters. I might also redo the pools of blood -- I'm not quite sure I like them. And I'll definitely be adding a spray of blood to indicate hits and small splatters of blood on the floor around the hit character.

As you can see in the video, items are picked up from the ground by holding down Shift and then clicking on the appropriate item label. Why not just be able to click on the item sprite itself, you might ask? Well, sometimes the item sprites are pretty small (like the 9mm Pistol) and I don't want players having a hard time picking stuff up. Also, when holding down Shift, only items that are within your range get the label, so you immediately know what you can and can't pick up. And, also also, if there's a stack of items or it's very dark, seeing the actual item sprites on the ground can be difficult. I believe Diablo 2 had a similar system -- at least, that's where I think I got the idea.

I'm also starting to think about the inventory system. I want to keep it as simple as possible and I'm currently not too fond of having a separate screen for handling your inventory, as I want to keep as much of the game as possible focused on the world map. So, my current idea is to move the icons for the items in your hands to the bottom corners of the screen and have a 'ribbon' between these with the items in your inventory. You'll be able to scroll through the items on this ribbon and drag and drop between your inventory and hands/ground.

And, finally, I'm working on first-person aiming. When you've selected a weapon in your hand, right-clicking on a character will have you automatically fire the weapon. Whether or not you hit is then calculated based on distance and the visibility of the tile the target is standing on (so characters in shadow will be harder to hit). But if you hold down the right mouse button instead of simply clicking, a meter will fill up on the mouse cursor. If you manage to keep the cursor over the target until the meter is full, a first-person targeting screen will pop up. This shows the silhouette of the target (in real-time, so it'll move if the target is moving, and the size of the silhouette is based on your distance to the target) and you can then aim and fire your weapon manually. I've got the basics already implemented, but it's not quite in a state to show yet. Look for it in upcoming videos!

That's all for now. I'm very pleased with the results so far, everything is just taking a bit longer to implement than I had originally anticipated. But I'm moving steadily towards my first milestone: Releasing a version for download with the most basic gameplay elements in place (you can shoot at NPCs and they can shoot back at you).

[eclectocrat]

Wow, looks great!

[Christian Knudsen]

Thanks!

[Christian Knudsen]

A bag full of guns
May 18th

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.

Click to enlarge

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.

[Christian Knudsen]

Got you in my sights
May 24th

Here's a quick look at the interface for the point-of-view aiming:

Click to enlarge

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.

[deathtotheweird]

that's awesome. kinda reminds me of how they did shooting in snatcher. but obviously a bit more interactive.

and enemies can shoot back? would be cool if you could shoot their arm to prevent them from shooting you or shoot them in the leg to prevent them from moving. but I guess that wouldn't matter if the camera locked on to the target?

yeah we need a video.

[Christian Knudsen]

Enemies will be able to shoot back (I just haven't implemented the AI for that yet). And you can aim at different body parts (arms, legs, head, torso) as well as doing critical one-shot kills if you hit the heart or brain "zones". Hitting the arm can result in the target dropping his weapon (and either running off or picking it up again). Damage to arms will also make it harder to fire accurately with that arm, and damage to legs will make the target move slower (I imagine the target will fall to the ground if there's enough damage to the legs -- I just need to make an animation for a target writhing on the ground).

[Christian Knudsen]

Development Video #12
June 7th

The latest development video is almost twice as long as the previous videos. But there's also a lot of new stuff to show!

This is the new stuff you'll see in the above video:

   * The inventory bar is working
   * Item labels (appearing when holding down Shift) automatically spread out so they don't overlap
   * Holding down the right mouse button instead of just clicking on a target will allow you to do an aimed shot
   * Characters can be shot in the head, torso, right and left arms and legs
   * There's a one-shot kill area on the head and torso to simulate shots to the brain and heart
   * Redid the expanding blood pools
   * Added blood splatter to the ground when a character is hit
   * Also added a blood squib to show which body part was hit

I'm still working on the female hit and dying animations as well as the doubling of directions for the male aiming and firing animations. When doing the automatic shooting, the chance to miss and body part hit is currently just randomly selected, so I'll still have to add some algorithms for that which take distance and level of light into consideration. I'll also be adding effects of damage to arms and legs (harder to aim and walking/running slower). When a character gets shot in the arm, there should also be a chance of the character dropping items in hand. Also, there's currently no line-of-sight check, so you can shoot at characters behind walls.

I've been playing around with making character portraits for dialogues. My current plan is that you can only engage in actual dialogue (i.e. the dialogue screen pops up) with secondary and main characters. Extras that fill the environment, hostile guards and similar characters will just brush you off with a quick remark written above their head. Otherwise I'd have to make hundreds of character portraits -- and possibly figure out how to make random character portraits if some of the NPCs are randomly generated. I think it'll also make it more intuitive which characters are actually important to the plot or mission at hand if you can't just talk to everybody.

I also managed to implement recording functionality. This'll record the mouse cursor position and keypresses each frame to a text file. It also records the initial seed for randomization. Using this seed and the recorded cursor positions and keypresses, I can get a playback of a play session. Being able to watch a recording of a tester's session will really come in handy!

[jotapeh]

Verrrrry cool. I like this a lot so far. As a side note I really enjoyed AsciiSector too.