next »

[Christian Knudsen]

HIDDEN ASSET IS LIVE ON KICKSTARTER!





https://www.kickstarter.com/projects/2034635017/hidden-asset-isometric-stealth-and-assassination-v

Subscribe to the mailing list if you want to be sure to know about game/demo releases or future Kickstarter campaigns!

PLEASE HELP ME TEST THE DEMO:


-- Download links --

North America:
Windows 7 or later (128 MB)
Linux 32-bit (126 MB)
Linux 64-bit (126 MB)
Mac OS X 10.5 or later (156 MB)

Europe:
Windows 7 or later (128 MB)
Linux 32-bit (126 MB)
Linux 64-bit (126 MB)
Mac OS X 10.5 or later (156 MB)


-- Debugging --

For the Windows and Linux versions, there are two executables: a normal version and a debug version. The debug version may run a bit slower on older computers, so if you're not getting a steady 40 FPS (hit F1 to toggle FPS on/off), you may want to use the normal version. But if you can use the debug version, please do so as this will provide valuable information in case of a crash:

- On Windows, the debug information will pop up in a window during a crash.
- On Linux, the debug information will be outputted to the terminal, so please run the game from the terminal (navigate to the game directory and run it with ./hiddenassetdebug).
- Please take a screenshot of the debug information and paste it here or send it to me directly in an email, while also letting me know where you were in the game/what you were doing just before the crash.

(Note that on Linux, you may have to set the run permission of the executable with 'chmod -x hiddenasset' to allow you to run it, as the permission is sometimes lost when compressing the game files.)


-- Feedback --

When you're done with the game, please send me the stats.txt file that on Windows and Linux will be located in the game directory and on Mac OS X will be in your '~/Library/Application Support/Hidden Asset' directory. You can either email it to [email protected] or write a post with a link to where I can download it.

Also, please share any thoughts or comments about the game! Were certain parts too hard or too easy? Was the game fun? Too much or too little tutorial information?


-- Linux dependencies --

If you don't already have SDL2, SDL2_mixer and SDL2_image installed on your system, they can be installed with the following commands in the terminal (given that they're in your distribution's repositories):

sudo apt-get install libsdl2-2.0
sudo apt-get install libsdl2-mixer-2.0
sudo apt-get install libsdl2-image-2.0


-----


Original first post:

I'm not getting too much feedback on my new game over at my development blog, so I'm going to cross post the latest blog posts here at TIGSource.

About the game (copy-pasted from my site):

Hostile Takeover is Laserbrain Studio’s first commercial game. It takes place in a not-too-distant future devastated by a global economic crisis. In a desperate attempt to counteract this crisis, the world’s governments agreed to grant all large corporations immunity from prosecution. This was meant to free corporations from the oppressions of control and legislation but instead cast the global business world into deadly conflicts. Now, no longer inhibited by law, corporations wage war. And within this new world, a new occupation has seen the light of day: corporate assassin.

You are such an assassin. Working for whoever hires you. Killing whoever they tell you to. You will infiltrate businesses. Shoot up offices. Assassinate CEOs. No mercy. No doubts. It’s all just business.

Presented in a third-person isometric perspective, Hostile Takeover will be a throwback to classics like Fallout, X-COM and Syndicate. You will control your character in a real-time environment, automatically switching to a turn-based tactical game mode when engaged in combat. As you progress through the game, your character’s skills will grow and new equipment will be purchasable for the money you make.

Hostile Takeover is currently in development. It will be available for Windows, Linux and Mac OS X. No release date has been set, but you can follow the game’s development on our blog.

And these are the updates so far:

First steps
August 4th, 2010

Whenever you begin work on a new game, the first question is always: Where do I start? I’ve decided to start with you. Well, with the character you’ll be controlling in the game. So here’s the very first Hostile Takeover development video:





As you can probably tell, it’s all very basic and only the very first baby steps towards a fully featured isometric engine. When clicking on a tile, your character will find a path there and walk towards it. Double-clicking will set him running. He’s currently running around in his underwear, as this is just a basic test of having an isometric sprite animation, but he will of course get properly dressed at some point.


Shadow and light
August 8th, 2010

I’ve been playing around with doing some lighting effects for the isometric Hostile Takeover engine. Your character has a shadow now, and I can designate an overall degree of lighting as well as spots of permanently lighted areas:





One of the things I loved in X-COM were the night missions. There’s just so much mood and atmosphere in those night scenes – beyond the simple dread in X-COM of an alien hiding in the dark right around the next corner. I’m not sure how this will be used in Hostile Takeover, though. I may have missions taking place outside, or I may just have missions that take place in an office building at night. A mission where you have to assassinate a couple of CEOs having a secret meeting at night would be pretty cool too. But I’m getting ahead of myself now...

Of other new stuff in the above video is map scrolling and some furniture I threw in to test draw order, so that sprites can be placed in front of and behind other sprites. Everything seems to be working fine, so I’ll move on to working on having multiple NPCs walk around as well.


Multiple characters
August 17th

Time for another video update on the progress of the game engine:

http://www.youtube.com/watch?v=vNrmoVM2rAk&hd=1

There are now a bunch of NPCs running around besides the player’s character. They all still look the same, though, as I haven’t started working on different looks for characters, so I needed something to tell my character from the others, which led me to adding the destination tile marker, and then the tile over marker. The character AI is still very simple; they’ll just select a random destination tile and find a path to it. If their path gets blocked by another character, they’ll just stop, which is why you’ll see them eventually ending up in big groups. The current AI is just for testing purposes to actually have the characters move, so it will of course be improved considerably for the finished game.

Another new addition in this video is dialogue being displayed above the NPCs. Again, the dialogue in the video is just for testing purposes. Can anybody guess which movie the dialogue is referring to?

I’ll be working on having the characters all look somewhat different next. I’ve devised a system where the engine can randomly mix different clothing sprites and give them different colors. Characters’ skin can also be colored differently, as can their hair. So instead of making 10 different looking character sprites, I’ve split a character sprite up into different parts that can be combined and colored in a multitude of different ways. This should provide considerable variety in how characters look – if I make enough clothes/hair/hat sprites, no two characters should look completely alike.

[deathtotheweird]

didn't know you even had a blog, I usually check the icons under the avatar for a users website (I have signatures turned off).

The premise seems really cool. Can't wait to see some combat.

[Christian Knudsen]

Glad you like it.

I've completely ignored the icons under avatars for some reason. I've now added a link to my website, though, so there's now a small globe under my avatar.

[Christian Knudsen]

The game plan
August 22nd

While the finished game is still far off into the future, I’d still like to be able to release something for you blog readers to download and play around with – and provide feedback on. I’ve received invaluable feedback and bug reports from players of my freeware game, Ascii Sector, and while Hostile Takeover won’t be freeware (and I’d thus be shooting myself in the foot by releasing the entire in-development game for free), I’d still love to be able to release something once in awhile.

My plan is to make the in-development versions of the game’s demo available for download when the game engine is running fairly stable and there’s actually something to do in the demo (mostly shooting people, I imagine!). I’m still working on the most basic stuff (currently making hundreds of sprite pieces in order to have characters not all look alike) but after that I’ll probably start working on adding some features that aren’t just about the game engine, but also about gameplay.

The full demo of the game will contain a few of the game’s starting missions and that’s what I’m currently working towards. So while the demo will function primarily as a gameplay demo for potential buyers, for me it’ll also function as a milestone in that I want the engine to be pretty much feature complete for the demo. It’ll then “just” be a matter of adding missions and assets for the full game.

It’s still a bit too early to say how far off the first alpha release of the demo is, but I hope to be able to release something at least within the next six months, hopefully sooner rather than later.

[Christian Knudsen]

Semi-random character appearance
August 30th

In the last video update, we had multiple NPCs randomly walking around, which was a big step towards the initial engine for the demo. They all looked the same though, like a bunch of clones, twins or ‘Malkoviches’. The latest work on the engine remedies that by creating the look of the characters by semi-randomly combining and coloring different body parts.






As you can see, none of the characters look exactly the same. Some of them look a bit similar, though, but that’s just because this test only has 2 types of shirts, 2 pants, 2 shoes, 2 hair styles and 6 hats to choose from (the guard uniforms aren’t combined with the other clothing types, so I’m not counting the uniform pants, shirts and shoes in this). Imagine the level of variety that can be produced with 10 types of each clothing part instead of just 2!

It does take quite some time to prepare all the various sprites for this – each character frame consists of about 15 sprites and there are 10 frames in this animation and a bunch of different sprites for each body part, so if you do the math, it really adds up – but I think the results are definitely worth it. I’ve also optimized my work flow in creating these sprites, so I can knock them out pretty quickly now.

I’m currently working on creating the sprites for the other seven directions (well, actually just 4, as three of them are just existing sprites mirrored), as well as for the running animation and the neutral position. This’ll probably take considerable time, so it might be awhile before the next video update – unless I do some work on other parts of the engine that are worth sharing. We’ll see.

[Christian Knudsen]

Clothing for walk animation done
September 9th

The sprites that make up the clothes and body parts for the 8 directions of the walk cycle are now done. The below video shows 90 randomly generated characters walking at different speeds:

Watch the animation on YouTube!

It’s been a bit more than a week since I posted the last video that showed off just one direction of the walk animation. This doesn’t mean that it only took that time to create the required sprites though, as I’d cheated a little and was already well into making the remaining sprites when I posted the last video. If I add up the time used, I think it’s probably taken about 14 days of full time sprite making to create these sprites (~2050 separate sprites in total), which isn’t too bad and makes me feel that the system I’ve set up is definitely viable. I can imagine that the final six months or so of working on the full game will be all about cranking out these kinds of sprites to allow for even greater variety in character appearances.

I’ve already started work on the sprites for the running animation (the neutral position is done) and am also looking at animation and body templates for female characters. A pity it’s just 3D models and not real models – would certainly have made the task slightly more interesting… Ahem…

Shooting and impact animations are also somewhat in the pipeline – as are weapons – but I want the walk and run animations to be done and implemented in the engine for both male and female characters before I move on to that.

[Christian Knudsen]

Creating semi-random character appearances – Part 1
September 14th

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.

To create the sprites, I primarily use two programs: Poser and GIMP.

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.

[Carrie Nation]

I love these detail and most importantly image filled dev logs, fun to read, keep it up.

[Christian Knudsen]

Thanks. Will do.

[Christian Knudsen]

Creating semi-random character appearances – Part 2
October 22nd

The continuation of last month's Part 1 is long overdue, but here it finally is. In Part 1, I described the process for creating the many subsprites that go into creating the full character sprites. In this blog post, I will focus on how the multiple subsprites are actually drawn to the screen to correctly form the complete character.

From:



To:

Two things need to happen for these subsprites to be drawn correctly. 1) The program needs to know where to bind the subsprite from, and 2) it needs to know where to blit it on the screen.

All these subsprites are pretty small in size and storing them all as individual images would not only result in a mess of thousands of image files, it would also present a problem for the game engine. The engine uses OpenGL for drawing stuff to the screen and OpenGL prefers its textures (the images to draw) to be power of 2 in size, meaning that the height and width of the image must be 16, 32, 64, 128, 256, 512 or 1024 pixels. Extensions exist for OpenGL that allow the usage of any size, but not all video cards support this extension, and there's actually really no reason for using non-power of 2 textures. Why? Well, because even though the subsprites are all very small, they can be packed together in a so-called texture atlas, and this texture atlas can just be power of 2 sized:

This mean that the extension for non-power of 2 textures isn't needed, but there's also another benefit of packing subsprites together in one large image file. Whenever OpenGL has to bind (prepare for drawing to the screen) a texture, it takes time as the texture data must be moved to the GPU. If all the subsprites were in separate image files, I'd have to constantly bind new files, but when related subsprites are packed together on a texture atlas, I only have to bind this texture atlas once and can then just tell OpenGL which part of the texture atlas to blit to the screen.

Telling the program where to draw from
And that's where we get to the first requirement: Telling the program on which texture atlas each subsprite can be found and what the individual subsprite's coordinates are on this texture atlas. Thankfully, I don't have to manually create a texture atlas and paste the subsprites onto it. A lot of free programs exist for doing this automatically. You just set the size of the texture atlas and select which files should be packed in it, and the program does it all for you - packing the subsprites together in the most efficient manner. Furthermore, these programs can then output the coordinates of each subsprite on the texture atlas in various formats. It's then just a matter of getting this coordinate information into the program and creating a procedure for grabbing the correct information for each subsprite.

In code terms, I've created a procedure that gets called with the subsprite's name and then returns the number of the texture atlas and the coordinates where the subsprite can be found. Here's a snippet of the Pascal code that returns the subsprite positions of all the sprites that go into making the ten frames of a male character walking south:

Code:

   PROCEDURE GetWalk1SpritePositionValues(SpriteName : String);
   BEGIN
      IF SpriteName = 'walk1-1malehair-1' THEN SetSpritePositionValues(walkmale1, 334, 257, 12, 11)
      ELSE IF SpriteName = 'walk1-1malehair-2' THEN SetSpritePositionValues(walkmale1, 442, 257, 12, 11)
      ELSE IF SpriteName = 'walk1-1malehat-1' THEN SetSpritePositionValues(walkmale1, 394, 257, 12, 11)
      ELSE IF SpriteName = 'walk1-1malehat-2' THEN SetSpritePositionValues(walkmale1, 409, 209, 12, 16)
      ELSE IF SpriteName = 'walk1-1malehat-3' THEN SetSpritePositionValues(walkmale1, 406, 232, 12, 14)
      ELSE IF SpriteName = 'walk1-1malehat-4' THEN SetSpritePositionValues(walkmale1, 337, 209, 12, 16)
      ELSE IF SpriteName = 'walk1-1malehat-5' THEN SetSpritePositionValues(walkmale1, 167, 392, 22, 17)
      ELSE IF SpriteName = 'walk1-1malehat-6' THEN SetSpritePositionValues(walkmale1, 345, 162, 18, 15)
      ELSE IF SpriteName = 'walk1-1malehead-1' THEN SetSpritePositionValues(walkmale1, 497, 162, 12, 17)
      ELSE IF SpriteName = 'walk1-1maleleftarm-1' THEN SetSpritePositionValues(walkmale1, 327, 270, 8, 10)
      ELSE IF SpriteName = 'walk1-1maleleftarm-2' THEN SetSpritePositionValues(walkmale1, 232, 488, 9, 24)
      ELSE IF SpriteName = 'walk1-1maleleftarm-3' THEN SetSpritePositionValues(walkmale1, 286, 232, 9, 24)
      *snip*
      ELSE IF SpriteName = 'walk1-10malerightfoot' THEN SetSpritePositionValues(walkmale1, 351, 270, 7, 10)
      ELSE IF SpriteName = 'walk1-10malerighthand' THEN SetSpritePositionValues(walkmale1, 202, 245, 9, 36)
      ELSE IF SpriteName = 'walk1-10malerightshoe-1' THEN SetSpritePositionValues(walkmale1, 202, 499, 9, 13)
      ELSE IF SpriteName = 'walk1-10malerightshoe-2' THEN SetSpritePositionValues(walkmale1, 494, 179, 11, 27)
      ELSE IF SpriteName = 'walk1-10malerightshoe-3' THEN SetSpritePositionValues(walkmale1, 259, 484, 9, 13)
      ELSE IF SpriteName = 'walk1-10maletorso-1' THEN SetSpritePositionValues(walkmale1, 410, 0, 35, 37)
      ELSE IF SpriteName = 'walk1-10maletorso-2' THEN SetSpritePositionValues(walkmale1, 48, 409, 35, 36)
      ELSE IF SpriteName = 'walk1-10maletorso-3' THEN SetSpritePositionValues(walkmale1, 460, 59, 35, 33)
      ELSE IF SpriteName = 'walk1-10maletorso-4' THEN SetSpritePositionValues(walkmale1, 425, 59, 35, 33)
      ELSE IF SpriteName = 'walk1-10maletorso-5' THEN SetSpritePositionValues(walkmale1, 390, 59, 35, 33);
   END;

The SetSpritePositionValues procedure that gets called is just a simple procedure for passing on the values to a set of global variables that I then use when calling the OpenGL blitting procedure:

Code:

   PROCEDURE SetSpritePositionValues(TextureMap, X, Y, Width, Height : Word);
   BEGIN
      GetSpriteMap := TextureReference[TextureMap];
      GetSpriteXPosition := X;
      GetSpriteYPosition := Y;
      GetSpriteWidth := Width;
      GetSpriteHeight := Height;
   END;

So the first value that gets passed is the number of the texture atlas (in this case, it is a constant value called 'walkmale1'), then the X and Y coordinates, and then the width and height.

All these procedures fill up a lot of lines of code, but they are quickly made since it's just a matter of formatting the coordinate information given from the image packing program. This is the quick and easy part. The program now knows where to draw from. It's the second requirement that takes a lot of time.

Telling the program where to draw to
For everything related to drawing and placing of characters, it all starts with the character template sprite. This is just the basic character frame with no clothes on:

This sprite is actually never used in the game, since the character sprites are all drawn by using the subsprites to form a complete character sprite. But the height and width of this template sprite is what's used for drawing the subsprites to the screen. The upper left corner of this template sprite has the coordinates (0,0). When I for example need to figure out what the coordinates of the character's pants are in relation to this, I just go into GIMP, paste the pants onto this template sprite, move them to the upper left corner to 'reset' the coordinates, and then drag the pants to the correct position on the sprite and read how far the pants have been dragged along the X and Y axis:

This gives me the pants' relative coordinates (relative to the template sprite's (0,0) coordinates): (6,43). When the character is drawn to the screen, I already know what the character's overall coordinates are. Let's say the character's coordinates are (201,750). To figure out where the pants subsprite should be drawn, I just add the pants' relative coordinates to the character's overall coordinates:

(201,750) + (6,43) = (207,793)

So I just tell OpenGL to blit from the coordinates of the texture atlas previously found and to the screen coordinates (207,793). This will draw the pants in the correct spot. It's quick and easy when everything's programmed correctly. What takes time is manually determining what each subsprites' coordinates are relative to the template sprite. That takes a lot of patience and use of GIMP. So, again, I get to listen to a lot of podcasts while doing this stuff!

There's still one thing left to do before the character sprite is ready to be drawn. As it consists of multiple subsprites, these all have to be drawn in the correct order or you risk having a character with his legs outside his pants, or his head over his hat. How this is managed will be the subject of Part 3.

[Christian Knudsen]

Male characters clothed
October 31st, 2010

The clothing sprites for the male characters’ walking and running animations are now done:

Watch the video on YouTube!

I’ve also implemented character selection with a green outline for the currently selected character. This will of course be used for selecting a character to attack, talk to, examine, and so on. I’ve begun work on the female characters next and am currently creating the clothing sprites for them.

[deathtotheweird]

Looks nice. Very fallout-ish 

[ANtY]

Looks very neat, waiting for some core gameplay

[Christian Knudsen]

Looks nice. Very fallout-ish 

That's definitely an inspiration!

Looks very neat, waiting for some core gameplay

I'm going to use most of the character combat code from my other game, which is why I'm mostly focusing on the visuals in these updates. The core gameplay is mostly going to be about sneaking around inside office buildings and assassinating designated targets (and whoever gets in your way!). I suppose it's inspired by Hitman in that respect. One idea I'm currently toying around with is having two modes of attack: a quick and an aimed. Characters that are alerted to your presence can only be attacked with the quick mode, meaning that you just fire/hit the target automatically, whereas you will be able to aim manually in a kind of first-person display at targets that aren't alerted to your presence -- so you will for example be able to set up a shot with your sniper rifle at an unsuspecting target.

Anyway, my first milestone is just being able to fire a gun at other characters. I'll probably release an early tech demo at that point, to make sure it's working okay on most people's computers.

[Christian Knudsen]

See women run
November 10th, 2010

Run, women, run.

So, yeah, I’ve got the female run animation and clothing done:

Watch the video on YouTube!

Working on the walk animation 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.

[deathtotheweird]

haha I was sad when there was no dance animations

made me think of this:

[Christian Knudsen]

Argh! That clip should come with an epilepsy warning!