Simple Game #2 – Iteration 1

My first idea was to make use of a cone field of view to simulate actor line of sight and orientation. This will probably be the best way to go ahead, but right now I’m not in the mood to research some new technology. I will make do with my current FOV implementation that does not take into account the orientation of the actor.

The quickest route to having something playable will be to reuse the code base from simple game #1 and to convert it to a real-time engine. My main reason for wanting to convert to real-time processing is that I want to make a multiplayer game in the future and I don’t see it working with a turn-based engine.

For real-time mode to work I plan to make use of mouse input to control the actor. The player will control his actor by clicking on the game map which will send the actor to the desired location. This behaviour can be implemented using the keyboard, but will require the player to hold down the directional keys to steer the actor.

I hope to have iteration 1 complete by the end of next weekend with the above functionality implemented. A static map with the player actor controller using mouse input in real-time.

Simple Game #2 – The beginning

For simple game #2 I want to explore some new techniques and technologies. My inspiration for this iteration is stealth game play found in games like Thief and System Shock. Obviously I’m not planning on doing anything as sophisticated as the aforementioned games, but would rather like to focus on the stealth elements.

A great gaming memory I would like to recreate is that feeling of being chased in a confined space. The bad guy is on your heels and you need to run for your life or die. If I think back to my childhood then it would be akin to the game of hide and seek (without the dying mind you :p)

To implement the above successfully I think a first person perspective would be ideal. First person really provides a great sense of immersion, especially when you can’t see the chaser (as he is behind you). Unfortunately I don’t have the appropriate technology available and think such an endeavour would be too great in scope.

In the spirit of keeping things simple I propose to make use of 2D graphics with the game play happening in real time. The player will control his avatar and interact with the game world using the mouse and primary interface. The premise for the game will be simple. You are a prisoner in a mental hospital (wrongly incarcerated – in your opinion) looking to escape. Your goal will be to avoid the doctors, nurses and guards while you try and make your way out of the hospital undetected.

The player will need to remain undetected by staying out of sight and keeping noise levels to a minimum. The enemies will each have a field of view indicator (cone shaped) and a hearing range indicator (circle) similar to the commandos series of games. Enemies will patrol the hospital following predetermined routes and schedules, I will see if I can make this procedural, but it might not be necessary.

For now I think this should be enough to make a game, but I might need to add additional elements if the above game play is too hard, or mundane.

Last Man Standing – Updated

I’ve uploaded a new version of the source and binaries to Codeplex if you’re interested.

The new version includes

• Improved the dungeon generation time
• Increased the field of view and torch radius
• Added more AI players
• Removed current threats window
• Increased size of competitors window
• Changed game to use full screen and adjust to current resolution
• Removed field of view checks from AI threat detection

I invested about 4 hours to implement the above changes and I feel the game plays a lot better now. Don’t get too excited though, it is and always will be, a simple game. It’s purpose was to try out some ideas and learn some lessons. In the end, I feel that I got what I needed from the exercise.

There were some elements that I could not easily implement and I will be focusing on these for my next project.

The game started to run noticeably slower when I added a few more actors. I will need to do some profiling to track down the problem, but I expect it to be the A* path finding. I will be doing some investigation on alternative techniques which are hopefully not so computationally intensive.

Generally the codebase needs a bit of refactoring and I hope to go through a few revisions before the next project. I will look at encapsulating game logic, engine logic and UI logic. I will also add all the unit tests for those that are interested.

I wanted to add the ability for actors to be aware of sounds e.g. doors opening, combat, etc. but could not see a simple way to include it in the current design. To implement the feature shouldn’t be hard and I propose to make use of a technique similar to sonar.

Each time an actor completes an action the engine would send out a ping to simulate the sound. The strength of the ping, loudness and fall-off of volume would be determined by the action, racial characteristics of the actor, distance and terrain. My first implementation will probably only cater for distance and terrain but that should be enough to provide a good indication of the impact on game play. I probably won’t even use a ping (modified shadowcasting or raytracing) but would just evaluate the direct line between the actor and each of the other actors (why look for them when the engine knows where they are).

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 https://LastManStanding.svn.codeplex.com/svn

The binaries are available at http://lastmanstanding.codeplex.com/

This game requires the .NET Framework 3.5 and uses the libtcod library for rendering http://thedoryenlibrary.appspot.com/.

 

Have fun and let me know what you think.