A Lexical Mistake

This project is no longer in development.

With all this Haskell programming and a rather lengthy predicted alpha data for the Haskell game engine, I started to wonder about my last game development project. Actually, it’s probably more accurate to say, I was looking over the Secret Maryo Chronicles forums and remembered how much I wanted to create a similar game, obviously with a somewhat different gameplay and tools.

See, this story goes further back to when I was still learning the basics of Haskell. I’d produced a simple game demo, but made no real progress in adapting that code base into something that would scale to a full game. That’s without considering the game specific tools either. My solution was to start a new project with the explicit goal of simply creating an actual game and level editor, based on the existing assets from Secret Maryo Chronicles placing the game under the same GPL license.

Since this isn’t the most graphic story from here, we’ll cut back to the present, which brings me to the first simple tech demo since I restarted the project. Its not much yet, just some code to test some basic view layout containers—the Shoes style stack and flow, although the larger design is inspired by Hopscotch more than Shoes.

I should probably point out that the entire program runs on wxPython and OpenGL, but doesn’t use the wxWidgets controls, but rather a uses a simple custom framework designed for rendering directly in OpenGL. This is meant to simplify creating the in-game menus and since the editor will need to utilize many of the in-game graphics anyway, not to mention the level test functionality, it will probably help there too.

This demo doesn’t do much really, it’s just a simple stack and flow layout container test, with a few image views. Also, you’ll need the wxPython, PyOpenGL and the Python Image Library (PIL) for this one. There is a fallback library, but I haven’t fixed a minor image flip but in the usage of said library, so the images will appear upside down. The demo should appear similarly to the screenshot below. (I found I had to move the window to get the OpenGL view to start drawing. Since I’m not developing on Mac OS I didn’t realize until I grabbed the screenshot for this post itself.)

To checkout the simple view framework demo for yourself, simply run the following commands (or for the git users out there, its on the demo-view-framework-1 branch.)

git clone git://github.com/krysole/smc-ma.git smc-ma
cd smc-ma
git checkout demo-view-framework-1

Then running the command python main.py should start the code.

– Lorenz

This project is no longer in development.

Well, its been somewhat slower going for the implementation of Fire lately. The interpreter I’m implementing is fairly simple, just an AST and direct interpretation of that, kind of like a Lisp meta-circular evaluator, but it has been surprisingly difficult to get around the complexity of the interpreter. I’m starting to thing this project may take a little longer than I originally expected, but that’s OK, it’s still been quite a lot of fun so far.

The biggest hurdle I’ve stumbled on over the past couple of weeks is getting the actual interpreter doing anything at all. There’s plenty of code sitting in the modules, but none of it can actually work since I haven’t quite managed to finish the implementation based on the design in use.

So Fire is basically just a heavily modified Smalltalk (or Self.) Most of the semantics are the same, with the significant exclusion of directly modifiable variables—but even those are supplemented with transaction variables and more functional programming facilities. At least that’s the design of the language so far.

The problem is that Fire, like Smalltalk, uses strict evaluation and at least some of the methods may need to, gasp, perform IO! To actually implement something like this, I have to implement the strict evaluation using the IO monad, even if it’s only by composing monads (or similar.) The story doesn’t quite end there though.

Programmers can also define local methods within a method in Fire. These methods are part of the lexical context, and correlate to the respective extension to the message send syntax. This means that the lexical context must be threaded through the evaluation of statement in a method.

Also, not all method calls return successfully. The return operator is also a variation of the normal return from a message send. The design of Fire here, calls for the usage of an Either return value, where the Left constructor provides a Fire exception object.

We would essentially like to hide the general flow using a monad for these two so that implementing methods for Fire in Haskell is as straight-forward as possible, not to mention the implementation of the interpreter itself.

So the decision I’m going with at the moment is to ignore any direct IO, which may eventually have to be reified back in later on, as well as transactions which should be a little simpler to put back in, and create a monad that captures both pieces of information. In theory, maybe it’s possible to implement this by combining monads—but the truth is, I’m just not that good yet. For that matter, this will be the first monad I’ve implemented (besides simple examples.)

Before I attempt the new design for the interpreter however, I also have another task I’m looking at which should be the topic of my next post. Testing Parsec parsers. All I’m going to say for now is that it involves QuickCheck, possibly because I haven’t actually finished writing the code yet. Until then, back to coding for me.

– Lorenz

This project is no longer in development.

Of all the programming languages I’m proficient in, not even Haskell is so curiously fun and exciting (in my mind) as the Smalltalk programming language. See the idea behind Smalltalk is deceptively simple, you have objects, which you send messages to. Those messages are handled by methods and finally, both messages and objects may maintain and carry references to other objects. This may just sound like any other object-oriented programming language, but all of this happens at run-time, including the creation of those methods, objects and classes!

Given my affinity for computer games, it’s not surprising then, that I’ve been eyeing off the usage of some dialect of Smalltalk for programming computer games. Even the performance of Smalltalk is competitive compared to many other high level programming languages. Since most high level game code is easier to program with the increased flexibility scripting/dynamic languages provide Smalltalk has always seemed to me, to be a very attractive counterpart to a C/C++ engine.

The same principle could also be applied to the Lua programming language, which is extraordinarily popular in game development right now, which is more or less designed to be attached to an engine written in the standard engine languages, C and C++.

As I pointed out in my last post, originally I only intended to create a game engine in Haskell, which could then help when developing games or frameworks dealing with the high level game code. But to make this easier I decided to put the conventional game development wisdom to good use, and add to the mix a scripting language instead. Also relevant are Haskell’s concurrency capabilities which, I believe, are drawing the most attention from more mainstream game developers.

A Counterpart To Haskell

It might be interesting to note that, in the early design of Fire, the language wasn’t actually going to be based on Smalltalk or any language specifically, rather, I was working out some of the design points to help in taking advantage of Haskell’s concurrency and functional programming capabilities. Eventually I came up with a basic features list along the lines of object-oriented, semi-functional, highly concurrent and prototype based (class-less).

While collecting my thoughts and trying to understand which kinds of syntax would be appropriate I noticed that regardless of which syntax I used, the language would have to almost completely separate the concept of mutable state from the objects themselves, allowing only the use of transaction variables. While I could technically have gone with almost any syntax from there, it’s a pretty sure thing that regardless of the syntax used, Fire was going to be a somewhat unfamiliar thing to work with. This is where Smalltalk syntax lends itself, not being difficult to adapt and extend, while also known for being easy to learn and unusually expressive.

There were some issues to deal with however. To start with, Smalltalk syntax isn’t technically a full language syntax, but only provides the syntax for method definitions. By proxy, the construction of objects and message sends is achieved, with a fair bit of help from the development environment (UI). It also helps to point out that image based languages are notoriously difficult to bootstrap, while many game developers these days use text based VCS anyway, it was obvious I would first have to invent the missing syntax.

After (admittedly) more than a few attempts, and the larger part of a notebook full of musings and hypothetical example code, I finally had a complete syntax and at least most of the basic semantics in mind. The resulting syntax now includes a module level notation, an object literal notation, there is a simplified notation for creating lists and everything else is a consequence of sending messages, as expected.

Difficulties

There are some issues in combining any object-oriented language with functional programming or concurrency. To make things simpler, and because Fire is designed for game development anyway, I’ve kept the basic semantics imperative, or more succinctly the language still has the conventional IO semantics of Smalltalk. The main differences, at this point, are the lack of mutable variables within the language itself (beyond TVars) and the extensive use of threads (asynchronous messages).

To make working with transaction variables easier, Fire does provides properties, implemented as objects responding to a ‘get’/’set:’ property protocol, and a property method syntax which maps a method pair (’var’/'var:’) to another object implementing the property protocol. Any object could theoretically be used here including IORef based objects, but that would generally risk concurrency issues and would probably be a bad idea. This is of course, alongside the usual method definition syntax, and a syntax for creating simply immutable variables, which is syntactic sugar for unary methods.

For those who have worked with Smalltalk, it’s immediately obvious that the main strength of the design has actually been lost however. That it, the main strength of Smalltalk has always been, at some level, the development environment itself. For those not familiar, the built in development tools allow any object, class or method to be reworked at any point while a program is running, even in the debugger. When developing an application, this level of flexibility is essential to the velocity a Smalltalk programmer can work at.

Such a development environment is probably going to be the most difficult thing to replicate in Fire, since both the UI frameworks as well as the tools themselves must be created from scratch. The VM will also likely require a way to allow programmers to ignore the immutability restrictions.

Luckily I do have something along the lines of a plan. What I believe will do the trick here is a simple dual mode VM, allowing (through the reflection layer) the modification of objects, while the finished games will use a release mode, preventing objects from being accidently scrambled. This solves both the development environment concerns, while keeping the language concurrency safe and hopefully simpler to integrate into the Haskell based engine. As as for the UI, I’ll get to that in a later post…

Clearly there’s a lot of stuff going on here, but for now, most of the work will focus on simply getting the spec written and the VM functioning. After then I can start moving only some of the details like the engine itself, and the libraries on either side of the language bridge. Actually, there’s the language bridge too, for that matter.

The purpose of this post is really just to give some idea of the reasoning behind a couple of the high level design choices used in Fire. There are plenty of other topics to consider yet, just at the language level, for example, prototypes systems are even more convention based than Smalltalk since the entire class system is replaced simply by methods for cloning and modifying the definition of objects. In any case, I think it should be interesting to see Smalltalk finally being applied to some serious game development, especially paired up to Haskell as well.

– Lorenz