Thordar's Adventure (early in-dev)

[DelphiMarkus]

Thank you for the examples! I will have a look at them when doing more graphics.

Currently I am implementing a small VM to make the game scriptable. I started implementing it in Python to see if it will work and to be able to do some tests on my computer. The scripting language will be something influenced by BASIC and some Pascal. I choose BASIC as it is relatively easy.
The idea is to have a small compiler on your computer which translates the script into byte code which can be executed on the VM on the Gamebuino. There is support for some stack (16 level -> 32 byte?, not defined yet) and 26 variables named "A" to "Z" to have some "external" storage (which will be inculded in a savegame).

The main instructions are implemented in the Python VM and it runs fine. I started porting it to the Gamebuino but I'm not finished yet. Some special instructions to interface with the game engine are missing and will be implemented later.
I'm currently working on the compiler also written in Python as it will never run on the Gamebuino. As it would probably last even longer if I try to create a parser, I decided to use a parsing library. It does a pretty good job and I can concentrate on generating an AST for now.

Some technical details about the VM:
As I am too lazy to get into register allocation algorithms, I decided to build a stack based VM. So everything is done on the stack. The byte code will be read from the SD card filling a 256 byte buffer. The VM reads its instructions from there and executes them. As the access to the SD is read-only the architecture of the VM is a Harvard architecture not being able to modify the program it is executing. Addresses will be identified by a 16 bit unsigned integer limiting the address space for any script to 64k.
The memory consumption of the VM (on the GB) is currently about 340 bytes + some implementation dependent things like a stack pointer, program pointer, ...

It will take me a while to finish the compiler. It's my first try to build a compiler but as I wanted to build one for quite some time I already read some information about compiler construction. However, there won't be many updates to Thordar in the next time.

[leiradel]

I wrote a similar VM for the Z80 some time ago. It takes too much instructions to decode the VM instruction to get the register index, and then to compute the register's address in RAM to finally be able to use its value. It's not worth the additional complexity in both the VM and the compiler. I ended up using the SP register for the VM stack so that I could use the push and pop instructions. Since the compiler can guarantee that the stack will be empty when the script finishes, it worked very well.

I did however implemented getlocal/setlocal to save values between script executions, but there wasn't any register allocation. The intention was to attach each game object to a script that would update the object every frame, and getlocal/setlocal would be used to access the objects' fields. Yes, they should be called getfield/setfield.

[edit] Another benefit is that the code density is higher with stack-based VMs, because the operand addresses are implicity. In a register-based VM with only eight registers, you'd need six bits just to address two registers, a source and a destination, leaving just two bits for the opcode, forcing you to either have 16-bit instructions or have a special accumulator register that would be the implicit destination of all operations.

Cheers,

Andre

[jonnection]

Very interesting discussion guys.

I have no experience of writing VM's but I used Pawn in one of my microcontroller projects (on a STM32F103) ... but that had 20kb of RAM. I guess writing your own VM is the only option on a 2kb device.

I had to read up on stack vs. register VM's to understand what you were discussing and seems like the stack based approach is the right thing to do. Writing games on the 8-bit AVR I am constantly amazed at the processing power it has and frustrated at how little space 2kb really is So I'd take any approach that saves memory at the cost of cpu cycles. Also, moving from 8-bit instructions to 16-bit you would definitely take a big hit in performance and memory use, and I doubt you would be able to recover your losses in other areas.

Please tell us about your progress DelphiMarkus as you go along, I'd love to hear about technical obstacles and solutions you encounter.

I love how this little DIY game console keeps forking into crazy sideprojects

[DelphiMarkus]

"Some" time ago on the Z80? I build a small Z80 computer in the last months and wrote a CPM2.2 BIOS and an interface to an SD card to use it as a floppy using an Arduino. It's a really nice processor but quite old, but it's relatively nice to program in assembler for it. And it is a great processor to learn some assembly.

However, I'm not going to write my VM in assembler, I will stick to C. I designed another VM some time ago using a register based approach but the instructions are getting bigger as you need to store more information. This is my first stack-based approach and it seems to be not that bad at all. And I don't need any register allocation stuff. The register allocation algorithms are complex as I expected and read in a nice (old) book available as free download as of today: Understanding and Writing Compilers.
I've got an RPN calculator from HP which I'm using regularly. My VM is quite similar to such an RPN calculator as there is a limited stack and a limited number of places for variables (e.g. from A to Z).
Many arithmetic opcodes have two addressing modes: (a) do the operation with two values from stack, (b) one operand from stack and the second one is given by an 8bit signed immediate value trailing the opcode. I expect that a range from -128 to 127 is enough for many operations. I had a third addressing mode at first with a 16bit signed immediate value, but excluded it as it took away too much space for other opcodes.
I ran almost out of space, even though stack based machines usually have a good density as the destination (and source) is implicitly defined. And density is the most important aspect for this VM. Reading from SD card is quite expensive as it consumed very much time.


I wish I had more RAM, but it's a nice challenge to squeeze as much information into a small amount of memory as you can. And writing a compiler is quite fun as well. It's a compiler with many small passes where every pass does some small adjustments e.g. optimise to get an executable.

And here is a preview of the syntax of the programming language:

Code: Select all

PROC MAIN(TEST: X, MX:Y)
    LET X = 20 + D + 10 * 3 + 3 * E + 99 - 6;
    LET *X = "Hallo!";
    LET X = ABS(-1);
    ALIAS TEST2 : X + 100;
    PRINT(*X);
    PRINT(1+1);
    TEST = 100 + 100 * (10 + D) + TEST;
    PRINT("Is 0 < X < 100?");
    IF NOT (0 < X AND X < 100) OR B = 0 THEN
        PRINT("YES!", Test2);
    ELSE
        PRINT("NO!");
    ENDIF;
    FOR X = 100 + 2 DOWNTO 100+2-33 + TEST2 STEP 1 DO
        PRINT(X, "Hallo!", 2);
        IF X MOD 2 = 0 THEN
            PRINT("EVEN!");
        ENDIF;
        // Test1
    ENDFOR;
    WHILE X > 1 DO
        X = X - 1;
    ENDWHILE;
ENDPROC

FUNC FAK(N:N)
    IF 3 > 2 THEN
        PRINT("WOW!");
    ENDIF;
    RETURN N * FAK(N);
ENDFUNC


So, no GOTO but structured programming. But no stack frames or local variables due to the small RAM...

I attached the instructions I want to implement in the VM to do calculations and communicate with the game itself. It's a ODS (for Libre-/OpenOffice) and an XLS (for Excel) file in a zip as "ods" and "xls" cannot be uploaded directly.

[rchpweblo]

So I watched your early game video and I'd like to leave suggestion.

I noticed that when you fired arows while running you were able to keep up with them.
I think that it would be more realistic if the characters current velocity is added to the arrows velocity every time they're fired.

Using that principle you could (if you wanted to) make it so a running shot does more damage then a standing shot.

So what do you think?

~Thanks, Rchpweblo~

[DelphiMarkus]

Hi Rchpweblo,

I totally missed your post, so sorry for late reply.
You are right, it would be more realistic if I add the velocity of the player and a bullet shot while standing. However, I decided to change the game mechanics (the little there was so far) rather drastically.

I'm currently moving the game towards something like (at least) Ultima III, IV and V in terms of controlling the player and how combats work. The game is becoming a turn based game where you can do an action every turn, then the enemies are allowed do do one. All combats take place on the map, not on a seperate map with several more enemies like in Ultima. Therefore bullets are not that important any more and there will only one bullet at a time due to the turn based nature.
I don't want to implement a party / followers like in Ultima as it would probably take a bit too much RAM I'm trying to save for other things (ai?, trading?, ...) I opened a new branch on Bitbucket and there is a HEX file to try the current state. I will definedly release a new preview video when combat is implemented.

I also removed the capability to read maps from EEPROM completely, there is only a sd card based version.

I hope I can make some progress in the current holidays, otherwise it will take untill February untill I have more time to work on this game. It's not that I gave up but I had almost no free time to work on this project the last (almost 3) months; studying Physics isn't that easy all the time.
So, that were just some updates on the current state.

[rchpweblo]

Hey DelphiMarkus!

I know this is an extremely, extremely late reply, but hey, I got caught up in life

So have you made any progress on the game? I'd like to think yes, and that you will actually reply, but who knows? Sometimes things fall under the cracks.

Now I don't know if you got the email or not, but Rodot sent out a announcement that he has finished getting some degrees and is moving into a dedicated office for work on the Gamebuino, and he also included a poll for things we'd like to see improved on the Gamebuino. To me it sounds like he has plans to make a 2nd gen Gamebuino with features that were highly requested by the community. If this does happen perhaps we will get a more powerful processor and some more RAM! That would allow for much more complicated games and would be very beneficial for your game especially!

So hopefully you'll reply and give me a progress report

And be sure to check out Rodot's poll to give some feedback!