Programming and other useless stuff

Saturday, January 03, 2009

Interfaces of the data value and data module

Hi,

as promised yesterday today I'll show you the interface to the data value and the data module. In fact, as I stated yesterday, the data value interface is quite small since it only has to identify the type and to provide basic getter and setter functions.

I was thinking about the most flexible way of usage for the interface. Since it is this tidy and tiny, the actual data getter and setter must be simple, too. I finally decided to make usage of strings (Note: ScxmlString is actually a typedef of std::string). The reason is simple: Everyone can handle strings with too much hassle and almost every type of data can be described using a string. An integer is as easy to put into a string as is a float. An array of numbers can be put into a string used a separator.

Furthermore, as I said yesterday, the datamodel itself is 90% linked to the script module (since the script module would be responsible for the expression parsing). This implies that the developer who's implementing the script module interface, would also make sure that the implementations of the different types of data values (integer, strings, floats, even objects) can easily be handled by the script module. This means, that the derived class may include access functions that bypass the get/set functions that make usage of strings. A derived integer class easily can implement a get and set function that makes usage of an integer. The script module only has to determine the data value type and cast the interface accordingly.

Thus, the interface of the data value in its basic form looks like this:


class IDataValue
{
/** \brief Identifies the type of the data.
*
* \return a string containing the identifier.
*/
virtual const ScxmlString& type() = 0;

/** \brief Access the data.
*
* \return a string containing the data value.
*/
virtual const ScxmlString& get() = 0;

/** \brief Set the data.
*
* \param a string containing the data value.
*/
virtual void set(const ScxmlString& _value ) = 0;
};


My first draft of the data module interface looks as simple as the interface for the data value. Currently only 3 functions are defined: a function to set data, a function to get data and a function to remove data.

Here it is:

class IDataModule
{
/** \brief Get data as a string from the data module.
*
* \return true, if the named date exists within the data module. False, if not.
* \param _name Name of the data to fetch.
* \param _out This variable will store the fetch result.
*/
virtual IDataValue* getData(const ScxmlString &_name) = 0;

/** \brief Set data.
*
* Data that is set in this way will be set to the data module.
*
* \return true, if the data could be set; false otherwise.
* \param _name Name of the data. This name must be unique. If the name is not unique, it will replace the data value that has been stored using that name before.
* \param _val Content of the data.
*/
virtual bool setData(const ScxmlString &_name, const IDataValue*_val ) = 0;

/** \brief Remove a data entry.
*
* The named data will be removed from the data module.
*
* \return true, if the data could be removed. false otherwise.
* \param _name Name of the data.
*/
virtual bool removeData(const ScxmlString &_name) = 0;
};


These 3 function would enable the developer to manage a set of data values within the data module. The identifiers (names) must be unique but that's part of the script module (or the implementation that makes usage of the datamodel interface).

Nevertheless, the interface for the data module is not complete. At least, that is my opinion ;) On monday or latest tuesday I'll tell you what is still missing and how that stuff is looking like.

Until then: Have fun,
Stefan

Labels: , , ,

Friday, January 02, 2009

Enhancing SSCXML

Ok... so as you might have read I plan to improve SSCXML (Simple State Chart XML) to mirror a little bit better what is actually written in the W3C draft. One thing that is mentioned in the latest version of the draft is the split into different parts such as the data module, the script module etc.

Although they describe them as being two different parts, they mention (in the same time) that the data module must provide a data access language which will allow to access the data stored in the data module.

Now, this sounds like a great idea, but IMHO this also implies that a complete expression parser must be included in the data module. Why? Because once you define a "language" that enables you to access the data, there are also some operations that you want to handle: using a variable to index an access to an array of variables ("a[b]" or "a[10]") or combine variables to create a new one (AKA as assign a value to another variable). Those are two examples of what ideally should be possible with the data module.

Unfortunately this implies a lot more: In fact, implementing a data access language into the data module ultimately means that you have a complete expression parser implemented to access, assign, handle, alter and delete the data.

And there's now the notion of the script module. According to the draft, the script module adds scripting capability to the state machine. They're giving the example of ECMAScript (aka JavaScript).

Now, think a second about what I've written above... complete expression parser... script module... You see it? Yes... for a developer this basically means the same: When you want to include scripting into your state machine, you automatically also have the data module, since you cannot script without holding a basic set of data. This means that for a programmer the data module almost always goes in combination with a script language and vice versa.

Now, my idea is this: The data module is only there to store data is using a very basic scheme: values put into relation with an identifier. For every value pushed into the data module, an identifier must be given. If an identifier is used twice, the previously stored data is replaced by the new value.

This notion of the data module has some advantages and some drawbacks:

Pros:
- no expression parser must be included.
- replacing data is easy.
- the data module is not responsible for solving the value addressing.

Cons:
- Access of large datasets might be more difficult
Example: a is an array of 1000 values. You can access a value by directly indexing it. Since the data module only has simple identifiers, an array must be mapped to a simple scheme such as "a[10] -> a.10" (access the 10th element of an array).
- The script module/expression parser is responsible to create unique ids and to verify that data is handled as expected (IE. temporary data storage).
- The data module would have no garbage collection.

To solve some of the issues, it is important that the value that is actually stored within the data module, is as flexible as possible. Also, one might want to have the possibility to enable the developer to implement his own data values (IE. an object, a specific data type, etc.). The data module must not now how to handle these new data value types. It only has to store them and provide access to them.

I'll write about the interfaces themselves tomorrow. So... keep coming back to take a look at it :)

Have fun and a happy New Year,
Stefan

Labels: , , ,

Sunday, September 07, 2008

Components enhancement

While thinking about the modifiers, I stumbled upon a problem that might not spring into mind when figuring out a game system. I wondered, how I would handle components that should be removed or deactivated? What should happen, when the game is paused?

Imagine a character has attached a buff which gives him ie. +5 Health every 10 seconds. When you pause the game, you might still want to update any graphic animations (ie. idle animation) but you certainly don't want any buff continue it's work. So you might have to put the buff into "pause mode", you'll have to deactivate the buff.

I played around with the components and modifiers (which are components, too) in my mind and finally decided that it was a good idea to have a ComponentContainer. This container would hold any type of component, and could hold a set of flags which ie. activate a component, tell the container, that the component should be removed (ie. during next update) or that the component should not get an update.

I then decided to derive my Component class from the ComponentContainer. The benifit of this is that I automagically have the possibility to attach ie. a modifier to a modifier (remember the timer example from yesterdays blog entry?).

Currently I have 3 flags: IS_ACTIVE, DO_UPDATE and DO_REMOVE.

DO_REMOVE flags a component to be removed during ie. the next update of the parent component (well... in fact, the one that holds the component container should decide when unused components should be removed. A character class ie. would remove them in every game turn, while a component would remove them in the next update.).

IS_ACTIVE and DO_UPDATE mostly come in pair. Only active components can receive updates. You can see that removing the DO_UPDATE flag from component would make them "pause" until you set the flag active again. Disable IS_ACTIVE is useful when ie. the player wants to push things around from the inventory to the character and vice versa. A grapped item (attached to the mouse) would be set inactive (while remaining on the character in a greyed out manner) and thus have no more effect on ie. the characters values (if there was a value modifier attached to the item).

That's my current state of the components. I'm thinking of how to handle those flag changes with small effort and the more I think of this, the more I'm convinced that my SSCXML has found a new place to be :)

Have fun,
Stefan

PS: It's quite possible that I'll have no blog updates in the next two days since I have to travel to some clients on monday and tuesday.

Labels: , , , ,

Friday, September 05, 2008

Migrating domains and SSCXML

Well... I'm currently in the middle of migrating all my domains from a shared hoster to a VSP. In fact, my hoster restricted a lot of things which were fine before. IE. the memory usage of processes is very low. So low, that even tools like image galleries that have been installed through fantastico will not be able to add a simple image.

That and some other considerations led me to search for a VPS. I came across a lot of sites and finally I found a VPS plan that was ok for me: not too expensive while still having enough features for my current needs. I took the lowest plan offered by Geekstorage. I talked with one of my friends who's already set up some VPS and has a lot of experience with Linux. So I spent most of my time today learning about VPS and Linux, httpd setup and all those things.

I must say that I'm happy with the choice I made although I pay like 10 times what I paid before. The support guys of geekstorage replied quickly (max. 2h although I posted my tickets in the middle of the day... in Europe). Not that I had any problem... just questions about setups and how to do things. I'll tell you more once I have more experience with these guys :)

I worked on a new release of SSCXML yesterday. Added some keywords to replace the & and > and < signs. Using those straightforward in condition strings within XML is no valid XML. You'ld have to write "& a m p ;" for an & (Sorry... had to put spaces between letters). So I added keywords which can be used by the users to replace things like &&, <= or >= (keywords are "and", "le" and "ge"). A "(a<5)&&(b>10)" would become "(a lt 5) and (b gt 10)". As readable and easy to retain as C/C++ code :)

So, SSCXML is V1.04 now...

Have fun,
Stefan

Labels: , , , ,

Monday, September 01, 2008

Return to work...

Today I visited one of my clients to talk about the next programming stuff to do for him. Nothing really spectacular. But this is the next stepstone in the business application we're creating. It's always good to make step forward and see that things work out well as expected and planned.

This evening I spent some time working on SSCXML. I had a user remarking that any expression using & or > or <>= or <= is no valid XML code. Instead when using a normal notepad, one has to put in "& a m p;" (please read it condensed) to express valid xml code.

Now this would be tedious to edit and the user suggested not to stick to C/C++ coding style here and use statements such as "and", "or", "lt", "gt", "le", "ge" and "eq". I added this to SSCXML tonight and my first tests ran fine. Now, I still have to trigger this a little bit since my current check is not independent of the cap. "and" will be recognized, "AND" or "And" will not... so I want to sort this problem out first before working on any additional stuff.

Talking about additional stuff for SSCXML: I'm thinking of enhancing the engine a little bit by allowing delegators or registering of class functions for executable functions in the scxml code. I still have to think about this, but it will definitely go into SSCML.

Have fun,
Stefan

Labels: ,

Tuesday, August 05, 2008

Restart

Hi,

although I have this account since 2006, I did not really post any entries. Hopefully this will change since I would like to share some of my experiences I make during the development of my spare time applications and games.

To give you some backstory: I've been in games business since 12 years now. Throughout this time span I was a simple programmer, translator (german->french), senior developer, lead developer, project manager, head of technology and freelance developer. I had the fortune to work with some of the best German game developers and some of the most talented German graphic and sound artists you might encounter. It was (mostly) a pleasure working with them although I managed to upset one person to a point he won't even talk with me anymore (at least one of whom I know).

The game genres I worked on were wide spread: from turn based strategy games through sports games up to casual games. The only thing I never programmed was an FPS.

In the recent years I sometimes turned away from game development to jump into the area which is called "serious applications" by the game developers. In fact, I made some quite interesting experiences there. I had the chance to contribute to the research and development of embedded hardware, wrote (mostly as a sole developer) the voice recognition, client-server based picking solution for one of the biggest spare part warehouses of Europe and contributed and still contribute to the development of a business application for a German music label and the planning and maintenance of an industrial CAD software.

Some month ago I published my own lib called SSCXML which is the first publicly available implementation of the SCXML draft (state chart XML) by the W3C.

In my spare time I started working on a small game called "Prohibition". It'll be a turn-based strategy game where the player must lead a police squad in it's fight against organized crime in the early 20th century. Since I'm working all alone on this project, progress is slow. I also tend to research and experience some programming ideas I have with this project. The game itself will be fully multiplayer targeted. Currently I'm working on the very base of the game: network layer, client-server structure, object management, ...

I think I'll post some of the things I do in this project in this blog :)

Have fun,
Stefan

Labels: , ,