next »

[Christian Knudsen]

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:

 

 

[Christian Knudsen]

Release: v0.1.5 (and Development Video #20)
February 3rd

Here's the latest version and a video demonstrating what's new gameplay-wise:

Hostile Takeover Demo v0.1.5 for Windows (21.5 MB)
Hostile Takeover Demo v0.1.5 for Linux 32-bit (21 MB)
Hostile Takeover Demo v0.1.5 for Linux 64-bit (21 MB)

Changes:
- Fixed issue with light sources on a tile with a coffee table.
- Fixed minor graphical bug at some wall joints.
- Created the player character's look and implemented the system for having characters with unique appearances.
- Made the animation and sprites for sneaking.
- Removed the planned separate sneaking movement mode (which was supposed to be more silent, while crouching would just hide you behind cover).
- Removed Combat Mode and just made it so that characters you need to talk to can't be attacked.
- Added Tactical Mode in place of Combat Mode, which highlights stuff that can be interacted with, shows the restriction level of areas (green, yellow, red) and displays a color-coded field-of-view cone for NPCs (and a white field-of-view circle for the player).

[Christian Knudsen]

Development Video #21
February 22nd

Here’s a punch to kick off the weekend!

Wait, that doesn’t make any sense… Anyway, melee combat!

[eobet]

There aren't many comments on this anymore... and I still have to wonder if it is because of the UI... which is... well... brown.

Any plans to bring it into this century?

[Christian Knudsen]

Release: v0.2 (and Development Video #22)

Here's the latest version and a video demonstrating what's new gameplay-wise:

Hostile Takeover Demo v0.2 for Windows (22 MB)
Hostile Takeover Demo v0.2 for Linux 32-bit (21.5 MB)
Hostile Takeover Demo v0.2 for Linux 64-bit (21.5 MB)

Changes:
- Fixed bug when changing movement type while shooting/aiming.
- Fixed bug that would make the player character disappear if movement set to sneak as the very first thing after game load/start.
- Fixed minor issue with double-clicking to run.
- Added melee combat.
- Added two additonal test maps (and a variation of the Hensley International map for when the assassination job has been completed).
- Added overworld map that's accessed when walking to the edge of a map.
- Added 'Restart this location' functionality.
- Redid the entire save game system to save information about multiple maps.
- The game now asks for confirmation before overwriting an existing savegame.

[deathtotheweird]

ugh finally fixed the rss reader issue. it was loading the wrong url and I just noticed that. jesus.

looking good, sad I missed all these updates..again.

[rui_curado]

I think most scenes are too dark. I don't like games (or movies) where we can't see many things, but that's just my opinion, anyway.

[McMayhem]

Hey Christian.

This is my first time looking at your game, and I have to say it looks fantastic. Love the art style you're going for and the mood you're setting with the environment. From the development system, it seems like the gameplay is really smooth and fluid, love all of it. I'm also really interested in the premise, seems like a very unique subject with interesting possibilities .

Keep at it, and I'll definitely be watching this one .

[Dragonmaw]

How's this cool fucking thing doing? Because it's pretty rad.

[Christian Knudsen]

Thanks! Doing quite well. I've just decided to go a bit dark with development, as I feel that I might have hurt future interest in the game by releasing stuff too early with not enough polish and the core gameplay not being honed enough.

[conorh]

Thanks! Doing quite well. I've just decided to go a bit dark with development, as I feel that I might have hurt future interest in the game by releasing stuff too early with not enough polish and the core gameplay not being honed enough.

I think it's becoming quite acceptable to exchange a bit of polish and production to allow people to play the game now, and give you feedback quicker. Given that a lot of indies will go the crowdfunding/sell alpha keys route, I'd like to see more peeps using this form of development.

For me personally, I could see the increased audience input as a motivational tool to keep the project going, as I tend to peter out due to lack of interest or by pursuing some crap idea into a cul de sac that becomes too much work to remove again. As well as the interest it generates in between major feature updates.

[Christian Knudsen]

I've had open development with downloadable updates for a while (you can still download the latest version -- though it is of course out of date by now). I've also got immense feedback from that, which has helped shape the game and make it way better. But those versions have lacked some basic and very necessary gameplay elements, as well as some gameplay elements just being too obscure (such as melee combat). I think there's always a risk with doing public releases too early, and in hindsight, I should probably have done closed releases until the core gameplay was up to snuff. I got some surprising press from the development videos (RPS wrote an article on it), but when people actually tried it out, their interest waned. The game as it stood just wasn't living up to the promise in the videos.

This actually goes into a much wider discussion on whether a demo will help sell a game or push a kickstarter campaign -- or whether the promise and allure of what a game might become is more valuable. Personally, I want to get feedback and release demos, but I still think you have to be very careful -- especially when the game isn't an open sandbox game like Minecraft, where the player shapes much of the gameplay for himself, and where the developer can always slap new stuff on top. Some games only really start being fun and interesting when all the planned gameplay elements start coming together in a well-designed level.

[Gregg Williams]

Makes a lot of sense, but you could still blog or post about development progress

[ryansumo]

The isometric view and gameplay caught my attention.  I will hold off on playing th elatest build though.

I'd like to second another poster's confusion over the wood panel UI though.  What's up with that?

[Christian Knudsen]

It's been a while...
June 2nd, 2014

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

[The_Otherworld_Agency]

Ah, awesome! I was wondering when you would post another HT update.

[Christian Knudsen]

Fixed the coloring of random NPCs. Before, it would just pick any colors for clothing and hair, so I'd end up with all these 80s pastel colors and purple/green/blue hair. I've now set up some simple rules so that hair is more normally colored and the clothes are more subdued, which fits better with the game's overall mood.

[Christian Knudsen]

Improved lighting technique
June 9th, 2014

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.

[Gregg Williams]

Neat, though all that splitting seems painful from my own experience. Of course I'm still fighting with units that occupy one tile, but partly extend into another. Had that fixed until animations came and suddenly made units extend into other tiles temporarily on given frames.

[Christian Knudsen]

Yeah, it did require a bit of fiddling, but now that I've got it set up properly, I don't need to fiddle with it anymore, since all floor and wall tiles are the exact same size.

I've also got a bunch of instances of characters extending into other tiles for a few frames. So my rendering loop just has a bunch of conditional checks to see if there are characters on adjacent tiles in some particular directions, animations and frames -- and then draw them if necessary. I gave up hope of clean code in my rendering loop quite a while ago!