Nearing my first release

I worked quiet a bit on the Mud Designer over the weekend and managed to get the Realm Explorer, Zone Builder and Room Designer Built up. The Realm and Zone editors will be fleshed out some more and finalized over the course of the week, get everything working together and publish a preview release of the engine and it's toolkit hopefully this coming weekend.


- Posted from my iPhone

Free-To-Play games vs. Subscription

Jeff Strain gave his opinion on Free-To-Play games earlier this week, and while I was reading it, I could feel myself becoming a little perturbed. His argument is, '”Developers working on free-to-play projects are too preoccupied with in-game revenue opportunities and don’t have time to focus on making games fun.”

Well, I can agree to a certain point with him on that. There are a few games out there that I’ve played where the company is more concerned with making money off the store transactions than making new free content for the players, but there are also a lot of games out there that employ the modal and still look out for their user base. The game is free to play and thus needs to generate revenue in some form, so that is to be expected and should be acceptable to a degree, provided new content and still provided to users on a free level as well. Something that Jade Dynasty has done, or Perfect World. Both have released several expansion packs for free to their users with a large set of changes and new content.

So Strains statement is an invalid statement, especially when you look at World of Warcraft, a game that focuses on it’s free 'patches being aimed at helping the lower level players, because they complain about things and Blizzard doesn’t want to loose their business. How about their expansion packs? Those aren’t free, and it’s another way of pulling subscribers that have canceled their accounts, back into playing paying for their subscription again.

Both sides of the MMO world is the same, they are both trying to feed their pocket book, and have a right too, provided it doesn’t take their focus away from the users and giving them a good experience. Something that Perfect World games have always done.

I’m have no problem paying a subscription fee for playing a game, I limit myself $20 a month in microtransaction fees, so my rant isn’t because I don’t want to pay the monthly fee. I paid for warcraft for 5 months before i canceled it.

One last thing I’d like to point out is that microtransactions usually employ character customization options such as new outfits or hairstyles that aren’t available in the standard game, and I like this approach as it provides users with a way to be different from others playing the game. Everyone can find something they like and wear it and be different.

RIP Visual Designer

I had to delete both the Visual Designer and the Visual Components projects from the MUD Designer Solution tonight. I was tired of trying to manage two different sets of editors for the same project, and had to make a decision. Which would be the easiest to build, and let me get something to the community fastest? The current setup, as the Visual Designer was going to rather elaborate and take awhile to work on, although it would be less code in the end, and probably easier to maintain, it was going to take to long to implement all of the dynamic components of the engine.

The current setup is quickly getting someplace, as tonight I managed to get the Realm Explorer built, Zone Builder started and Room Designer stable. The Realm Explorer allows users to launch the Zone Builder to build rooms that they can place within Realms. The Zone Builder lets users launch the Room Designer and create Rooms for the Zones to hold.

At the moment, both the Zone Builder and Room Designer is accessible via the Mud Designer Main Window, but once I get the Realm and Zone Builder in a stable state, I will remove the Zone Builder and Room Designer from the Mud Designer window. Users will access them in a hierarchical fashion, starting by launching the Realm Explorer.

What happened to Indie development?

I remember a dozen years ago, Indie game developers where using game engines or rendering engines such as Ogre 3D, Irrlicht, Blitz 3D or building Mods for games such as Unreal, Quake, Starsiege Tribes or Half-Life. We didn’t really have complete engine kits available at the time like the Unreal Engine, Unity or Torque, heck most AAA game titles weren’t even made with an all-in-one development kit like we have available today.

I was really disappointed in Garage Games when they began charging $1,000 for their new flag ship engine Torque 3D, which while is impressive, is cutting out a huge portion of the Indie community. Remember when Torque Game Engine was just $100? Yes, Torque 3D is a lot more impressive looking and state of the art, but the Torque Game Engine was state of the art at it’s time. It had most of the major components featured in major AAA titles at the time, and it was still only $100.

Why does Garage Games move to charge a solid grand for their new engine bother me? Because they are taking away from the ‘Garage Gamers’ who might want to spend $100 on a game engine, but can’t afford  $1,000 on one. Indie game development has started to become a mainstream item, with a lot of potential for financial success in it. Indie gaming is no longer cost friendly for a vast majority of people who could have easily spent $100 on the engine.

Unity 3D and Epic’s Unreal Engine has now been released for free, and this is a solid move by both. While you can’t sell your game’s really without purchasing a license, I can guarantee you that 80% of the indie games released out there on the market, where not self published. They are sold on the Garage Games marketplace, Steam, Xbox Live ect. The publisher can easily pick up the tab on purchasing the commercial license to the engine in order to sell the product. Garage Games requires developers to buy the engine before building their games, while Unity and Epic allow developers to build their games before buying the license.

While I still prefer the Torque Toolsets, I favor the Epic and Unity pricing model, and applaud them. I’ve heard rumors that Garage Games might do the same, but come on now, these guys are the pioneers of Indie game development tools, they should be setting the standards, not competing with new standards set by major corps.

Clarifications & Concepts

I wanted to take a few minutes to clarify a couple things.
First, the Mud Designer is a complete IDE for developing Mud games. It's currently composed of several editors, such as the Room Designer and Project Manager. A new edition to the Mud Designer is a tool called the Visual Designer. This is a test editor, that will replace all of the currently existing editors if it goes right. What's different about it? It contains editors for every object, with a single designer. Instead of launching the Room Designer, and the Zone Explorer, you will have a single designer. The Visual Designer will replace every editor with a single editor that manages everything.

Now, I remember saying I didn't like this approach originally, as it creates a mess with the code. It's an even bigger mess when you start generating objects and building the editor dynamically during runtime. So why am I still pursuing this as a viable option for the Mud Designer? I've figured out a way to keep everything dynamic, and keep the code easy to maintain.

With that being said, what are some of the pros and cons between the current setup, and the future Visual Designer? Let's take a look at them individually.

The current setup is pretty static. Each editor was originally planed to be independent of each other, but that ended up not being the case as keeping things simple, required cross-editor interaction. Not a bad thing though, and the code to add it was small and easy to implement. The editors have a generic look, and if a new object is created within the engine, I will have to go build a new editor for it. That's not a big deal either, but I will have to go to every editor that will need interaction and add the support. Again, this is not to big of a deal, however what if 3rd party members want to add onto an existing editor? They will be required to modify the source. What if they want to create new assembly project and build custom objects that inherit from the standard engine classes in order to make managing Mud Designer updates easier. None of their code is overwrote. This isn't possible with the current setup and I don't think it ever will be due to how it was designed.

Enter the Visual Designer. This designer loads the engine and builds a list of all game objects. Those objects are displayed in a toolbox that users can have access too. The engine will have the plugin support implemented, allowing for developers to create their own libraries containing their own objects and having it loaded into the engine. The designer will then place all engine and plugin objects into the toolbox without any extra code needed for the 3rd party addons. This also removes the need for me to keep going back to the editors and adding the new objects to the editors manually. The Visual Designer handles it for me. If I create a new class called NPC, the designer adds it to itself automatically. I don't have to touch it.

How will I design the editors for each object? I've Created a base control called VisualContainer, and given the BaseObject class that as a Property called Control. Developers can build their own user control that inherits from VisualContainer, and the editor will automatically place the control in the designer. Developers can have access to the control by accessing the property
"Room.Control.Title = My Control"
This let's me focus on building editor controls for each object in a modular fashion, and the designer generates all of it's content during runtime.

It's a concept still being worked on, and mostly works, I just need to work out a few of the kinks before deciding this is acceptable, and removing the current set of editors from the solution.

- Posted from my iPhone

Still trying to tackle scripts

It's been 3 weeks or so now, and I have went back and forth on how I want scripts implemented into the MUD Designer. I spent last night trying to build a UI that would let me piece together the scripts with the script engines class builder tools, but now I think I'm going to do something different. Jus let users write their code. Breaking the scripts down into smaller pieces will probably make it harder to manage than jus having the entire script available. I will allow scripts to be wrote classless. Meaning users will write the code needed, and the script engine will wrap the code in a namespace and class during runtime. The whole point of he designer is to simplify MUD development, and removing the need to encapsulate your code in a class and namespace helps simplify the scripting aspect of it. If users want more control and freedom then can write their game with c# instead of using the editor, as the engine will support several compile styles. This just happens to be the style I'm going to choose for the designer.

- Posted from my iPhone

Plugin support

As I was working on adding scripting support to the Room Designer last night I began messing with loading content on the fly, and found that it was really simple. I liked how easily .NET has made loading .dll files into memory. I could do it with the Scripting Engine but it's not designed to load several assemblies into memory for plugin support. It's designed to hold a single script assembly. I fleshed it out and got a nice plugin feature implemented. It currently only works with the Room Designer, but that's just due to me testing it. Once I get it fleshed out all the way I will move it into the engine so that all editors can access the plugins if needed without re-writing the code for each editor.

I want to wait on moving the code into the engine until I figure out how I want plugins to be implemented. There are several ways I can do it, and I want to make sure the best way is selected. In the future it would be nice to build plugin support into the editors themselves so users can write editor plugins, extending the designers. It would be nice for users to create custom classes that add new functionality to the engine, then add that functionality into the editor with a custom plugin. Or perhaps build it all as a single item. A custom class and custom editor or extended editor, that the engine will jus load and use. The engine will load the class, the editor will load the custom editor plugin. All contained within the same plugin library.

Just some thoughts I'm floating around. Plugin support won't get any serious attention till later. As I'm wanting to focus on completing a few designers first, to get the editors useable and release a Preview release on codeplex.

- Posted from my iPhone

Visual Designer shelved

I spent last night getting doorways working in the Room Designer. I am much happier with how the progress is going using a seperate project for each editor. The Visual Designer concept was nice, but I spent two weeks messing with different GUI designs instead of coding. I decided to just shelve it for now and focus on building editors independently from each other.

Last night went well, I got installation and uninstallation of doors into rooms working, implemented plugin support into the room designer and began work on the design script editor. I'll touch on the plugin support and scripting in a different post, but it works pretty good at the moment.

All in all, the Room Designer is coming along smoothly. I'm hoping to have it finished by this weekend.

- Posted from my iPhone

Mud Designer Scripting & thoughts

I'm working hard at coming up with a way to implement scripting support into the Mud Designer. One of the problems you encounter with a visual approach to anything is constraint. All MUDs will act the same, and feel the same when created using a visual tool. Scripting breaks that issue, and provides MUD designers a way of expanding or changing the way things work within their game, a way to make it unique. The interface provides new comers and seasoned pro's a quick way to prototype and build a base game, and then build ontop of that via a script system.

I'm pretty sure the route I'm going to take is to give The BaseObject class a script Property. This way every object in the MUD can have a script attached to it. Doors, Rooms, Zones, individual items and even characters.
All scripts will have an OnCreate(), OnEnter(), OnExit(), OnDestroy() function. Additional functions will be added overtime as I think of them.
Each script object will inherit from BaseObject, and have all of those functions contained within BaseObject. Then users can create their own OnCreate() functions that get called and still use base.OnCreate() in order to have the stock OnCreate function executed. This is the best approach, as it allows users to piggy back the existing code, or omit the 'base' call and write their own.

Another thing I'm planning is to build a BaseCharacter class, all characters will inherit from that, regardless if it's a monster, player or NPC. The goal is to build Party Support, communication and fighting all within the BaseCharacter class. Monsters, NPC's and Players classes can be tweaked on how things are done, but still have the bulk of the code already contained within BaseCharacter.
It would be neat to have NPC's able to join the players party and fight, or have monsters fight in Party's, with supportive and offensive monsters working together. This can be achieved if they all share the same Party code found in BaseCharacter.

- Posted from my iPhone

Seeking an XNA Team.

I posted a new topic on the creators club today seeking developers to join a new team, and build an editor for creating 3D games using XNA. The editor will be the sole source of editing for 3rd party users using it, as they won’t ever need to develop in Microsofts Visual C# like XNA requires you to. Instead, we will implement Managed Scripting into it, and provide developers with a real time script setup allowing them to develop their games from within the editing environment.

So the UI is already being designed by myself, and as team members join, it will get tweaked as suggestions roll in. I’m currently setting up the scripting engine to run with it, and I’m going to take the Unreal Engine approach with it. I have a BaseObject class that all scripts will inherit from, and I think I will have a DrawableObject and GameObject class that inherits from it as well. Then developers can decide which object their script will inherit from. DrawableObject will inherit GameDrawableComponent and GameObject will inherit GameComponent from within XNA, allowing any script wrote to be initialized via the Component’s Initialize() methods.

Next I am going to work on Content importing. This is something I want included in the editor engine instead of the editor itself, so that any game using the engine can import content during runime if it wants to, allowing for custom 3rd party content such as avatars or skins to be added to their games without the developers of the game needing to ship the game editor with their product.

Shell Replacement thoughts

So after making a post about replacing my Vista shell with a custom shell, I stopped and thought a little more on it, and decided that it would be a nice challenge to try and attack. So I created myself a new project tonight and I’m going to mess around a little bit with it.

What goes into replacing a shell? A lot of things. I will need to recreate the start menu in some form, and I’m not sure how I want to do that just yet. The standard Vista start menu needs to go, and I’m thinking for something along the lines of how Mobile phones work. I really like the Expose for the iPhone, and might consider going with something along those lines. I wouldn’t exactly go the same route, as an icon based home screen would be cluttered for a desktop PC that can have 10 times the amount of apps an iPhone can carry. However, creating an icon based container with categories is a nice idea, as user’s can create categories or tags to store their applications within, much like how we manage our Music and Photo’s. Applications shouldn’t be any different, and it seems that no one has thought outside of the box, and realized that we have improved how we managed our media, but managing our installed applications hasn’t changed much since the 90’s.

So there’s one thought, what’s next? I need to be able to access currently running processes, allow users to change their windows settings and provide a better alternative to file management than the standard Windows Explorer. Much like Gnome 3, I want users to manage their files without having to browse the hard-drive all over the place. I like the Favorites links that Microsoft introduced in Vista’s Explorer file browser.

One of the important things I need to get built in right away is method to re-instate the original Explorer shell. If I can get the replacement shell far enough along to be simi useable, I will start using it in my day-to-day use, but just incase something goes badly wrong with it, I can at least get my Vista shell restored.

There’s quiet a bit of work that goes into a Shell replacement, accessing currently running services, task managers, settings, file management, working with user accounts, ensuring one user can’t access another users information, and lastly, trying to keep it as cross-platform as possible.

Enter Mono 2.4, the Linux and Mac OSX port of the Microsoft’s .NET Framework. If I can keep the Shell fairly modular, and keep it as Object Orientated as possible, then I can write OS specific pieces independent of the Shell, and allow me to easily get it ported from operating system to operating system. While Gnome and KDE is the primary IDE’s on Linux systems, there really isn’t anything out there just yet that grabs my fancy like Gnome 3, and Windows users don’t have anything close to it yet.

Juggling Three Projects

There’s one thing that I’ve learned while writing iRingtones, Managed Scripting and Mud Designer and that is maintaining three different projects is rather time consuming. I’m glad that they are all free and thus I’m not totally obligated to devote 100% of my time to maintain and improve on them, and considering that iRingtones has so far be the most popular project of mine by far, I’m beginning to re-think how I write my applications and what kind of projects I will take on in the future.

In what direction will the three projects I’m managing start driving towards? Well, iRingtones is pretty much going to remain as-is. There will be an update soon providing batch conversion, and if I can get the chance to look into MP3 conversions, I will try to allow MP3’s to be converted as well, instead of WAV files only.

Managed Scripting has a couple things that I need want to do with it, and that is Domain support, security policies and finish up the VB support. Once that is done I really won’t have a whole lot of work left to do on it besides just add additional functionality, which at the moment isn’t a huge rush considering the script engine has only been downloaded 15 times. There doesn’t seem to be much interest in it. Or I’m just not doing a very good job or spreading the word about its release. Considering all I used was Twitter and this blog to advertise iRingtone, and a couple website signatures being updated to include it, I got 170+ downloads in less than a week. Managed Scripting I actually went to various websites and posted a new topic showcasing it to people, and got less than %10 of the downloads iRingtones got. Simply put, the demand for a managed scripting engine isn’t as great as an iPhone ringtone conversion utility.

Where does this leave Mud Designer? I’m still wanting to build an IDE for MUD Development and the project isn’t going to be left out either. Once iRingtones and Managed Scripting have had the updates done to them I’m wanting to do, then Mud Designer will get it’s share of the lime light from me as well. I’m still messing with the WheelMud framework and thinking about implementing it into the IDE instead of building my own engine, but that is still up in the air. While the WheelMud author has been nice in answering posts of mine, I never really got an answer from him about me joining his team to build the IDE.

There’s a couple things taking shape over the horizon for me, one being the possibility of developing a game editing environment for someone advertising on the creators club site for a team to help build a game together. I’m also sick of looking at my Windows Vista Interface and I’m considering writing my own Shell implementation that follows along the same concepts that Gnome 3 has introduced.

For now, I’m off to play some MMO’s.

Mud Designer hang ups

More changes for the Mud Designer are planned, as the re-build continues. Change set 40304 introduced a new Project called Visual Designer that is a test project of mine. I get tired of the same Windows Look & Feel that all of the editors currently have, and I wanted something more disconnected from a standard windows application, and so enter Visual Designer.

Visual Designer makes heavy use of  the Managed Scripting engine I wrote and released. It uses it to instance objects and access their properties in a visual way. However the current design is just for testing purposes, it’s working out pretty nicely. I’m planning on the engine being script based, and having the IDE generate Hybrid Scripts that the script engines hybrid compiler will use. It will allow me to generate C# scripts that can be stored and loaded allowing for it’s objects to be edited once again.

One last note that I want to make is that I’m looking into using the WheelMud engine as the Designers engine source instead of developing my own. It appears to be a solid engine already miles ahead of something I would write, and seems pretty flexible.

Slow release

Managed Scripting has been out for three days now but has only been downloaded 10 times. That's a little dissapointing considering I spent a solid year learning and developing it. My iRingtones was downloaded nearly 100 times within it's first three days, and I did less promoting on it. Perhaps I should spend more time promoting my ringtone app rather than my script engine.


- Posted from my iPhone

Managed Scripting goes live!

Today marked the official release of Managed Scripting Beta 1, and with it comes support for source compiling, batch script compiling, runtime code generating, C# and Visual Basic language support along with the libraries needed to run it on both Windows and Linux PC’s.

Beta 1 was supposed to have XNA support but that will be included in a future update, as there where a few more kinks to work out of it, but for the most part that feature is functioning and should be released soon in an update. Go grab your copy and get yourself a script engine implemented into your project today!

del.icio.us Tags: C#,VB,Scripting,XNA,Managed Scripting

IRingtones 1.1 changes

I will begin working on v1.1of iRingtones later this week adding a batch conversion for converting multiple files at once, then I will be changing the iTunes library location to accept Library.XML file instead of the Music Library folder. I will also look into possibly converting mp3's into wav files for users that want to convert mp3's. I'm not sure I see the point of this yet, as users have to load the mp3 into an audio editing program to edit their mp3 and then re-export it as mp3. Exporting it as WAV doesn't add any additional steps to the process.

- Posted from my iPhone

IRingtones hits 100+ downloads

That number is more than what I was expecting when I initially put it out there on Codeplex. I'm also surprised that iRingtones has been mentioned in 4 different blog posts so far. Fairly good for me doing no advertising really, 100+ downloads and 4 blog mentions in 4 days.


- Posted from my iPhone

iRingtones is getting recognized!

Sandip over at blogsdna wrote a blog regarding the iRingtones app I uploaded to Codeplex this weekend. I’ve noticed between the tweets regarding it and now his blog, that my downloads have jumped. Pretty pleased with it. You can read his blog on the app HERE

Room Designer & Zone Builder thoughts

I've spent a good chunk of time thinking on a different way to develop the Room & Zone editors, and I think I've figured out the best method for it.

When you break the two editors down, it's actually fairly easy to come up with a design plan. The Room Editor is just that, a Room Editor. Build rooms and add the content needed to fill the room. Does it have doors? Add doors if needed. Building a room shouldn't consist of linking two rooms together. That's what the Zone Editor should do, as it is a collection of linked rooms.

I've decided that the Room editor will let users add doorways for specific directions, then let the zone editor connect the doorways to other rooms.
With this approach I can now adjust my Room Editor UI to allow for tabbed editing, letting users create multiple rooms at once, similar to how Visual Studio works.

The Zone Editor will allow you to link rooms together by connecting them the each rooms available doorway.


- Posted from my iPhone

Mobile Signatures

I'm not sure what other peoples takes on the topic is, but I like attaching a signature with the content I send/post from my iPhone. A lot of the apps you download automatically attach a signature for you, although I tend to edit the signature to remove any app references from it unless I really like that app. I try to keep a generic Sent from my iPhone signature.

Why do it though? A lot of us have socialized our lives via outputs such as Facebook and Twitter, everyone knows what everyone else is doing, where they're at and now they can know what app they're using to do their socializing. I don't really see it as a bad thing, as I use signatures on all of my out going mail, blogs and other methods of communication that supports it, such as auto-reply features of an MSN client. Message from iPhone. I'm AFK and will reply shortly.

Brings me back to my question. Why should I do it? Personally, people are accustomed to instant communication or fast responses. Attaching a signature to an email showing I'm on my phone is a way of showing the mail recipient my response will/can be delayed due to me being mobile. An indication I'm not at my desk and probably busy. It's another form of AFK that I can use. There's other reasons I use it too, and I'll use my blog as an example. Typing lengthy blog post can be difficult on a mobile platform. No spell checking. No grammer checking. No URL checking. Attaching a mobile signature to the post will inform people that hey I was mobile so it's goin to have typos

Do I like using signatures? Yes. Is it a good idea to? I'll leave that up to each individual to decide.

- Posted from my iPhone

iRingtones

I’m pretty happy with iRingtones, it got a whole 9 downloads this weekend! While that’s not a large number, it’s still better than what I was expecting. I need to look into spreading the word more about the release of it. A free iPhone ringtone converter! More people need to know about it so they’re not wasting money buying applications to do it when they don’t really need to.

http://iringtones.codeplex.com/

Re-thinking the Room Designer

In my quest to keep things simple, I’m beginning to wonder if I am taking to correct approach with the Room Designer. Currently it’s UI is designed to allow for dragging and dropping existing rooms onto the current rooms doors, allowing them to be instantly linked together. That feature works out pretty nicely, but now I’ll have to include a list of all the realms, zones and rooms within the room designer. It’s not that big of a deal to add, it would really just take a couple minutes to implement, but I was trying to keep objects created with each editor separate from other objects unless they are parent of another object. An example would be that the Room designer can’t touch anything related to Zones, but Zones can display and load various details about the Rooms it contains. With how the room UI is designed at the moment it means the Room editor will need to interact with the Zones and Realms.

Should I just build a Room Designer, then allow the Zone edit to link rooms together? Or let the Room Designer handle it… I’m not to sure yet.

iRingtones goes live

I went ahead and opened sourced the iPhone ringtones project I had been working on for awhile. It’s been posted on CodePlex and can be seen HERE

del.icio.us Tags: iRingtones,iPhone,Codeplex

Currency Editor & additional changes

Well I actually got the Currency editor up and running rather quickly tonight. Since Currencies are a rather minor element to a game, I decided to just rely completely on a PropertyGrid to get the job done, and it worked out pretty well.

Once the Currency Editor was completed I went back and began doing some cleaning up. When I was working on the HUB I had it searching the Project Managers directory instead of every directory within the solution for .exe files that could be editor applications. At the time I only had the 1 editor (Project Manager) and so I really didn’t worry about it. I spent about 30 minutes tonight revising the code and getting it working properly and I’m pretty pleased with it. I also added some exception handling tonight to the HUB incase it tries to start an editor app that does not exist for some reason.

I moved the Environments namespace into an Objects namespace so now it reads as Objects.Environments. I also created a BaseObject class that will contain basic information that all objects in the game will share, such as a Name & Description. I then changed the Realm, Zone and Room classes to inherit from BaseObject.

With the Currency Editor already completed, I think I will spend some time tomorrow if I can working on the Realm Builder. I need to take the time and think out how it needs to look visually, as it’s not going to be a very detailed editor. Realms are simply put, a container that holds Zones for organizing purposes only, so nothing fancy will be needed.

So far so good, the Mud Designer is really coming along pretty well.

del.icio.us Tags: Mud Designer,MUD,C#,Codeplex,Game Engine

File Type Backend, Project Site & Updates

I’ve had a busy night tonight working on the Mud Designer, and I’m not quiet sure where to start. I think I’ll start with the projects new site over at CodePlex. It’s been setup and is running pretty nice. I got the home page configured, setup the Discussions and Documentation tabs and finally created a 'Help Wanted’ ad, which it must be a new feature to CodePlex as I don’t remember it having that back when I was working on the Mud Creator. I requested help with the Networking side of the designer along with assistance in writing the documentation for the project. I also noted under the Documentation the requirements needed for downloading the source and compiling it.

Next up is the File Type Backend, which is a pretty clever idea that I ran across while browsing the web tonight. The engine contains an XmlSerialization class that saved and loaded all of the designers files to XML. Nice right? What happens though, if I wanted to offer SQL support? How about adding support for a scripting language? Saving and Loading of the files will need to be changed, and it will need to be changed across every editor within the designer. That would be a pretty big pain to mess with, and as I’ve mentioned several times already, I’m wanting to keep the code for the designer and its editors simple and clean. So how do I fix this situation? I created a backend class called FileSystem. The editors now call Save and Load from the FileSystem class at which point the FileSystem checks to see what File Type the project is using, XML, SQL ect., and calls the class necessary for saving it in that file type. For now I only have support for XML serialization, but if I offer SQL the editors wont know any different. They’ll continue to call FileSystem.Save() and the FileSystem class will handle switching between XmlSerialization.Save and SQLData.Save. One location to make the adjustments and that' saves a lot of headache.

I’ve done a lot of work to the Project Manager and the MUD Engine and it’s starting to make some headway. One of the most notable changes would be the finishing of the Project Manager and changing the Zone class to inherit from Realm and Rooms to now inherit from Zones. This allows me to create default properties such as Name and Description within the Realm class, and all Zones and Rooms will have the same property. No re-duplicate coding required.

What’s next, I guess I can begin working on the currency editor, and better refining how the engine will handle the currency.

del.icio.us Tags: Mud Designer,Codeplex,C#

Realm & Zone thoughts

Realms won't be to hard to program really as they're just acting as a container for Zones. A way of breaking up Zones into groups and make it easier to find a Zone when your project contains thousands of them. Realms will have a few Properties but not many, I think they'll only need a Name & Description Property, along with a List to hold a collection of Zones.

Zones won't really be much more difficult than the Realms, they will need to hold a large number of Rooms, and have some default settings that can be used on all rooms when first created. Things such as Always Dark, Always Light, Cycle Day/Night, Default Smell/See/Hear/Feel descriptions, a SafetyZone option that can ensure the player is never attacked by monsters and a collection of NPCs and Monsters that can roam the Zone.

I'm still debating on the NPC collection, I'm wondering if that should be something setup within the NPC editor instead of assign the NPC to the Zone, this way one NPC isn't placed in multiple Zones by mistake. Monsters is acceptable because users can fight the same monster across multiple Zones, but typically you won't see the same NPC in multiple Zones. While assigning an NPC to a Zone during NPC creation prevents duplicate placement within the world, it will require the engine to scan every NPC in the game during startup to place the NPC as needed. It would be faster to just load the NPC list from the Zone, and load only the NPCs needed. Leaving it to the developers responsibility to ensure duplicate NPCs aren't placed in their world, so in the end i'll probably end up having the Zone editor add NPCs to the environment.
Now that Im thinking about it, there could be thousands of NPCs in a game, I'll need to work on either a search feature or a grouping feature to reduce the amount of time spent searching through NPCs

-- Posted from my iPhone

Setting changes doesn't need code!

This was something I failed to mention in my previous blog, and that is the nice fact that PropertyGrids allow the editors to change properties and not need any code to do it. When I was using text boxes in the I i initial source code upload I had to write code to handle the text being changed and update the classes property. Using a PropertyGrid removed the need to write code updating class properties. It's handled by the Grid for me. This means a simpler approach and less code. Easier to maintain.


-- Posted from my iPhone

Thoughts on Scripts & design conepts

I've been putting a lot of thought into the idea of using my Managed Scripting engine with the Mud Designer. It would be a nice feature to have so MUD developers can extend on the engine, but I'm starting to not see the point in it. It's open source. Developers have unrestricted access to the toolkit source and so thus don't really need a scripting engine.
Another reason i think I will avoid it is due to the added level of complexity with coding the designer. The whole point of the re-write is to build the designer and the engine using clean simple code that can be easily read and modified when needed. Generating code during runtime within the editors for script engine compiling would create a mess internally.

I'm quiet pleased with the progress I made last night. The Project Manager started out with one design and ended the night with a different approach. The initial decision was to use text boxes for all of the project settings, but I was worried that would clutter the UI up and make it harder to add additional features in the future without re-organizing the UI to fit new things in. I decided instead to use a PropertyGrid control, which allows me to freely add or remove project setting options from within the Project Information class and not have to touch the UI to add the new feature. This was a feature used heavily in the Mud Creator, however I'm trying to avoid having the editors rely only on PropertyGrids. This time around the Grids will be used to help keep things clean, but will not be the only method used to create game content. Using it as an aid for various options rather than relying on it for everything is nice, as now I can build editors to generate game content in an easier manor than propertygrids allowed.
I'm going to spend this afternoon doing some thinking on how I want the Realms, Zones and Rooms to be designed internally and how they will interact with eachother so I can better plan my UI designs when I'm ready.


-- Posted from my iPhone

A night of coding

Spent a good chunk of tonight working on the re-design of the Mud Creator, and decided I am going to re-name the toolkit while I’m at it. It’s now called the Mud Designer, and I have created the Editor HUB and began work on the Project Manager. The Project Manager saves the project settings when the editor is closed, and loads them when the app is launched.

All of the apps are being wrote to be independent of each other, with a lot of care being taken with the HUB so that it is not a required component to run the other editors. Each editor can be launched on its own without any adverse effects on the project, since they are all kept separate from each other.

This time around I am focusing on reducing the amount of code needed to run the editors. Searching for ways to re-use code, so I can prevent a lot of re-work. The Mud Creator was riddled with duplicate code all over the place and it was clear that the project was a mess when I opened the designer and began scanning over 3,000 lines of code. I’m hoping with splitting the project up into multiple independent editors like I am, the source files will remain fairly small and light which will make it easier to maintain and update.

I also managed to get the project uploaded to a new CodePlex site tonight. It can be viewed HERE.

The source code for the project has been uploaded to the Codeplex SVN and since I uploaded it tonight I’ve commited 2 additional versions of it with modifications and bug fixes. I’m hoping to spend this weekend fleshing out the project manager and get the currency editor up and running, then it’s off to next week and the development of the Realm Builder, Zone Editor and Room Designer, all of which will take a few weeks to complete and will require some thought on how I want to build the UI for these apps.

del.icio.us Tags: Mud Creator,Mud,Mud Designer,C#,Codeplex

The MUD Tool Kit HOME app

The MUD Creator tool kit is going to feature a HOME application that can be launched. It will allow users to create a list of tasks that they need to complete with their MUDs and provide them with a proper workflow for how to build their MUDs. I will list all of the editors in the order that I feel would work best for creating your game, starting out at editor #1 and ending at edtor #14 and having the game ready to go.
The HOME won't offer any project specific options that can be edited, and won't tie into any of the tool kits tools so developers won't worry about an update to an editor breaking the HOME or a custom Room editor being used and breaking the work flow.
The task list will let developers create a list of tasks such as "Force the Elven Paladins to only start out in the Bekang Realm". It can serve as notes and reminders for the developer to make adjustments and changes. A possible log system might be put in place as well to monitor changes made to game objects and make note of the changes, developers can then scan the log and pull out what Ganges it would like to include in his/her release notes when they release a new version of their MUD.



-- Posted from my iPhone

Mud Creator Re-design. Revisited.

I have had several problems with getting the Mud Creator to commit to CodePlex's SVN over the last two weeks. It keeps erroring out and giving me a headache. It had been working fine for the last year or so, something happened that screwed up my repository and now I can't get it fixed. With that being said, it looks like a good time to sit back and re-look at how I want to design the engines tool kit. The re-design was already underway when this error occured, but I hadent really put much thought into it. I was flying blind. Today however, I took the time to sit down and right up how I felt the tool kit should be laid out.
I'm going to design the tool kit split into seperate programs. One program for designing rooms, another for creating skills ect.
I'll develop an application that will act as a HUB, displaying all of the editors that can be launched. I've jus spent about 30 minutes on the editor list and in what order they'll be laid out and came up with a decent list I think
1: Project Manager
2: Currency Editor
3: Race Builder
4: Class Editor
5: Realm Editor
6: Zone Builder
7: Room Designer
8: Equipment Builder
9: Item Designer
10: Skil Designer
11: Book Editor
12: NPC Manager
13: Quest Builder
14: Monster Creator

That's my basic list of editors for the moment, with the names and order of work-flow still pending. Most of the editors are self explaining as to what they're for, but I thought I'd clarify what the Zone and Realm editors will do.
A Realm can hold an unlimited number of Zones. Zones can hold an unlimited number of Rooms. Since rooms are what players traverse, you can think of them as a physical room. A zone could be a single house, a city street, an entire city/kingdom, a complete forest or what ever you want. A zone is how you will setup borders for the player. The player can easily find out what Zone they are in, and these can be used to inform the player as they move from city to city or something along those lines.
A Realm can be used how ever developers would like to use them, but the original intent was that they would act as a country or continent that contained several kingdoms/cities (Zones) that the player explored. This way a Race can be tied to starting out in a specific Realm, and each class for that race can have a seperate starting zone for the realm their race is tied to. Traveling outside of the realm into another realm can be done if the MUD developers allow it.
I'm planning on giving a brief overview of each editor over the next couple of weeks as I begin fleshing out the new design.

-- Posted from my iPhone