Some years ago, late 2009, i bought a brand new iMac 21.5" with a 9400M GPU, 4GB of RAM and a 500GB hard disk. I really liked that machine and although it was far weaker when it comes to graphics from the GTX280 PC i had at the time, the fast and clean Mac OS X, the bright display with rich colors and, well, the new toy effect made me use it all the time. Obviously i had to program it, but first i needed to get used to Xcode for writing C (and later, Objective C) code.
As a small project, i decided to write an interpreter for a simple programming language. I had heard of Tcl and how it was based on a few simple principles, so i decided to write something similar to it. I didn't really knew Tcl at the time, so beyond the basic stuff about string substitution and the basic syntax symbols (like the dollar for getting a variable and brackets for subcommands) i came up with the rest on my own. I named that language LIL, for Little Interpreted Language.
At the end i didn't really like Xcode much, so after a while i switched to Eclipse with CDT which i used in other platforms then.
Three years prior to that, around 2006, i was toying with an experimental engine i called Alithia. This engine can be seen briefly in the video below:
The engine was inspired by the Cube 1 engine, using mainly the idea of a 2D grid with a floor and ceiling height per cell as if someone made a Doom 1 map made out of tons of tiny sectors. I abandoned that idea and the engine itself a little before i joined Track7 Games to work on Theseis (a story for another time) but with the new computer and new things to work on, i decided to give a second try to that approach. I started Alithia from scratch and one of the main ideas was to make everything in the engine accessible to scripts written in LIL.
At the end i found the in-engine editor with the first person perspective annoying to work with (the previous incarnation of the engine had a dedicated editor, but i wanted to try Cube's approach of in-game editing) so i scrapped the engine altogether. Still i liked using LIL to write scripts and despite being a small language it felt like a complete one.
So i decided to use it everywhere. Over the years i wrote a lot programs that used LIL, even if it was for simple things. One of the programs i wrote was LILCard, a sort-of HyperCard clone:
LILCard was written in Free Pascal and Lazarus. Instead of interfacing with the C LIL using some sort of DLL or other linker trickery, i decided to reimplement LIL in pure Free Pascal, writing the code in a more object oriented way and taking advantage of the language's features like dynamic arrays and properties. The end result was FPLIL which since then i have developed almost in sync with the C LIL.
FPLIL was done as a Free Pascal unit but also as a Lazarus component - realy to be dropped in a LCL form. Since i used - and still use - Lazarus a lot for GUI tools, it made sense to add scripting support to those tools with LIL (today Lazarus comes with its own set of components for scripting using Pascal Script, but at the time there wasn't anything like that).
So when i decided to add scripting to Runtime World, my 3D world editor, it made sense to use FPLIL for it. While Runtime World doesn't really take advantage of scripts as much as most of my other scriptable programs (i added scripting too late to the project), scripts are still used to implement any game-specific functionality.
In the spring of 2012 i found an ad from a local company asking for XNA game developers and decided to answer it. I called them and told then that i didn't knew XNA but i knew about game development. They said that if i knew C++ it would be fine, so we arranged to meet and talk in person a week after the call.
In the meanwhile i decided that it would be a good idea to try and learn XNA if i was going to use it there. I download Visual Studio 2010 Express and the XNA SDK and started messing around with it. I decided to make a simple 3D platformer with levels made using Runtime World and after a while i had a simple game going on.
Sadly the meeting proved to be unfruitful because of a miscommunication between the company in question and the ad agency. The company wanted to cooperate with other developers to produce games, but the way the ad was worded i thought they were looking developers for hire.
I was bummed but on the bright side, i had a game i could work on, which i named RobGetOut. After getting some feedback on the graphics that wasn't exactly positive, i decided to rework the graphics bit and later after deciding that sticking with a single platform wasn't something i liked (after all i use Windows, Linux and Mac OS X often) i decided to ditch XNA and rewrite the entire engine in C.
And after my experience with the Alithia Engine, Runtime World and a few other smaller projects, the choice for scripting was obvious - the new engine, which i named Runtime Engine, would be fully scripted in LIL.
It took a while to bring Runtime Engine up to speed with the XNA game, but that was expected since with Runtime Engine i was writing a lot of functionality that XNA provided out of the box and the XNA game was written haphazardly in a week while i was learning both C# and XNA.
Eventually i got busy with a new job so i abandoned the game. However i did a few tests here and there with the engine, adding things like soft shadows and SSAO, although i discared most of that code because it was done in a quick-and-dirty fashion to try out ideas.
Last year, after i left said job, i decided to create a new game (initially i thought to continue the work on RobGetOut but what i wanted to do with that game needed more assets - and more detailed ones - than what i can do at the moment). The first few months i mostly worked on the engine, but as i switched towards the game and scripting side, i faced a few problems.
The first one was performance, as LIL was never meant to be fast and indeed in a test someone made some time ago comparing scripting language performance, LIL came last by being around 600 times slower than native C code. To address this, i improved the C LIL performance by tacking several low hanging fruits with the interpreter and by changing what some scripts were doing.
The other was that writing the scripts themselves was a bit annoying. Up until that point i used whatever text editor i had at hand, usually using Tcl syntax highlighting (if available), but i decided that i wanted something better that would also provide a bit of integration with the engine.
To that end, i wrote LIL Studio, a simple IDE for LIL. Calling it IDE might be a little stretched though since all it does is provide a text editor with (minimal) project support, LIL-specific syntax highlighting and an FPLIL (it is written in Lazarus) instance so you can evaluate code inside the editor.
The biggest feature LIL Studio has however is its ability to connect to a "remote" server and send LIL commands. This isn't anything complicated, all it does is open a socket and send commands using a very simple protocol that can be implemented in a manner of minutes. The server side is expected to evaluate those commands and send back any output the scripts have.
LIL Studio allows you to evaluate, either locally or remotely, the currently edited file, selection or function and in the latter case it can also optionally execute the function immediately (it tries to guess the function code and its name from the formatting).
This makes it possible to modify the scripts or alter the game state while the engine is running without a need to restart the game (at least as far as scripting is concerned).
In the video below i show how the connection is done with the engine communicating with LIL Studio and how to modify something - like the jump distance in this case - while the game is running:
So far LIL proved to be one of the most useful projects i worked on - to me anyway. While i have written several scripting languages at the past (and even after LIL - one of my attempts to fix scripting performance in the engine was to replace LIL with a C-like language i wrote, but eventually i decided against that because of all the functionality that LIL provided), however LIL seems to be the one that has stuck so far. The fact that i developed it for both C and Free Pascal, two languages i use often (the latter mainly with Lazarus) probably helped there too.
In the meanwhile i found out that others have used LIL in their projects, mainly because of how simple it is to expose C (and Free Pascal, although i don't know of anyone who used FPLIL) functions to it.
Yesterday i decided to assist a bit with experimenting with LIL and made a small GUI based LIL environment (and TBH, i just wanted an excuse of shoving LIL in some program again :-P). The end result is WinLIL:
WinLIL is very loosely inspired by PythonWin, although only with a fraction of features. It provides an all-in-one program with a console window to type LIL code in, multi-window text editor to edit LIL scripts and run them, embedded documentation and a few extra WinLIL-specific functions for drawing simple graphics that can assist in said experimentation.
WinLIL isn't meant to replace LIL Studio - and at the moment LIL Studio isn't publically available anyway - but to provide a simple self-contained environment to try out LIL in. WinLIL consists of only a single executable that is around 432KB (200KB in a ZIP file) and should run under any Windows OS - including even Win9x - and Wine.
WinLIL isn't the only LIL-related tool i wrote recently. Another one is LIL Text Processor, a GUI tool to process text files line-by-line using LIL code.
And of course there are other LIL-related projects, like LILArt, a document formatting system inspired by DocBook and Lout, LiLt, a language-agnostic preprocessor for literate programming and a bunch of others i don't remember.
I'm not sure what lies ahead for LIL. At some point i want to create a proper 1.0 version (so far all versions are just dates) but i want to make sure that both the API and the language are stable before that (i am against the idea of semantic versioning and other bullcrap like that that validate breaking backwards compatibility in libraries, so i want to avoid it). I haven't done any significant change since the first time i wrote the LIL header almost 7 years ago (beyond adding stuff), but at the same time i do not think LIL has been "battle tested" yet to truly declare it stable.
In practice, especially if you don't care about potentially breaking slightly the API (unlikely as that might be) sometime until a proper 1.0 comes out, i think LIL is stable enough for using it.
