No RISC, No Fun!

The Gothic Fever and Other Problems

2006-11-12T15:55:00.000+01:00

The Gothic fever hit me harder than I expected (even though the game is not as good as I hoped). I have almost fully recovered by now but unfortunately there were other problems. I won't bore you with my private life. But fact is for the duration of a month I didn't had much time to work on any RISC OS stuff. Half an hour here, half an hour there. Impossible to work productively under these conditions. Unfortunately things won't get any better in the near future.

Hence I made the decision to take a break from RISC OS work. A month or two should be enough. Hopefully I will have more time available again thereafter. Sorry to all, who wait for updates and/or the SRPG release.

What did I say?

2006-10-12T09:57:00.000+02:00

"hopefully I still can blogg at least once per week."

Oh, dear. Almost two weeks since I wrote that and no new entry. Sorry! Had some very hectic days and wasn't able to make much progress on any of my projects.

"unfortunately" tomorrow is the German release of Gothic 3, which means I won't be able to get any work done for several days, because I will be busy playing. It would surprise me if I even find the time to eat and drink enough to save myself from starvation and dehydration. Doing any work is totally out of question.

Slowing down

2006-10-01T12:12:00.000+02:00

Those of you, who are following my blogg on a regular basis, have probably noticed by now, that my posts are getting more infrequent. It looks like my RL is getting more demanding again, so the time available for RISC OS work is more limited. It shouldn't be too dramatic. I guess I will be able to devote around 50-75% as much time as before and hopefully I still can blogg at least once per week.

Back to SRPG: Today I implemented a kill count mechanism. Obviously this can be of some use for the player, since fighting will be an important part of the game and he might want to know how many creatures of a specific kind he already has killed.

But the kill count has another, even more important purpose. Apparently no self-respecting RPG can get by anymore without a "My cellar has been invaded by n rats. Please kill them for me."-quest.

Actually I am not so sure about that. It sounds rather stereotypical. On the other hand stereotypes only become stereotypes, because they work. And the rat quest gives the player an easy, familiar way to get accustomed with the battle and quest system of the game.

Various Bugs (Mine and those of other People)

2006-09-22T15:00:00.000+02:00

While writing the encounter macros, I encountered another bug in DScript. Nothing very serious, but apparently the Byte, Half, Word, Float and Double instructions aren't working with a quantifier of 0. SRPG is becoming more and more a stress test for DScript.

I found another bug in gcc, which I overlooked in gcc 3.4.6 r1. This was pretty stupid of me, since now I have to wait for another release. This means my build system is still broken, so Graphite is on hold probably for a few more months.

The good side of this is, that I can concentrate more on SRPG. I am working on the battle system now and it proved to be more tricky than I expected.

Encounter

2006-09-16T12:50:00.000+02:00

The encounter system is mostly done. I still have to write some DScript macros and probably some more tests are in order. Next I will start to implement the battle system.

OK, how is the encounter system working?

Each location hat a set of possible encounters, each with a certain probability. When the player goes hunting in a location, an encounter is randomly selected. Since encounters can be invoked from a trigger it is possible to let other actions start an encounter. Let's say the player is mining in a dangerous spot. The mining action has a trigger, which has a certain chance to invoke an encounter. Makes mining much more interesting ;)

The set of encounters for each location is static (it can't change while playing the game), but the system has some dynamic components. It is possible to modify the probability of an encounter. Is is also possible to modify an encounter through a power factor, making it more or less dangerous. Both factors (probability and power) can either me modified locally or for the whole world.

Time

2006-09-11T10:26:00.000+02:00

SRPG can now keep track of the passing of time. This can result in changes to the player state or even to the player skills, depending on what the player is doing.

I did spend the last weeks with lots of small stuff, that is required for the bigger features. Now that I am through with it, I can start to implement the combat/encounter-system. Looks like we are finally getting somewhere ...

Here is a short summarisation of my to-do list:

encounter system
battle system
crafting system
trade system
item usage system
magic system
+ about a dozen smaller improvements and additions

I guess once encounter/battle is done, I am halfway through with the backend.

State

2006-09-07T14:23:00.000+02:00

The character state system is almost finished (with character state I mean things like health or mana).

Each state value consists of two party

the current value (modified by various actions and events)
the maximum value (determined by skills/attributes and other state)

Furthermore some state will be marked as a "life state". If one of these ever drops to 0, the player is dead.

For the world, that I am working on in parallel to writing the back end, I plan 5 state values:

Body points
Health points
Spirit points
Mana
Stamina

(the first 3 are life state). More details later ...

Attributes and Skills

2006-08-30T14:14:00.000+02:00

I decided to reuse the skill system for the player's attributes (like strength, intelligence, ...). An attribute will be just a special skill, that has no explicit usage (it affects the use of other skills though). This method does not require any additional implementation in the back end (it will be up to the front end to distinguish between attributes and skills).

I haven't said anything about the skill system yet. I guess I need to catch up on that, since it is mostly finished.

SRPG will have a hybrid skill system. Basically it is learning-by-doing. While using your skills, you gain XP in that skill, in your main level and sometimes in an attribute. If you get enough XP in a skill/an attribute/the main level it will rise by one point.
With the main level the hybrid aspect comes into play. For each level you gain a free point, that can be used to improve a skill (or an attribute). This way the player can develop and customize his character a bit beyond skill training. Furthermore the hybrid system allows XP rewards, which does not come from using a skill. This can be used for quests and probably some other things.

After the Release is Before the Release

2006-08-26T20:12:00.000+02:00

The path handling routines in DScript are causing trouble again. Looks like the latest fix created another bug. Absolute paths, that contain system variables, can't be used with Path, Insert and Include instructions, though using foo$Path variables with the foo: syntax works properly.

The problem is rather easy to fix, but I don't think that it is serious enough to justify another release at this time. Instead I will focus on SRPG for a few weeks.

Examples

2006-08-22T15:49:00.000+02:00

I am very close to another release of DScript. The executable is build and I'm working on documentation and examples now.

After the release of DScript 0.10 some people complained, that there were no example scripts. Probably justified. But it isn't easy to come up with a good example. A good example is simple and self explanatory. So what data can we create? It needs to be in a format very well known by lots of people. This rules out most interesting options already. So we are left with a few standard formats: DrawFile, Template, Sprite and a few others. I finally decided for DrawFiles or rather a subset of this format, since a DrawFile is pretty complicated.

While working on the examples I found two more bugs. The first one affected the @@-expression. @@ gives you the current address, but I took the address when creating the expression object, which doesn't work from within macros. Easy to fix. I am glad, that I found this bug so early.

The second bug is something I am not happy about. It is a compiler problem, one I knew about for a long time. But I didn't notice, that it affects DScript in this particular way.

It makes a program crash, when an exception is thrown (which happens a lot in DScript's error handling), but only in the release version (which is compiled with -O2). The development version is not affected, which is the reason, why it took me so long to notice the problem.

The obvious solution is to switch from the ages old 2.95 compiler to 3.4 (done that already for SRPG). That should fix the problem. But 3.4 has another problem (I wrote about it before). It makes working on SRPG a very annoying task and I simple don't want to add these kinds of trouble to another project.

For now I compiled the release version of DScript without the -O2 switch, so it will be a bit larger and a bit slower.

/me is too lazy

2006-08-21T08:18:00.000+02:00

For some reason I didn't manage to do any RISC OS work last week. Which is rather strange, because it wasn't very busy at all. Well, I guess the title of this post says it all. I promise to do better this week.

DScript bug fix

2006-08-13T13:14:00.000+02:00

Finally I found the a bug, that was troubling me since the release of DScript 0.10. The Include instruction didn't work as expected and now I know why. There was a problem with handling of local paths in the foundation library. Time for another patch ...

DScript is really making great progress. If nothing unexpected goes wrong, I should be able to make another release within this month.

Don't litter!

2006-08-10T10:01:00.000+02:00

SRPG now has triggers, that are local to locations. So far I have only implemented a local trigger in the "drop item"-action. There is a wide field of application for this trigger. It could be used to stop the player from dropping stuff at certain locations, let's say inside a shop or even in a whole town. Or the player could be forced to pay a fine for dropping stuff on the street. Evil, isn't it?

Since DScript's error reporting mechanism is working properly now, I was able to make some improvements to the world script. It is much easier to fix a script, if you get the line number and don't have to search a 20K script file for a faulty line.

Hunting the line counting bug

2006-08-06T14:17:00.000+02:00

He tried to hide, he tried to evade, but finally I hunted him down and nailed him to the wall. Poor bug. Against my superior debugging skills he never had a chance.

Ok, let's get serious again. As expected the bug was in the scanner, which is a part of the foundation library. I have fixed it in version 1.12 which is used in DScript. Now I have to manually transfer the changes to 1.20. Maybe it is time to start thinking about SVN.

In between I made another addition to DScript: The Report instruction writes messages to the standard output stream. Not very spectacular, but still useful, I assume.

Verification

2006-08-03T09:02:00.000+02:00

Yesterday I added the verification instructions to DScript. These instructions don't generate data, but check that some conditions are meet. This is a very important addition, because it allows the writing of much more robust macros. Available instructions: ?Full, ?Align, ?HAlign, ?True, ?False

Example:

FlagByte fl
8 Flag fl 0
?Full fl ! good

NTString "draw"
?Align ! good

Table ta 2
Entry ta
?Full ta ! not good

The last instruction would produce an error message, that can be used to easily track down the bug in the script.

Or at least it would be easy, if the error reporting mechanism would be working properly. I have narrowed down the problem to lines, that contain comments. Apparently these lines confuse the line counting mechanism, but I have no idea, what is causing this. More investigation needed ...

On the SRPG front I didn't make much progress. It looks like I have to add some kind of logging to the world loading code, so I can track down problems easier. This has priority over new features.

Using DScript

2006-07-30T11:24:00.000+02:00

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
    Trigger
        Cond_HasItem I_Coin 10
        Act_RemItem I_Coin 10
        Act_Chain_Begin
            Act_Message "No_Money"
            Act_Abort
        Act_Chain_End
    TriggerEnd
Exit L_BP_HauntedMine
    TriggerBegin 1
    Trigger
        Cond_Skill Sk_Level 5
        Act_None
        Act_Chain_Begin
            Act_Message "Lvl_Low"
            Act_Abort
        Act_Chain_End
    TriggerEnd
ExitsEnd

SRPG trigger and DScript bugs

2006-07-24T12:35:00.000+02:00

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.

Recovering

2006-07-20T09:35:00.000+02:00

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.

I hate Mondays

2006-07-18T09:42:00.000+02:00

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.

Project #3

2006-07-16T12:08:00.000+02:00

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

Progress on the library front

2006-07-15T12:33:00.000+02:00

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:

'd'
'r'
'a'
'w'
' '
' '
' '
' '
' '
' '
' '
' '

About libraries

2006-07-12T09:49:00.000+02:00

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.

DScript status II

2006-07-09T17:06:00.000+02:00

I'm done with coding. The front end is finished, too. Things left to do:

compile release version
write documentation
package stuff
upload stuff
update website
post to c.s.a.a
enter DScript into various software databases

Why do I get the feeling, that releasing software is even more work than writing it?

DScript status

2006-07-08T16:26:00.000+02:00

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 ...

Operators and some examples

2006-07-06T14:04:00.000+02:00

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
End

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
Align
End

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 ;)

DScript Progress

2006-07-03T13:58:00.000+02:00

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.

DScript

2006-07-01T14:05:00.000+02:00

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.

Projects

2006-06-29T15:26:00.000+02:00

At the moment I work on three active projects, which is actually a bit too much (I had always the unlucky tendency to spread my workforce too thin among too many things).

The first project is Graphite (download available from my site, see sidebar for a link). Some of the features I originally planed for Graphite aren't in yet. Same applies to a lot of features proposed by users. Quite a few of them are essential. But hey, Graphite is only at version 0.45. I still have some version numbers left before 1.00.

The next step in the development of Graphite is a huge, monotonous and monolithic task (more details some other time). I am not very eager to start with it, but sooner or later I will have to.

The second project isn't ready for going public with it (it doesn't even have a name yet, though there is already a healthy amount of working code).

The third project is called DScript and it is clearly worth a post of its own. For now I will only tell you, that the first release isn't far away anymore (I'm aiming for next week). Today I got the confirmation of my allocation of the application name. The promptness and easiness of the allocation process is surprising me again and again. Alan Glover is really doing a great job.

Source Code

2006-06-28T11:33:00.000+02:00

It is very likely, that I will include some source code snippets in future posts. Considering this Blogger probably wasn't a very good choice. It is possible to paste source code into posts without manual editing, but only with some tricks. Syntax colouring would have been nice, too. Nevertheless I have decided to stick with Blogger.

So far I wrote most of my code in English, but with comments in German and most of the technical documentation in German too. Recently I came to the conclusion, that it would be better to switch to English entirely. But that is mostly relevant for future code. There are about 15 MB source code sitting on my hard disc and I have no intention of translating them, if it isn't absolutely necessary. A large fraction of this code belongs to abandoned projects, but that doesn't mean it can't appear in an active project. Code reuse is great! Would you believe, that a significant portion of Graphite was once part of an abandoned RPG project?

When I post larger code sections, it is quite possible that some German comments will show up, which escaped translation (same has happened already in Graphite's GUI; very annoying). I would like to excuse in advance for that kind of problems.

Welcome

2006-06-27T13:18:00.000+02:00

A recent Drobe vote brought me to the idea of starting a blog. I have no idea, if this works. If it takes away too much time from programming, I will stop blogging instantly. But let's not get overly pessimistic. It could be a very productive experiment as well.

So, what can you expect? Since this blog is about coding, obviously a lot of very technical stuff. I'll do my best to make it interesting too for people without programming background, but I wouldn't bet on the success of this endeavours.

The main purpose of this blog is to keep you informed about the progress with my various projects (hopefully this works better than the infamous progress page, that I had on my site a while ago). Occasionally I might digress from day-to-day coding and state my opinions about more general programming topics. And when I'm fed up again too much with my idiot box, you can be sure to see some rambling about how much I hate Windoze.

All comments are welcome. Have fun!