Sunday, July 30, 2006

Using DScript

Sorry for not posting for such a long time. Was a pretty stressful week. Anyway, I made some progress with SRPG.

Besides others things I started to develop the game world (so far I had only some test locations). And in doing so I found another bug in DScript. The error reporting mechanism isn't only off by one (as mentioned in the !Help file). While working an the world script, it went completely bogus. By now I am almost regretting, that I did release DScript that early.

I won't give you much information about the game world, because that would be a spoiler. But here is an excerpt from the script, just so you have an idea how it looks:

Exits 3
ExitNT L_BP_City
Exit L_BP_Mine
TriggerBegin 1
Cond_HasItem I_Coin 10
Act_RemItem I_Coin 10
Act_Message "No_Money"
Exit L_BP_HauntedMine
TriggerBegin 1
Cond_Skill Sk_Level 5
Act_Message "Lvl_Low"

Monday, July 24, 2006

SRPG trigger and DScript bugs

Last weekend I wrote a trigger system for SRPG. A trigger consists of a condition and two possible actions. Think of it as an "if <cond> then <action1> else <action2>" instruction.

I have already a large collection of conditions and actions, though probably a lot more will be needed. Because of the nested structure of the trigger system, it almost provides the functionality of a fully featured script language. Only loops are not available, but I think we will get by without them.

Currently I am not planning to give SRPG a script language of its own. The trigger system should be sufficient to handle all quest-& story-requirements. And using DScript's macros (SRPG world files are generated with DScript) we have almost a script language (though it looks more like assembler than like a high level language).

While doing tests on SRPG I discovered two bugs in DScript. Apparently it is possible to crash DScript by using the Include instruction. Very annoying. I thought DScript to be totally stable. The second bug is related to the Path instruction. Strangely it does not show up in version 0.10. It only gives trouble with my current development version of DScript. Looks like I broke something recently. I will have to investigate further ...

OK, now how are these triggers working? There are placed on certain events, e.g. player is trying to use a connection between two locations. Than the trigger can start certain actions and either let the player continue or stop him.

In the above example the trigger could be used to limit the access to a location to characters with certain skills or with a special item in their inventory. Or the player could be requested to pay a toll. Or ... Well there are certainly hundreds of options.

Thursday, July 20, 2006


I'm recovering slowly from that dreadful Monday.

The problem with DScript expressions is fixed. Was about two hours of work. Not too bad actually.

The problem with SRPG was ... well, no real problem at all. There wasn't a bug. The documentation of the language, which is used for communication between the front end and the back end, was faulty. Apparently I can't use my own language properly. But it wasn't intended for use by humans anyway and hey, it was Monday. That excuses a lot.

On the build system front things didn't went so well. I have found the source of all the trouble. gcc 3.4 has a problem with path handling. In some cases RISC OS paths don't work, so you have to use Unix style paths. But on the other hand some parts of my build system don't like Unix style paths at all. I guess I can't do anything about it, except for waiting for a new release of gcc.

Tuesday, July 18, 2006

I hate Mondays

Did you ever had a day, when nothing worked? Yesterday was such a day for me.

Disaster #1:

While working on the expression classes of DScript, I noticed that I made a mistake. There is an abstract base class for expressions. And there are the concrete classes for the different types of expressions. And that's all. No base classes for expressions with common traits (eg. binary operators). That means, when ever I want to change the functionality of all binary operators I have to change all the classes. WTF? I am not supposed to make such mistakes. I have written at least half a dozen parser systems and non of them hat problems of this kind. Absolutely no idea, why I did such a stupid thing.
Now I will have to introduce at least two more base classes. Not very complicated, but a lot of work.

Disaster #2:

In my last post I mentioned, that SRPG has a working resources gathering system. Forget that! The system is at least partially broken. Probably nothing too serious either, but I will have to look into this.

Disaster #3:

Ever since I changed from gcc 2.95 to 3.4 I noticed some oddities when compiling stuff. Yesterday I found out, that it is far worse, than expected. Something in gcc 3.4 doesn't go along with my build system. I don't even have an idea where to look for this problem. It will take a lot of investigation before I can write a proper bug-report and/or find a workaround.

In the meantime I am left without a working build system, which means whenever there is a change in a file, I have to manually track down which other files need to be recompiled/relinked.

DScript is not affected, because I am still using 2.95 here. But SRPG is and Graphite will be, once I changed to 3.4 (which is absolutely necessary). I can probably handle SRPG this way (though a lot slower), but there is no way I could work on something of Graphite's size without a working build system, which means Graphite is on hold until the problem is fixed.

Sunday, July 16, 2006

Project #3

Some posts ago I mentioned a 3rd project besides Graphite and DScript. Now I feel ready to go public with it.

It is a game, a single-player RPG, to be more precise. It is in an early stage and doesn't even has a name yet. The working title is SRPG, where 'S' stands for simple.

Now simple doesn't mean, it will be a simple game. What I am trying to do is building a complex game by simple means, so that development time can be cut down considerably.

I give you an example: Most RPGs today have a map (either isometric or real 3D with first person perspective), where the player can walk around freely. SRPG won't have that. Instead I will create a set of locations, that can be reached through a well defined set of connections. These locations can be represented on a graphical map, but a pure textual user interface would do as well.

I am not aiming for a textual game. SRPG will have a GUI, but that is only for the players convenience. It could as well be played from a console-like user-interface without loosing any gameplay functionality.

I am trying to adapt features commonly found in MMORPGs, especially resources gathering and crafting, giving the game an addictive quality. In MMORPGs the economy is shaped by the actions of the players. In a single player game that isn't possible, since there is only one player. Instead I am planning to let the storyline and the major quests influence the economy (eg. events can raise or lower the prices for certain materials, increase/decrease the demand for weapons and other equipment).

Combat will be rather tactical. Again, no map, where player and enemies can roam freely. Instead I am aiming for something like the old Bards Tale battle system. For those of you, who don't remember: In BT foes were listed by distances, which opened up tactical options like advance/step back/range attacks/melee attacks and so on. Furthermore I want to add a complex system of attack/damage-types and immunities, so not every attack will work equally well on any foe.

The overall design is rather experimental. To be able to concentrate on the gameplay I separated the back end (that is where the gameplay takes place) strictly from the front end (the GUI). Now that by itself is neither experimental nor unusual. On the contrary, it is generally considered good design.
What makes this setup so special is the interface between front end and back end. It is pure textual. The front end translate the players instructions into some commands and sends them to the back end. The back end does the gameplay stuff and then sends some commands back, which are used by the front end to update its display of the game state.

The main objective of this design was, that I could work on the back end without worrying too much about the front end. Only much later I noticed, that I created an opportunity for parallel development. Someone (me) could work on the back end, while someone else writes the front end.

Now I know, that there aren't that much developer left and most of them will probably prefer to work on their own stuff. I don't have much hope to find someone, who would be willing to write the front end for SRPG. But it is certainly worth a try, so I will ask on the newsgroups (and maybe some other places), once the development is a little more advances. Anyway, if someone who reads this post (and has sufficient programming skills) would be interested in taking part, please let me know. You can either comment here or send me an email (address in the contact section of the Z-Pages, see sidebar link).

I would like to show you some screenshots, but there isn't anything to show. My temporary front end consists of a solitary console, through which cryptic instructions can be issued to the back end, which answers in an even more cryptic way.

So far I have the following stuff ready:
  • a basic item system (no item usage yet)
  • the foundation for the skill/levelling system
  • one flavor of the gathering system (mining-style)
  • the location system

Saturday, July 15, 2006

Progress on the library front

The necessary changes on the foundation library and the framework library are complete. While working on them, I noticed some details, that I don't like. The way the code is partitioned into these two libraries doesn't make much sense. Also I would like to change the way how the GUI-related stuff works.

The longer I look at the code, the more I get the impression, that these two libraries have reached the end of their life circle. Maybe it is time for writing a new set of libraries to replace them (re-using as much code as possible, but without inheriting the design weaknesses). Anyway, that is something I will think about later (much later). For now I have more than enough tasks at hand.

After finishing with porting the libraries to the new compiler, I took a look at the Graphite source. It seems like some pieces of old style code skipped into Graphite, too. Annoying. Now I have to repeat the whole procedure.

In between I made a small improvement to DScript. The NTString instruction can now take an optional 3rd argument, that specifies which value is used for padding, e.g.
NTString 12 "draw" " "
This generates the following sequence of bytes:
' '
' '
' '
' '
' '
' '
' '
' '

Wednesday, July 12, 2006

About libraries

The release of DScript was delayed by a showstopper bug, but now it is done and I am free to work on other things. Well, at least partially. Version 0.10 is really too incomplete to keep it that way for an extended period of time, so I will have to start working on 0.20 very soon. But for now I will concentrate on some maintenance work, that was long overdue.

Back in 1998 when I started to use C++ there was a lack of C++ libraries for the RISC OS platform. So I started to write my own, which acted as a foundation for all further C++ development (hence the name foundation library). It contains:
  • some very low level stuff
  • some OS dependent stuff
  • a replacement for a subset of the STL (STL wasn't a very big topic at that time and my understanding of templates wasn't too good, therefore I didn't even consider using the STL)
  • a lot of GUI stuff (including a complete replacement for the toolbox library, included in the AcornC/C++ package)
  • some more stuff
Later I created the framework library, which provided basic editor functionality:
  • document handling
  • multiple views of the same document
  • undo/redo
(you can find out which versions of these libraries are used in my software by opening a taskwindow and typing ".!RunImage -ver" and "DScript -v")

Both libraries look very old and dated now and though they received a lot of improvements and modernisations over the years, they won't compile with a modern C++ compiler. Namespaces are a problem, as well as things like
class ostream;
That was perfectly legal C++ once, but now it isn't anymore (because stream classes are templates now).

With the current state of these libraries I am stuck with version 2.95 of gcc. Much too old to be used for productive work. Its time to change to the 3.x line of gnu compilers (and I am really looking forward to the 4.x version), so I finally decided to start updating the code.

It isn't a very complicated task, but a time consuming one, because the changes are spread all over the source. The foundation library for example consists of 6 subsystems and it took me the whole yesterday evening to update only one of these.

Sunday, July 09, 2006

DScript status II

I'm done with coding. The front end is finished, too. Things left to do:
  1. compile release version
  2. write documentation
  3. package stuff
  4. upload stuff
  5. update website
  6. post to c.s.a.a
  7. enter DScript into various software databases
Why do I get the feeling, that releasing software is even more work than writing it?

Saturday, July 08, 2006

DScript status

The binary operators are done. While doing some tests, I found a bug in the table feature. Nothing serious, but I have to investigate this problem, before a release of DScript is possible. Looks like I am a bit behind the schedule ...

Thursday, July 06, 2006

Operators and some examples

Yesterday I finished the unary operators, so the binary operators remain to be completed. I know that there are tools, that can be used to automate the creation of a parser, but I prefer to write my own parser by hand. It is more fun that way (am I crazy, because I like writing parsers?)

OK, time to start with some examples. How about building a draw file in DScript? First some macros:

Macro Header prog xl yl xh yh
NTString 4 "draw"
2 Word 201 1 ! version
NTString 12 prog
4 Word xl yl xh yh

Macro Text textcol backcol font xsize ysize xc yc str bb_xl bb_yl bb_xh bb_yh size
Word 1 ! Text
Word size ! total size of text object (future versions of DScript will be
! able to calculate this value automatically)
4 Word bb_xl bb_yl bb_xh bb_yh
2 Word textcol backcol
FlagWord ! little trick to ensure only lower 8 bits are set
! (upper 24 are reserved)
8 Flag font
2 Word xsize ysize
2 Word xc yc
String str
And now a draw file:
Header "draw" 0 0 1000 1000
Text 0 255 0 16 16 0 0 "test" 0 0 1000 1000 60
The given values are more or less arbitrary. Not sure if they would give reasonable results, but that doesn't matter since it is only an (untested) example.

These macros have pretty large argument lists. We could improve them by putting some values in variables, that could be modified by other macros, e.g. the colours:
Header "draw" 0 0 1000 1000
SetTextColour 0 255
Text 0 16 16 0 0 "test" 0 0 1000 1000 60
Text 0 16 32 0 0 "test2" 0 0 1000 1000 60
Since I am running out of time, I won't give you the SetTextColour and the modified Text macro here. You can try writing them yourself, when DScript is released ;)

Monday, July 03, 2006

DScript Progress

Usually, when I set a release date, I can't hold it (at least when working on stuff in my spare time). Delays of several weeks or even months aren't uncommon. But this time it could be different.

Yesterday I wrote the last main feature. Now I have to do some work on expression parsing and some other minor stuff. Then I will have to write the documentation (fear and loathing) and create a front end. And that's it.

The first version won't have all the features I am planning. You can see that very easily from the list of reserved (but unimplemented) keywords:
  • DefMap
  • Set
  • Map
  • MapCol
  • Defer
  • Return
  • Function
  • Global
  • SysVar
  • Report
  • Alias
  • Full
  • Size
  • True
  • False
  • Label
  • Type
Nevertheless the first version should be usable very well and I am almost 100% sure, that I can make the release before the end of this week.

Saturday, July 01, 2006


DScript, my latest project, is a tool, that lets you generate binary files from scripts (a simple desktop front end to DScript will be provided).

There are numerous uses for a tool of this kind. Let's imagine you are writing a new editor and you start with the redraw routine. Now you need a file for testing the redraw. But you don't have any editing functions yet, so you must put one together by hand. DScript can handle this task with ease.
Or let's imagine, you are writing a game (think of something like HoMM2). While developing the game, you will need a map to test the features you are working on. Later you will be writing a nice shine map editor. But now that task would only get in your way (probably because it would disrupt the workflow and the map format might be subjected to changes). DScript can be used to make such a map file and with the macro-feature changes to the map format aren't a big problem either.

These are only two possible usages and I am sure once I released DScript, people will came up with more.
Actually I have used DScript already for the two purposes given above, but that was with a different instance of DScript, I wrote many years ago. It was written in C, never spread beyond my harddisc and since this was my first compiler-like tool, I didn't know very well, what I was doing, which resulted in extremely unmaintainable code.
The new version is a complete re-implementation, that isn't reusing any piece of the old code. I used to opportunity to clean up the script language and to remove some irregularities. Therefore at least the concept should be mature and stable from the first release on.