dLISP 0.100.0 Released

I am proud to release version o.100.o of dLISP, the LISP interpreter for D.

This is still experimental software, but is used already as a scripting language for a free game under development. During the course of using dLISP in practice a laundry list of bugs were discovered and fixed - too many to list here. Also note that dLISP is not a faithfull implementation of Common Lisp, and isn't even trying - it's just another Lisp dialect.

Changelog

• Closure support. Functions now carry their own context with them.
• Constructs such as (1 2 3) are not valid any more - these shadow too many bugs.
• Ridiculously easy bindings for D classes - see iteration-zero source for example.
• Simple object model. Prototype based class hierachy. Automatic generic functions for classes exported from D.
• Partially covered by test cases now.
• Added gensym.
• Friendlier to debug complex code - built-in tracebacks.
  

Known Bugs / Missing features

• Generic function evaluation doesn't work out of the box for user defined methods.
• The ,@body syntax is not supported.
• Keyword arguments are not supported.
• Source code positions on errors are wrong.
• Tracebacks may be misleading in places.
• Missing function macro-expand.

Thanks go to the original author, from whom I have taken over the codebase:
Thank you Fredrik Olsson.

The download can be found on the google code page.
Bug reports go to the issue tracker.

Have fun!

No closures? Rant.

Warning: rant mode

Taking over another codebase allways has it's risk, but today I was really annoyed by this bug ridden crash prone piece of crap, called dLISP when I discovered that it doesn't support closures.

Really, how can you declare a functional language to be nearly done, when you don't have closures?
With my current state of agony I can only assume the original creator abandoned his creation in disgust.

Wow, writing just that felt good... Though I am in no position to really complain, but well I didn't expect readyng dLISP for my use to be that much work. Right now I am considering a switch to PyD for the bindings - but before that I'll check how difficult it is to remove the worst problems I discover in using dLISP during my work with it.

Game Design Document II

After a long time of silence due to being packed with work from other directions .. besides enjoying the sun .. here's another stream of thought on the game design.

Battle tactics

The tactical options in a sci-fi RPG underly different constraints than those set in the classical pseudo-medieval fantasy world. Basically three different classes in a group battle are of importance. The tank, the artillery and the supporter.

The tank is usually used to stop the other groups tanks, which have equally good hit points and armor while they deal large amounts of close range damage.

The artillery - the typical Fireball blasting Mages - deal damage over the distance and either give your tanks the edge or take out the other teams artillery and supporters.

Apart from the usual "heal the tanks" kind of spells the supporters make the battles most interesting by supplying new tactical options.

The usual battle procedure

Of course these roles aren't set in stone, but the usual battle procedure is to move your tanks forward as fast as possible and build a defense line. The artillery then has the task to take out the most dangerous enemies while trying to not die by stray enemy tanks or enmy artillery.
The supporters will disable, confuse or slow enemies and at the same time try to - well - support the tanks by healing and buffing.

Translation to the future

The key problem for translating this simple but fun design to a sci-fi scenario is that in a direct translation there are no believable close range weapons and spells.

Thus the battles would consist of groups of artillery performing a shoot-out and the team with the higher firepower will win. That's boring. Since any advanced enough technology will resemble magic it should be possible to overcome this in a believable fashion, while not trying to just rename the priest to a psionic (or whatever) and the tank to some laser sword
wielding super-human.

Ansatz for fun battle tactics in IZ

For iteration-zero I plan to indroduce basically three classes of weapons, one that has a decreasing damage with distance - but a large per shot damage - this would be plasma guns. The damage is is distributed over
a set of smaller bullets, plasma pellets or whatever. Opposite to this are ray guns, which do the damage in a single shot and additionally a continued shot may add a damage multiplier in the next shot at the same target. Both plasma guns and ray guns will use up all remaining movement points for the current round, thus making hit and run techniques not feasable.

The third class is just the average set of hand guns - future versions of modern projectile weapons doing less damage than above futuristic weapons.

Apart from personal armor, which offers limited protection, personal shields are available, which use a constant amount of
energy if active. These shields will damage the user continuously and slow him down (less movement points). On the other hand, they will substract a constant amount from the damage dealt by energy weapons.

As an added option equipment called shader is available, which works as a personal cloaking device. For each effectivity there
is a distance above which the user is not detectable, a distance where he might be detected with some probability. Those radii will depend on the perception attribute of course - and to let the player choose the risk for himself hovering over en enemy will display these radii so that the choice of risk is on the player.

--

The above analysis and description of gameplay is incomplete of course and highly dependant on the actual balancing used
in the game settings itself. However I think the Ansatz is promising.

The weekly TPS report!

I hoped to be able to release a technology demo this weekend, but even after using most of my free time to code this didn't quite turn out to be feasable. Sadly I won't be able to present any new screenshots, as the visual appearance hasn't changed a lot in last days despite reaching revisions numbers in the seventies ;-).

Anyway here's the feature list that needs to be implemented before releasing that 0.1.

• Core Functionality: Gui Library (75% done)
• Core Functionality: Scripting (95% done, just needs some testing.)
• Gameplay: Running around the map, shoot at stuff (50% done)
• Gameplay: Fly around the planet (0% done)

Doesn't look to bad. But porting Guichan took too much time and kicking the code into something worth an dsource entry would take even more time. So I'm ditching that idea.

Yet another GUI lib.

It took me an quite some time, but I got Guichan ported to D - at least it compiles - which doesn't mean that the port is somewhere finished ... But the tedious work is done.

In order to motivate myself (a bit) I tracked the number compilation errors during my iterative adaption.

Hopefully soon the gui system will be up and running so that I can finally start to implement game logic.

DLisp

I have chosen a scripting language for my game, and after having brief uninformed looks at MiniD, PyD and DLisp - I choose the most obscure, least maintained of the bunch - DLisp.

What is it?

It's a minimal Lisp implementation in D, taking full use of the builtin garbage collector of D. Sadly the author kind of faded away, I just hope he is healthy and alive. So for now I forked the codebase and will try to maintain and extend it. After some fiddling around unittests run again - but the test suite is fairly limited.

Since I want to use it as a scripting language for an object oriented game written in D, I decided to add builtin object orientation since I hope this will ease the exposition of game objects.

Edit: Why DLisp over the others?
So why did I choose the least maintained and complete scripting language available? Basically two reasons - First I started this Project to learn new stuff - and Python I use regularly, the languages inspired by D or simply Lua don't offer something new. So choosing a Lisp version and a tiny one offers the opportunity to learn something completely new. Second I needed a data description language - I know that lua and python can be used like that (though using Python using as a DSL feels like an abuse.) - but the others didn't struck me as such.

A third reason I might add, is that having intimate knowledge over the script languages
implementation enables me to fix bugs and odd behaviour right away.

Status

DLisp is fairly usable already, although the OOP code and syntax is still under heavy development.

Syntax snippets

;; Level Data
;; Mar. 2008
(setf *level*
(make-instance level-class "My Test Level"))

(defun place-tile (x y name)
"place a tile at x,y created from tile-prototype name"
(call-method *level* place-tile
 (x y (make-instance (get-attr *dataset* name)))))

(map place-tile
((5 5 "red")
(5 5 "red")))

;; Method calling syntax?

;; Explicit - Works but ugly syntax
(call-method object 'method-name args)

;; Implicit
;; Problem is that we need 1 lookahead
;; and one cannot override macros.
(method-name object args)

;; Special syntax
;; Looks a bit unlispy - and overriding functions
;; would still need the implicit syntax ...
(object:method-name args)

Binding snippets

  class MyClass {

 // Some constructors.
 this() ...
 this(string name) ...

 // Some methods
 void methodName(int arg1, int arg2) ...
 string returnsString() ...

 // BINDING CODE

 // Generate the core binding
 mixin BindClass!("MYCLASS");

 // Default constructor is autogenerated
 mixin BindConstructor!(string);

 // Bind the methods.
 mixin BindMethods!(methodName,returnsString);
}

Game Design Document I

The goals of iteration-zero are to create an role playing game with a simple interface and gameplay in a closed world.

You are playing a space marine, cyber assassing or something like that who lands on a new planet and has to fullfill a mission. You are supplied with a glider, an aircraft enabling you to travel accross the planet to different locations of interest. Accompanying you is robot with an A.I. and up to 6 other compagnions you can invite into your traveling party. Your party will earn experience and find new technology through overcoming enemies and fullfilling missions given by locals.

There will be two major game modes. With your glider you can travel over the planet and visit known places or try to find hidden areas. You will be able to land nearly everywhere, but most landing areas will be devoid of anything of interest.

You will have to refill your fuel supply and make sure your glider can carry all your equipment. Upgrades to the glider can be bought at several locations.

So the exploratory radius is constrained by the fuel supply and the player has to make a choice between different equipment available. The random levels at each possible landing location give the planet a feeling of space, while not interfering with smooth gameplay. Hidden areas can be revealed simply by riddles giving out coordinates upon solution.

You will explore alien ruins, infiltrate military outposts and hunt down delinquents. Hostile encounters have to be resolved by tactical skill and using your resources wisely. Upgrading your bodies and minds with the technology of the future might help you to survive the more dangerous missions.

Basically combat will be turn based, starting after an enemy has been encountered. As with other RPGs your party members levels and your equipment will determine the outcome of attacks. The RPG system will be designed in more detail later on.