Gods reverse engineering
 

Hello all,

I was curious about the engine used by Gods and how they linked the files built by their own editor to the game (you know, the article shown at Guardians of the Past: http://www.guardiansofthepast.co.uk/...?Version_ID=10).

I have still a lot of work to do like finishing decoding the cripal files, but its on his way.

As you may now (by my other works), i don't have the intention to do any remake. I only want to understand the inner work of the games and how they were coded 20 years ago by coding a custom tool.

To pique your curiosity, here's a little teaser showing a flying enemy wave triggered by an event:
Attachment 29349

I will add the possibility to show the event details within the next weeks.

FYI, i use the Atari version of the game because of the powerfull Steem debugger. You may notice some visual differences with the PC or Amiga version. I need to map some hardcoded values to make it compatible.

Cya,
Kroah

Awesome work!

When you get done with Gods, perhaps you can help me find some secrets in K240 :spin

Well done maybe JOTD might be intrested but still good work Dude

Gods is one of the biggest game i have ever decompiled with almost 200kb of asm for the main game loop. K240 must be even bigger :shocked.
I have never played K240, after finishing Utopia on Amiga (and its data disk), i jumped to Fragile Allegiance on PC. Too bad I've never saw a review of K240 in my french magazines, i think i would have loved it too. You understand, digging in the code of a game you have never played is very tedious.

He could use it to fine-tune some of the puzzles or the location of the objects, but like he said in a previous thread, importing and using the data would take a lot of time doing it now, especially since he is busy IRL. But who knows...:)

I am more than interested. As I said the other day there's no trace of the hidden objects, but maybe you can resource enough to make them appear

Kroah I take anything you code! you are really impressive

I'm willing to completely rework my remake if your examination of the data files is worth it. At least the flying monsters trajectories could be imported back in my remake, making them more faithful.

Also we could understand / find the last remaining secrets if there are some.

Can't wait to see an update on this thread.

Hidden objects are triggered by events as you may guess. So it's really easy to get the coordinates when you know the event structure.

Thanks but it's a little too much :). The preliminary works you and Qube have made are useful.
I began to work on the PC version by unpacking the files with your tool (dynamite). Then I have uncompressed the c*.* ST files (packed with a very basic RLE-like encoding).

With the viewer C# source, you will be able to code the wanted output format or see how to read the data.

Data are quite well ordered. The algorithm is rather simple. I was only surprised the path origin depends on the screen position, i.e. the path coordinates are relative to the scroll position. But most (if not all) events (spawning flying waves) are triggered from only 1 way (left, right, ...). So the scroll position is always the same for the event.

Yes, i hope there are still some extra things we haven't noticed or guessed.

Concerning the event system, it's pretty simple.
There are 6 type of events:
- spawn flying wave
- spawn ground wave
- check a puzzle
- spawn intelligent enemy (todo)
- activate a moving block
- spawn a guardian (boss)

A puzzle event is conditioned by up to 3 conditions (as seen in the bitmap brothers editor). If all conditions are met, the effect is triggered.

There are 7 condition types (with their negative counter part):
- the player is (not) carrying a specific object X
- the player has (not) equipped a specific weapon X
- the event X has (not) already been triggered
- the player health is (not) greater than X
- the elapsed time is (not) greater than X
- the switch X is on/off
- the player score is (not) greater than X
- the player remaining lives is (not) greater than X

There are 15 effects:
- the object X is spawned at x/y
- the weapon X is spawned at x/y
- the door X is opened/closed
- the backdoor X is opened with a type "teleport" or "world completed" (as in the end of level 1)
- the event X is triggered
- the object X is destroyed (only for type 4 objects like spikes, serpent vase, beehive...)
- the trapdoor X is opened/closed
- the player loses the weapon X
- the elapsed time is reset
- boss fight start/end (todo)
- no effect (but the event is still flagged as "triggered")

I'm currently working on rendering these information in the viewer.

excellent work as always.

What about the messages that are displayed on the bottom green bar ? It also is an effect, I don't see it in your list.
Also: there are moving blocks that stop once they have reached their destination, and others which move constantly back and forth.

You're right, i forgot to mention it.
When a puzzle is accepted (all 3 conditions true), the effect is executed AND a message displayed (facultative).
If you want a message to appear when you reach a specific location (without picking up a Hint), just use a puzzle event with a message and without condition, nor effect.

I still have to decode the moving block parts. I only have the initial state of the moving blocks right now. I will do this after the rendering part and before the CRIPAL part.

Just for info, the files "alfils.0XY" are in fact a concatenation of several files (found in some demos):
- flying waves (missing name)
- godYX.evt
- ground waves (missing name)
- intel.0YX (the cripal file for intelligent AI)
- switches.0YX
- teleport.0YX
- trapdoor.0YX
- mblocks.0YX

Concerning the SMC (self modified code), it seems it's only used to optimize the main game loop (for example, when the player reaches a guardian, most function calls in the main loop ends up to a RTS : no need to check for moving platforms, most collisions, etc...).
Even if this frees up many cpu cycles to avoid unnecessary checks, i don't understand why conditional JSR/BSR are not used like everyone do. I'm not sure the gain is great (without talking about the problem/incompatibility of cache flushing on higher cpu and disabling the JIT in emulator).
On top of that, the JSR/BSR is still executed, using unneeded cycles with the stack.

Example:
You can see that 4E75 (RTS) is put at the NOP when nbMovingBlocksB=0.
There are around 50 cases like this (more or less equivalent).

Very clever design indeed.

I'm sure of a thing: the "big chest puzzle" at level 3.3 (you have to press 2 or 3 secret buttons, including one button at level 3.2) does not work when JIT is enabled, even with my fixed whdload slave (which fixes a lot of SMC)

About the reason for using SMC, maybe they needed to do it at some point but could not afford to change all the callers, or they wanted to be sure that the call was disabled... yes, not very efficient programming...

I can't wait for a full decode of the game!

Regards

I keep this in mind for checking later, thank you.

- Here's a screenshot of the viewer:
Attachment 29361

- Here's a link to the binary + source of the viewer (7zip - 4.7mb):
http://bringerp.free.fr/Files/Gods/Gods Viewer - 00.7z

This is an early WIP version, don't expect too much :).

You can't change the map right now without recompiling (1 map = 2 worlds, here level 1-1 & 1-2).

I will explain later the meaning of the colors, the acronyms and the white box for the waves... time to sleep :xmas.

Edit: You need .Net Framework 3.5. The project uses Microsoft Visual C# 2008 Express Edition.

Just ... awesome! BTW I don't see the speed bonus (which should be a gold bag in the center of your display)

This is the P6 just on the left of the GW12 ;)
You can only see it with the viewer, it spawns by an event.

Edit: spawned objects & weapons are now semi-transparent

I am forever fascinated and impressed by those possessing programming skills of this level.
I just wanted to say so. :)

works great! I have already learned some stuff I did not know (like timer on help bonuses). Apart from that we had everything figured out already. But the next levels will certainly reveal secrets.

Pretty awesome Kroah - keep it up - You are becoming the master of game reverse engineering :) Working out the inner workings of old games can be fun and rewarding, and expands the mind! ;)

I remember a year or so ago I cooked up some crazy hacked up map viewer app and got it to finally show the maps from First Samurai, it's only basic, I think for that game the data was 2 bytes per tile, again a collision/event map ahead (or after) the tile map, I had to ignore every 2nd byte or something crazy, then the tile map tiles are 32x16 in size, strange one, but I digress.

If you put your mind to work, you can achieve anything! I'm thinking Gods had one of the most elaborate engines of games of that era.

Q :)

P.S. I wonder if Steve Tall ever reads this stuff, or even knows how his gem still gives many hours of enjoyment to people still.. 20 years later..

Yes, this is really fun and entertaining. Reverse enginneering a game is really like making a puzzle: you have some hints about the game, and the more you understand the inner working, the faster it goes and you understand the whole. Sometimes you reverse some isolated code and you hook it up to the main disassembly code like a part of a puzzle.

Interesting, i've never thought to map this game. Do you have any screenshot ?

Gods has a good engine, but imho Cadaver has a better and more versatile one. Gods engine is totally oriented toward an arcade game with some basic adventure elements. Cadaver is the same with a more elaborated script engine and an incredible "3D world simulation" (weight, gravity, collision...) for its time.

Too bad we don't have any news :(. I hope they will be flattered and won't become angry because we disassemble their code.

New WIP version of Gods Viewer. You can grab it here (source included):
http://bringerp.free.fr/RE/Gods/wip.php5

http://bringerp.free.fr/Files/Gods/WIP%2001.png

New features:
- all worlds available (still the Atari version)
- forward & backward recursive links: you can see the links between the game elements (objects, events, doors, ...) recursively. For example, hovering a hidden key will show how it appears and where it's used.
- almost all game elements can be hovered by the mouse
- left clicking & dragging a wave event will show the screen position relative to the event. The outer white rectangle is the screen, the inner gray rectangle is the scroll limit. Because flying wave can be relative to the scroll position, this helps to see the correct ingame flying path.

Tips:
- World A = World 1&2, World B = World 3&4
- when 2 or more objects are stacked, you can left click to swap between them.

Todo:
- Intelligent enemies
- Moving blocks
- Some display options

Have fun!

http://bringerp.free.fr/Files/Gods/WIP%2000.png

Neat work Kroah, will test later on when I get a mo!

Have you thought about supporting the Demo game files at all? I don't know if there is anything to learn from such and it's only a partial first world map. I remember the ST demo had some minor different map tile graphics changes.

I will see if I can sort a screenshot out, it's on my old computer somewhere, time flies so to speak..

Q;

This might be a Very silly question and not suitable for here - But does Gods 8 way/diagonally scroll and if so how well.

for example and I havent tried but might if theres no answear you edited a blank level and and started at the top Jumped down diagonally for quite a high hight what would happen?

Most of the time you just scrolling horizontal or climbing verticaly.

Gods uses a 8 way scrolling. FYI, the scrolling steps are 1 pixel vertically, 4 pixels horizontally (it uses preshifted gfx). This information may be specific to the Atari version where bitplanes are interlaced).

FYI, they use the STe color hardware for the background raster effect (more than twice the number of colors vs ST). I don't see any specific STe blitter scrolling code though. The Amiga uses its copper for the raster effect (= STe) and I think they use the blitter as they did for chaos engine.

I will have more information about this when the Amiga version will be disassembled (i need this to get the hardcoded value of many variables for the viewer).