The Robot World Repo on GitHub
The Forth Repo on GitHub

I know what I would like to accomplish next. If there’s a way to do it, I can’t find it. I need help, or a change in direction, or both. #StopTheCoup!

My Forth is far enough along that I’d like to start writing Forth to control the bots in Robot World. My vision for the next step is that you have the world’s graphical window and a Terminal window, and you type Forth into the Terminal window and the bots do things in the graphical window.

Now, possibly, this is the wrong next step, but it has the very nice characteristic that with Forth linked to the World class, Forth could just use the base-level World methods, step, take, turn, and so on. We could strip out all the rigmarole about JSON and parsing commands and such. And, of course, our Forth currently runs from the Terminal, so we’d be all set.

However, looking out further, probably we would package the game as a single graphical window, one part of which has a Forth prompt and another part that has the world display. But I see that as an improvement to the UI, not a fundamental step in developing the product. It feels to me as if both sides, Forth and World, are ready to be hooked together, and I just don’t see how.

Pace Bryan1
I should mention that Bryan Beecham argued long ago that the server part of Robot World should be fully separated from the client part. I refused to go along with that idea. The upshot is that there is a pretty clean separation between the current Python client code and server code but the connection is direct, although it does take JSON in from the client and parse JSON in the server.

We could, in principle, complete the separation and use a network connection of some kind, http or socket or whatever, to drive the world. Then the Forth code could be enhanced to use http or socket or whatever, and to format JSON, and there we’d be. But I don’t think we want to be there. I think this program wants to be a standalone Forth-driven Robot World, not a networked Robot World. I’ve kind of given up on that dream: it just didn’t catch on in our cohort.

Even so, going into and out of JSON seems like the wrong path for what we’re up to now.

But I was saying that I don’t see how to do it. The issue is that Terminal input blocks, and therefore waiting for the terminal would stop PyGame from running. (The picture wouldn’t disappear: it just wouldn’t change. Maybe that’s OK?)

But even that isn’t good enough. We can’t go hanging on the keyboard on every draw cycle. We really only want to five Forth control on the return, when we have a full line of input.

You would think that asyncio would offer a way to do this but my searching is telling me that there is no non-blocking access to the line input capability.

One possible way …

PyGame can detect keystrokes. We use them all the time in games, WASD and arrow keys and so on. I have been able to grab keystrokes inside PyGame and echo them to Terminal:

    def main_loop(self):
        one_time = True
        running = not self._testing
        while running:
            for event in pygame.event.get():
                if event.type == KEYDOWN:
                    if event.key == K_ESCAPE:
                        running = False
                    elif event.key == K_RETURN:
                        print("I saw that")
                    else:
                        print(event.unicode, end="")
            ...

But that’s weird, typing into the game window and the output appearing in Terminal. So perhaps what we have to do is to work more directly toward adding a Forth pane to Robot World. I’m pretty sure we want to wind up with something like that anyway.

An idea forms …

We’re going to be stripping out most of the code from Robot World, even all the JSON code from the World side, to plug it into this new Forth-driven game. So what if we start on the Forth side? We have a Forth that takes input and displays results on Terminal. What if we wrote a little PyGame app that takes input and displays it in PyGame as some kind of scrolling text, and then we hook that to Forth and get Forth running in a PyGame window?

Maybe that would be a decent approach. It requires a bit of a diversion, creating a little pygame loop, but that is certainly something we’ve done before. Should we start with a standalone spike, or try to build it into our Forth program? I think the standalone spike is a smaller, and certainly less risky step.

That’s probably what we’ll do. But I’m still not ready. We’ll let this idea perk.

See you next time! #StopTheCoup!



  1. That’s Latin “pace”, pa-chay in church Latin, probably pa-say in real Latin. Meaning “peace” in this case toward Bryan, with whom I disagreed and who may have been right all along.