I’ve been thinking lately that, although it will take a long time, and I’m not too sure of the commercial approach (there is none within practical reach), working in this area will probably the Work of my life.

So yeah, I’ll keep writing here, and I hope to set up some open work & discussion area somewhere/somehow. But my available time is limited now, so for some time I’ll probably keep just posting articles every now and then.

I’ll definitely be really happy to discuss things and approaches!

If you do decide to work on this let me know. I’d love to discuss some approaches…

And since even small amounts state very quickly pile-up to become impractically large to analyze, it can be trivial, but totally impractical to determine the behavior of a program on finite-state computers, such that we’re better off treating things with the same tools used to analyze programs running on non-finite-state machines.

I admit I haven’t read Turing’s work directly, and someone correct me if I’m wrong, but from what I understand, the main insight that Turing gave us for the halting problem, is that for you to determine whether a program that uses N bits of state (i.e. memory) halts or not, then you need a decider (i.e. a program designed to decide whether its input halts or not) with at least N+1 bits of state.

As far as I understand, *that* is the real insight, which is not what most people understand as the halting problem.

Now of course, if you apply the above insight to a Turing machine, which is an imaginary machine with infinite memory and which will never exist in the real world, then of course to decide whether a program halts in the general case you need infinite amounts of memory in order to run the decider. Therefore, in a Turing machine (i.e. in Turing’s imaginary machine), it’s impossible to construct this decider.

But coming back to the real world, it is mathematically proven that for finite-state machines, i.e. machines with finite memory (or “computers”, as I like to call them), you can trivially decide whether a program halts or not, because if a program doesn’t halt then it eventually has to start repeating states (due to the machine having a finite number of possible states).

Of course, it might take you an intractable amount of time to reach that conclusion if you just use the most naive algorithm to determine if a certain state repeats itself, but it certainly is possible to design much more clever and faster algorithms that can determine that, sometimes in a very short amount of time.

The only thing that is mathematically proven is that to determine whether a program which uses N bits of memory halts, then in the worst case you need at least N+1 bits of memory to run the generic decider.

http://www.youtube.com/watch?v=7XUWpze_A_s&feature=youtu.be

Yet, great though this note that the (jump) function knows “how high” and is linked to the game’s control interface. Is this intrinsic to the act of jumping common to all platform games? No.

Then this (jump) acts in concert with the (gravity) and (move) functions, each of which mix similar collision code and characteristic parameters in hard-to-edit places. It isn’t as if the program has a set of adjustible sliders for gravity, movement speed and jump strength. The collision code ought to act as a constraint on a dynamical system of tangible, weighted, entities. In a sense “The World” should be a given: a stage onto which your actors may (attempt to) perform.