Archive for November, 2009

Nearing my first release

November 30, 2009 Leave a comment

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

Categories: Uncategorized

Free-To-Play games vs. Subscription

November 29, 2009 Leave a comment

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.

Categories: Uncategorized

RIP Visual Designer

November 28, 2009 Leave a comment

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.

Categories: Uncategorized

What happened to Indie development?

November 27, 2009 Leave a comment

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.

Categories: Uncategorized

Clarifications & Concepts

November 27, 2009 Leave a comment

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

Categories: Mud Designer

Still trying to tackle scripts

November 25, 2009 Leave a comment

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

Categories: Uncategorized

Plugin support

November 25, 2009 Leave a comment

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

Categories: Uncategorized