photo credit: Idhren

I bring this up because this last weekend I started playing Aion.  A very nice game that I have high hopes for, but its probably the first MMO that I am actually interested in a bit of the lore; I even went so far as to read some of the important quest text.  Its shocking yes, but they really did do a good job making the player feel like they are not just a drop of water in an ocean; which is worthy of recognition in itself.  Unfortunately, Aion suffers from the unique name dilemma so while I am trying to rescue the damsel from a horde of black winged bandits I am constantly running into ‘XXSlayerXX’ or ‘RoGeGardian’ and that is just terrible from an immersion perspective.

But what can be done about it?  After all, a lot depends on character names.  PMs, brokers, mail, friend lists, etc etc.  Obviously a new system has to enhance game play, not restrict it.  I propose a system where each character is assigned a unique number, not a name, which can be used for all these means of communication with just a little extra effort on the programmers side.

To illustrate my concept I will run through a few normal MMO actions and highlight how this idea works in comparison to the character name.

Auctions

This is the easiest, when a character posts an item you simply register the item with the character id instead of the character name.  All transactions, searches, bids, use the character id instead of the name.  A really simple swap out in this instance.

PMs

Probably the first problem that would come to your mind.  Obviously having to type /tell 00283023 to talk to a player would be murder on your player base.  PMs can be handled nicely, it just takes a little more work and polish out of the box.  For instance, to talk to someone who made a comment in the chat window, just click on their name and reply.  The reply would pull the character number from the chat window so the player would see the character name but actually be replying using his number.  Now, if you want to type up a pm to someone you met in an instance but did not befriend, things get a little more complicated.  Lets say for the sake of argument that you remember his character name and you wish to send him a message.

There are two solutions I can think of off the top of my head.  First, typing /tell William will bring up a list of all ‘Williams’ in the world sorted by last interaction.  Meaning if he met William during a live event the previous night, that William would be listed above a William he met out in the plains last week.  For this to work players would need to keep record of the players they meet and timestamps, not impossible but not very practical.

My next solution would be to improve the friend system to be more intelligent.  Instead of storing a list of people the player manually types in, it could store a list of acquaintances that the player has met over time.  It could list people he met, ordered by zones, time spent with the person, number of interactions with the person, etc.  This way the player would build a network of contacts in the world without having to manually type in their names or numbers.  These two systems not only improve the experience for the player, but also improve immersion since this is normally how people relate to each other.  I can think of five different ‘Chris’s I know, but when attempting to address one I use the social path that has been created between us.  My social network determines the means to communicate.

Mail

Another tricky problem which can be gracefully solved by an expansion on the friend list concept I wrote about above.  When the player tries to send mail he can browse his social network for a contact to send mail to.  This is a good time to mention that chatting with another player would make a new network with that person.  This includes someone chatting in general, city, trade, whatever.  To model those interactions a network of recent chat messages would be displayed for the player to pick out the appropriate recipient.

Groups / Raids

Most groups and raids are formed by pm messages or chat window invites.  Since we have already established that in the chat window a name is really a character id handing invite requests is as easy as opening a new pm.

A final note about the new social system.  Updating and management does not need to be left completely to the program.  With a new friends system comes a completely different way of interacting with players in the world.  Players should be able to modify their networks, add people to groups, tag communities of links.  I have more than once wished to have a system where I could tag players or organize relationships by specific words.  Not wishing to come off as an elitist but I am sure more than one of you have wanted to tag someone ‘noob’, ‘idiot’, or  ‘can’t play his class.’  With a more friendly social network system you could organize your contacts, including all the people you no longer want to interact with into a group.  Then when they say something in chat, send you a pm, invite you to a raid, you will have fair warning.

When all is said and done I am really advocating a new type of system for interacting with players in an online world.  One built on networks of links instead of a simple one dimensional friends list.

Ok, enough of the shameless self promotion, as for blog content.  I have a couple articles in the works but have yet to publish them as usual.  I have been a little lazy the last few months due to a varity of things.  Firstly college obviously, secondly I have adopted a new sleep schedule known as polyphasic sleep.  During my adaption period I fell behind on a lot of projects I was working on so I am now catching up.  I might post a summary of my research and theories on this sleep schedule, but I did not want to do a daily sleep log like thousands of others have.

Also on the backburner is an update to my game AI project.  After running some scalled tests involved word processing I have moved into simple game development to test action automation and decision making.  The first difficulty involving the 3d engine has been crossed and I am not in AI development mode.  I chose to use Ogre3d as the engine mainly because I have had positive experiences with it in the past.  I will be posting my research on that project soon.

First off let me say that I use debain as the main operating system for ALL my servers.  My asterisk, data, and web servers all run debian and I love the stability and flexibility that comes with debian and apt.  I have spent at least 4 years working with debian casually and through all the problems, ideas, and solutions that are typical in my line of work have presented me plenty of opportunities to exercise and expand my knowledge of linux.

It was just over a year ago that I tried moving to a linux environment on my laptop.  Since my laptop was custom built all the parts worked well with ubuntu and I had very little configuration troubles.  Unfortunately after a couple months I encountered problems caused by my tinkering that made me have to reformat.  I believe at the time I was trying to get Compiz or Beryl to work with my ATI card, something I think caused a lot of people some hair.  At the time I decided to reinstall Windows XP because I could no longer justify the inconvenience of playing around with linux when I could not make it do what I wanted.  This I will admit was because at the time I had very little experience with linux desktops, and my number one gripe was network configuration, which does not seem to have improved but more on that later.

This is a post about why I believe linux is not ready, nor should it try to compete in the PC desktop market.  Linux is an excellent server environment make no mistake, I would choose linux over Windows Server any day of the week.  I find the code for critical applications to be very well maintained, optimized, and in general very clean.  On the other hand, I find the code for desktop environments and ‘configuration GUIs’ to be a joke and buggiest pieces of software I have had the misfortune to work with.

For further reference, 4 days ago I decided to reformat my Vista desktop to Kubuntu, an operating system I had worked with in vm’s and had pleasant experiences with.  I chose to leave Vista because of a bug with USB hand off to my virtual machines, which is a crucial element of programming a Nokia 810.  This inconvenience was the last straw for me and I made the decision to reformat to an operating system I felt would work better for control freaks like myself.

My first impressions of kubuntu, was the very excessive amount of useless garbage programs sitting in my application menu.  My second problem was with the desktop widget system which would seem like a good idea but is executed very poorly and is not very user friendly to say the least.  After removing as many of the useless programs I could and installing some other better programs I opened firefox and was greeted by the ugliest looking interface I have ever seen.  I will admit, I have never been a fan of the GTK interface.  Even on windows I found the layouts and graphics to be messy, unappealing, and bland.  So when I came to realization that my entire desktop would look this way I was a little put off right off the bat.

However I was determined to give this a chance since indeed I needed to be able to program my new Nokia 810 and linux was the only solution.  I visited the Ubuntu forums, a place which actually deserves the praise it gets, and found various things to do ‘Right after installing ubuntu.’

I installed more programs, added sources for my media and graphics, updated openoffice, speed tweaked the file system and boot process, and was fairly happy with the end result.  Firefox looked half decent, my programs had neat little effects like wiggle, darken, etc, and most of all it was running on par with my windows system.  So I began to seriously exercise the system and bring it up to my standards.  I installed dmraid to manage my nvidia raid array, I got my other disks provisioned in fstab for automatic mounting, configured all my programs to work exactly as I wanted them to, and in general personalized the system to my liking.

It was during this time that I started to notice the little problems and glitches.  Firstly, I was not happy to see that the network manager was still the worst configuration app in the entire system.  I ended up uninstalling it and setting a static ip in network/interfaces.  Then came the problem of getting my dual monitors to work, and in turn, get nvidia drivers installed.  The automatic ‘Install restricted drivers’ wizard failed to produce any results, so I turned once again to the ubuntu forums and a script called Envy which did the job very well.  Configuring TwinView was then just a simply xorg.conf edit.

This brings me to point number one.

Linux is not ready because to much configuration is left to the command line

The gui configuration utilities simply do not work.  Those that do work have limited functionality and you end up configuring it yourself in the command line.  When was the last time you saw a standard user open ms dos to configure his network settings?

So as I finished configuring various systems and building the system as I saw fit I decided to try to actually use the os.  Opening firefox still left me with flash backs from 10 years ago, but it worked fine, so all was good.  I then downloaded and installed pidgin, as I could not live without a constant line to any of the people on my buddy list and was once again greeted with those flashy windows 95 graphics.  At this point I was getting pretty frustrated.  Sure, my windows swayed, they faded, I could alt-tab like a pro but my applications looked like they were resurrected from my old DOS laptop.  Something had to be done, so I immediately went online searching for solutions.

I found that you have the option to install custom themes for things like text layouts, colors, window styles, etc.  Something that I have never really used on Windows but I went ahead and dived into the top rated everything to bring my operating system into the year 2008.  I found that these layouts helped a little bit, but the real problem, boxy art, out of date pictures, remained.  It was at this point that I decided to look for different GTK themes and customizations, hoping to fix the problem at the source.  However I soon found out that GTK artwork is non-existent, very hidden, or just not possible.  Tell me what is the point of a centralized graphics framework when you cannot change themes?  This definitely deserves a check-minus in my book, and introduces point number two.

Linux is not ready because the system looks like crap

While the underlying framework and core operating code is fantastic, the GUI’s and desktops need work.  KDE4 from my understanding is an attempt to mimic some of Vista’s features and has been touted as the better desktop.  I could not disagree more.  The system was buggy, slow, and definitely not user friendly at all.  As a side note, in the little time I spent analyzing and poking at KDE4 I could never figure out why we needed a separate desktop ‘Widget’ to display files that are in the desktop folder.  The widgets sit on the desktop, but the widgets display the desktop files…

As an additional side note I have only had the pleasure of using Gnome, KDE and a splash of X during my brief forays into the linux desktop world, if there is a better desktop out there please feel free to post.

At this point I was pretty frustrated with the whole mess so I went to sleep and decided to work on it more in the morning.

After a good night sleep I was back on my computer and ready to tackle the operating system once more and amidst the endless forum searches, configuration tweaks, Dolphin crashes, I realized something.  This something is my third and final point and probably the one that will get the most flames.

Linux is not ready because linux does not work for the user, the user works for linux

Let me explain what I mean.  While I was wondering around the settings screens (the few that there are) I found myself continually frustrated at the limit of what I could change, configure, optimize, or just in general, ‘do.’  Linux is very much a arrogant bastard who would much rather give you a new world and say have fun then give you the tools to operate in its world.  When using windows, all the tools you need to change the system are given to you, right out of the box.  If you want to do something incredibly difficult, like add a 3d desktop or program your own file explorer, you are pretty screwed, but for most situations windows gives you the tools to handle the problem yourself in its world, not your own.  Linux on the other hand, even though its open source, is ruled by obscurity.  There is no consistency between the network configuration and the display configuration.  There is no intermingling of different programs, as was painfully pointed out to me when I tried to burn an iso image from a windows machine across the network.  All and all, linux is very introverted and unlikeable.  Now I must make a small note here, the ubuntu community needs to be given a handshake for their excellent effort on compiling useful guides and providing help to any strangers who grace their doorstep.  Unfortunately, all the smiles and friendly hand shakes do not detract from the serious design flaws inherent in any operating system in the hands of anyone who uses it.  And even though I hate to say this, I much prefer my operating system built by a money corporation where strict testing, quality assurance, and optimizations are kept at the forefront, not for the customers, but to make themselves competitive with other corporations.  On that note I would like to say that I might actually prefer to try a Mac OS next time I feel pined down by the Microsoft money machine.

So there in lies linux’s biggest problem.  It is not competing.  Not that it does not want to, it just can’t.  It can not compete with the multimillion dollar budgets of Apple and Microsoft dev teams, and it certainly cannot get any decent project management system in order to organize the thousands of varying and unique programs built for it since release. But this is OKAY.

Its OK that linux can not compete, its OK that the programs are different.  What is not ok is trying to convince people to install linux on a desktop or laptop pc where hardware is never consistent, drivers are always needed, and just getting the thing to recognize and deal with the thousands of different environments is itself a full time job.  No this is not where linux’s strength truly lies.  To find where the future of linux lies I took a look back at the device that started all of this.  The small, sexy, and very much in control Nokia 810.  This little device is run by a special operating system built off of debian called Maemo.  You will find no better example of synchronous design and program execution then here.  Why?  Because its not a pc, its not a computer that needs a new video card every two years, it does not need to know about any other devices outside of its own perfect little world.  That is what makes it the best version of linux I have used.  The system is still open, but users do not have to draw cards to tell whether they will spend 5 hours getting running or 5 days.  With this increase in freedom comes standardized programs and configuration GUIs, systems that actually WORK.  The Nokia works so flawlessly that it inspired me to first install Kubuntu, then write this article because I feel that the future of linux does not lie with the desktop pc, but with these small devices.  These devices, that have a set of unchanging hardware, guarantee that no network manager will crash when detecting your Broadcom modem model number x15220 from 1997.  It guarantees that when you run network configuration your settings will take effect on your true device, instead of usb0 or visa versa.  I am currently reinstalling Windows Vista on my computer and with that I will reinstall VMWare and find a solution to my original bug so I can setup the maemo sdk and start programming applications for this device.  Yet in order to do this I am ditching my linux desktop solely because I just could not stand it compared to Vista.  Vista is by no means perfect, and in some ways it can make me just as frustrated as Kubuntu did, but I can accomplish a hell of a lot more in a windows operating system at this time.

Maybe this will change, maybe there is some other desktop environment that people like me use and I am unaware of it.  Certainly if you the reader have any suggestions I would welcome them and maybe even consider reformating again to try them, but at this moment I stand by what I have said in this article and hope that those who read it can offer constructive feedback, good or bad.

If you can think of a good solution feel free to post your ideas, today I will be writing about my solution and things that worked and did not work, and things that still do not work.

The situation I am referring to here is parsing a call data file known as a BAF file.  The file structure and definitions for these files are described in detail in a document known as the GR-1100 which is published by Telcordia.

To parse this file your program must know and recognize about  1000 different field types and 200 different record types.  Fields are organized in records, you can probably say that records are defined by their fields.  Oh, also, there are about 100-200 defined modules that theoretically can be appended to any record.  Each module is again a set of fields.  So if you were to summarize this file it would be laid out like this.

Record Start
Fields
Record End
Any number of modules
New Record

I have already talked about pluggable factories, which is the main design element I chose when first designing bafprp.  I decided to create a maker factory for fields and records, and define each field and record as a class.  Now this was BEFORE I found out exactly how many different types of fields and records there were in total.  All I had to build off of was an open source project called bafview which contained a very small subset of the actual fields and records that are defined in the GR-1100.  I only recently learned about the inadequacies of this subset when I was notified about missing records and fields that were not in bafview, and thus, not in bafprp.

When I released version 1.0 of bafprp it contained only about 100 different fields and records.  A number small enough that the maker factory pattern made sense.  Obviously however this needed to be changed if bafprp was to become a complete GR-1100 compliant program.  So now we must free ourselves from the basic design and fall back to the drawing board.  Something that many designers, myself included, are very bad at doing, and so I did not.  Instead I though about another solution, which extended the concept of pluggable factories into what I will very loosely call run time programming.

Now do not jump to any conclusions about a self correctly, self building, automated executable.  This is NOT run time programming in the strict sense of the word.  What I did not was allow for the extendability of certain classes at run time.  Meaning that a basic class is interpreted hundreds of different ways depending on run time data. Using this method I created a handful of basic classes that could be extended by strings passed by a user to define the specifics of the field.  To define the default fields the default data is hard coded into the program, but the user has complete control over any field in the program through two specific command line options.

There are some similarities to basic scripting, if that is what you were thinking.  There is one major difference however, bafprp remains in complete control over the program.  With scripting languages the program surrenders part of itself so the user can change default behavior.  In bafprp the basic classes remain in complete control of the operation, but the user has complete control over the data.  Something that I have not seen done in any other program yet.

So by now if you are still reading you are probably itching for some source code.  The design is pretty simple, we have eight or so basic types using the pluggable factory design.  These basic types operate on string data passed to them, how they operate and the string syntax is completely up to them, however for these elements I had them conform to property name, property value pair of strings for operating data.

Here is a simple example of my Date field type

std::string DateField::getString() const
	{
		LOG_TRACE( "DateField::getString" );

		std::string ret;
		if( !_converted )
		{
			LOG_WARN( "Tried to get string before field was converted" );
			ret = "";
		}
		else
		{
			char year[5] = "";
			time_t ltime;
			struct tm* mytm;
			ltime = time( NULL );
			mytm = localtime( &ltime );
			strftime( year, sizeof( year ), "%Y", mytm );
			year[3] = _return[0];

			property_map::const_iterator itr = _properties.find( "format" );
			if( itr != _properties.end() && itr->second.find( "Y" ) != std::string::npos && itr->second.find( "M" ) != std::string::npos && itr->second.find( "D" ) != std::string::npos )
			{
				ret = itr->second;
				ret.replace( ret.find("Y"), strlen( year ), year );
				ret.replace( ret.find("M"), 1, _return.substr(1,2) );
				ret.replace( ret.find("D"), 1, _return.substr(3,2) );
			}
			else
			{
				std::ostringstream os;
				os << year << "-" << _return[1] << _return[2] << "-" << _return[3] << _return[4];
				ret = os.str();
			}
		}

		LOG_TRACE( "/DateField::getString" );
		return ret;
	}

The date field will take a format property and change the data it converted appropriately. This is an example of a basic property that each field can have. For a more complex operation here is the same switch function

std::string SwitchField::getString() const
	{
		LOG_TRACE( "SwitchField::getString" );

		std::string ret = "";
		if( !_converted )
		{
			LOG_WARN( "Tried to get string before field was converted" );
			ret = "";
		}
		else
		{
			props_pair switches = _properties.equal_range( "switch" );
			std::string sw;
			if( switches.first == switches.second )
			{
				// No "switch" property so assume we switch on character 0
				sw = "0" + _return;
				sw.resize( 2 );
				property_map::const_iterator string = _properties.find( sw );
				if( string != _properties.end() )
					ret = string->second + " ";
				else
					ret = "Unknown: " + sw.substr(1);
			}
			else
			{
				for( property_map::const_iterator pos = switches.first; pos != switches.second; pos++ )
				{
					sw = pos->second + (char*)&_return[ atoi( pos->second.c_str() ) ];
					sw.resize(2);
					property_map::const_iterator string = _properties.find( sw );
					property_map::const_iterator desc = _properties.find( pos->second );
					if( string != _properties.end() )
					{
						if( desc != _properties.end() )
							ret += desc->second + " = " + string->second + " : ";
						else
							ret += string->second + " : ";
					}
					else
						ret += "Unknown: " + sw.substr(1) + " : ";
				}
				ret.resize( ret.length() - 3 ); // remove last ':'
			}
		}
		LOG_TRACE( "/SwitchField::getString" );
		return ret;
	}
}

Now here is my general disclaimer, if you see problems with this code feel free to let me know I know it is not 100% efficient and perfected and this is because I have never done this before so I was making up design as I wrote the code.  Eventually I will do yet another rewrite and fix the code with a more complete understanding of the design.

But the switch function needs some explaining.  I think it would be best to see an example switch field

		FieldMaker::setFieldProperty( "calledpartyanswerindicator", "datatype:switch" );
		FieldMaker::setFieldProperty( "calledpartyanswerindicator", "size:1" );
		FieldMaker::setFieldProperty( "calledpartyanswerindicator", "desc:Called Party Answer Indicator" );
		FieldMaker::setFieldProperty( "calledpartyanswerindicator", "switch:0" );
		FieldMaker::setFieldProperty( "calledpartyanswerindicator", "00:Called Party Answer Detected" );
		FieldMaker::setFieldProperty( "calledpartyanswerindicator", "01:Called Party Answer not Detected" );
		FieldMaker::setFieldProperty( "calledpartyanswerindicator", "02:Answered Attempt" );
		FieldMaker::setFieldProperty( "calledpartyanswerindicator", "03:Simulated Called Party Off-Hook Indicator" );
		FieldMaker::setFieldProperty( "calledpartyanswerindicator", "04:NCD, CAS, Blocked After Answer" );
		FieldMaker::setFieldProperty( "calledpartyanswerindicator", "05:NCD, CAS, Blocked Before Answer" );
		FieldMaker::setFieldProperty( "calledpartyanswerindicator", "07:Service Features Not Provided, Call Answered" );
		FieldMaker::setFieldProperty( "calledpartyanswerindicator", "08:Service Features Not Provided, Call Unanswered" );

Ok so first we set the basic data that defines a field: type, size, and desc. This is all that is required to make a field. We then setup a switch on character zero by setting the switch property to zero. The properties after that list the values for the switch. If the switch character is zero print “Called Party Answer Detected,” and so on. The syntax for these are to have the property name before the value, separated by a colon. This of course is completely arbitrary and can be anything depending on how you want to assign properties. The property name syntax is the switch number first, then the switch value. Only two characters are required because I only allow one character switches.

The trick here is how the switch class uses its properties.  For the date object, all it did was change the format of the date, however the switch completely depends on the properties to be set correctly to function properly.  The properties of a switch class define the switch, whereas the properties of the date class hardly do anything.  It is this range of effective designs that make the application successful and indicate proper orthogonality, which is the number one most important design philosophy.

I am finding that increasingly complex posts are getting difficult to write and even more difficult to read so from now on I am going to try and keep posts small and exercise a specific element instead of the whole design. I left a lot out of this post simply because this is a blog not a research paper, so I will try and get some more data posted soon.
In the meantime, you can always check out the source at bafprp’s web site.

Here is the basic idea, you have x number of objects your program can create.  These objects are all children of a base interface.  You have cleverly created an abstract factory to create the various instances of your objects, but there is a problem, you are asked to add several new objects and/or remove several objects.  So you jump back into your code and make a new object or remove an object.  You compile your code and try to use the new object, OOPS, you forgot to add it to the abstract factory!   Or, after removing the object you run some old data and OOPS, your program crashes as it tried to return an instance to a class that does not exist.

To be fair, if your program was written correctly it would not compile in the latter case, but that is besides the point.  Sometimes abstract factories can be a pain in the ass.  So, here is where pluggable factories step up to the plate.

They offer you the ability to create or remove objects without modifying any part of the project.  All you, as the programmer, need to do is create a new cpp with two well defined classes and you can use your new object.  How does this work?  It relies on a very simple but powerful aftereffect of static objects.

See, the basic idea of a static object is that only one exists.  It gets setup at the start of your program and never moves or changes.  If it is a method, it gets a special place in memory and any children of your class call that exact function.  If it is a variable, it gets initiated at the start of the program and all references to get sent directly to that location, no mater where in the program you are.

The idea behind pluggable factories is that you silently initiate several classes that only exist to make one specific type of object.  These classes are known as makers, and they are the key to pluggable factories.

Makers come in many different flavors and styles, but we will focus on one type for now.  Let us define an object derived by a common interface.

class Controller_Letter : public IController
{
    friend class Letter_Maker;
public:
    ~Controller_Letter() {}

    int fitness( void* data )
    {
    if( (char)data == _letter || (char)data == toupper(_letter) )
        return 1;
    return 0;
    }
    void perform() { printf( "%c", _letter ); }

protected:
    Controller_Letter() {}

private:
    void setLetter( char letter ) { _letter = letter; }
    char _letter;
};

Now this is a basic controller class for a project of mind, so do not pay to much attention to the methods. From the basic idea of this controller, I would want at least 26 of these classes, but to be safe I will instead make 255 of them. Can you imagine a switch statement with 255 cases?

To make our lives easier we will construt a pluggable factory to automatically create each class.  A pluggable factory is made of three parts, a std::map, a constructor, and a pure virtual make method.  The map will store our database of makers, the constructor will be used by our children to register with the database, and the virtual method will be defined by our children so they can make their object.  Lets take a look at a basic parent maker class

class Controller_Maker
{
public:
    static IController* newController( const std::string& type, void* data );
private:
    typedef std::map<std::string, Controller_Maker*> maker_map;

    static maker_map& getReg()
    {
        static maker_map registry;
        return registry;
    }
    Controller_Maker() {}
protected:
    Controller_Maker( const std::string& type )
    {
        getReg().insert( std::make_pair( type, this ) );
    }
    virtual IController* make( void* data ) const = 0;
};

We have defined all three parts, but there is something I would like to point out to everyone.  Notice the getReg function.  It would make sense to have our registry variable static inside the class, then have the children directly access it to register themselves, HOWEVER, here is the problem.  When your program gets compiled all your static elements are juggled by the linker and eventually end up sitting in an initialization list somewhere in your binary.  Among these variables are your child makers trying to register themselves in the registry.  Imagine what would happen if a child is initialized before the registry map is.  BOOM CRASH BANG, yep, you get a splendid show of fireworks before your program disintegrates back into the void.  The getReg function is how we avoid this very nasty problem.  See, functions do not need to be setup before hand, a static function is just an address, it can be called at any time.  Therefore we put the registry inside a static function, and we can guarantee that it gets initialized before a child tries to use it, because when a child uses it they initialize it.  Simple eh?

So now you have a maker, an interface, and an object you want many many variations of.  How do you define the individual makers to first register with the parent maker, and second, create the desired object?  Child makers will, as you may expect, define the make function from the parent maker and call the parents constructor.  However the key to child makers are the static instances of themselves they define.  It may sound weird, but each child defines a variable inside itself of itself.  This variable is initiated at the start of the program ( because its static, remember? ) and thus the child is registered with the parent.  Here is the child maker

class Letter_Maker : public Controller_Maker
{
protected:
    IController* make( void* data ) const;
private:
    Letter_Maker() : Controller_Maker( "letter" ) {}
    static const Letter_Maker registerThis;
};

Notice the constructor, it calls the parent with the type of object it makes, thus registered a new type of object with the pluggable factory.  Also key here is the registerThis variable. The only purpose of this variable is to register the class without modifying any factory or project source.  This class is naturally defined with the class it creates, this way you just add a cpp to the project and you have a new object.  Impressed yet?  Lets dive a bit further.

If you have been paying attention you have noticed that I have not defined some key methods, namely, Controller_Maker::newController or Letter_Maker::make.  Well it does not take much imagination to define these, here they are

IController* Letter_Maker::make( void* data ) const
{
    Controller_Letter* ret = new Controller_Letter();
    ret->setLetter( (char)data );  // Sending NULL will not hurt anything
    return ret;
}

IController* Controller_Maker::newController( const std::string& type, void* data )
{
    maker_map::iterator itr = getReg().find( type );
    if( itr != getReg().end() )
        return itr->second->make( data );
    return NULL;
}

I usually keep these methods separate from the header files for neatness sake.  Here is the quick run down on these.  Letter_Maker::make will make the object it was build to make.  Think of it as a small builder ( if you have read Design Patterns ).  Its important to not fall into temptation and pass void* data to the new object.  Notice how I create the object then call its setLetter method?  The maker data should stay independent of the object definition.  Remember DRY?

Controller_Maker::newController is just what you probably expected, it simply searches the registry for the type of maker we ask for and calls the specific maker’s make function.

In the end, we are left with a nice set of classes that can easily encapsulate all 255 acsii characters in just 255 lines ( if someone wants to add up the maker and controller class lines be my guest ).

Here is how we use the maker

IController* a = Controller_Maker::newController( "letter", (void*)'a' );
IController* b = Controller_Maker::newController( "letter", (void*)'b' );
IController* c = Controller_Maker::newController( "letter", (void*)'c' );
IController* d = Controller_Maker::newController( "letter", (void*)'d' );
IController* e = Controller_Maker::newController( "letter", (void*)'e' );
IController* f = Controller_Maker::newController( "letter", (void*)'f' );

Keep in mind that is by far the simplest way to use pluggable factories.  For more examples you can check out bafprp’s source code, pluggable factories are used for creating fields, records, and the most interesting of all is the output class, where I merged the maker and the object into one class.  And that is not all as far as I know I have barely even scratched the surface of pluggable factory design, so if you come up with a new technique, feel free to post!

Project source code here!

My first logging framework was log4cplus, which is a very nice and complete logging framework for C++. I used it for one linux application I wrote and it works perfectly despite being several years old. Unfortunetly I was uncomfortable with how much work it took to write a message each new function ( two lines instead of one ) and it would not compile in windows so for my next application, bafprp, I set out to write my own.

When I completed the class I was left with one macro to print a log message depending on the level you wanted, ie, LOG_TRACE( string ), LOG_DEBUG( string ), etc. I then made sure I was adding trace messages to each and every function as I made them, instead of later on in the design. For example, an empty function would look like


void BafRecord::getType()
{
LOG_TRACE( "BafRecord::getType" );
LOG_TRACE( "/BafRecord::getType" );
return;
}

Each function would have a start and stop trace message.

Now this might raise an eyebrow or two but I assure you it definitely helps when your program crashes and you do not have a nice debugger on hand. Like say, if a non-technical user is using it.

This is how my linux application was programmed and I went the extra step in bafprp to work these in while I was working. Enough about this though, a short while ago, after adding one of the major structure types to the program my application slowed down from parsing a 12 meg file in 2 seconds to 2 minutes and I was greatly concerned over the well being of my design.

I tried many things, first I greatly reduced the number of memory copies my program executed, then I changed my file input so that it would read the entire file at the start and reference a data bank instead of reading the file each cycle. However none of these things put a dent in the processing time. So then I went online to try and find a nice and easy code profiler. Code profilers will basically watch your program execution and tell you which function your program is spending the most amount of time in. I ended up finding LTProf which allowed me to profile my program without recompiling or changing my program at all. I am actually very surprised at how well it works with compiled binaries. After running a release version of my program it was still able to accuratly determine function names and operate like it had a window into the source code.

I found that my time stamp function, NowTime, which returns the current time as a string, was taking a noticably large amount of my program’s time. Thinking back to what code uses this function I discovered the flaw.

When I wrote the log program I wrote the log level exception into the log class. This way if the program tried to log a trace message it would get sent to the output class, which would then pass it on to the logs if the level was at or below the log level type. However this was not enough. as it turns out simply creating the log message twice in each function had a substantial effect on the processing speed of my program.

Needless to say as soon as I moved the log level check to the macro the process speed dropped from 2 minutes to 30 seconds. Now some might say that trace logs this detailed are excessive, however I believe they can help greatly when dealing with a malfunctioning program. So as a final statement, be careful when you design systems, and beaware of how to use your tools. And if your program runs 3 times longer then a similar program, there is probably something horribly wrong.

As some might have expected this project is taking more time then expected, partially because I am currently downing bosses in WoW, and partially because its very hard. So lets just cover what has been going on since my last post.

I spent a lot of time thinking of the best structure for my idea in terms of objects and file formats. I do not know if I covered this before because I am to lazy to view my past posts so heres a recap of the basic composition of what I have been calling a ‘Puppet.’ A puppet is a game object with x number of movable joints. These joints are built in a tree structure and move based on messages passed to his parent. These messages are generated from a actor class who learns actions and movements as I previously discussed. When I was designing the puppet class I hit a big fat road block. I wanted the ability for a puppet to be independent of his underlying joint structure. That way I could have a puppet control everything from a human to grass. So you might think, ‘No problem, do some tricky interface work and have derived classes for each type of puppet.’ WRONG!

See I myself have read many articles about component game object design, and I do believe I wrote an article on this in the past. However do not get the wrong idea, what I did is not EXACTLY component objects, but kind of close. Because when I thought about components I also thought how to best describe them in a file format. And after thinking about that I decided that I wanted a global file format to describe not only each type of puppet but the entire world. And that the entire game will be built out of components in a tree structure built at load time from this file format. I am getting a bit ahead of myself here so lets get some examples here.

<world>
<name type=string>Main</name>
<description type=string>
Big world for which to run tests in
</description>
<floor type=plane>
<p1 type=vector>-1000 -1000 -1000</p1>
<p2 type=vector>1000 1000 1000</p2>
<material>dirt01.mat</material>
</floor>
<joint>
<position type=vector>0 0 0</position>
<orientation type=vector>0 0 0</orientation>
<puppet>arm.puppet</puppet>
</joint>
</world>

This is my toy world I am working in. The file format is xml and I use tinyXML to load and parse these files. For those familiar with ogre, I made a resource of type XMLFile to load these. Now here comes the clincher, this XMLFile resource will load every type of game object I desire, regardless of type or purpose. Not only that, but I only added 2 methods to the class.

So let me explain a bit about these methods, they are named ‘build’ and they are called usually immediately after loading the file. Basically what they do is look at an element in the xml, find a builder for it, have the builder build it, and attach the new object to the world tree. In this example, the world has no parent and all elements inside the world tags are children of the world. I use the type descriptors so that I would not have to write many classes that do the exact same thing. Elements that load another file, like the puppet tags, will load that file in their own world and all objects created from that are children of the puppet. After the build the main program is not aware of any object other then the world. Messages are passed to the world when need be, however most thought processing is done in the world object, not by the game engine.

Lets get an example puppet up here:

<puppet>
<name type=string>arm</name>
<description type=string>
Generic arm
</description>
<joint>
<name type=string>shoulder</name>
<gib>upperarm.gib</gib>
<joint>
<name type=string>elbow</name>
<gib>forearm.gib</gib>
<joint>
<name type=string>wrist</name>
<gib>hand.gib</gib>
<joint>
<name type=string>pinky</name>
<gib>pinky.gib</gib>
</joint>
<joint>
<name type=string>ring</name>
<gib>ring.gib</gib>
</joint>
<joint>
<name type=string>middle</name>
<gib>middle.gib</gib>
</joint>
<joint>
<name type=string>index</name>
<gib>index.gib</gib>
</joint>
<joint>
<name type=string>thumb</name>
<gib>thumb.gib</gib>
</joint>
</joint>
</joint>
</joint>
</puppet>

As you can see this file format is very flexible, the same structure that built the world can build a puppet and also a gib:

<gib>
<name type=string>forearm</name>
<notes type=string>
Fore arm gib
</notes>
<mesh>forearm.mesh</mesh>
<input>
<name type=string>shoulder</name>
<position type=vector>0 0 0</position>
</input>
<output>
<name type=string>elbow</name>
<position type=vector>7 0 0</position>
</output>
</gib>

I want to clarify one thing before I go on. Elements called position or orientation, these attributes are not given any attention by the builders. Instead those objects simply exist on the tree for someone else to read them and make the correct adjustments. For example, the puppet’s name element simply sits as an element on the tree until a debugger opens and the entire tree structure is displayed. At that time the debugger will go through each element and find name tags that it will use to give more information on the node. And the description works the same way.

They are both created by the string builder, as denoted by the ‘type=string’ attribute I give them. The value is assigned and the name of the new object is set, but the type is always a string.

So what exactly is required to declare a new type of object? Just a builder and an actual object. Take this example of the string object.

class ScktString : public ISocketable
{
friend class StringBuilder;
public:
void setValue( std::string val ) { _string = val; }
std::string getString() { return _string; }
private:
ScktString( std::string propName ) : ISocketable( propName ) {}

std::string _string;
};

class StringBuilder : public IBuilder
{
public:
StringBuilder() : IBuilder() {}
Socket* build( std::string element, Socket* parent );
const std::string& getType() const;
static std::string BUILDER_TYPE_NAME;
private:
static const StringBuilder registerThis;
};

As you can see its relatively easy to create a new object. Lets start at the builder, when the xmlfile is building it will search for a builder based on its type name, which is assigned by you. A builder list is created at the start of the program, as each builder has a static ‘registerThis’ variable that adds it to the builder list. Those familar with static factories should be familiar with this. The builder’s build method gets called with the name of the element and its parent’s socket. A socket is an object that accepts links from children. The builder then builds the object passing its name. The sockable base class is for objects that can be socketed or linked with a parent.

So the string object is created and the string builder passes back the parent object. This is done in case the new object has a socket himself. In that case he would pass back his socket and the builder would build his children and attach them to him. In string’s case however, there is no socket and a little while later the builder assigns the string object a value by calling the setValue method in the parent object with the objects name and value as parameters.

After all the work we are left with one tree that contains all objects in the game. Kind of like a scene manager, but for ALL objects, not just renderable ones. And oh, don’t forget that the entire tree was created by one instance of XMLFile. As programmers we should always strive to achieve the cleanest and most powerful format we can muster. This format is not only really easy to implement, but also holds unlimited power. You want to load a texture? Create a texture socketable object, and implement file specific loading inside it. You want to script AI? Either create an AI socketable object that reads children objects that decribe a strategy, or create a python socketable object that will load your ai scripts and parse them. In this way our file format can act a proxy for another format or as the direct format. The most important thing however is that none of our in game objects need to give file formats a single thought.

I started by defining what I would be given, and what I would need to produce, and I decided to start with nothing but basic preprogrammed controllers attached to the actor’s to control everything about it. Rotation, position, scale, etc. For an npc, he would have controllers on all his bone joints, for an example. These controllers will have a predefined range of accepted values and know how to move around those ranges. What I wanted to end up with was a high level action, something that will ultimately be composed of hundreds of controller movements over time. And I needed a nice system to wrap up all this data into a structure the npc can store and build off of.

To start off, picture a flat plain of controllers. Each controller knows what it can do, but there are no existing actions yet so this npc is stupid as a brick. During training, actions will start simple, something along the lines of, ‘bend index finger’ works. The npc would look at its action graph and see only the flat plain of controllers, so then its asks each controller if it can accomplish the task of moving the finger’s x position by 1. The controller(s) that respond will have already been defined as able to do this so the npc builds a new action that connects directly with the controllers found previously. Now if the game asks to bend a finger, this action will say ‘I can do that’ and use the correct controller to chance the finger’s position. Its worth noting how the action knows it can do this, so I will explain that a bit. Each action has a function that reads the actor’s current state and determines if it has actions or controllers in its collection to handle that state in any way. If it does, it says yes.

So as the npc adds more and more actions it builds it’s web of linked actions, the process looks a lot like building a neural network. Actions have many actions linked to it, and many actions linked to. I cannot go to much farther without showing you the action class definition so here you go:

class Action
{
Action();
Action( Action* next );

bool validStart( Actor* );
bool validEnd( Actor* );

void AddNext( Action* );
void RemoveNext( Action* );

private:

std::set<Action*> actionList;  // Each entry in this action array represents a start state.
// What about actions that have many independant start actions?
};

When designing this class I thought it was going to be some monster from hell, but after I thought about it, added some recursion, and trimmed it down I think it ended up rather nice. Its simple and works well. Each action will hold links to one or more actions. Each action link represents a valid start state, so when validStart is called the class should call each of it’s start states validState functions and return the OR of their return. This design is very recursive, a next link could be another action or a controller at the very basic level. Therefore chains of actions will form in neural network fashion with proper training. When the npc wants to change his state (execute an action) he simple needs to figure out what state he wants to be in, call validEnd( endState ) on each of his higher level actions that match his start state and if one matches, execute the action.

Only problem here is the tremendous overhead of using the brain. Take an example actor with just three levels of actions, when the game asks to do an action on the third level that action asks for valid start on all level 2 actions linked to it, and in turn those level 2 actions call valid state for all level 1 actions linked to it, which in turn call validstart for all controllers that are linked with it. We could be looking at thosands of function calls with a simple 4 or 5 level npc. And the growth is
exponential.
For now we will just have to deal with it since I believe this to be the best way to describe dynamic actions however in the future tremendous effort will be required to optimize this code.

I will be working on integrating this design into my demo project so if my explanation is way off I will have sample code sometime soon.

I have been working on this component AI idea and have come to the point where I need to start defining actor actions through scripts. How I have it setup now is the npcActor’s state will slowly degrade over time (think the sims) and when it reaches a threshold they go and search for an object that can alleviate their problems. Its a pretty simple design for a simple test. As mentioned in previous posts, I want these npc’s to learn from interacting with the environment. This combined with the mbti structure and other things should produce reasonably agile AI (see previous posts for specifics).

I thought of making this post to stress a key factor in my decision making process as it pertains to this project. And that is abstraction. The abstract is key to this project. In an ideal world, nothing here should be hard coded, unfortunately that is a little hard to do, especially right from the get go. So what I decided to do was to brute force my way to a reasonable demo app and work backwards from there. Removing static code as needed to perfect the design. For instance, I have pretty much decided on a syntax for my scripting language, but I have left much of the interpretation to genetic algorithms in the compiler. Here is a sample script


using actions
using health

_actions::sit $this
$sitting = true
callback -actions::stand _stoodup
{ $health::comfort +1 / 5 } while $sitting

_stoodup:
$sitting = false
::
I am not going to explain the syntax because to any programmer the intentions should be clear. The problem I have been facing is how to keep the intentions abstract enough to allow multiple interpretations. I want Bob’s sitting to look different from Kim’s. I have currently setup a system where the compiler creates these jobs for each script and at the appropriate times sends messages to actors to handle actions. It is then completely up to the actor as to how to handle the action. For instance, when the compiler runs over ‘_actions::sit $this’ it will send a message to the host actor to sit on the target object. In this case the message will not be as simple as

msg.id = ACTION_SIT;
msg.target = 0x01234567h;
msg.brainless = 1;


Instead the message will contain a number of input to be inserted into a designate neural network, which would have been trained earlier to sit when given those inputs (exactly how they sit is up to the GA).

So then how to handle direct variable access like the ‘$health::comfort +1/5′ line above. Well some messages will have to be specially constructed to be brainless. I figure I will have a range of message id’s designated for variable access, neural network input, etc. So a msgID of 1 would be to set a variable, and 2 would send the incoming data into the NN.

This is not the final system, just what I am currently using for testing. However this is the current framework for future applications. The goal of this first program is to weed out any bugs and get a clear understanding of how I want this thing to run.

You can notice how this solution offers a direct line to the actor’s state of mind without hard coding everything, which is exactly what we want.

Basically, we want the npcs to operate off of components they learn about through their training. I know I did not mention training in my last post, but it is necessary for the npcs to not look like mindless zombies through half the game. Each npc will have to be fed through a virtual school where they will learn, through various tests and challenges, how to operate in their world. But I am getting distracted here, back to the design.

Component based objects can be summed up as imaginary containers that are filled with components that operate the object. For example, one component might be a renderer, another holds a model, and one more holds animations. These three together form a solid object that will be displayed in game. They are attached to each other solely through the object manager, but nonetheless are able to effectively communicate with each other through interfaces and a messaging system. I wish I had GPG5 around me so I could yank their example, but I think you get the general idea.

Anyway, objects communicate with themselves through messages, and each of the components that make up an object can subscribe themselves to different messages. A render component would subscribe itself to a ‘draw’ message, that way when the game sends a ‘draw’ broadcast, all objects that have the render component will draw themselves.

That is how component object systems work, when we introduce the ability to pick up new components during run time through actions, we have component AI. The npcs will be equiped with the simple components, model, render, animate, physics, ai, etc, and they will be able to pick up new components from the world to plug into their brain for future use. These types of components can subscribe themselves to messages, and even communicate with each other to achieve the best results. Some form of genetic training will have to be used to teach these components how to effectively communicate. When the npc comes across something new that it doe not know how to handle, picking up a chair for example, it will need to know things about weight, body position, what limbs to use, how to grip it, pretty much everything, and the only way he will know is if the components in his head know how to communicate effectively.

Yes I did mention body position and dynamic animation. I already mentioned the fact that objects themselves will hold data on how to handle them, generally. Then after the npc does that action he will gain a new component for handling that object. This system does not conform very well to static animations like most games keep. So animation will be dynamic and learned by the npc over time. This allows npcs to gain their own style of movement and actions.

Yes yes, I know I am going a bit over board again, running 8 or so npcs each tugging about 10,000 or so AI components will probably be a big load. That is why I need to write a demo application one of these days to see how much this will cost. For right now I am planning to go all out, screw the cpu, but most likely for slower computers we can introduce a system to merge and combine components to save processing time. However the more components you combine the more hard coded the npc becomes.