Some thoughts on Last Man Standing

If you had been following this blog you would know that “Last Man Standing” was originally intended to be a simple game with a very limited scope. The original scope did not really cater for any game play other than killing all the monsters or being killed. In order to release the game, I felt that I needed a few extra features, and so “Last Man Standing” was born.

To make it a game I added the following features:

  • the ability for actors to gain health and damage from their victims,
  • all actors are enemies i.e. it is a free-for-all,
  • and a user interface showing player stats, current threats, opponents and game messages

Overall I was happy with the end result, especially considering the amount of time I spent implementing these features (about 8 hours). But even as I put it all together I realised there were some flaws in the design. I’ve listed the main flaws below and included some discussion on how I propose to fix them.

  1. The end game is really boring. I often found myself running around in the empty dungeon (for a long time) looking for the last opponent. I tried to remedy this by letting the computer AI seek you out if it is just the two of you, but it wasn’t enough. I have a few ideas on how to fix this situation.

    • The first would be to make the last opponent immediately visible on the map no matter where he is. You can then just run up to him without the whole hide and seek factor. I am, however, worried that this approach would take away some of the tactical combat elements and might be a bit silly.
    • A review on cymonsgames suggested directional cues, these could be visual or in the form of context sensitive game messages e.g. “You hear some movement to the west”. I’m not sure to what extent it would eliminate the hide and seek problem, but it’s worth a shot. I think this feature will enhance the general game play and is well worth implementing.

  2. Combat is very basic at the moment. All you can do is run up to a monster and hit it. There are a few options for me to implement.

    • I can implement ranged combat and spells. This would add immediate variety in how you engage with the monsters. My concern is that I don’t really want to implement ranged combat and spells in the traditional sense. Ranged combat would require a different weapon type and potentially an inventory system. Spells would require all kinds of different effects and not to mention a complete magic system.
    • Another technique would be to implement different abilities. These could include swap life, spirit walk, phase door etc. I guess they’re could be seen as spells. My implementation, however, would limit these abilities to different races, or hero types. You pick a hero or race at the start of the game and then have one or more abilities available. This would provide you with completely different playing styles depending on what hero you choose.

  3. The UI is hardcoded to a specific resolution. I propose to implement some kind of variable layout that would keep the standard output fixed, but scale the portion of viewable map area. I would have to implement map scrolling, but this isn’t a big deal.

I am sure there are a lot more flaws in the game, but I feel the above list is a good place to start.

Simple Game #1 is alive!

Inspiration struck this morning at 04:00 and I decided to turn Simple Game #1 into a little mini game. My inspiration was the highlander movies.

The premise is simple. You’re in a dungeon with 10 other bad guys. The objective is to be the last man standing. The twist is that whenever you kill someone you gain their abilities (Health and Damage).

Therefore the more you kill the higher your chance of winning. Of course this counts for the monsters as well.

You can find the source at

The binaries are available at

This game requires the .NET Framework 3.5 and uses the libtcod library for rendering


Have fun and let me know what you think.

Simple Game – Progress Update #3

I have finally completed my first simple game. It feels great even though the end result is really basic. The nice thing is that I have a good base to work from for future projects.

The current feature set includes the following.

  • Game loop
  • Speed system
  • Damage
  • Health
  • Death
  • The end game
  • Races (Tank, DPS and Human)
  • The player (Human)
  • Lighting (Shadow Casting)
  • FOV (Shadow Casting)
  • Fog of War
  • AI (ZombieBrain and NullBrain)
  • Movement Behaviour (Humanoid)
  • Sight Behaviour (Humanoid, Nightvision, Torch)
  • Dungeon Generator (Corridors, Rooms, Doors, Prefab Rooms)
  • A* Pathfinding

I am in the progress of thinking about the next milestone and at the moment I’m considering the following functionality.

  • GUI
  • Save/Reload
  • Replays
  • Scripting Engine

For a GUI I’m going to have to think about what information I need to present to the user. I’m a bit uncertain of this as I don’t know what my future games will need. Maybe I can implement something basic and just work from there.

Save and Reload is self explanatory.

Replays is an idea I’ve always wanted to implement. Imagine the replays in Warcraft 3 where you can fast forward or rewind the replay to an exact point in time. I propose to implement this by storing each “event” in the game in sequential order. I can then replay these events to restore the game state to a certain point in game time.

The scripting engine will allow me to “easily” configure new games (story, NPC, quests, races, classes, equipment etc.) It essentially decouples the game code from the infrastructure code. I haven’t decided on a scripting language yet but I’ll probably use LUA.

Simple Game – Progress Update #2

Today is a good day. I added my first computer AI with attack and movement capabilities to the game. It almost feels like a real game! My current test environment has the player in a 10×10 room with two zombie-like opponents chasing him down and beating him to a pulp.

I feel I am very close to completing my objectives for the simple game. All I need is some UI feedback on player health, monster health, etc. Plugging in the old random dungeon generator code and then some polish and tweaks.

The great thing about this is that I can then proceed to the next level of simple game. But more on this later.

Simple Game – Progress Update #1

I was able to make some good progress over the weekend.

I completed the keyboard input handler. The player can now run around on the map and attack monsters. The game loop is holding up well and I’m happy with the design. Dead monsters are removed from the map and not included in any further game logic.

I am using the command pattern to encapsulate the attack and move functionality. This is working well so far, but I’m not completely happy with the coupling. My initial design was that the various commands would totally abstract the logic away from the main game loop. The various AI implementations are responsible for instantiating new commands and allowing the game loop to process these commands.

I always seem to need a reference to the actor initiating the command, the other actors on the map, the terrain, and the direction. This requires my AI implementations to hold too many irrelevant references, making them brittle. If my commands had an implicit reference to the actors, terrain, objects, etc. then I would only need to pass them a reference to the initiator (the AI host) and a direction. To remedy this I propose to add some kind of factory that knows about the current game state.

I currently don’t have a concept of an encapsulated game state, as I haven’t needed it. But the design is now requiring such a construct. I’m thinking of creating the concept of an instance. The instance would represent a dungeon level or town area. I don’t know if it will represent multiple dungeon levels, but it could.

The AI would then ask the current game instance for a new Move or Attack command and pass it the Actor and Direction as input parameters. The game instance would instantiate the requested command with the appropriate data for the AI which would then pass it back to the game loop. The coupling will now be reduced to a single instance class which should prove to be easier to work with.