A Lexical Mistake

I realize that A Lexical Mistake has been somewhat dark for the last few months so I figured since my current project is starting to look more likely to actually happen I’d put this post up.

See I’ve also been reflecting on the last few projects I attempted and the core problems faced while working on those projects (why I dropped them).

Most of my effort in my personal projects has been focussed over the last couple of years on learning and understanding new programming languages. The problem is that while learning new languages can be very enlightening and quite fun, I found myself wanting to return to my original interest in software development—that is, game development.

The problem is that, while looking at various project ideas, and even attempting a couple (one of which can be found in an earlier post, although the code has been pulled since), I’m still faced with a number of inefficiencies that scream right towards my language design interests.

For a start, if you wish to provide a sandboxed game code environment then the only real option is to combine two languages using the bridge between them as the sandbox. This isn’t really a problem if your interested in simply creating a game now of course, and you don’t have to use a sandbox unless you want to run downloaded game code, but I don’t feel that these technologies really respect the time restricted resources of a small-team game developers (hobbyists, Open Source, relevant Independent gamedev companies).

Respectively, this is also what killed my Haskell gamedev project. That doesn’t mean I don’t intend to look into Haskell further—just not for gamedev tasks in the near future.

And furthermore, both conventional languages and embedded languages almost always require a restart before new code can be tested. I think that by reducing the turnaround time on new game code (or even engine code), the game programming process could be made significantly more accessible to smaller development teams for both smaller ideas or bigger, possibly open source projects.

So what have I actually been doing then?

I’ve actually been putting together a collection of notes and though experiments designed to push my understanding of Smalltalk and programming language design in general enough to put together a cohesive conceptual design for a decendant of Smalltalk, not to mention brushing up on my understanding of existing Smalltalks and the what the various Smalltalk related communities are working on.

Until recently however, I wasn’t convinced that there was an existing language that suited my somewhat unusual requirements for implementing this Smalltalk (or should that be preferences?) Recently I finally figured it out.

As it turns out, I believe that the best language for the early prototypes is The Java Programming Language!

I realize of course that Java won’t give me the best performance, nor will it be the simplest implementation, but when it comes right down to it, I’m just not familiar enough with another language with the necessary UI capabilities that actually conform to the conventions of the underlying operating system. I should even be able to take advantage of several library bindings before tackling C!

So there you have it, a post almost devoid of any real content, announcing my new programming language and both the interpreter and the design in general are coming along nicely so far, so you can look forward to more interesting details in the near future (like the core principles of the language design or the purpose of the language).

Oh, and one thing before I forget, I’ve named it The Mention Programming Language.

After reading Torsten’s nugget of truth in Planet Smalltalk recently I couldn’t help but be reminded of a Smalltalk based language I’ve been throwing around lately. Not because my language is interesting yet—I don’t even have a prototype concrete syntax—I’m actually referring to my immediate reaction when he wrote:

“Smalltalk is not a language — it’s a dynamic object system with the language built in… [sic]

This is, in my opinion, more cautious than it needed to be. Smalltalk really is just a dynamic object system, but beyond that, I would argue that the language is really just a collection of DSLs.

The first, method definitions is kind of the core DSL of Smalltalk. While not necessarily as small as a simple DSL it provides all of the behavioral elements that make Smalltalk code actually do stuff, all of which can be replicated by generating AST objects, programatically.

More obvious however, is the class definition syntax. This quasi-message-send actually causes so many hacks and side effects that suggesting that it resembles any kind of message programmers would be comfortable sending normally is just outrageous! Really it describes the structure of a class and allows us to manage that structure. Oh, we can also file-out that sucker, too!

(The OMeta parser generator can also be used to write methods. The tool support was iffy last time I looked at it though.)

My point is, Smalltalk is really just a collection of DSLs that allow us to effectively program with a pure object system, and it’s this phenomenon that I believe will allow us to dramatically improve both the appeal of the language as well as its usefulness in the future.

— Lorenz

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