Archive

Archive for August, 2010

Room Restoration

August 30, 2010 Leave a comment

This weekend I spent time working on finishing up the environment restoration. Yeah I know, it’s still not done. I ran into an issue with re-linking Rooms that’s forced me to re-think and re-implement the how Rooms are restored. When a Room is loaded it will create it’s doors and link them to the required Rooms. However, if the Room is not loaded yet, the Door loads it on its own. Then the Zone goes on and keeps loading the rest of it’s Rooms.

As a example, what happens when Bedroom has a Door linking to Hallway? The door will load the hallway. When Bedroom is finished the zone loads the next Room which will eventually be the Hallway. So now I have two Rooms loaded in memory and independent of each other which isn’t a good thing. Bedroom within the Zone will be different then Bedroom connected to the Hallway.

Because of this I will instead, load all of the rooms and ignore the Doors, once every Room is loaded the engine will perform the linking.
This isn’t the best approach in my opinion but it works for the moment. Hopefully I can wrap it up by Friday & spend the weekend tightening things up and release on Sunday.

Wrapping up Environments

August 23, 2010 Leave a comment

I spent this morning thinking about the progress of the Mud Designer and decided to put character leveling on hold.

The engine is wrote very well I think in terms of modularity, allowing objects to work independently of each other. I’ve been meaning to button up the environment objects but it’s been getting shoved to the side due to it being more like tweaking and fixing and not as gratifying as adding whole new components to the engine.

I’ll spend the next week working completely on environment objects, tidying things up, making sure Rooms can be traversed across Realms & Zones along with deciding how I want to handle game object placement within the world.
The benefit to wrapping up environments is being able to build on the rest of the engine and using a finished component that I know will work as intended while building other major components that might rely on it. It will also provide a finished component for testing a GUI editor design with.

What’s left to do with the environment? Not very much, mostly finishing up the create command, provide search methods to Realms & Zones for seeking content that they hold such as search a Realm for a Zone or search a Zone for a Room. I also need to button up the movement code in characters (which I consider part of environment) to support locked doors and provide some sort of verification for environment existence.
The GameWorld needs to suport adding Rooms via the AddObject method as well, replacing the Zone.AddRoom() method.

There’s quiet a few minor things like the ones mentioned that need completed before I move on to the next major component of the engine. I want to make sure each major component is polished prior to working seriously on another one.

Character Stats & Leveling

August 22, 2010 Leave a comment

After releasing the latest build of the Mud Designer I began doing some research online on how character stats and leveling is handled in various MUD’s and RPG’s. I found that there is a wide range of different systems available out there and I decided I’d look into implementing one at a time.

At the moment the Character Stats is seperated from the Character itself, which was done to allow for custom stat and leveling systems to be wrote and assigned to the Character. The Character Stat class is called BaseStat, and a developer can inherit from it like such:

public class SkillBasedStats : BaseStats
{
}

Now they can implement what ever stats they want to, and assign it the their player like this.

  public BaseCharacter(Game game) : base(Game)
  {
       this.BaseStats = new SkillBasedStats();
  }

Basically developers will re-reference the characters stats property to use theirs instead. This is something that the Game class is currently doing with BaseCharacter, allowing developers to re-reference the PlayerCollection property within Game to reference their custom player scripted class instead.

I think what I will do is implement basic content such as player Health and Level into the BaseStats class, and then I will write several different Scripts that will inherit from it, each implementing stats in a different and unique way. This provides developers with a solid collection of different leveling and stat systems they can use for their games, and if one doesn’t fit their needs, they can extend off an existing one and modify it, or just write one themselves.The goal of the engine is to be modular and easily extended on, and this approach will fit right in with that goal.

Looking at what I have planned for the next release of the engine, I doubt that I’ll have the changes made and ready in time for a weekly release next Sunday. I probably won’t get started on writing any new code until Tuesday, as I need to spend time updating the websites documentation to reflect the changes made with the release of Alpha 1.3

Mud Designer Game Engine Alpha 1.3 Released

August 22, 2010 2 comments

This release of the Mud Designer Game Engine includes a large amount of bug fixes and optimizations, along with several new features.

The largest change is the introduction of the Script Library. A collection of scripts pre-wrote for developers to review. Most of the scripts are in-game command scripts, but it will give the developers a better understanding on how they can write content for their game.
Also included is the new GameTime class, that now keeps track of the game-world time, allowing for a true persistent game world. Entering the command ‘SaveWorld’ will save the world to disk, and when the server re-starts, the saved content is re-loaded, letting the world resume right were it had left off.

Several new commands are included with this release, the two most important commands being the ‘Create’ command and the ‘LinkRoom’ command. These two commands allow Admins to connect to the server and create Realms, Zones and Rooms dynamically on the fly while players are still connected and playing. Note that these two commands are still under construction and probably contain several bugs. The LinkRoom command does not always correctly link Rooms together and will be addressed in a future update. The goal was to demonstrate to developers how to build complex scripts for their games. Both of these commands are a part of the new Script Library. This library will increase in-size with each release as I try to code the bulk of the game object code in script to allow for easy access and editing by developers.

Help commands are now supported as well, allowing users to type ‘help’ and recieve a list of all available commands (both internal commands and script based). The user can type ‘help commandname’ it the help documentation for that command will be printed to the screen for the user to read. (Example: Help Walk).

This release also includes the Mud Compiler for compiling your scripts to check for errors without having to start/stop the game each time. Included with this release for the first time is the complete source code to the project. I wanted to provide it in a complete package, so developers did not have to download the source separately any longer.

Several optimizations and bug fixes are included with this release. Hope you enjoy it! As always feedback is critical in order to remove bugs and better build a solid product.

Remaining Changes

  1. Added a GameTime class. Now fully supports custom Day/Time lengths and keeps track of time in sync with the server time. You may use the new command GetTime to have the current in-game time printed to the player.
  2. The Game class now contains a property called MinimumPasswordLength that lets developers assign how long of a password they will require users to make during account creation.
  3. Fixed the ScriptEngine and CommandEngine not loading Custom game commands from scripts.
  4. BaseCharacter’s Create, Initialize, Send and FlushConsole are now overridable via scripts.
  5. Invalid commands are now printed to the player "Invalid Command."
  6. Script Engine now compiles scripts as C# 4.0 Types instead of 3.5. Scripts can now use Dynamic Type
  7. All commands are now required to have a Help property
  8. Set the Game.PlayerCollection property to Protected. You can no longer modify this list unless the class inherits from Game. Only 1 script is allowed to inherit from Game.
  9. Created Game.GetPlayerCollection() method for retrieving a read-only reference to the playerCollection so scripts can access player data it might needs.
  10. GameWorld.AddRealm() method replaced with GameWorld.AddObject(). It accepts any Type passed to it. You can now supply a Zone to it (provided the Zone.Realm property is set first) and the method will add the Zone into the appropriate Realm for you.
  11. System.Linq and System.Text using statements added to scripts when they are compiled. Script writers no longer need to type out the fully qualified name for those namespaces.

Real-time world construction

August 19, 2010 2 comments

I started work last weekend on a new “Create” command. With this you will be able to construct your entire game world as a connected Admin rather than having to code it all via scripts. At the moment admins can enter the Create command and a list of options become available. The ability to create Realms, Zones or Rooms. The admin can then select a Zone (for example), and it will list all of the currently existing Realms the user can place the zone within. Once the admin enters the Realm name, the Zone name can be entered and it is then created and stored within the admins selected Realm, in real-time, making it instantly available for players to traverse into. Over the next week I will finish up the command by allowing Room creation and linking along with some editing features (possibly via a Edit command).

The in-game time class has prooved to be a challenge as it’s not going to smoothly. I was really wanting it fully completed before Alpha 1.2 gets released but it’s up in the air at the moment. I don’t believe it to be critical for me to get it fully implemented immediately as nothing within the engine relies on it as of yet.
What’s the GameTime class do that’s making it difficult? The In-game time allows admins to specify how many seconds are in a minute, minutes per hour, hours per day, days per week, weeks per month and months per year. The in-game time also let’s developers specify what name each day/month has, as an example it’s possible to have 4 days a week, 34 weeks a month and 16 months a year in-game. The issue I’m having how ever is syncing the game time with server time. Meaning every-time the server’s alive time (in real-world time) is incremented the game time needs to. If 2 real-world seconds pass since the last game loop for some reason, the in-game time needs to advance by 2-seconds. Why is this critical? Some people might have time sensitive things happening in-game and use real-world time to judge how long it might take. What about character aging? Item life spans? In-game quest timers? All of these things will depend on having a synced time between the server and client, so users can better judge how much time in-game it might take to complete something and can keep track of it while afk using real-world time. Granted those using custom time frames (such as 15 seconds = 1 minute) will have to provide their users with a conversion document, but for the games that keep to the standard time frame (even with custom days), the player will be able to better keep track of in-game time.
At the moment the in-game time increments seconds up until it needs to increment the game time by 1-minute, at which point the game-time minutes begin acting as if they are seconds. It shouldn’t be difficult to fix, but I just haven’t really sat down and crunched it out. The GameTime has not been a fun class to write really, but I’ll make it a point to debug and fix it today.

I’m Hoping to get Alpha 1.2 out this weekend, I’ve liked having a weekly release put out as it makes the project look alive (which it is), and provides motivation for pumping out changes quickly. Alpha 1.2 won’t be a large update to Alpha 1.1, but it will include the beginning of a library of scripts I’m writing for developers to use, extend, customize and learn from.

C# Programming #2: Type Overview

August 10, 2010 Leave a comment

The C# programming language is a strongly-typed language. Meaning that every variable, every class, every constant is a Type, including any expression that evaluates into a value. Every method in C# uses Types as return values, and method parameters supplied are Types.

The .NET Framework library includes hundreds of classes that represent a wide variety of simple and complex Types. Wait, a class represents a Type? What’s that mean? Well, a class encapsulates your source code, it contains all the code that makes your Type work. Think of it in this light, a class is the blueprint, a Type is the finish product.

You probably know that most software is compiled into 1’s and 0’s right? Well Microsoft has done something interesting, they’ve create an intermediary of sorts. While your programming language of choice might be C# or Visual Basic.NET, there is yet one more language included in the .NET Framework and that’s the Common Intermediate Language (or CIL for short).
CIL is not 1’s and 0’s, but rather byte code. It’s still humanly readable, (albeit not easily understandable), and is what is eventually compiled into 1’s and 0’s. At first this seems like an extra step, but I’m going to explain why it’s done this way.
So, you’re language of choice is C#? You compile your application and it gets compiled into CIL code. What if your friend makes an add-on for your application, but he wrote it in VB? His add-on will still be compatible with your C# application due to the fact that his VB source code will be compiled into CIL as well. Once the C# and the VB codes are in CIL, they are considered equal, they are the same language. Even though your .exe file is sitting there looking at you, it’s not really in 1’s and 0’s for the computer to read, it’s in CIL. When you start your application, the .NET Framework immediately compiles the CIL code into 1’s and 0’s, so that your application runs as a Native app.

What’s this have to do with Types? Well, like I mentioned before, a class contains all your source code, it acts as a blueprint. When you compile your source code into CIL, the class becomes a compiled Type. A finished product. What’s this mean for you? It means that your finished product, your Type, can now be used within your software or anyone else’s software. What if you are writing your application, and you write a class, and you need to use your class for your application, does it need to be compiled separately from your program in order to be used? Not at all! For an example, lets assume we have a class called Car and your program wants to use the Car to let people drive it. You have the class, but you don’t have a compiled Type yet, not only that, but the Car is part of your program and thus you can’t get access to the compiled Type right? You only have access to the class? (blueprint in source). Well that’s actually incorrect, as the C# compiler will see that your application needs to use the Car class, and will go ahead and compile it into a Type while it compiles the rest of your program, allowing your compiled program to use the Type internally.

Hopefully I did a decent job of describing the difference between Types and Classes, if not, feel free to drop a comment below. Just remember as we go through the remaining tutorials in this series, that when I mention class, it refers to your source code, and when I say Type, it refers to the actual finished object.

I will explain more on Types as I get into creating Properties, Fields and Methods.

Project Collaboration Fellowstream

August 9, 2010 3 comments

I saw a tweet by TorquePowered last week on a new Project Collaboration tool called Fellowstream and decided I’d take a look at it. After using it for a couple days I must say that my first impressions of it are pretty solid.

The site is in Beta and gives you a sub-domain that your team/company will use. Once you have your site setup, you create a project that’s associated with your Team and create some Milestones for that project. Milestones can be populated with Work Tickets and each Ticket can be assigned to a team member. When you are ready to start work on a Ticket you set it as your current Status and work on your Tickets activity. Once completed you mark the Ticket as complete.
Fellowstream let’s you build groups of users, like one for QA, one for Programmers etc. As you complete Tasks your projects progress is tracked and a progress bar on the projects home page shows how far along you are.

The real meat of Fellowstream however comes with their Stream feature. It works very much like Facebooks stream, were every action performed on the site, either editing an existing Ticket, Comments or deletions are placed in the Stream for all users to see. Project managers and team leaders can log in and quickly see what activities their team members have been up to.

The product is in Beta still, so it has a couple bugs and is lacking a few features that prevent it from being a complete tool, but it’s Beta and the Fellowstream team has been very responsive to my emails. They’re customer service is really impressive and I have a lot of faith that this product will be a stellar collaboration tool when it’s out of Beta.

Go check it out!