The “THING” class

As stated previously, I am porting a version of Rogue from 1984 originally written in C for DOS into C#.

Many things wind up easy to port.  Most #defines wind up as const or readonly fields.  Everything winds up a static field or method of a single Program class.

However, the THING “class” was the strangest bit to port thus far.

THING represents either a monster or an item.

It is a union.

Each of the two substructs in the union contain pointers to other THING variables.

So, its a linked list *AND* a union.

Now, I’m attempting to do a “faithful” port, which means it is my goal to get as close to the original as possible (within reason), so I’ve got a kind of ugly re-representation of THING in my code.  It works, anyway.

When porting old code like this, I don’t typically question these things too heavily.  I have to rely on the good faith of the developer twenty four years ago.  He had a perfectly good reason for choosing a union.  I just don’t see what it was.

Rogue Port

So what if I don’t have focus?

Along side other things, I am doing a port of Rogue into C#.  In particular, I’m doing a port of the Epyx version 1.48 for DOS.

The method of porting is very similar to the method I use to port old BASIC games into C#.  First, I move all of the code into C# file with every line commented.  Then I go and slowly replace the commented lines with equivalent C# code.

Rogue, however, is rather unlike the BASIC games I have ported.  In BASIC, there was typically only a single listing/file to port.  Rogue has dozens of C files.

So I decided to abuse the “partial class” feature of C#.  Each of the C files went into a CS file with the same name.  There is a namespace around the code, and the code exists within “partial class Program”.  Yes, I have a Program class that spans nearly 40 files.

I can hear the C# people cringe.

But it just goes to show… a language like C# doesn’t force anybody into object oriented programming.

Space Trader for XNA is GO!

Space Trader is a game for Palm, and it is my desire to port it to XNA.

Of course, it has periodically been my desire to port it to the Yahoo! Widget Engine, JavaScript, and plain C#. I have taken up the project a number of times, and failed at it. I’ve got lots of stray code to show for it.

The original was written in C, and is heavily forms based (as one might expect for a Palm app). Fortunately, all of the resources for the UI, strings, alerts, bitmaps, etc were recoverable using the PalmOne tools (they extract them into a nice XML file).

It is also GPL, which means I don’t even need to talk to the author to do this port. And I haven’t.

There is already a C# port for windows, but it has some differences in it that I don’t like, including the “put all of the screens on one window” thing that I don’t care for.

The screens are all 160×160, which really can’t give too much information at a time. Currently, I’m working on it in 800×600.

One of the first things I did was to make a utility app to scan in the resource xml files. I did this mainly for the large number of string and alert resources. The forms I just have to duplicate by hand, since they need to grow in size anyway.

Which brings me to control issues. The Palm version used (duh) the stylus, for which the windows equivalent would be the mouse. However, in XNA the target controller should be the 360 controller and the keyboard (the two controllers that both windows and the 360 support) but more importantly, everything should be doable from a game pad. It’ll be interesting to see what I can come up with for equivalent controls.

Diamond Maze

Well, there’s not much to it yet, but the maze is present, and the player can move about the maze.  There is nothing for him to do yet, however.

Some differences from the original version include a different screen resolution (800×600 instead of the original 640×480).  I did not change the actual number of ascii cells, which remains 40×30, it just scales the sprites to the 20×20 from the 16×16 in the bitmap.

However, the area left for the minimap has changed this time.  Originally, this area was 128×128, and it is now 160×160.  Since the minimap consists of individual pixels, and I don’t want to be scaling something like that, I’m going to  change the size of the entire map to 160×160.

Originally, the individual “rooms” of the maze were 16×16, and there was a grid of 8×8 of them.  This leaves me with a decision to make.  Stay with the 16×16 rooms and change the number of them to 100?  Or, stick with 64 rooms and make them 20×20?  Or, go with a totally different room size completely.

After that, I have a few other decisions to make.  The original game had 4 differently colored doors, and the differently colored keys to go with them.  Do I leave it at 4, or change it?  The four potions: invincibility, freeze, health, and wealth.  Keep as is or add/remove/modify the list?

In any case, the end result should be interesting, and recognizably  the same game as the original, so it really doesn’t matter what is decided as long as it keeps the game fun.

Maze Generation Code and Diamond Maze

The following is the current iteration of the maze generation algorithm I’m using.  Currently, I am working on a remake of Diamond Maze with XNA.

Yes, it will be using the same ASCII style graphics as it did originally.  This is more of a “ramp up on how I’m going to do stuff in XNA” than anything else.

A colleague of mine once referred to Diamond Maze as a roguelike, which I had never really thought of it as, but I guess the term does accurately describe the game.  I usually associate a way more elaborate combat system and inventory system than what I used in DM.

This code is my implementation of Pim’s algorithm.  It isn’t terribly useful without the associated classes, but I just wanted to share it.

public void Generate(int randomSeed)
{
Random random = new Random(randomSeed);
Clear();
List<MazeCell> frontier = new List<MazeCell>();
MazeCell cell = GetCell(random.Next(Width), random.Next(Height));
cell.Frontier = false;
int direction;
for (direction = MazeDirections.First; direction <= MazeDirections.Last; ++direction)
{
if (cell.Neighbors[direction] != null && cell.Neighbors[direction].Frontier)
{
frontier.Add(cell.Neighbors[direction]);
}
}
while (frontier.Count > 0)
{
cell = frontier[random.Next(frontier.Count)];
frontier.Remove(cell);
cell.Frontier = false;
do
{
direction = random.Next(MazeDirections.Count);
}while(cell.Neighbors[direction]==null || cell.Neighbors[direction].Frontier);
cell.Portals[direction].Open = true;
for (direction = MazeDirections.First; direction <= MazeDirections.Last; ++direction)
{
if (cell.Neighbors[direction] != null && cell.Neighbors[direction].Frontier && !frontier.Contains(cell.Neighbors[direction]))
{
frontier.Add(cell.Neighbors[direction]);
}
}
}
}

Inevitable

JetLag in XNA screenshot

Download RAR file containing game here.

Stand Alone Version

For a stand alone version of Connect!, I could have gone with a number of different solutions.

One, I could just distribute a zip file with the html and js files in it. This did not appeal to me, as it wasn’t really any better than just having it on the web.

Two, I could make an Adobe Air application. While I still may do this at some point, I don’t want to go through learning where all of the little tweaks have to be done to make it work. Also, I don’t want to force players to install Adobe Air.

Three, I could translate it into a Yahoo! Widget or other widget/gadget/doodad thingie. While I am likely to still make it a Yahoo! Widget, the same idea of requiring the user to have a particular install on their machine isn’t what I want.

Four, I could translate it into another language. I considered C#, ActionScript, and the ECMA-esque scripting language of Wintermute.

I actually decided on C# (realizing that I’m limiting the players to windows, but the Mac folks can wait for the Yahoo! Widget), but I also decided not to translate the game itself… I decided to simply use the WebBrowser control in .net to run my game inside of a very simple C# winforms application.

As it turns out, this is a pretty easy thing to set up. It’s pretty easy to link the C# application to the script running inside of the browser. The script can tell the application to resize, and the application can tell the script to start a new game, and that’s about as far as I’ve gotten, but the proof of concept is there, and I’ll be able to flesh out all of the functionality within a normal windows menu bar once I’ve got the game itself done.

Here’s what it looks like:

And here’s where you can download a RAR file with an installer. Keep in mind, not all of the functionality is in the stand-alone yet…. this is merely a concept demo.

http://www.playdeez.com/games/connect/1_0_0_0.rar