Werewolf

Well I'm going to be honest. I was hoodwinked out of time to work on Werewolf this weekend so this status update will be pretty sparse. One of the problems that I was struggling with over the week was how to address "linked" entities. The problem is that you can't link a definition to another definition because the definition may instantiate multiple concrete entities. Take this scenario for example: you place an area trigger and define its dimensions. You place a gate in a door way and configure its properties. Next you want to link the trigger to the gate so that when the player enters the trigger area the gate shuts. Using pure definitions this doesn't work. A fantastic parallel to this is NeL's own concept of sheets and Ligoscape. In all fairness the only difference between sheets and my entity definitions is that I do not assign a sheet ID. I use the same loader (Georges) and I use the same storage technique I just don't assign sheet IDs which is important - NeL expects that instead of saying "use entity definition 'lauralin_shopkeeper'" that you'll build a sheet ID map and send over 28852 and the client will be able to look that up. This is is because sheets define entity characteristics such as appearances and basic game logic.

So the challenge clearly lies somewhere else and probably in the server. So I thought about this concept of aliases and links. The idea here would be that I could configure a component to link to an alias and a concrete entity has an alias which can be defined by its to-be-designed level format. This at a functional level accomplishes my gate use case.

Lets say we have a gate entity definition that also defines a "triggered" scripted component. It watches the entities properties for a change in the triggered property. We have an area trigger definition with a trigger component that looks at a list of aliases which define the links for the trigger component. Now we instantiate the gate and give it an alias of "lauralin/shop/gate" and place it in the world appropriately. Next we instantiate the area trigger, provide it points to define its location and shape and give it a list of aliases to link - in this case "lauralin/shop/gate". Through playing a player comes into the area triggers zone of effect. The area trigger looks up its links, retrieves the gate entity by alias, checks to see if it has the triggered property and sets it with "triggered" and "triggeredBy" to provide the gate with which trigger activated.

Having a triggered by could be useful because you may want two or more triggers affecting it. The gate closes when you get close but opens when you stand on the other side of the room. Add a third trigger on the far side of the gate and this means that players have to cooperate. I stand in the pressure plate to hold the gate open, then you go through the gate and stand on the opposite side's pressure plate so I can come through. I love the idea of generating scenarios that require the player to cooperate with other players.

So I'm trying to mock this up with the entity component sample I have but I'm working through "faking" an event server and ensuring that the components still behave the way I'd like when driven by events. If being event-driven works out and I can produce a convincing demo of this alias-link system I'll have to consider how the level editor format is designed. The more I struggle with this the more I realize that Ligoscape (NLLIGO) is the "right" tool for storage of this kind of data in a file. Right because it's been demonstrated to work (Ryzom) and because it's already written. But part of me goes back to one of our earlier design ideas - pure in game editing. I won't need a file format if I'm doing my level design through the server. I can just continue to persist the world to the database (see my earlier blog post) and as long as I put some logic in there such as entity-valid-version and make sure that the players don't see draft versions we'll be good to go.

Neloid

I actually did spend some time working on Neloid. I added a basic level editor and the ability to select next and previous tile types using the scroll wheel. I started to experiment with some particle systems for the goal and start tiles but I don't have anything worth looking at just yet. I think I have the basic grasp of NeL particle systems now though and my failings are no longer really a lack of understanding of the system but moreso of my failure as an artist. Something I haven't attested to being for almost a decade. I did make a brief, crude demo.

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.

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...

I'm a little behind the ball on this but I recently read a very good blog post by Barry Reddy called MMOs and the Suspension of Mortality . He discusses the concept of permadeath, which is a core tenant of Werewolf. This is not to say that permadeath will be a non-negotiable fixture of Werewolf but simply that in the current design we feel that permadeath is an important feature. Barry explores many of the concepts, ideas and alternatives that we explored in designing Werewolf. This, to me, is very encouraging. It means that we're on the right track, that someone else is thinking the same way we are.

Dealing with implementing permanent death as a game design element is not a trivial task. You do not simply take your typical MMO recipe and eliminate respawning. This would ultimately lead to frustrating the player. We decided in designing Werewolf that we had to address a few topics of game design before implementing permanent death: how a player dies, what happens when a player dies, and what defines a successful character. The first two probably seem obvious but the third may be a surprise to some people.

First you need to determine how you handle player death. How can a player die and what kind of measures are you going to provide to help guide a careless player away from a senseless death? One of the things the Werewolf team considered was a realist approach to character death. It was sanitary, brutal and uncaring. You walk into the woods and see something lurking and don't run away? That's just too bad then. We thought maybe that would be too harsh and may discourage players from experimenting and exploring. So we considered implementing handlers that "took over" your character when in danger. This is a concept familiar to people who have played MUDs and have set their "flee" hit points. Werewolf however wants to guide people away from stats and game mechanics and wants people to play not calculate. So giving players the flee threshold was out of the question.

While I don't think this is completely settled our ultimate goal is a mixture. We want the village or Laurelin to be a bleak and foreboding place that's dangerous. We want it to feel dangerous to the player but we also want the mystery to be difficult to solve. With no consequences to wandering around alone in the Vargskogen we knew without a doubt that people would just run around the forests, caves and mountains looking for something. If I die then so be it, I'll just respawn and head back out! The first iteration of Werewolf will be this awful and brutal response to player death. Sorry, but if you run into something bad in the woods then you're dead. As the first chapter evolves we'll be adding psychology handlers onto your characters so that if you're foolish as a player your character still knows better. If you're an exceptioanlly foolish player no amount of compensation by your character will make up for it.

This last paragraph touched a little bit on the how you die but not on the what happens part. One of the conversations I had once with patosan was about a time when I played Call of the Cuthullu D20 with some friends of mine we deviated from the typical pen-and-paper RPG character generation. Instead of spending 15 minutes generating a character and then 30 minutes generating a background story and personality we spent 15 minutes generating 5 characters and 5 minutes a piece on background. This gave us very little bond with our character and the reason the GM did this was to limit our emotional tie to this character so that when and if the character died we'd be frustrated but okay with it. I went through all five characters that night and I had a blast. The point is this: to enjoy the world and the adventure my character does not necessarily need to be successful but I do need a way of continuing to play.

We tried to think of ways of compensating death. While we wanted character death to be bleak and unforgiving we also did not want to leave the player high and dry back at the beginning with nothing to show for it. We struggled with this one and I think we still struggle quite a bit with it. We looked at ideas ranging from account karma to a complex concept of inheritance and offspring. Barry also discusses these and in particular focuses on account karma. I really like this idea and I think it has a place early on in the development of the first chapter of the game but for one core reason: it's a reasonable compromise to the offspring system we truly want which will require a sizable effort to plan and implement correctly. Barry's discussions about account karma really leads us into the next topic of character success so lets just pause and consider how account karma would work with regards to the what would happen. Barry suggests as a stop-gap a "judging of the gods" as a means of arbitrating character death. His reasoning on this is that if you have a Leeroy Jenkins type of incident or a problem with griefing that you may need  way to stifle the flow of complaints. I played on a MUD called Medievia some time ago that led a similar concept of death. That once you die you have to go and find an altar and pray. At the time I really liked this idea: I lost my loot, a bunch of experience and I was inconvenienced for my stupidity but I was still able to get back up and play. But when I began designing Werewolf with the others I realized that this wasn't truly a punishment that forced me to consider my actions, to take better care of my character or to heed danger. It was a punishment that inconvenienced me and really lead to very little change in my game play or behavior. I still went running into rooms and areas to see what was there - I just made sure to visit a bank and drop my gear off at a locker first. I think to impose this true sense of risk to your character there has to be a true consequence to actions. You must die and stay dead.

So you've died and you have a way to start over. Without explaining the specific mechanics of account karma or offspring you still know that you have a way to start over but not totally from scratch and assuredly it will be a different character. It will force you to design a new persona. But now we have this mysterious question of what defines a successful character. This is really the key reason why the discussion of permanent death is typically so negative. Today players are diluted into a sense of suspended mortality which distracts them from story telling and into character building. It's not the only reason we do this - the fact that most MMOs encourage the grind or make merely a haphazard attempt at disguising it contributes greatly as well. If the measure of your success is the level of your character or the loot you receive you will be sorely disappointed when your character dies. In Werewolf one of our challenges will be changing the definition of character success and focusing more on player success instead. We still have an astounding amount of work to do around this but I think the core principle of this will be the backstory of Werewolf and the evolving involvement of the players.

Werewolf intends to tell a story and provide mysteries to solve. The idea behind Werewolf is to empower GMs of the game to interactively tell the story and involve the player. It may be their character living the story but its the player hearing the story. As players an guilds unfold the story their players will be awarded for this through merits and medals. This we know. We also intend on engaging the role players to expand the story and in distant future versions allowing for character-run politics. While this isn't a measure of success this concept will help make permanent death more interesting and more, I dare say, beneficial. This is the other thing - harness permanent death to fix frustrating game mechanics. How many times have MUD clans battled it out? I can say through years of playing MUDs I was "in" a number of clan wars. These are ultimately fruitless endeavors that have no end result or resolution. There really aren't true winners or losers. With political intrigue the best that games can offer now is some means of "voting" for their representatives. But there's no danger of a coup and if there is danger it isn't truly risky - so you're ambushed a couple times and killed. Respawn and restart. Now with permanent death things like this have a possibility of being changed. Real battles for political control of a village or town with real results.

Just something to think about. Maybe permanent death doesn't have to be bad. Maybe we just need to rethink the standard recipe for MMOs.

So three months ago I created a CDash -based site for performing Contiunuous Integration (CI) with NeL . I created a little document and posted a news post and a forum post requesting volunteers to "donate" server time to do builds and unit tests for our site. To date I have received no volunteers. Fortunately my host for opennel.org's server has made some moves of my machine and I now have a little more liberty to consume CPU cycles and memory. So I have configured NeL's dashboard builds on my host. If you look at the NeL Build Dashboard you will see that I am now doing Continuous builds as well as Nightly builds. I'm still hoping for a host that can do Nightly builds using VS2008.

I'm really hoping that once I start getting a variety of hosts and compilers submitting builds to this site that the number of incidental errors we create when developing for a specific platform will begin to fall. There are a number of instances in which a unit test is broken on gcc when coding using the benefit of a known compiler quirk in Visual Studio, for example. In the early days of NeL development, especially after we forked to OpenNeL, we encountered these kinds of incidental errors often. This was also back when Visual Studio was less strict and gcc was beginning to be much more strict.

On that same note we face this problem with gcc as well. A great number of distributions are using gcc 4.3 for example while my builds are occuring on gcc 4.4. We've seen each version of gcc become increasingly strict in its compliance to the standard. In some versions so much so that NeL even refuses to build on the newer version until we remediate the violations. As long as we continue to have a mixture of compiler versions CI will help facilitate at least rudimentary regression testing for situations such as new code created against a less strict version or changes to bring code into compliance potentially breaking builds on other platforms.

Other than our lack of both platforms and compilers represented in our CI environment the other major problem we have is a significant lack of unit tests. We have a number of unit tests in NeL but we have had no such test-driven-development (TDD) philosophy in the development of the libraries, tools or applications. Especially the applications which have devolved into a hodgepodge of questionable patches. Hopefully in the near future we will also expand our unit testing into areas and applications which have no representation in testing.

If you're a NeL user or developer please consider donating your system time to our CI environment and please keep a close eye on the NeL Build Dashboard for errors and warnings. We always gladly accept patches .