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.