Samstag, 14. Juni 2008

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.

  • 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!

Dienstag, 10. Juni 2008

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.

Montag, 9. Juni 2008

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.