Features 1

This section and the following will describe the main features very briefly. The descriptions won’t point out solutions as to how to implement the respective features, nor is it always clear whether the features can be achieved with reasonable effort or not, but is rather a form of “whishlist” of all the things I deem necessary for a new gaming languages

Strict Division Between Code And Data

What? Heresy! Yes exactly, that’s the first reaction. After all, ever since Bjaerne Stosstrupp has brainwashed us all into believing that Object Orientation with C++ is the nonplusultra, it is clear to anybody that code and data belong together.

However, I have several problems with that. One was already mentioned in the Intro section: If you want to keep code and associated data close together, oftentimes it is not clear, where the code belongs. Take a simple example in C++ like this:

A function A should manipulate the classes X and Y in a way that the changes made to X and Y are pretty much equally important and equally work intensive. Where does the Function A go? Will it be a member function of X and therefor access the data in Y through access functions in Y or the other way around? This is a relative common problem in my experience and my decisions were always arbitrary so that I could not really justify them before myself.

Often it isn’t even clear that a code section should be part of any C++ class at all. Some code is more like a tool code that shouldn’t be part of an interface or should be visible to the programmer in the IDE in close conjunction with the data structure at all. So it is better if the code doesn’t have to be artificially associated with a certain class, or, worse, be made a global function thus breaking the OO style used for all the classes.

Here is another big, big problem that is specific to a certain type of application, mainly client/server type programs, which is what I spend the last 15 years dealing with:

Suppose you have a datastructure X. This data is to be shared between the client and the server. On the client this data is only read. For instance, imagine the data that describe a character in an RPG and which would typically contain such things as hit points, mana, the name, speed, encumbrance, the complete inventory the character is carrying and so on.

Now, the client will read this data in order to render the respective information but will not alter them. The server on the other hand will have to do quite extensive data manipulation which can run into tens of thousands of lines of code. Needless to say that this code will not be “self contained”. It will access lots and lots of code that is part of the server. Obviously this code will not compile for the client application.

So what’s the solution? The naive C solution is to use #ifdef’s and some definition constant like SERVER and CLIENT and then compile the code conditionally. I did that with my first client/server game and it was a huge mess in the end. So for my second project I decided to split each data element in two. Say for instance you organize your character in smaller subobjects to keep things neat, for instance a subobject “Fight_Data”. Now, I split the data from the code and created a data class which depends on nothing that is not available on the client, just put some bare bone essentials into it for instance read and write functions so the data could be stored and loaded. The server then has a “Fight_Data_Work class which contains the “Fight_Data” data class and has access to it’s fields as if it were a part of the server class. That “Fight_Data_Work” then contains all the code that does the heavy lifting and ties the data into the server system.

So the next logical step in my eyes would be to completely separate code and data, as it was done in Pascal or Modula for instance.

Now I hear the screams about “but what about data protection”. Yes what about it? In most classical C++ cases, a class will have access functions to give access to each class elements (getter and setter). These are not protected. Any rogue programmer could access these just like the raw data elements. So why write these access wrappers at all? They just cost additional time.

Besides, we’re not dealing with a fortress here that is to be fortified against the enemy. All programmers that have access to the structure work for the same company, or they have bought your library to accomplish something. So we can safely assume, we’re all on the same side. And if your company has a numbnut programmer that constantly causes mayhem, maybe it’s easier to exchange that guy instead of putting “protection” mechanisms into the code.

So I have no problems whatsoever with open structures. There is however a way, to protect data in structures, even way more efficient than the getter and setter functions in C++. This is an option that may be part of the language or not. I will address this later after some other topics have been discussed.