AGC - Adventure Game Creator - source code

Just in case anyone is interested, here is the source code to the AGC program (see previous post).

It is written in delphi, it is 20-odd years old; the Delphi version is outdated, the code, is probably not pretty and buggy.

You might be able to get it to compile - you might be able to make a half decent program using bits of it. If so, that's great. Crediting me would be nice, if you feel that way inclined.

Obviously, there is no warranty, and don't come to me crying if it blows your computer up. Or something.


Grab the source archive here

AGC - Adventure Game Creator

Back in 1996, using apparently Delphi V1 or 2, I wrote an adventure game creator program, called AGC.

It was a blatant rip-off of the PAW by Gilsoft, and I'd like to apologise to Tim for massacring his software in this way!

Today, I came across the backup floppy I had of the original program, and so I'm putting it up here for posterity.

If you run 'project.exe', you'll get a reasonable (I think) version of the original PAW demonstration game, in the park. As I recall, even things like the bird semi-autonomously moving and so on, used to work.

If you decide to have a play, beware - it was written in 1996, and according to the about page, it is only version 0.2, so god only knows what happens when you press some of the buttons.

You can get it here

Progress 20190129

The worker module has been translated. This actually includes a considerable amount of text spread out in loads of files, and so represents a lot more work than 'the worker module has been translated' leads to believe.

Doing this actually allowed me to strike TWO items off the TODO list.


(and when you click 'publish' instead of 'save' the post becomes considerably more visible...)

Sanity checks

So, since i have (currently) 5 working and 1 WIP DLL for the backup system, and since four of these share the exact same interface,, i thought it would be a proverbial Good Idea (tm) to force compliance - force the signature of all exported functions to conform to a predefined type.

Let me explain. I can have a function called MyFunc, it looks like this: function MyFunc(inP: Integer) : String;

so it takes an integer and returns a string. Why not.

What I wanted to do was define a type : type TMyFunc = function(inP: Integer) : String;

then define the real functions in each DLL as conforming to the type TMyFunc. That way if I change the definition of TMyFunc, the compiler will let me know because the functions are no longer defined correctly.

Well, to cut a long story short, you can't. You cannot define a function according to a type. Which is a bit of a pain really. Wouldn't be useful to very many people I suppose, but in my case, it would have been great.

So to work around this, I did it another way. In the initialization section of the DLL, I now have a little but of code:

var lMyFunc : TMyFunc;
  lMyFunc := MyFunc;

(I turn off the hints so that the compiler won't tell me i have a variable to which I assign a value and then never use it).

So I have a variable of type TMyFunc - a variable which is a function. And I assign a real function (MyFunc) to that variable.

Works perfectly, and if I change the definition of TMyFunc (which is in a shared unit), the compiler will complain that "parameter lists differ". I have to do this manually for all exported functions from my DLL, but it is better than nothing!

Now to continue implementing the stuff. Doing this added quite a few items to my TODO list...and doing this wasn't even ON the TODO list! But having a caller fail because the DLL was compiled with an old version of the interface is not really "cool". I prefer to have the compiler tell me, rather than users...

Progress (20190110)

Quick update. Translations for the following modules are done into French (including of course the modifications in the modules to use the translations):

  • Restore (even though this module is not 'finished'
  • ABLocal (save to a local directory)
  • ABS3 (save to amazon S3)
  • ABFTP (save to an ftp site)

I want to make changes to the translation system to have this handled by configdll, right now each module will have its own copy of all the translation texts, which is not ideal. It won't make any difference to the API interface from the caller, though, which is great.

I've also updated the copyright texts in all modules' build configuration to 2019, fixed a couple of cosmetic bugs I found in those (this is stuff I haven't really looked at for ages). Also made a post-build tool file. And discovered that the service module doesn't have a build file, and the trayicon module needs some work.

I now have a fairly good idea of exactly what is in an unfinished state, as well as the functionalities I need to implement. Since this is a glorified TODO list, I'm working through it slowly, but real progress is being made.