Matt Raykowski Blog from March, 2010

  2010/03/01
Werewolf Progress Update 3-1-2010
Last Changed by Matt Raykowski, Mar 01, 2010 06:54

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.

Posted at 01 Mar @ 7:51 AM by Matt Raykowski | 0 Comments