Quests #3

I remember a great gaming experience I had with Might and Magic VI. The game started in a small town where everything seemed to have a place and a purpose. I really enjoyed the immersion factor of this area. Never did I get the feeling that I didn’t belong or that my actions were meaningless. Unfortunately, the rest of the game didn’t quite live up to the promise of that first area.

That initial town started me thinking about crafting playing areas where everything had a function. As per my previous posts, I will explore the potential of using a village (and surrounding areas) as the main questing area in the context of a roguelike.

I want the village to seem alive with every actor having a clear role and back story. The village should function like a living organism. It should be able to operate without relying on the actions of the player and should react to environmental events (weather, economic, physical threat) in a acceptable manner.

It is my vision that the player will be able to see the impact of his actions on the livelihood of the village and it’s villagers. If the baker gets sick (special event) the player can choose to go find a cure or do nothing. If the player fails (there might not be a cure) or does nothing, the baker could either die or get well. If the baker dies there might not be a baker in town for a while, which could impact the baked goods supply within the village. There might be other consequences depending on the other relationships impacted by the death of the baker.

It is these indirect consequences that I would like to explore in a game design. I am hoping that direct feedback (through quest rewards) and indirect feedback (through changes in the village) would inspire the player to engage with the game.

For the next few posts, I hope to explore building the indirect feedback loop into the fundamental game design.

Advertisements

Quests #2

Traditionally, roguelikes have been about random generated environments, turn-based game play, tactical combat, character progression and inventory management. A few modern incarnations have had some form of questing system, but not to the level as described in my previous post.

In order to facilitate a meaningful gaming experience I need to find a way to engage the player with the game world. I want the player to feel like he belongs in the world and the he can make a difference to his character’s life and the lives of the other characters within the game world.

As a first implementation, I propose to centre the action around a single village. Each character in the village will have a specific role and purpose. I don’t want any meaningless elements within the game world. Everything should be built according to a plan and a purpose.

The player character will be a member of the village. I want the player to feel like he is a part of the village and has some purpose in the village. I don’t think the player will take a primary role within the village, such as the role of the innkeeper, smith or butcher, but will have some kind of supporting role within the village.

I can achieve the above mentioned supporting role through various means. An obvious way would be to make the player a child of one of the villagers. The player will start his journey by assisting his parents with their particular tasks and then gradually branch out to do greater things.

Another possibility is for the player’s livelihood to be threatened by some external force, causing the player to seek refuge at the village and requiring the player to take steps to get back on his feet. For example, the player could have his farm destroyed by a band of Orcs and would then need to take refuge at the village Inn. From there he has various options available to him. For example, he could assist the villagers with their tasks or leave the village to find the Orcs. It becomes the player’s decision and his decisions will change his experience.

The outcome of the player’s actions would, hopefully, have a lasting impact on the lives of the villagers, the overall future of the village and possibly the player himself.

Quests #1

I’ve been thinking about doing an experiment with quests in a roguelike game. My ideal quest implementation would steer away from the traditional Fedex and “kill x number of y creature” quests. The problem with the aforementioned quests is that they are easy to implement and simple to complete and therefore very tempting to use. Unfortunately, they are also very boring and unfulfilling.

I hate it when a game gets me to spend my time on it and then rewards me with inane quests and even better, zero consequences for completing them. I don’t see a quest reward in the form of an item or experience points as being a good consequence for completing a quest. Although these rewards have an impact on my character, they don’t have any bearing on me, the player.

A great example of this is Oblivion. A game with an “immersive” game world, where you can do almost anything, but whatever you do has no real impact. I remember one quest where the champion gladiator asked me to find out about his parents. During the quest you discover that his father was a vampire or something sinister like that. Upon telling him the disturbing news, he responds with some cookie cutter dialog and carries on hacking away at the practice dummy he was busy with. So after I travelled half way across the world, fought many deadly enemies and delivered this dire news, my actions have had no impact whatsoever. I ask myself, what was the point? All the game designer actually did was waste my time to give my character experience points and maybe some items or gold.

These quests although meaningless from the player’s perspective, do serve some purpose. They are useful in driving world exploration and rewarding the player character with experience and better loot, constantly steering the player experience towards a (hopefully meaningful) conclusion. In essence there is nothing wrong with this, but I want more from a game. I want to be engaged and entertained, I want my efforts to have some meaning to the world my character inhabits.

I hope to explore some quest designs that will, hopefully, engage the player and reward him with a meaningful playing experience.

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.

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.