2010/02/09
So I saw a link first thing this morning for Myst Online's developer page which stated that Myst Online was being open sourced. The page is somewhat vague as to when, what's already been accomplished and so on. So I started to do some research. This sounds like a pretty exciting thing for the open source MMO arena. It's nice to see games like Planeshift and Peragro flourish from a pure community but the introduction of large code bases to the open source world does nothing but good to foster other projects. I think NeL is a good example of that despite the fact it's use in the wild is still somewhat limited. One of the key things that the open source world gets when these kinds of projects open source: knowledge.
I can safely say from personal experience very few of us hobby game programmers have done this for real, for a living. We've never completed a game on a timeline in a structured environment with responsibilities. We haven't had the pleasure of working with seasoned veterans that can help prevent us from wasting precious time on concepts/designs that simply won't work or don't scale. This last one is one of the major reasons I never seem to make any progress in Werewolf. After several tries at a problem area (which means several large refactors) I finally squash a problem. Then I realize that I need to move on to the next problem space. Sometimes this means that I didn't think something through on the previous problem and have to refactor both.
What I'm trying to get at here is that by having large professionally developed MMOs source code available to the public projects like mine can begin deriving ideas and best practices for their own project and their own needs. It means when I face the next big problem space I'll be able to look at someone who is doing it and more than likely doing it right and start getting ideas. In fact I'm kind of hoping that I can look at the tools that Myst Online uses for world building as maybe an inspiration for the tools that Werewolf will implement. Now that I think I have a workable entity and component system with a definition manager (the ability to define entity types and then spawn instances of them) completed in testing and will be shortly going about implementing into the main game the next challenge I face is world building and layout.
As with any task or project you need to know what you're doing before you do it. This is a valuable lesson that Werewolf learned the hardware and because of it I've been teased with comments like "I thought Werewolf was just fiction and not really a game." So I started looking at what else was out there and was astounded by the cool factor of the Torchlight Editor . I figured this is what I need. While you can download and play with Torchlight's Editor it's clearly not open sourced (yet?) and so other than an inspiration not entirely useful to me. However Myst Online will be releasing Plasma and the accompanying Plasma20 3DStudio MAX plugin. While I'd love to see a Blender plugin for NeL the reality still is that most content creators will still need to have 3DStudio MAX to create content for NeL so "ideas" from the Plasma20 plugin may meld nicely with NeL Ligoscape plugin for MAX. For the uninitiated Ligoscape (or the NLLIGO module) is the underlying library and file format that NeL/Ryzom world editing is based on. Unfortunately do to the lack of documentation on Ligo and the fact that Ryzom isn't open source this really doesn't leave me much to work with.
In the mean time I'll keep working on my own direction and hope for some inspiration. I'd also like to think Trefall for his article on the OGRE forum about Component/Entity systems . This has been instrumental in my redesign of our entity system. While my sample greatly reflects his sample by the time I get to merging it into WWCOMMON it will be a wholely independent system. Chiefly the changes will be that I use events and not commands and my components likely will become singletons managed by the component factory and will not have a unique instance per entity. It seems silly when considering the objective of scaling to thousands of entities to spawn a large number of components. Lets say that I have on average 9 components which each have 5 properties.. This means in a 1000 entity zone I'll have 15,000 objects created. If I made components statics (like I do with my state classes) I now have 6009 objects instead.
Anyway look forward to a demonstration of the new system in the next couple weeks...
2010/02/22
So I decided on weekly progress updates. Be forewarned that there may not be very many of them as I'm stretched pretty thin these days. I'm going to give a couple non-Werewolf progress updates first here real quick.
Neloid
I decided to write a Tetrisphere like game a few weeks ago and I just haven't sat down to put pen-to-paper and code-to-files as I have struggled to put my head around some of the basic piece storage. I have the essential game play down and how to make it look like a sphere should be pretty simple but how best to store the pieces and track things like combos is still plaguing me. One day while doing some digging through DAG code to see if it work work for me I came across this post about a small clone that some guy made in Panda3D. I looked at his code and realized how simple it really was and thought this might be a good thing to get me in the mindset for a small puzzler game. It also gave me an excuse to explore some sides of NeL I, as a server programmer, seldom touch: 3D. Boy was I in for a surprise. One of the things that the original programmer did was something that modellers frequently do: group objects and then use the parent to execute transforms on the children. The beauty of this is that you can leave your objects where they are make modifications relative to another object. NeL's parenting hierarchy doesn't work like this. When you parent two objects the child takes on the world matrix of the parent and a "snapping" effect occurs - the child moves immediately to the parents location - and then the hierarchy is broken it goes back to its original world matrix. I had to think smart and work around this a different way and since I don't think smart I had to enlist the help of RTSan who helped me do this in a substantially smaller amount of code than using parenting. At this point in time we call this fun little app "Neloid" but it doesn't really matter. It presently allows movement of the block, has a portal tile type functioning, a weak tile type, goal and falls and some small amount of particles being demonstrated. Below is a picture of it and you can find the code on Google Code . Coming up is a re-factor of tile logic, some more particle system demonstrations and hopefully I'll start doing more block and tile animations.
Tux Target
In other news theTux Target fork of MTP Target needs coders. I've been trying to help out but I don't really have the time. Right now this is based off of the 4 year old code available through CVS. A comprehensive review of the newer client has uncovered some good fixes and some of them have been applied but a lot of the code is based around new features only available in the closed-source server (things like new dialogs for donations, etc.) There's been a substantial amount of code around converting the MTP Target GUI to support Unicode strings. My suggestion is to drop the MTP Target GUI and convert the menus to use CEGUI instead which already does support Unicode strings. In one of my samples I've written I use the load layout PropertyCallback to intercept "Text" properties that start with "i18n:" and convert the following string using NLMISC::CI18N. I think this would be more than sufficient. At this point in time you can build and run the server and connect to the server using the client in LAN mode. We've played a couple levels and everything seems to be happy with a couple minor exceptions. Anyway if you're interested at all email me or find me on IRC in #tuxtarget on irc.freenode.net. You can talk to me (sfb) or Lubos.
Werewolf Update
So I warned you that there wouldn't be very much to put here since I've been busy on trying to hatch my little indie game idea and working on Neloid but I have put some more design and code into the new entity system. I haven't posted anything about working on this so I think it's probably a good thing to post. One of the problems I ran quickly into after I completed the chat event code was the fact that there was no information about a SOB transmitted from the server to the client other than the EMD that was in use for the entity. That got me thinking about properties and how to easily implement them and how to implement them in a way that they can be serialized. This has proven to be more challenging than I expected because it lead me to completely reconsider the way that I'm handling entity functionality. In Werewolf we call them "SOBs" which is short for Simulation OBjects however they're still just called "entities" in my sample to demonstrate my new technology idea. In addition to not sending any property information over I was not informing the client on what handlers/controllers were in use by the simulation object. This I determined to be a fairly substantial problem as I don't really want to hardcode types into the client. My new idea changes handlers and eliminates controllers. It also eliminates all sub-classes of ISimulationObj but to be honest I'm a few weeks away from implementing this in the client/server code.
But instead of rambling you probably want a description of what I've done. I'll disclose that I am heavily influenced by Trefall's Component System . I've broken things down into three essential elements: Entity Definitions, Components and Properties. The Entity Definition is at the core of this. This does not define a specific entity (this is a problem to be tackled later) but rather a type of an entity. For example I may have a "rock" definition that I use for dozens or hundreds of entities or I may have a "laurelin_shopkeeper" definition that I use for only one entity. When I inform a client about a new SOB I'll end over the entity definition and any pertinent properties. I should be able to do this handily through a custom message or as hard coded fields on the CSobAddEvent that gets transmitted to clients when new SOBs are within their range of visibility (using the proximity grid.) Before I get to this part though I'm implementing a basic event server (that will not be reused - Henri's CGameEventServer is very powerful) to ensure that event-based "commands" to the components still works the way I want it to. I see no reason for it to not do this. Components will again be static and not per-entity. There's a massive savings of memory to be gained by doing this but I haven't re-factored the ComponentFactory to reflect this yet. I will do this within the week to be certain. Finally once I'm certain that static components and events are doing what I expect will begin serializing entities to retain their properties and component layouts, as an entity may and will have components and properties that aren't part of its definition as a growth of gameplay. I will more than likely for the purpose of this technology demo simply use IStream to dump the entities to a CIFile to the disk and then reload them at startup of the demo. Finally after this I'll add some code in to "persist" entities to a database using SOCI to perform the database logic.
So you may ask why serialize and persist and I have a very simple answer for you: serialization is how I put an entity into a CMessage (for transmission to other services or to the client) and persistence is how I will store the world. Persistence is a very easy way of world design for a game at as early of a stage as Werewolf presently is. I'd love to see a world building tool using something advanced like NLLIGO but I don't have the time and so we'll go with the easy fix and hope to recruit someone enterprising and eager to help with this effort. Persistence through the server also allows me to perform "world building" using the client. At the simplest level I can send commands to add new entities (which then get persisted.) At a more advanced level I could begin adding UI elements to assist in the placement of entity definitions (spawning entities and thus persisting them into the world.) I will also add a new flag at this time for persistence levels because I want some entities to be transient (go away in the event of a server crash or shut down.)
So that's it for this week. Hopefully I'll have something more for you next week. At the very least I'll post about Neloid.