Saturday, March 22, 2014

What is this?

This blog documents my project to port the Commodore 64 version of the classic RPG Telengard to the web using the Elm programming language.

Released for the C64 in 1983, Telengard was one of the first RPGs I ever played, so it has a lot of nostalgia for me.  I also think there is merit in fully documenting an early piece of computer gaming history.  Finally, there are good technical reasons for choosing this game to port.

For performance reasons, most C64 games are written directly in assembly language, but Telengard is largely written in BASIC, with only a few minor assembly routines.  This makes it comparatively easy to reverse-engineer the code in order to do the port.  Also, since it runs on a computer with only 64K of addressable memory, it should be a relatively small project (which is good, because I have real life, too).

Elm, on the other hand, is only a couple years old.  It is a language designed to experiment with functional reactive programming (FRP) on the web.  I think statically typed functional languages like Haskell, OCaml or F# are nice because their programs are quite high-level and resemble mathematical specifications more than a list of commands.  Higher-order functions (functions that take functions as arguments) often allow you to write very concise and reusable code, and lazy evaluation can help you write code that works on infinite data structures in a natural way.

However, building user interfaces in functional languages is an area of active research.  A UI is usually modeled using mutable state that changes in response to asynchronous events like user input or a timer.  But functions that mutate state and have time-dependent behavior aren't really "pure" from the functional perspective.  FRP is one approach to working around this by allowing special functions (signals) to be functions of time.  Your program, using signals for input (like the mouse, keyboard or timer), then becomes a function of time that produces an output signal (like a scene to be drawn on the screen).  The compiler takes care of all the details of mutable state and event propagation, and your program remains a pure function.

Since I enjoy functional programming, am interested in FRP, and would like to help contribute to programming language research in my own small way, implementing in Elm seems like a good choice.

I'll document my progress here as I make it.

No comments:

Post a Comment