Werewolf Blog

Well, I haven't posted here for awhile so I thought I'd get some info out there. I worked with the NeL community to recently get NeL 0.7.0 released and we should hopefully be seeing this in Debian and Ubuntu real soon now. It sounds like they've also packaged Snowballs and the NeLNS Qt Launcher so I had better get cracking on getting that demo shard running soon! Which leads me to the other thing: we were forced to move servers due to stability issues and general old-age of our former Debian VM. We're now running upgraded JIRA, Confluece and FishEye on a new Karmic VM at the same host. So far this seems to be faster and definitely more stable.

As for Werewolf I've only had meager moments of time to work on it. I've worked on the CEGUI/AngelScript module as well as beginning to bind NeL and Werewolf code in our WWSCRIPT module. There are two script demos in the source code repository: one demos the script engine's various features such as auto-binding using property maps and recompiling individual scripts from disk-source, the second is more of a play-ground to develop and demonstrate the AngelScriptModule I'm building for Werewolf's GUI. The ultimate goal here to to be able to siginificantly limit the scenarios where we need to recompile the source code to alter or add GUI elements.

In other news I moved on to renovating the chat system. This was unfortunately a heck of a lot more work than I had expected. One of the first problems I ran into was the inconsistency of players to users - every connection generated a user but not necessarily a user. That lead to a disconnect in users which are often the key for looking up characters and (in this case) the EMD or EMT used. Ultimately I eliminated all of the CPlayer usage in the frontend service (although I'm afraid there is still some vestigial code in there that we will need to clean up.) This forced me to expand the users table (not to be confused with the LS's user table) and the CUser object. I also added a ton of database persistence and "caching" logic to CUserManager.

After getting to a point where users are consistent with the user information being forwarded to the frontend server I needed to make sure that the client-server world was clean. This, unfortunately, is still a work in progress and I'm afraid may require me to do some large changes to ISimulationObj. I have some planning to do here. What I have done is updated the GUI to have a "Create Character" screen which is extremely rudimentary (it gives you a free text box and a drop down with available EMDs) which will transmit a CH_CR message (CHaracter_CReate) to the server to allow players to create characters. This required some updates to both the callbacks as well as to the CCharacterManager class. Related to the necessary changes to CUser and CUserManager the CCharacterManager needed to be able to pull up a CUser object to determine what the maximum number of characters a player could create was. When the FS receives the CH_CR it asks the character manager to create the character and then sends back a CH_CR_ACK (CHaracter_CReate_ACKnowledgement) message. If there was a problem with creating the character the first element of this message is a "reason" string. If it is not empty the client did not succeed in creating the character and is left at the character creation screen. We still have to create a dialog box to handle those non-empty reason scenarios which really just means I need to implement a framework to do modals in CEGUI.

Now we (theoretically) have the ability to log in, create characters, connect as a character and walk around. The next bit was to implement the simulation event chat system. As it stood before I embarked on this effort the chat system was basically this: the client grabbed a chat line from a dialog box, created a CHAT message containing nothing but the chat string. The FS then received that and forwarded it out to all clients. It was pretty crude, didn't take any proximity information into account, wasn't exactly something that could be scripted (e.g. AI listening) and contained no player/object information.

What I ended up doing was ditching the CHAT message entirely. I had to do some work on the GUI since a lot of the layouts are distorted still but the chat box now appears cleaned up. Next I created two sets of events: CGameChatEvent and CSobChatEvent. This can easily be looked at as a request/result pattern with the request (CGameChatEvent) being a player sending the chat and the result (CSobChatEvent) being the activity actually occurring. There was a necessity to process these on both sides.

First I needed to create ways to process the request on the FS. When the FS receives the CGameChatEvent object the CGameEventManager receives and processes it using its chat method which simply does some error checking (make sure I don't attempt to send a chat as someone else's character, for example) and then translated the CGameChatEvent into a CSobChatEvent and posts it on the server's event queue. Next I made two modifications to the server object view (SOV.) First I needed to make sure that it started listening to events targeted at Sob ID 0 (global, root sob.) The other modification was to ensure that I filter out any CGameChatEvents. Since the default behavior on events in the client is to attempt to repost them using an EVT to the FS I wanted to make double sure that the client didn't receive its own chat request and cascade chat events to the FS. The SOV now takes care of forwarding CSobChatEvent objects targeted at it's owner-performer and at the root sob to the client.

Next we needed to receive this event at the server. Initially this isn't a problem. The client infrastructure automatically posts new server-sent events to the event queue. I just needed a way to process and display this event. To accomplish this I created a new view called CPerformerChatView and made it a listener. I know this slightly "breaks" the policy of views being driven strictly by Sob data but I had one problem - I needed to know about chat events I originated as well as those targeted at me and a Handler will only receive those targeted to me. This view is pretty simple right now, it just takes the chat message and posts it to the GUI.

What is next on the agenda is to start to define our simulation object property dictionary. This is important because it is becoming increasingly difficult to find where data is hidden in the Sob hierarchy which includes character information. If I can simplify Sob properties to something similar to a dictionary it will also make scripting handlers easier (like owner->getProperty("name") for example) and just generally makes the code less complicated.

I should probably mention the work that's been done on Werewolf recently, especially the work with WWSCRIPT and the new chat infrastructure but I'd like to skip all of that noise for now and say that I'm recruiting talent for the project. I need help! So please, if you're interested take a look at our project and contact me if you're interested!

Wow, it's been over two years since a news post has been put up here. I don't really know if anyone is even following anymore! So I'll cut to the chase. For the past two years I've been heavily involved in the NeL project, which is the engine that drives Werewolf. There have been a great number of improvements, set backs and strides. One of the key challenges was the failure of both Nevrax and then the following year Gameforce France (whom bought Ryzom.) At this point the NeL community forked, resulting in this (opennel.org) web site. About a year following that a new company bought Ryzom and we began the process of merging the fork back into the new company, the result is dev.ryzom.com and it has been a fantastic success.

Some good improvements have been made and a couple are on the cusp of being "broken" which are crucial to the development of Werewolf. Chiefly among these is the ability to include a NeL graphics context within an existing window object. This functional is important so that we can begin creating cross-platform, non-MFC tools that function similar to the NeL Object Viewer.

Werewolf has been refactored slightly to remove the integrated login tools, functionality that, should we desire it, would be easy to put back in place as most of the actual code is replaced by the NLMISC::CLoginClient methods now (a huge savings for Werewolf developers.) I removed this in favor of a Qt-based cross-platform launcher. The reasons behind this are not entirely related to Werewolf - the intention is to have the login service (LS) be communal, allowing players to use a single launcher against a single service to play any NeL-based game online that they have installed. That project has a long way to go but since the basis of it was in place for my Snowballs development efforts I chose, for simplicity, to make the change in Werewolf. It eliminated a lot of code in CNetworkTask. A lot of fairly ugly code, I might add.

To get things running in Linux with the most recent GCC, which I have been forced to adopt as my preferred development environment due to hardware problems, I had to do away with my registrar code. This, as it turned out in retrospect, would ultimately have to have been done for Visual Studio 9 as well as it has also become a little more strict. While it was an incredible hack that made my life easier it was, nevertheless, just a hack. I opted for the course of simplicity. In WWCOMMON I added a new function called registerEvents() which you are obligated to call upon initialization of the service/game/tool you are coding should you want the polyptr's for the various events to work.

Additionally I ported the build to CMake. With all of my interesting post-build and pre-build scripts no longer necessary this task was fairly trivial. It allows me to work off of NeL in an installed directory on Windows and Linux. Previously, especially in Windows, we were sourcing our NeL-based Visual Studio projects directly from the NeL Subversion repository. For someone like me this is a problem as my NeL source tree tends to be "in development" perpetually. I also think that it better simulates what an outside contributor might be exposed to.

For the website I took back up the task of cleaning up the wiki that you see here. There's still a lot of work to do here. I believe Jason began the process of doing this so we had a number of duplicates such as Werewolf Server and Server - I jockied things around and moved them into the simplified destination that Jason had originally intended to use. I also limited access to the World Design sub-sections, specifically the General Timeline and the Encylopedia. You may notice that there are two in there - I did not know what state Henri, Elo and Jason had left this migration to the new encyclopedia format. It may have to be taken back up by them or potentially by new content writers if we succeed in attracting them. I've noticed that I'm linked to our old server for our art resources (see the media information for the Ironic Demo design documents.) I still need to figure out how to get all of those reference images, those are beyond value.

To prepare for the next "lunge" of the project I also created a new JIRA project. At the posting of this news I have 16 issues open and have added a view to the release portlet for the Werewolf project onto the wiki homepage. Most of the issues exist in the 0.1 version but you may note that most of them are also trivial. The ones that aren't I think are crucial to returning Werewolf to a usable state. The first 2 and probably 3 versions of Werewolf will likely not address advanced features or even nagging problems of any outstanding complexity. For example the failure of the client and server to keep in sync without introducing jitter via DR updates is beyond my capabilities. An issue will be opened to address it at some point but merely getting a usable framework is of the utmost importance.

Keep an eye here, I'll try and do weekly updates.

Disabled the flash based gallery plugin, since it resizes images to fit the screen and does so without anti-aliasing - also it does not work decently in all browsers.

As all of you know we have started to create the special purpose technical use-cases. Now tho I have created a parent page for em that has some basic terminology listed as well. You can find it at TechUCs
Feel free to explain terminology more nicely, add terms that you would like described and of course choose things from the ObjectsInTheSimulation page that you would like described in a tech UC. The call for expanding that page as well is still valid of course
The FireTechUC is most complete atm altho still lacking some vital info as indicated by the problems listed. I have started on a PotionTechUC but that will take some time..All in all I hope to at least fill in a few of these with Jason today. And generally I hope to get a decent amount of them done before I leave y'all for a while again.

Last changed: Dec 17, 2006 20:58 by Jason Oppel
We're having a meeting this Saturday.  The most important points of discussion will be the Base System Interview and a discussion about Management Systems.

View the meeting agenda here: Meeting2006-12-23.

Well I started thinking about the base system, as you guys might have already noticed yesterday (what with all the annoying interview scheduling and all). All in all the interview with Jason will take place on Saturday and with Matt maybe next Friday then. In the meanwhile we can map out some basic things about the game. On that note I started a lil page called ObjectsInTheSimulation. This should list all objects that can be present in the simulation and their behaviour, actions and attributes and such. Feel free to append things to this document and of group things. Basically do not fear repeating things (like rabbit, bear etc.), we can always group em later (animals). Just trying to make sure we do not miss anything terribly important.
Later on we'll classify all the attributes and objects and stuff in order to see what kinds of game objects and simulation nodes in general we need. The page GameObjects was started with that idea.
Have fun kids

Another meetingThursday morning.  Once again on Skype and Gobby.  This time we'll continue storyboarding and work on the GUI design a bit more.

Here's the meeting agenda: Meeting2006-12-19.

We'll be having a team meeting this Saturday, Dec. 16th.  We'll be using Skype, so bring your headset.

You can see a very rough agenda here.  I'll fill out the agenda in more detail tomorrow.  It is very late and I need to get some sleep (yes, I'm weak!).

As you've probably noticed, I've changed the theme for our space a bit to use the Left Hand Nav Theme.  I also brought over the Werewolf Logo from the old Twiki site.  I think it is a bit nicer to get around in.  Anyhow, vote if you like it better and we'll see if it stays.

Communication...a big problem in an inter-timezone project like ours. Again I think it is rather imporant to realize that we can not overcome the need for sleep (not for long anyway), hence some things are certainly complicated. Here are my musings on communication issues and what we should think about.

The most important thing is - how do we deal with show stopping issues?
Everyone has different times when they are free to work on WW. However interdependencies can not and should not be elliminated - just coordinated more.
So let's take some examples.

1. I get up in the morning and decide to work on WW. Say I have 3 hours of time. After 20 mins I run into a problem - a UC lists 2 contradicting conditions. Which is true? I do not know enough about the subject and can not make a decision. So I can't work on it. Now everyone else is asleep at this time so my only possibility would be to mail the person who could answer the question or a list.
   A few things can be done to alleviate this situation:
   • Have other things to work on besides this, so the available 2.6 hours are not wasted.
   • Have me understand the subject well, so I can make the decision myself
   • Have the other people answer the mail asap..since our time difference is 7h, the shortest time limit we can set is 7h..but usually it can be answered quicker and should be, just in case I have some more time available right at that moment or something like that.
2. I am working on something during the time that others are awake. I run into a show stopping issue. But noone is around on IRC. How should I contact people? IRC lag can go as high as 1.5h..people can time out or even not answer the question at all. Mail...I have had mails not answered at all..or answered in several days time..not very nice in such a situation. Blogs are even worse than mail in this regard..also private matters are not suitable for blogging for sure. So what is the solution?
3. I am working on something and know that in 2 days I will get to a certain point in development where I need component X. I have no clue about component X and how it would be made. Someone else has to make it. How do I notify them that it should be done by that time? How do we make sure it does get done?

Post your own scenarios and of course ideas for solutions.

Not to mention that they are often interrupted by someone having to work, eat or go to the bathroom or some such nonsense.

You can try and hold it.

What we have to realize is that the time issue is mostly beyond our control.

It is agreed that life is what it is and no one is doing this full time. It is difficult to squeeze more things done out of a given day.

1. Planned meetings.
   These we know about at least a day in advance. In my option the person who called the meeting and/or presides over it should start a wiki document or something that shortly lists points he thinks should be discussed.
   Then other people taking part of the meeting will add their ideas to the wishlist. There is a deadline on this. After the deadline and before the meeting, the presiding member will go over the list and prioritize the points.

Unless it is a very large meeting, usually this can be done just minutes before the meeting. 10 mins. before the meeting should be fine for a cutoff. Still, I wouldn't throw out a good idea for a bullet point just because they didn't meet the deadline. We shouldn't plan 1/2 the meeting this way, but the occasional item here and there can be forgiven.

We should set an amount of time that we will allow discussion on a given topic. This will help prevent needless chit chat and wandering from the subject going too far. The presiding member can extend conversations at the expense of other agenda items if most everyone agrees that it is important enough.

1. Impromtu meetings.
   For these there should always be a list of issues that need discussion..preferably prioritized to some extent.
   Of course usually the meeting is called with a purpose, so the purpose goes to the top of the list.
   Otherwise the process is the same as for planned meetings.

There needs to be an agreement about who will transcribe the outcome on to the Wiki. These types of meetings would preferrably occur on IRC, and the contents / decisions should go in the Wiki. A mention of the meeting should go in a News item, so people who didn't happen to be around at the time can still read and comment / debate the decision. Even if you think no one would be interested in the meeting, it could be useful for historical purposes and for noobs sniffing around asking, "How / why was this decided?" Go read the Wiki and / or the logs you insufferable newb!

Work continues apace on the IronicDemoDesignScratchpad.  It's banging into shape pretty nicely.  The goal is basically to have a document which describes the demo on a high level that is readable and understandable by River Trolls.  C'mon now, no faces like that...  I work with some river trolls, although they deny their heritage!

One of the things I'm working on some Agile Paragraphs for Matt so he can continue is design of the modular design system.  I'm also reading a bit about

and

so I can evaluate them a bit more since Matt seems interested in this approach.

While there are some really good things about these methodologies, developing things completely within a unit and waiting too long to do integrated testing seems like a potentially dangerous recipe.  We'll see...  I stil have a fair bit of reading before I make any final conclusions.

I'm also beginning to research workflows and potential quality management systems.  Hopefully this could really help our production, which has been difficult to keep at a high level.  Henri and I have already had a chat about possibilities for these systems, which includes workflows revolving around traditionally film based workflows like the concepts of developing storylines, storyboarding, storybeats, etc.  Revolving around management and process control research for me has been Lean Manufacturing, Just In Time Manufacturing and the Six Sigmas.  Detailing the exact approaches will have to wait until we have reseached things a bit more thoroughly and consulted our river troll.

This is a test blog entry.

Basically I have a bunch of exams and tests to do so I have no time to work on WW really for some time now. 

Looking at the terms_of_reference.rtf in CVS it is a mess that needs cleaning up before I can do a very decent job creating a UseCaseTemplate.  This is a start to the Use Case Template, but it is wholy inadequate atm and is just a skeleton.  We need to get the demo design straightened so we can create some valid basic Use Cases.  How can you create a decent test use case if you don't have a very good picture about the demo?

In the coming days I'll be taking this document, dividing and editing it to make it a bit more clear, the initial document is the IronicDemoDesignScratchpad.  Also, some parts will likely be split into separate documents.  If you have some comments on this approach, or the UseCaseTemplate as it stands now I welcome comments (as always).