Newsletter #74 - MMOVoices and FSM

News

The crew at MMOVoices interviewed our programmer (InvisibleMan) in their latest podcast episode: http://www.ifthensof...?showtopic=2187


From the Programmer
Written by InvisibleMan

What was originally a small detour into studying finite state machines has completely redirected development.

Due to the spaghetti code which was SAO state handling, I started researching finite state machines.  The idea is that a finite state machine would clean up the code and make it easier to read, and bugs would be easier to detect as well.  If you want to know more about finite state machines, I highly recommend these two articles: UML State Machine on Wikipedia and Finite State Machines (FSM) by Jason Brownlee.

The FSM system which I wrote involves a main CStateMachine class, a base CState class, a CTransition class, and a CEvent class.  There are also some derived state classes, namely CStateTopSimple, CStateTopComposite, CStateSubSimple, and CStateSubComposite.  CStateMachine stores the root state, and manages the initial event processing.  CState, CTransition, and CEvent are what you would expect them to be; they represent and manage a state, a transition between states, and an event respectively.  The derived state classes are there mainly to make the code easier to both read and write by automatically setting default values and ignoring certain features of the base state class.  A state can have multiple transitions attached to it, which are triggered by events.

An explicit FSM like what I just described is certainly useful, but it's a bit too much for managing character states in Stick Adventures Online.  Because of this, I will be trying out an implicit FSM in one or two test projects.  After I have experience using an implicit FSM, I will be returning to work on SAO: Redux.  An implicit FSM is very similar to how I have been coding state handling already.  However, with my experience in writing and using an explicit FSM, I should be able to write better state handling code.

I have also decided to scrap the engine and start from scratch.  Like with FSMs, I now have more experience which means I can probably write an engine faster and better than I could before.  There are some problems with using an engine for a long time.  One problem is that you forget the original reason for a feature, for example the garbage collection system; it is intended to allow generic RAII and automatic management of memory, so it does not need to be used if these features are not required.  Another problem is that the engine was written with less experience and knowledge, possibly made worse by later additions which piled more recent knowledge on top of the old, possibly bad, designs.

At any rate, I will be working on at least one test project before getting back to SAO: Redux.  Just like with Redux though, I will probably release builds of these projects to people who are in the online chat.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #32

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by willl and jaythemage

Anticipation arises as we wait for SAO:Redux demo 29.  With the production of demos halted at the moment, many members are  beginning to feel uneasy and think that Invisible has stopped working on  SAO: Redux. Though that is not the case, many (typically younger  members) tend to flame InvisibleMan and ITS saying that they could make a  game like SAO a lot faster than this. Some of them try, fail to do so,  and apologize; others ragequit and end up coming back later for any  updates.

If you have anything you would like to say in the next community spotlight article, please post it here.


Funny Quote of the Week
From the online chat

pifreak: An Easter-egg I found on accident: hit F5 in notepad. It inserts the current date and time!
InvisibleMan: Edit->Time/Date F5
pifreak: cool, they hid the Easter egg in the menu <.>