Scionwests Blogging

Changing Blogging accounts

noreply@blogger.com (Johnathon) — Thu, 14 Jan 2010 05:35:00 +0000

I’ve used Blogspot for the last year or so and I have recently decided to move over to Wordpress. There are several advantages to moving to Wordpress for me, one of them being having a better blog editor on my iPhone so that I can blog from my phone while I’m on the go. I’m wanting to start blogging on topics other than the Mud Designer, things such as mobile technologies, gaming news and various other tech information.

The new blog can be found HERE, I encourage those of you who subscribe to this blog to change your RSS Link to that of my new one as this one will no longer be posted to.

One GUI to rule them all…

noreply@blogger.com (Johnathon) — Sun, 10 Jan 2010 01:41:00 +0000

It was just under a week ago that I discovered how to attach a custom control to a Class Property and allow the control to be shown when using the PropertyGrid via UITypeEditors.

It’s been quiet a week for the Mud Designer. I created a test editor so that I could mess around with using the UITypeEditor, and I found that it was actually really easy to implement. The more I worked on the test editor, the more I liked it. The current layout of the editor I have never really liked. It was really easy to maintain due to the code being segregated into multiple editors, but it made it difficult trying to get all of the editable Properties of each object into the editor. There wasn’t enough screen space to fit it all, so I started adding tab controls and really cluttering up the UI quiet a bit. I didn’t like it, as it made understanding the flow of the editors difficult.

The test designer had a simple work flow. Menu driven, and easy to understand what’s going on. The UI was designed much like Visual Studio, with a project explorer and object property editor off to the side of the GUI, and a large open workspace for a future designer that I would like to implement. Objects are created via the menustrip, and once created and saved, are displayed in the Project Explorer, where right-clicking on the object displays a couple of options including Editing it and Deleting it.

Realms and Zones can now be created truly independently of each other. Zones are stored in their own ‘Zones’ directory, and when a Realm is loaded and being edited, the user can select ‘Zones’ on the Realms Properties and it will open up a custom TypeEditor allowing users to move zones out from being within the independent ‘Zones’ directory and move the files and contents of the Zone into the Realm’s directory ‘Realm Name/Zones/Zone Name’. Users can create Zones and add their Rooms to it, without having to place it in a Realm if they don’t want to.

While the Test editor can’t create or link Rooms yet, it does several things that the current set of editors can’t do.

Build Zones outside of a Realm
Move Zones in and out of a Realm
All Objects are now accessible at anytime, from within the same GUI.
Objects are now Auto-Saved anytime a change is made to it.
Object Management has been greatly simplified

I spent all day working on the creation, saving, loading and linking of Realms/Zones and was surprised at how fluidly everything worked together. There are several areas that I want to re-visit and refractor, but that will happen at a later date.

With the progress I’ve made over the last week, I’ve decided that the Test Designer will become the Mud Designer, and all of the current editors will be removed from the project. The latest SVN commit at Codeplex no longer contains the previous editor tools, and only contains the new Mud Designer. I’m hoping I can get the Room creation setup tonight, and the Zone/Room and Room/Room linking put together by the end of tomorrow.

Once all of the Environments are able to link to each other and work correctly, I will work on the visualizer, which is going to be a visual display showing all of the Realms in the project. Users can select a Realm in the visualizer and the visualizer clears out to show all of the Zones contained within the Realm, along with showing the user what Zones are linked to it. Selecting a Zone will reveal the ‘Zone Entrance’ room, and all of it’s doors, letting users click a door and travel through the zone door to door.

The visualizer is a planned concept, but has taken a back seat for the moment while I work on linking the environment objects together. I also need to take a look at some of my existing code, and do some clean up on it. Refractor some code from the designer into the engine classes and work on building a few helper methods within the engine to help simplify the actions that the designer needs to do.

del.icio.us Tags: Mud,Game engine,Mud Engine,C#

UITypeEditor implementation

noreply@blogger.com (Johnathon) — Mon, 04 Jan 2010 04:15:00 +0000

As I continued to develop on the Designer tonight, I thought I’d re-visit an area of UI development that has always been difficult for me to grasp. The UITypeEditor and implementing custom editors for custom Types that the PropertyGrid can use. I thought about it tonight and began working on building a custom Script Editor to test out editing scripts inline from within the PropertyGrid with a custom editor. It had been over a year since I had visited this approach and I had learned a lot regarding C# over the course of the year and I was actually pretty surprised at how easily I was able to put together a custom UI editor for the propertygrid.

This opens up a whole new can of worms for me and my approach to designing the UI for the designer. Most of the UI was designed due to custom objects that couldn’t be edited from within the standard PropertyGrid due to it containing custom Types. I couldn’t edit a Rooms Doors from within the PropertyGrid as the Doors where a custom Type. The PropertyGrid couldn’t do it for me, that is until now, with my understanding how to implement a custom TypeEditor.

What’s this mean for the designer? It means I’m going to look at re-designing the editors to support it. I might be able to finally merge all of my editors into a single editor like I wanted to from the beginning. It also allows me to look into dynamically generating the GUI content as I can store the TypeEditors within the Engine itself. So that as I make changes to the engine classes, those reflections can be made immediately within the designer, just make a couple adjustments to the TypeEditors within the engine and the designer will reflect those changes.

It also opens up an easier avenue for developers to write plug-in support, and extend off existing classes with their own. They can build a TypeEditor and have instant access from within the designer to their custom Types, without having to modify the original source code.

I see quiet a bit of testing and exploring over the next couple of weeks while I take a look at this, there is some serious potential here.

A New Year

noreply@blogger.com (Johnathon) — Sun, 03 Jan 2010 21:57:00 +0000

Now that the holiday season is over I can spend more time focusing on developing on the Mud Designer, as I know that I’ve been slacking on it over the last two months. There are several things that I am wanting to work on over the next couple of months and I’ve started working on them today.

I setup a forum online so that people using the toolkit can communicate with each other and I can hopefully get some feedback from those using it. I can see that the source code is being downloaded and so I know there’s people checking it out, but I haven’t heard from anyone on it yet. I’m hoping this fixes that issue. It can be accessed HERE

Next I want to finish up the Zone builder, and flesh out the Room designer some. Button it all up to make it work good and get some documentation wrote on it. Once that’s done I’ll work on building an offline runtime for users to play test their mud environments, and then start working on a preview release that I can upload to the codeplex site.

There’s a lot of things I have planned over the next couple of months and I’m hoping that I can get them implemented and some feedback from the users using the software via the website.

Mud Designer Script Considerations

noreply@blogger.com (Johnathon) — Sun, 20 Dec 2009 21:29:00 +0000

I spent all night last night messing around with the Unity3D game engine and I have to say I really like how they handle scripted objects in their engine. You place an object in the world, and then attach existing scripts to it. This is a nice concept, as it lets you re-use a script file over and over for several other objects.

Currently the Mud Designer allows each object to have a single script, and the script is owned by that object and not shared by any other objects in the game. After messing with the Unity engine’s scripting setup, I'm currently thinking about changing how the engine handles scripts. I’m considering a script repository that the Designer holds, and developers can drag and drop the scripts onto objects within the game. I’m not quiet sure how I want to go about implementing this concept, as it works great with a single IDE interface, that allows drag and dropping from object to object, but the Designer is broken up into several editors and thus making it a little more difficult to achieve.

Concord3D

noreply@blogger.com (Johnathon) — Thu, 17 Dec 2009 22:55:00 +0000

I finally ran into a fellow developer on the Creators Club site that had interest in starting a 3D Engine project with me. While I have been fairly busy lately and unable to spend much time working on the Mud Designer or any other projects, I’ve managed to get things straightened up and release some free time to work on a couple projects. Hopefully development on both projects can progress smoothly.

Serious Design Flaws

noreply@blogger.com (Johnathon) — Mon, 07 Dec 2009 22:41:00 +0000

As I began working on linking rooms together with the Zone Builder I ran into several issues with the design of the toolkit. Serious design issues, and it is forcing me to re-work a pretty large chunk of the editors and engine to fix the issue. One of them being that the filenames are not modifiable by the users, I have forced them to be read-only, with the engine assigning a filename to each object. This creates an issue with room names, as what if I want a Room called Bedroom but 4 different variations of it, I can keep the Room title as ‘Bedroom’ but have the 4 variations saved as different filenames.

The next issue I ran into is what if I want to have two Zones with the same name, but within different Realms? This isn’t possible as Zones are contained within their own Data directory.

Another problem is that Realms contain a collection of Zones. The collection contains the entire Zone class. Wait a second though… Zones contain a collection too. A collection of Rooms, holding the entire Room class. What’s this mean? It means that even though the Zones and Rooms are being saved out into separate files, the Realm files where also saving every Zone and Room it contained. Duplicate saving was happening, and having a Realm save every zone, with every room, is going to take a lot of time up during the loading and Saving process.

Lastly, the linking of Rooms was going to seem cumbersome with the installing and uninstalling of doors into Rooms. It was a neat concept at the time, but I have since decided to do things differently.

So what am I planning? I will allow for custom filenames, move the Zones data directory into the Realms directory that owns them, provide Realms with a link to their Zones, but not an actual copy of the Zone, along with removing the copy of the Rooms within the Zones collection, and providing Zones just a link to the Rooms. Lastly I am deleting the Room Designer from the project, and giving the responsibility of creating rooms to the newly renamed Zone Designer. This is a couple days worth of work to get ready and finished, along with adjusting my namespaces within the classes. Hopefully by the end of the week I will have the Zone Designer working fully, with the creation and linking of Rooms completed.

A little perspective

noreply@blogger.com (Johnathon) — Sun, 06 Dec 2009 20:39:00 +0000

This image shows how everything is linked together and what has been developed so far. Everything shown here is added in the solution, either fully working or not working.

Re-work

noreply@blogger.com (Johnathon) — Sun, 06 Dec 2009 20:22:00 +0000

Now that I have the Room Designer, Zone Builder and Realm Explorer all linked together and working with one-another, I have started working on adding Room Linking within the Zone Builder. I’ve spent a lot of time thinking of various ways to implement this feature, and I still haven’t decided on a solid method of doing it yet. I really like the drag and drop method of it, but I’m not sure how to build on to that idea. It’s not a new concept for me, as my previous Mud Designer IDE that I replaced with Mud Designer used a drag and drop approach, and it’s really simple to implement, however it would require me opening up the Zone to accessing the Realms. It would need to in order to allow Rooms to be linked to Rooms/Zones within other Realms and I don’t want that. I’m trying to keep each editor segregated from their parents. Realms can access Zones but not Rooms as that is a child of the Zone. Zones can access Rooms but not Realms, as Realms manage and control the Zones.

So how should I approach the Room linking? I’m still not sure, I’ve started with trashing 80% of the Zone UI, as it wasn’t going to cut it. Not that there was a whole lot to the UI in the first place, but it had to go. I’m thinking of adding a ‘Realm Exit’ property to doors, or something along those lines, at which point the Realm can select the Zone and view all of it’s Realm Exits. Users can select a Realm Exit and link it to a Realm Entrance within another realm. I think this is the best approach to take, but implementing it is going to take some serious thought. It sounds fairly simple, but I need to make sure that the implementation of it is well planned. I don’t want to do a whole lot of re-work on this, and I want to make sure that the classes are built correctly. It’s very time consuming to do re-work within the editors when I remove or change an engine class. I spent close to 2 hours re-working the editors after I decided to remove the Engine class earlier this week. I’m trying to avoid that this time around with some better planning.

I was hoping to release a tech preview of the toolkit in a binary form this weekend, but that’s not going to happen sadly. Hopefully next weekend something will be ready, but until then people will just need to download the source and compile it in order to take a look at it.

Congratulations Garage Games. I am pleased.

noreply@blogger.com (Johnathon) — Fri, 04 Dec 2009 02:44:00 +0000

Last week I wrote about the state of Indie Game Development and my disappointment in Garage Games due to them charging $1,000 for their new engine while Unreal and Unity released theirs for free.

While I still stand by my statement that Garage Games should be setting the Indie pricing and content standard instead of following corporate pricing modals (such as being out done by UDK), they have done a good job in changing the Torque 3D licensing fees. You can now purchase a binary version of the engine with all of the same features the $1000 Pro version contains (without the source code) for $250. If people purchase it during the month of December they can get it for a cool $100.

Nice job Garage Games, this is going to help indie developers get their hands on a high quality engine with a low budget. Hats off to you.

Merged Projects

noreply@blogger.com (Johnathon) — Wed, 02 Dec 2009 03:33:00 +0000

I spent tonight merging projects together with the Mud Designer. Previously all of the editors where contained within a different project, segregating each editor from another, but this created issues when trying to debug the project and test features, as the Zone Builder would place its files within its debug folder, then the Realm Explorer couldn’t see them due to being in a different project directory.

This has been fixed by moving all editors and the engine itself, into a single project. I was actually surprised to see the project file size be reduced from 3.9mb to 575k, not that it really matters now-a-days, but that was something i hadn’t expected.

Some of the items within the project is broken due to the change, as this was a pretty heavy overhaul. All of the namespaces have been restructured and editors that where previously calling files to load (like the Realm Explorer executing the Zone Builder.exe) are now working in a hacky manor until i get something better setup, which shouldn’t be to long. Hopefully by the end of the week I will have the Realm, Zone an Room editors all synced up and ready for a preview Release on Codeplex.

Nearing my first release

noreply@blogger.com (Johnathon) — Mon, 30 Nov 2009 16:58:00 +0000

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

noreply@blogger.com (Johnathon) — Sun, 29 Nov 2009 17:59:00 +0000

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

noreply@blogger.com (Johnathon) — Sat, 28 Nov 2009 08:36:00 +0000

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?

noreply@blogger.com (Johnathon) — Fri, 27 Nov 2009 23:51:00 +0000

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

noreply@blogger.com (Johnathon) — Fri, 27 Nov 2009 15:28:00 +0000

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

noreply@blogger.com (Johnathon) — Wed, 25 Nov 2009 20:15:00 +0000

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

noreply@blogger.com (Johnathon) — Wed, 25 Nov 2009 19:53:00 +0000

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

noreply@blogger.com (Johnathon) — Wed, 25 Nov 2009 17:37:00 +0000

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

noreply@blogger.com (Johnathon) — Tue, 24 Nov 2009 18:49:00 +0000

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.

noreply@blogger.com (Johnathon) — Sat, 21 Nov 2009 20:12:00 +0000

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

noreply@blogger.com (Johnathon) — Tue, 17 Nov 2009 04:07:00 +0000

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

noreply@blogger.com (Johnathon) — Tue, 17 Nov 2009 03:06:00 +0000

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

noreply@blogger.com (Johnathon) — Sun, 15 Nov 2009 20:55:00 +0000

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

noreply@blogger.com (Johnathon) — Sat, 14 Nov 2009 17:26:00 +0000

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