Finished the port to XNA 3 (CTP)

I’ve just finished porting my work in progress Roguelike to XNA 3 (CTP). I have created a new project on Codeplex. All new project updates will be uploaded to that URL.

This release contains the following features:

• Basic dungeon generation
• Dungeon prefabs
• Fov using shadow casting
• Coloured lighting using shadow casting
• A* path finding used in dungeon exploration

and has the following dependencies:

• DirectX 9c
• .NET 3.5
• XNA 3 CTP

The major new feature is the auto-explore option. Press "enter" to activate/deactivate auto-explore. The player character will begin to explore the dungeon using the A* algorithm when auto-explore is active.

Have fun with this new release and, as always, your comments are appreciated.

XNA 3 CTP

If you haven’t heard yet, the XNA 3 CTP was released a few days ago.

I care because, OpenGl is a pain to work with. Mainly due to my inexperience. Considering I’m trying to write a Roguelike (which traditionally uses ASCII), the effort to get OpenGl to render properly just seems to be a waste of time.

The final straw was when I discovered that my game doesn’t render properly, using OpenGl, on ATI Radeon and old NVidia cards. Is this what all game developers (and I use “game” loosely) have to go through?

The exciting thing about XNA 3 is the support for Visual Studio 2008. I dabbled with version 2 for a while, but the step back to .NET 2 is really painful if you’ve become used to the C# 3 language features.

Enough ranting, the point of the post is that I’m porting my rendering to XNA 3.

It’s Alive (almost)

I was able to implement A* pathfinding over the weekend and this opened up a lot of functionality. My A* implementation was based on the following articles.

Path Finding Using A* in C# 3

Amit’s Game Programming – A* Heuristics

I used Eric’s articles for the A* algorithm main loop and data structures and Amit’s article to tweak my movement heuristics.

My first usage of the new pathfinding code was to write a “explorer”. My plan is to use this during dungeon exploration. The player can switch on “Auto Explore” and the explorer code will automatically explore the dungeon on the player’s behalf. It’s almost like running in Angband, but the code will only interrup when a monster or new item is detected.

My explorer uses a simple methodology for exploring the map. Pick the closest unseen tile, find a path to it (using A*) and then navigate there. Repeat until there are no more unseen tiles. This seems to work quite well.

At the moment this exploration algorithm is a bit “dumb” as the closest unseen tile isn’t always the best tile to pick. An improvement would be to give unseen tiles within the current room a higher priority than tiles outside a room (if the player was inside a room). This will cause the explorer to finish exploring rooms before heading out into tunnels.

My next usage of the explorer was to tweak my dungeon generation. As I generate a dungeon I let the explorer try and visit all the “walkable” tiles. If he can’t find a route to a specific unseen tile then the dungeon was generated with inaccessible areas.

My algorithm then switches to “Dig” mode. I find the closest seen tile (to the inaccessible unseen tile), find the path, and navigate to the seen tile. I then change my path finding behaviour to ignore all movement costs for walls (allowing it to move through walls) and to favour up, down, left and right directions over diagonals. A* now finds a path, through walls, to the unseen tile and my explorer now navigates to that tile. Everytime the explorer “bump’s” into a wall it creates a floor tile, forming a tunnel. My dungeons no longer have inaccessible areas.

The abibility to switch, replace or alter movement behaviour is quite important to me. I can now, independent of the type of actor (player, monster, type of monster) change the way it moves on the map. An “ethereal” movement behaviour would allow an actor to move through obstacles, a “digger” movement behaviour would allow the actor to dig tunnels through obstacles.

So far I’m quite happy with the results.

My next step is to implement some simple AI types that will “explore” the dungeon e.g. wandering monsters, follow the player, or guard an area.

Lighting and Dungeon Prefab Techdemo

The purpose of this demo is to show off the dungeon generation that makes use of dynamic and static light sources and custom dungeon prefabs. You can download the binaries at codeplex.

For this release I improved the room and door placement as well as adding the dungeon prefab functionality. I still have situations where the dungeon generator creates unreachable areas. This is due to the way rooms are placed resulting in certain corridors being cut off. I tried to remedy this by
always adding a door to a deadend with a corridor on the opposite side. Its not perfect yet, but I’m happy with 90% of the results.

I haven’t thought of placing lights in a procedural manner and as a shortcut I make use of the prefabs to get them into the dungeons.

The lighting has been adjusted to allow for proper alpha blending of the light values (before I just used an additive blending which resulted in mostly white lights). There is still the problem of tiles being lit by lights from behind walls. I hope to correct this in a future release.

I am still undecided as to whether lights within the dungeon actually add any value.

Enjoy, and as always comments and feedback are welcome.

Dependencies:

This application was developed using .NET 3.5 and is written in C#. I use SDL.NET which runs on top of the Tao.NET framework. Input is handled using SDL and rendering via OpenGL. I use DevIL to do image loading etc.

I have only tested this on Windows XP. And you will need .NET 3.5 to run the application. I have added the SDL dependencies to this release.

I am struggling with getting the application working on OpenSUSE. The error has something todo with DevIL. If anyone is willing to assist. You will need to install Mono 1.9 and SDL.NET. To run the application on mono you will have to use the following script ‘mono RogueLib.Game.exe’

Issues:

I have noticed some rendering issues on my Radeon X1900. Could be driver related. Works fine on all NVidia machines I’ve tested. I didn’t expect to have any issues using OpenGl but I do.

Keys:

Use the direction keypad or numeric keys to navigate the map.
Use spacebar to create a new dungeon.
Use escape to end the demo.

Custom Dungeon Prefabs:

The dungeonprefabs.xml file in the config directory is used to configure custom dungeon prefab rooms.

The layout tag uses a CSV layout to describe the structure. Use 0 for a NULL tile, 1 for a floor, 2 for a wall and 3 for a closed door.

Each dungeon row begins on a new line.

The light sources tag allow you to specify lights within the prefab. You can customize the light colour, radius and the attenuation function. The attenuation parameters are used in the formula 1 / constant + (linear * distance) + (quadratic * distance * distance).

The connectors tags tell the dungeon generator how to place a prefab within the dungeon. The generator will attempt to connect the prefab to a corridor for each connector specified. I haven’t really tested this algorithm for connectors within the prefab. My examples only have connectors on the edges of the prefab.

The prefabs will be placed over any existing dungeon structures. At the time of placement there should only be corridors and the prefabs will be placed adjacent to any corridors.