completely fucking fucked

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?

new examples of usefulness of meta-programming compiler

example 1:

meta: ExpandComparators

if a < b < c < d < e
puts “a < b < c < d < e”
end

meta: End

becomes:

if ((a < b) && (b < c)  && (c < d) && (d < e))
puts “a < b < c < d < e”
end

obviously useful if you are doing this sort of comparison a lot.

Another example:

ruby compileMeta.rb –fixToS  myProgram.rb (this doesn’t even need to be run on a “rbm” – ruby meta – file)

will turn, for example:

puts “testVal: “  + 1 + “!=” + 2

into:

puts “testVal: ” + 1.to_s + “!=” +  2.to_s

—

Now, that last example might not seem like much, but consider:

1.) It is an unambiguous error (i.e. there is nothing else that could POSSIBLY be going on)

2.) I make it a lot

3.) This can be just one of many possible unambiguous and common errors that I make – I can have a flag like –fixMyErrors so that the call to the ruby interpreter becomes:

ruby compileMeta.rb –fixMyErrors myErrorFile.rb myProgram.rb

myErrorFile.rb can also do more intelligent things like check parens.

—

One final possible counter-argument is that this functionality could be replaced with a good IDE. Nonsense! First, show me a good IDE. Second, now that you’ve shown me Emacs, does it have a good, easy-to-use way of implementing these kinds of changes? Is it ruby-specific? Oh, I have to know Lisp? So I have to learn Lisp to write Ruby?

Anyway, I am continuing to try to justify this time-sink, as you can tell.

case study: string tokenization

Ok, so I’m writing this meta-ruby compiler but I’ve returned to ground zero because my tools were not sharp enough. In particular, I want transparent representations. Here’s an example:

Let’s say you have the following string of Ruby code:

a = “why, I ‘never’ \\\” would \\\” do ‘that” +   “said’ the man”

My goal is to create a “data structure” containing “tokens” so that I have a more efficient way of accessing information about this string. For instance, here are some questions I might like to ask:

Where are the string literals?
What variable is being assigned to?
What operators (if any) are being used?

Etc.

The number of questions I could ask about the string are infinite, but it seems like there is a “sweet spot” which it would be nice if I could access in O(1).

This brings me to the idea of a new data structure – the “flagged” list. It’s just a list, but each element has a “flag”. So the tokenized version of the above might look like:

["a"->symbol, " "->space, "="->operator, " "->space, "why, I 'never' \\\" would \\\" do 'that"->doubleQuoteContent, " "->space, "+"->operator, "   "->space, "said' the man"->doubleQuoteContent]

The goals for such a representation are:

1.) Fast query

E.g. I can say “flaggedList.getAll(“space”)” or “flaggedList.removeAll(“doubleQuoteContent”)” or “flaggedList.getAllAfter(“=”)” or whatever. The entire point is to make the structure extremely flexible.

2.) Fast extension.

Ok, this is a subtle point, but it’s important because I might want to build yet another compiler on top of my compiler. For instance, I might want to do something KERAZZY like make operators delimiters (so that everything between operators becomes absorbed into a token). Needing to create a new class for each type of token will just hurt my little old hands. Seriously, though, it’s better to just add a line to a list somewhere (operatorDelimiter) instead of creating a whole new class.

I don’t know why programmers are so afraid of flagging with strings. Maybe because it’s error prone? Bah humbug.

3.) Information Persistence

Another goal is to persist all information. None of the detail of the first line is lost in its flagged representation (e.g. even spaces are maintained). I can drop detail out if I want, but it is not dropped by default.

Anyway, there are other reasons, but they should be obvious. Or you can think of them. Whatever! The structure just appeals to me intuitively! Is it isomorphic to some other structure?
—

I guess the high-level claim here is that the difference between expressing something via one line of code vs. via two lines of code is enormous if you are planning on expressing that thing many many times. The difference between dropping a little information and dropping no information is enormous if you intend to extend the system ad infinitum. The difference between flagging with strings and flagging with classes is enormous if you want to maintain cognitive state (i.e. if you don’t want to forget why you wanted to add a flag while actually adding it).

You could summarize the design philosophy behind this approach to tokenization as: “Always sugar. Always.”

typing and fast conversion

Let’s say that you have the following situation:

You have an object that you want to model. Let’s say it’s a cube.

Now, what’s a cube made of? Well, vertices, edges, faces, “content.”

So you go to work and you implement your cube.

Later you find out that you need the geometric information related to the various parts of your cube. You now need to talk about Points, Line Segments, Bounded Planes, etc. Further, you need to be able to do “operations” no the geometric space which means you need heuristic characteristics: Vectors, orientation, “inner vs. outer,” etc.

Later you find out that you need to import data in a standard array-like format (cube described by array of “faces” which are really just arrays of “points” which are just arrays of numbers)

You might need to switch between each of these three domains fairly often. What the hell is the solution? Is there any programming language in which you can do this easily?

It seems like our ability to express how types are related is woefully, woefully, lacking. Now, you could say “make your Vertex a point.” But what type of point? An n-dimensional point? What if I want to write a 3D geometry engine? Then I have to think about how to relate the n-dimensional point class to the 3D point class.

The issue is that when we talk about types in everyday life we use vastly more relations than is-a. For instance, I could say:

“A vertex of a graph is an n-D point when the graph is embedded in n-D space.”
-or-
“A face is a bounded plane except that the orientation of the edges bounding a face matters.”

Computer science can be seen as “implementing math.” Imagine how stilted math would be if we had to perform these tedious conversions all the time. The crux is the following:

Conversions between types is fast and trivial when types are bound to computational contexts.

If I transition from the “graph theory” context to the “geometry” context then conversion between primitive types should be trivial (read: automated). I should be able to indicate which context I’m using.

continuation * nontrivial

So that previous post kind of set me to work on developing a set of meta-programming tools for ruby. This is very experimental. Really I’m just having fun writing my first compiler which tokenizes ruby with extra symbols and implements changes to the code following a set of rules. The goal is to set it up so that one can write “meta-programming strategies” (kind of like LISP macros, but different in a way that I’ll explain).

Here are the two examples I’ve implemented so far:

First, a string literal reverser:

meta: StringLiteralReverse

a = “abcdef”

b = “he said \”yo!\”"

endMeta

outputs to

a = “fedcba”

b = “\”!oy\” dias eh”

Cool, huh?

Next example is more sophisticated and highlights the “power” of these types of mini meta-programs w/r/t Lisp macros:

meta: BindingsCapture

a = 1

b = “hello!”

c = [what's your name?]

endMeta

meta: BindingsCapture

eachBinding(sym)

if (sym.class == Array)

sym << “yo!”

elsif (sym.class == String)

sym += “yo!”

else

sym += Char(‘y’) + Char(‘o’)

end

symCopy = sym

endMeta

outputs to:

a = 1

b = “hello!”

c = [what's your name?]

if a.class == Array

a << “yo!”

elsif a.class == String

a += “yo!”

else

a += Char(‘y’) + Char(‘o’)

end

aCopy = a

etc.

I’m totally eschewing the normal Compiler methodology (Parser -> Tokenizer -> Syntax Tree -> etc.) because really all I’m doing amounts to is implementing a language for writing FSM’s which use regular expressions to search in code. One of the reasons I want to write this ruby extension is that I like writing programs which use globally defined functional predicates. For example:

$startsWithColon = Proc.new {|x| x.class == String && x[0..0] = “:”}

$endsWithPeriod = Proc.new {|x| x.class == String && x[-1..-1] = “.”}

But I also like writing combination methods, for example:

$andPreds = Proc.new {|*x| Proc.new {|*y| val = true ; x.each do {|proc| val = val && proc[*y]}}}

But let’s say I’ve made a lot of the above predicates (startsWithColon, endsWithPeriod, etc.) and I want to form the and predicates (so that I can easily refer to, for instance startsWithColonEndsWithPeriod). This obviously requires some scripting (since it’s just a matter of calling the functions correctly. I want to be able to write something like:

meta: CombineProcs

setProcs(procs) // startsWithBlah, endsWithBlah

setCombinators(combinators) // and, or, xor, etc.

writeCombinations // writes out the combinations in the form startsWithBlahAndEndsWithBlah, etc. – will write lots

endMeta

You might ask what is the value with this. I say there are two values:

1.) Ease of reference (it is annoying to combine predicates, especially in “pseudo-functional” languages like Ruby)

2.) Verifiability (because it is done automatically I can rest assured that only the basic definitions need to be correct)

Then we can start combining things. For instance, how do we get the “procs” and “combinators” variables above? Well, we simply write a meta flag around our (named) predicates and they are automatically collected (nice!) E.g. we might write something like:

meta: BindingsCapture -> procs // puts the bindings in a named array

$startsWithBlah = Proc.new blah

$endsWithBlah = Proc.new blah

endMeta

etc.

Since I eschew the normal methodologies associated with tokenization (which creates the false dichotomy of symbol/operator) I am free to play games with variable names and crap.

I think that this sort of play has been largely missing in the programming world and I will tell you why – there is a strong understanding of the computer-related elements of semantics/syntax, but there is a somewhat weak understanding of the relation of those elements to their human-oriented correlates. How does a variable assignment correspond to what is going on in my brain? What is the semantic value of a variable name? Etc. Time will prove how useful (or unuseful) this approach is.

Trivial * Impossible

Here’s some code I wish I could write:

vals = []

meta: InputValues -> vals {

bind(a, 1)

bind(b, 2)

bind(c, 3)

}

print vals // [:a, :b, :c]

valsPP = []

meta: ModSymbol -> valsPP {

vals.each do |val|

newSymb = appendSymbol(val, “PP”)

bind(newSymb, eval(val) + 1)

end

}

puts valsPP // [:aPP, :bPP, :cPP]

puts aPP + bPP // 5

Too bad every programming language sucks. If I weren’t at work, this post would be longer.