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.

As classes and consulting work at Omega Vortex keep pushing me more and more into .NET development, I thought it would be a good time as any to try to start learning new things and try to keep my mind working on this stuff. I decided to start looking for an Open Source project that I could contribute to.

After noticing someone on Twitter mention a LINQ to WMI project, it seemed like the perfect fit. LINQ (Language-Integrated Query) is something I’m not too familiar with and want to learn. While I’m somewhat familiar with WMI (Windows Management Instrumentation), it’s huge. There’s still plenty left to be learned about it.

I’ve become a developer on the LinqToWMI project at Microsoft’s CodePlex and I’ve already made two major updates for those who are interested. One of which is the ability to generate “Commonly Used” WMI classes instead of just generating the ones you need one at a time. The next is a major speed enhancing change on the ClassGenerator.

It came to my attention while testing the project that it would crash with a NullReferenceException if there were no instances available of the class you wanted to generate. (Example: It would crash when trying to generate a Win32_FloppyDrive class. My laptop has no floppy drive.) In re-working the generator to not use an instance to generate code from, we gained a pretty huge speed boost from not having to search for an instance. Before, it took about 4 or 5 seconds to generate around 15 classes. Now it takes a fraction of a second.

If you’re needing to use the WMI on a project and want an easy way to query it, give this project a shot. If you think it’s good, help us out by contributing patches or bug reports so we can make the project even better.