I’m developing a game in Ruby using SDL. The name of the game is completely fucking fucked. The idea is that I want to be able to create a game architecture that lets me change whatever I want whenever I want. This should allow me to cook up some truly post-modern gaming experiences. Walking on the walls, walking on air, fast color changes, tempo changes, whatever I want, whenever I want.
So how is the game engine that I’m building different from all other game engines?
Well, the motivating idea is that if we loosely model a game as a set of interacting finite state machines then what we have to do (at most) is describe how all the states interact. That’s about n^2 things you have to specify (where n is the total number of states). Not so bad, especially considering that you won’t usually have to specify them all.
The cool thing about writing games this way is that you don’t have to worry about anything other than what you are looking at at the moment. The structure is completely local.
For instance, I want to add a block object. I already have a mario object. What do I have to do to give the block object its behavior?
Well, I have to prepare the following:
Predicates for determining whether mario enters from the bottom, from the top, from the left, or from the right.
Predicates for determining whether mario is in the block.
Operations who function based on predicates above. For instance:
if (enteredFromBottom(mario)) and isInsideVertical(mario) and isInsideHorizontal(mario)) then
putBottom(mario)
makeFall(mario)
end
The idea being that I have to write the above once and then never, ever, EVER, think about it again. Or, if this is not the case, I have to update the framework so that it is the case.
Another THING motivating the design is the desire complete informational transparency. What do I mean?
For instance, in the model (where all the entity state is contained) I should have access to the keyState (what keys are up and what keys are down). Now, this seems to violate modularity (shouldn’t we want to have the model and the controller separate, you ask?) The answer is yes and no.
Yes, if we had just one model and one controller then we would want them to be separate. But when I think about the game I really think about it as a large number of models + one controller.
I mean, why can’t I have a model whose purpose is to describe the low-level model+controller system? This model would describe what happens, for instance, when a state-transition occurs. Obviously information related to state-transition (changes in the model’s representations) is not itself an aspect of the model. Thus it must be meta-information. Similarly, the controller is interested in processing key events – it should not be concerned with the current keystate – this, too, is meta-information. Therefore, since we have two nice pieces of meta-information we can write a model to use them. BadaBAM.
What benefits does informational transparency give you? Well for one thing it makes shit way easier to write. If you want a value you just get the damn value. You don’t have to ask around for the damn value.
Another design decision is to not use threads/message systems. I’m doing this in ruby and threads will only slow this motherUFF down as well as adding infinite complexity. I model animations as functions which know how to update even in the face of irregular update requests (parameterization, baby).
This post was not lucid but I don’t care. Hope you got something from it. I should be releasing a pre-alpha of CFF within the next few days. Does anyone even fucking read this?
