Recently I've been learning a little more about stack-based languages like Forth and Factor.
There's been some discussion here about Forth and roger levy's game engine (which I haven't looked at yet), but what I'm wondering in a more general sense is how you go about writing a game with something like Forth. It's pretty far from the programming concepts I'm used to. For example here is part of Tetris in Factor:
...<snip>...
Is it just me or does this seem like it would be confusing even if you knew what you were doing?
What are some general techniques for doing things like a game loop, managing game entities, managing state and scenes, with the stack? Is it that you don't just use the stack but create other layers on top/around it to manage the program flow?
I don't know much about Factor or Forth, but I have dabbled with game programming in PostScript, which has stacks and could be considered a concatenative language but some academics might argue over the last point. I've also written my own stack based language similar to PostScript.
However, I think that with following structured programming in Forth, Factor or PostScript, you can do things cleanly by being aware of the type of functions, so that data passed between functions and not kept in any intermediate place, sort of like message passing or functional programming where everything is about inputs and outputs.
In languages like these, I think the real hints are in the type signatures and when deciding how something should be done, one might write the types of the function before filling in the details (knowing your input and output).
This is achieved by finding common patterns and expressing things in terms of other things, rather than writing large functions that do unrelated things on the same data, which would cause much headache when trying to understand or refactor code.
It does take some time to understand how to program effectively, but this is probably just a matter of experience.
a game loop might be a function that takes an initial game state and produces another game state as output, then run it forever it will continue to supply input to itself, but internally ofcourse it could decide to terminate if the user wanted to quit the game.
Managing input, I'm not sure how this is done in Factor or in Roger's library, but either a lazy list of input events could be supplied or the current state of key presses queried, I'd prefer the former and if not a lazy list that could be consumed partially then a function which pushes an event on the stack as input to a function that deals with user input.
Ofcourse there are other ways, such as having a list or stack of things which are subscribed to certain types of input, topmost elements of the stack of subscribers can be fed the input events if you were doing some sort of basic windowing hierarchy.
From my point of view a lot of concepts in C or C++ etc can be translated to a stack based language.
hopefully that wasn't too incoherent
Developer
