I’ve finally decided that I’m going to take an active role in getting myself out of this almost year-long development-less funk that I’ve been in. I’ve been pouring over information and ideas, trying to come up with something that I could spend my time on and make a personal project of. I actually came up with a few. They’re all Omega Vortex projects from back when we were trying to bootstrap a software company by consulting. The projects never got enough attention because of the consulting and we started to enter the really nasty area of the recession, so the consulting projects also started drying up, leaving us without enough income to allow us to move forward …

Fast forward a couple months where we were wrapping up our last consulting gig as I was taking a job at Highwinds as a Systems Engineer. Presumably to Engineer some cool tools and systems to help make our collective jobs easier. If only I knew then what I was really getting myself into. Honestly, I’m glad I didn’t. I probably wouldn’t have been so eager to take the job. Not too long after I started, our more senior engineer and overall badass Systems Ninja (hi, Matt!) got an offer he couldn’t refuse and decided to move on to higher places. It was about that time that my world turned upside-down.

With almost zero previous experience as a Linux SysAdmin, I started a journey that would lead me to a great wealth of knowledge, a much greater understanding of how our systems worked and interacted with each other, as well as roughly no amount of time to spend on any of my development projects. We went through several ups and downs as I came up to speed, learning everything I could about running our Linux systems and how all of our software worked, the way the whole deal was architected, and everything I needed to know to keep it all running. It’s a constant learning experience and I’m still picking up stuff as I go along, but I feel like I’ve come a very long way in a short amount of time and I’m far more comfortable on the command line now than I ever was even back when Linux was my primary OS on personal machines.

Since then, we’ve hired quite a few Linux folks. Less pressure is square on my shoulders now that we have more very capable people to help distribute the load. We’re making progress to working smarter and not harder, spending less of our nights in contests to put out fires and more time with opportunities to relax. Things are becoming increasingly stable which is giving me more free time during off-work hours to do whatever I want. At first, I took this time to goof off and not do a whole lot, because I hadn’t had the opportunity to do so in so long. Now, I’ve decided to transition back to active development work in my free time.

I’m sure those of you who follow me on Twitter noticed that I said I’ve officially started working on ComicShout and OmegaFlash again. That’s not all, and I’ll have a lot to say about these and other projects in future posts. In the meantime, you can keep track of what I’m working on via GitHub and Ohloh.

The repositories on GitHub are very ugly at the moment. They’re essentially dumps of what was in the private Omega Vortex repositories as of last night. A lot of code that never got committed was lost on a few of these. Keep in mind that these projects didn’t get enough love, before. My plan is to fix that. My current focus for a while is going to be OmegaFlash, so don’t expect too much activity on the others for now. As I’m able, I’m going to start putting up more information on my vision and goals for each project at their respective GitHub wikis. Anyone who’s looking to contribute after I’ve put up more info, please fork away. I’ll be keeping an eye on forks and will quickly integrate good additions. Habitual good contributors can be given direct commit access to the repositories.

If I’ve got your interest, please keep an eye on the progress at GitHub and Ohloh. Also, keep an eye on this blog. I’m going to start putting up some high-level overviews of what I want to do with the projects. Until then, I’m interested to hear ideas and suggestions from all of you.

/// <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.

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.

Thanks to Dutch giving me a wireless keyboard and mouse that he wasn’t using, I decided to start using the HDMI out to hook it up to my TV. It worked out pretty well:

I’ve been thoroughly enjoying this setup, so far. It’s even really nice for writing code. I think the most awesome part about the whole thing is that it can do full 1080p. My previous HDMI-enabled machine could only do 720p. Since the video card is pretty beefy (for a laptop), I’ve been playing a few games in this setup. It’s nice. Just as good, if not better, than sitting in the recliner and playing on a normal console.

Now, I need to get a gamepad that’ll work with it wirelessly …

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.

Thankfully, since I use Dropbox, it was easy to login to the website and revert the data file to a previous version and try it again. Otherwise, I wouldn’t have a copy of the data file and would have to re-assemble it from the pieces I had four hours ago.

Thanks, Dropbox!

Event-driven Programming

A topic of discussion that came up during tonight’s book club pseudo-session was using a more event-driven process to control the flow of the game. We believe we would prefer a lot of interactions to be based on events, as that’s how we conceptually see them. That brought us to a head with our language choices. PHP and Python currently have no built-in way to handle events. We would have to roll our own implementation. Considering the scale of the project we’re planning to put together, those are resources and cycles that we just can’t afford to give up. We just didn’t believe that either language would be capable of managing a full-on userland Event Management implementation as well as everything we actually wanted to do in the game itself. The two languages were already fighting an uphill battle to stay on our radar, but tonight’s realization pretty much doomed them. Sort of.

C#, IronPython, and the Dynamic Language Runtime

That sort of brought us down to the two options that we were sort of avoiding up to this point. Not because we’re not capable in either or because we have any particular gripe against them, just simply because we believed we could get more done faster in PHP or Python. The two options I speak of are C# are Java. Well, the heading above this section sort of gives it away, but we didn’t pick Java. Not having any experience with it personally, I’ve heard a lot of bad things about Java’s event model. While I have personal experience with C#’s event model, and have heard a lot of good things about it. Not to mention the fact that I have some good things to say about it, but that’s sort of beyond the scope of this post.

That solved one of our two problems, but C# is a compiled language. If we need to make changes to the game, that’s going to require a recompiling and stopping the game to drop in the new binaries and … wait a minute. I remembered the DLR. Not only did I remember the DLR, I remembered that the languages (IronPython, specifically) can be embedded. Meaning, we can do our scripting for the game in IronPython, and it offers us up the opportunity to do nifty things like reload game scripts at runtime. This is absolutely amazing because it minimizes downtime for the game, in the long run, and allows us to immediately add new features and such to the game without a restart. It also still lets us do a lot of stuff in one of our preferred languages, while still being able to utilize C# for any heavy lifting that needs to be done.

In my mind, this seems like a very win-win scenario. We’re going to be future-looking, so I’ve already been considering the use of things like C# 4.0’s dynamic keyword for making interacting with IronPython that much easier. It also helps that I’ve already been using the Visual Studio 2010 and .NET 4.0 Betas. We still have a long way to go before we get something usable, but locking down our language choice is a huge milestone and an issue that’s been bothering us for a long time now. With that gorilla off of our back, we can start working more on the actual design of the game and how we want the core pieces to interact, knowing that we have an Event model that’s built-in to the language we’ll be developing in.

I’ll keep the updates coming as we have more things to share.

Offline Training

I’ll start with Offline Training. In order to try to reduce the disparity between “hardcore” gamers and “casual” gamers, we’re going to use a system of offline training so that you can put together set training sets for your character to perform while you’re not logged into the game. Any character can do this and, while it won’t raise your skills as quickly as you actually being in the game and performing the actions yourself, it’ll be a huge benefit to people who can’t be inside the game all the time. You won’t have to feel quite so behind. There will be limitations, though. We don’t want the system to be abused.

1. You will only be able to perform one training set at a time while offline. This means that you’ll only be able to increase skills that the training set touches.
2. Your training will not be performed indefinitely. After a certain period of inactivity (think days, not hours), your character will eventually “go to sleep” and stop training.
3. The speed in which you learn things will be directly inverse to how much time you spend in the game + how many total skill points you already have.

More Uses for the Spirit Realm

The Spirit Realm is a huge part of Journey of Souls. We want to make as much use of it as possible and not in just a “you died, now make your way back to the physical realm” sort of way. We want it to be just as alive as the physical realm and make it useful for solving certain challenges. Those of you who are familiar with the “spectral realm” from Soul Reaver will experience the same types of puzzles and challenges, but probably on a much smaller scale. Not every character or race will be spiritually in tune enough to be able to take advantage of those types of activities, so we don’t want to alienate these races.

Another thing we want to do with the spirit realm is allow people who are spiritually in tune (and even those who aren’t) to occasionally see things in the spirit realm even when they’re in the physical realm. An example Dutch used was a room that may have a chair, a lamp, and a rocking chair that could only be seen by people who could see objects in the spirit realm. The neat thing here is that people who are right on that edge of having their spiritual awareness cross that threshold of being able to see things more often will oftentimes see things in the spirit realm and then look again to see that they’re not there.

One more thing we discussed was an area’s “spiritual power” being able to fluctuate based on things that happen in that area. For example, a death releases the soul from the physical body into the spirit realm. That release of spiritual power will raise the rating of the room so that actions in the spirit realm will bleed through to the physical realm more often. The big item here is death. One of the “cool” things we’d like to do is have the spirit realm of an area retain the finishing blow of a battle. Those with the spiritual awareness to see this from the physical realm, or those who just happened to be in the spirit realm at this location, will occassionally see the deaths of others replayed before them for a set amount of time. Truly spiritually aware players entering the site of a large conflict may get a sensory overload from all of the death that occurred there and “freak out” which will require outside assistance to get them back to a safe location.

In-Game Consequences

Lastly, we want to put a very firm focus on in-game consequences for actions. We want to encourage or discourage appropriate behavior strictly by using the mechanics of the game. We want this to be a living, breathing world of its own. One with few “external” rules, but plenty of consequence for each action. Some of the examples we used this evening were characters taking advantage of offline players’ training locations in order to attack them or somehow harm them while they’re offline. Rather than come up with a way to just say this can’t happen, we eventually settled on another use for the spiritual creatures that can cross back and forth between the spirit and physical realms along with guards for the training grounds.

We do want to make it perfectly clear that dangerous lands will be dangerous. Venturing into these sorts of areas will mean that there is no protection, and it will be possible for you to be killed. That’s perfectly reasonable and we won’t do anything to prevent that. We’re hoping that we can leave it to the players to enact justice where it is needed through the appropriate in-game systems. In the absence of that, we’ll probably do so ourselves through careful working of NPCs.

I’ll post more updates as we have more discussions about game mechanics and make more progress with the development of the game.

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.

First of all, it’s going to be a medieval-fantasy setting. For races, there will be your typical humans, elves, dwarves, etc. We also have a few races we want to add that aren’t necessarily unique, but aren’t commonly found in this setting. Things like “Avions” or winged-races, Bonewalkers (skeletal-races), and a few other things. As well as branching races to allow a sort of “metamorphosis” between two similar races. For example, any race can become a “Bonewalker” and keep a portion of the original race’s strengths/weaknesses while adopting the Bonewalker’s strengths/weaknesses.

We want the game to be extremely player-oriented. With most things eventually becoming entirely player-run. We will be providing NPCs in the short-term to fill the gaps in the player base, but we want the world to be significantly impacted by player actions. The goal is for it to be possible to have entire cities rise and fall around players and the decisions that they make.

Rather than be “just another” medieval-fantasy game, we’re looking at ways to put a unique spin on different aspects of the gameplay. Our plans for the combat system, for example, are extremely detailed and will offer what we hope to be the most realistic experience possible, without sacrificing any “fun” value for the sake of realism. Bones will break, limbs will detach, blood will spill. Everything matters, from the type and weight of the equipment you wear, to your fatigue, your stats and skills, as well as how hungry and thirsty you are.

While on the subject of stats and skills, the game will be completely class-less and level-less. Everything will be “learn by doing” and your stats will be completely based on what you do. Physical activities will increase your strength like mental activities will increase your intelligence, and so forth. Your character is yours to mold and evolve and we don’t want to restrict you to any one play style. Decide you don’t like the route you’re taking? You’re free to change it up at any time.

The NPCs will be more intelligent and more realistic than your average RPG. Nothing “materializes” out of thin air. If there are no guards around when someone shouts for them, none will come running. Shopkeepers keep hours of business. They enjoy their off-hours. You’ll find them in taverns, in their homes, visiting with friends and family. NPCs will gossip with one another just like real players. Each NPC will remember you and actions you take that they either see or hear about from other NPCs for extended periods of time. They’ll like you or dislike you based on their own traits, moods, and the things that they know about you and what you do.

Economics and trade will have a huge impact on the game. As I said before, nothing materializes out of thin air. Game state will be forever and there is no “reset” button. Food must be grown, harvested, hunted. Materials for crafts must be acquired through conventional means. NPCs will mine, hunt, fish, farm, and all of the other actions required to keep materials flowing in and out of cities. Equipment must be crafted before it can be sold. No shopkeeper will ever just “have” inventory. Caravans will bring materials to and from cities. Losing those caravans for whatever reason (Bandits, Natural Disasters, etc.) will cause shortages of whatever material that caravan was carrying. Shortages will lead to prices increasing due to demand with a lower supply. Just like a surplus would lead to lower prices.

Death is not the end. The Journey of your Soul will take you to the spirit realm whenever your physical body is no longer able to carry your soul. At which point you will need to make your way to one of many points of resurrection in order to get back to the physical realm. The penalty for dying alone is small. The spirit realm is not safe, though. Mystical creatures that you’ll run into on your way to the resurrection points will hunt you and be capable of draining the essence of your soul, thus reducing your abilities, both stats and skills. But there will be ways to avoid them, and even ways to use the spirit realm to your advantage.

There are so many aspects to this game that I just can’t cover in a single post. This is already become one heck of a wall of text, as it is. I really do want to create a world that will truly be alive. Something that people can join and be apart of something special. It’s not going to happen overnight, but I will bring it to light someday, and we’re already starting to make progress. Any ideas and help you guys can offer will be greatly appreciated, and hopefully you will all enjoy playing the game at some point in the future.

[01:11] Jeremy Privett: Oh, and we’re coming up on 9:09:09 9/9/09.
[01:11] Dutch Buckholz: yes, yes we are
[01:11] Jeremy Privett: It was nice knowing you.
[01:11] Dutch Buckholz: nah – that’s 2012, everybody knows that
[01:12] Jeremy Privett: lol
[01:12] Dutch Buckholz: today is just a day without LOLcats

Either way, make some attempt to enjoy the day. I mean, you’re only ever going to see 9:09:09 9/9/09 once in your lifetime, after all. Well, twice if you count the PM version.

I actually scheduled this blog entry to post exactly at 9:09:09 9/9/09. In some timezone. I don’t remember which one it’s set to.