Jeremy's Blog

This probably isn’t the most elegant or efficient method of doing this, but I needed a way to perform an “ArrayShift” on an array in C#. There’s no built-in method to do this, so I wrote up and dropped this method in my ToolBox:

/// <summary>
/// A C# implementation of "ArrayShift" this is a generic method that
/// will take an Array of T's, shift one off of the beginning of the
/// array and return it.
/// </summary>
/// <typeparam name="T">The type of array.</typeparam>
/// <param name="array">An array of T's, will be modified to remove
/// the first element.</param>
/// <returns>First element of array.</returns>
public static T ArrayShift<T>(ref T[] array)
{
   T first = array[0];
   IList<T> list = array.ToList();
   list.RemoveAt(0);
   array = list.ToArray();

   return first;
}

It’s a quick and dirty way to accomplish what I needed. If anyone has a better method, I’m open to it.

I’m about to wrap up a reasonably productive evening of coding and I’d like to go over a little of what I accomplished. It wasn’t a whole lot, but there were some very important pieces put in place that will allow us to actually start connecting to something soon.

1. The DescriptorCollection (namespace JoS.Game.Collections) class mentioned in the previous JoS entry is pretty much completed. It needs a little bit of code commenting to round it out, but for the most part the starting functionality is all there. It holds a Dictionary<String, Descriptor> which is the collection of Descriptors. .addDescriptor adds a Descriptor to the list, .getByEndpoint allows us to look up a Descriptor by its remote socket endpoint, and .delByEndpoint removes a Descriptor from the list.
2. The beginnings of the actual Descriptor (namespace JoS.Game) class are now there. Needed to make sure DescriptorCollection works, of course. We’re a couple methods away from being able to read from/write to client sockets using this class.
3. I’ve completed a pretty basic Logger (namespace JoS.Utilities) class to handle any logging that we need to do.
4. The beginnings of MainGame.Main() (the entry point to the whole app) have been put together. Main game loop coming soon.

Will probably take another hour’s worth of coding to get us a functional “chat” server using our game’s conventions. Then we can move on to dropping in the rest of the content needed to get us rolling. In case I haven’t mentioned this, the goal is to get us back to at least where we were, functionality-wise, with the old PHP JoS by the end of November. We’re well on our way to meeting or beating that goal, if I can keep moving at a reasonable pace.

The old PHP version of JoS made the JoS_Core class the central point of almost the entire game. It kept references to all of the descriptors, areas, rooms, etc. It was kind of ugly and I don’t think I want one class basically being the owner of every piece of the game. I’d like to split things out more than that.

There are a handful of requirements that we need to meet with our class/object structure/architecture:

1. We need access to all of the Socket resources from the game loop in order to perform a Socket.Select() on them.
2. We need to be able to match a Socket resource to its Descriptor object.
3. We need to be able to quickly query for any available resource by some unique identifier (id number, guid, short unique name, etc).
4. Unless performance requires it, we should try to avoid the “reference” soup that came with the previous implementation. Every object had a property with a reference for each object that was related to it in any way.

Example: Room objects had properties with direct references to all of the characters in the room, the rooms exits, the area the room was apart of. And the exits had references to the rooms they led to and the rooms they were in. The characters had references to the room that they were in. There were a lot of circular references and it’s hard for most reference counting garbage collectors to properly free resources with these types of references.

5. Classes with Events and Event Handlers need to be public so that scripted pieces in IronPython will be able to see them properly.

Possible solutions:

#1 and #2: Keep a Dictionary<String, Descriptor> that has all of the Descriptors in it in a DescriptorCollection class which will have the lookup methods mentioned in #3. The String key would be the string representation of the Socket.RemoteEndPoint. Including the remote port. Not including the remote port would make it impossible for us to accept multiple connections from the same IP Address.

#3 and #4: The resources could all be kept in their own Collection classes with the resources mapped out as necessary in Lists or Dictionaries. Multiple Dictionaries using references can be created to facilitate multiple identifiers. We’ll tie the identifiers to the rest of the objects and use the lookup methods on the Collections when we need to get an object reference.

#5: Make sure classes are defined as public. They’re not completely public by default.

This entry is almost entirely copied verbatim from the current revision of an internal collaborative document. There were some minor edits for clarification.

We’ve been giving a lot of thought to our choice in Programming Language for Journey of Souls. For a while, it was starting to look like we were going to end up writing everything in PHP or Python. I think we’ve made our decision (or at least are very close). It ended up coming down to a few things that PHP and Python just don’t have any out of the box support for. Things that it would be extremely stupid for us to roll our own implementations, when another language offers the feature up really well. The first of these being Events and Event Handling. The second being a way to write game scripts in a way that they can be replaced on the fly while the game is still running. Here’s some of the details from our research and decisions. (continue reading…)

I covered a few of my goals for Journey of Souls in my previous post. Dutch and I actually kept our plans to book club this evening and it brought about some discussion on a few game mechanics that we’d like to see in Journey of Souls. First of all, there’s a huge disparity between people who spend way too much time playing games and people who play casually. We want to make some enhancements to try to reduce that disparity and try to keep it fair to the players who do invest their time. Second, we’ve identified ways to enhance our use of the spirit realm to give it a few “eerie” but what we believe to be very cool effects. We’ve also discussed ways to clearly communicate what’s in the spirit realm versus what’s in the physical realm and different “affinities” to different areas in the spirit realm. Finally, we want to make it clear that we’re going to try to make in-game (or in character) consequences to as much “bad” behavior as possible. We don’t want to write code to prevent people from doing logical things, no matter how screwed up their logic might be. Instead, we want there to be in-game consequences to all of your actions. (continue reading…)

This post was scheduled to be published on the other 09:09:09 9/9/09 for the day. Cause I’m corny like that.

As some of you may or may not know, I’ve been off and on working on a MUD called Journey of Souls. I wanted to take a moment to go over what my plans are for the game for the benefit of those of you who don’t read what I write on Anfiniti. Dutch and I’ve been more inspired to work on the game lately, and we’ve even decided to book club a selection of chapters from a game development book which closely relate to what we’ll be doing. The plan is for this book club to actually start this weekend, so we’ll see how that goes.

At the moment, I’m right on the edge of finally choosing the language we will be developing the MUD in. We originally started in PHP, but there are some things that it can’t do (without some highly unsupported extensions) that some languages (say, Python) can do by default. And then there’s that whole we plan to run this on a server for months at a time thing. I originally started with PHP for two reasons, one of which was to prove it could be done in PHP (and done well). So, we’re still surveying that landscape to figure out what we’ll finally be settling on. I’d like to make a decision by the weekend, because I’d like for us to do any examples from our book club in the language we’ll actually be writing the code for the game in. Anyway, onto my goals for the game …

My goals are a bit lofty. It’ll be a long time before the game is available to the public, but I’ve been slowly gathering together ideas over the years for different things to incorporate into the game and different ways to get it out to the masses, once it’s ready. I want to try to summarize my goal for JoS into this post and give you guys all an idea of the type of game I’m going for. If I could just get the cat to stop sticking hair to my monitor. (continue reading…)