How can I help?

[liamoc]

I own both Desktop Adventures games, and I have some skill at reverse engineering. Is there any way I can help with this project?

[shinyquagsire23]

Well in terms of reverse engineering there's a good amount of stuff to be done with unknown sections. I have a general idea as to how the puzzles are 'linked' together, and if you look at the PUZ section vs IZAX you can kinda get an idea: PUZ determines the ending goal item you need before the final part of the map, IZAX defines which items can be given on the maps and which ones are needed, so you can kinda create a string of maps.

If you're familiar with Indianna Jones you could probably set up ANAM, PNAM and ZNAM, or just look into different sections which are unimplemented in general. Some sections are easier to reverse just looking at the actual data compared between zones, others like scripts I had to look at IDA. For what it's worth, I'm actually not 100% certain the script and trigger commands are identical between Indy and Yoda Stories, so there's that too I suppose.

Aside from reversing unknown sections there's also the task of moving this from just a map/data viewer to actually being a game. Things like player movement/animation, collision, scripts, map setup, etc.

[liamoc]

Do you have any idea what the IZXn sections are for, if IZAX already defines the items?

[shinyquagsire23]

I'm not 100% sure, not a lot of maps use the sections though so maybe it could be found by comparing maps that have it?

[IceReaper]

Im currently working on an unpacking / packing toolkit. Still WIP, but just follow this to get updates: https://github.com/IceReaper/DesktopAdventuresToolkit Source Code will follow when its done - will not take long. You can use it as reference on how to read the assets or simply work with the unpacked assets if you want to allow mods to extend with more features not possible with the original engine.

[shinyquagsire23]

@IceReaper Just curious, but any progress on that? Even if it were incomplete it would be nice to add more documentation regarding some of the currently-unknown sections in the .dat

[IceReaper]

Okay, ill push it. Currently on hold as i got a new job, will continue on it next month. Need to clarify: i double checked every value myself. Did not simply rely on someone other code. Only used other projects as hint, but verified every single value if they were right.

[shinyquagsire23]

@IceReaper Thanks, looking at https://github.com/IceReaper/DesktopAdventuresToolkit/blob/master/src/net/eiveo/original/Container.java actually already helps explain a lot of things (especially with Indy, I never really played that and don't have a lot to go off of there). I'll probably only be pulling structures you documented, can't really use the actual code in here because it's Java and not C, although I chose C intentionally anyhow because I'm only looking to recreate the engine to make it portable to different platforms.

[shinyquagsire23]

@IceReaper Just a thing I noticed but with Java you probably want to be careful with things like https://github.com/IceReaper/DesktopAdventuresToolkit/blob/master/src/net/eiveo/original/sections/todo/not_converted_yet/ZONE.java#L95, since all of Java's values are signed by default, watch out reading unsigned numbers since trying to read and use them as a short variable (or int for 32 bit values) will show negative values. Really messes with for loops and whatnot, drove me nuts with Java when I tried doing ROM hacking with it. It was either scale up or do weird & 0xFFFFFFFF stuff when accessing values.

[IceReaper]

Yeah, i encountered it multiple times while working on my primary project kknd-game.com. Regarding the desktop adventures source i made sure it can read and write the original format first. Archives can load up ingame. Was helpful as i had modified values to determine them. Then i started with exporting to readable and moddable formats plus the repacking. Will finish it by time as it might be useful for people to create custom desktop adventures

[IceReaper]

As this project seems on hold...? Any help required to continue?

[shinyquagsire23]

@IceReaper I actually had some changes stashed away which I just pushed, but basically the situation at the moment is this:

IACT is basically done for the most part, most scripts are in fact working. What is needed now though is world generation, which is where things get pretty tricky. I did start a basic idea on how I kinda want to structure that in with loading, but for the most part I'm not sure how to tackle it. Research would be handy for the most part.

I found an interesting dialog box in the released version of Yoda Stories which could help examine generated worlds a bit better. Ctrl+Shift+F8 can show a box with the current zone number, X, Y and an E value (no idea on that). So perhaps the best way to go about starting to implement world generation may be documenting the item chain required from start -> finish, with zone numbers? Could also look at the generated save files, might have some useful info there.

Aside from world generation I think weapon damage and entity AI is still a thing which needs to be done, probably easier to tackle tbh.

[cyco]

Hey guys,

i'm really excited to have stumbled up on this project. I've been working on this as well for quite some time now, not sure how we've missed eachothers projects.

I started off with a reverse engeneering environment in c++ and then moved to a reimplementation using web based stuff. My current status is this; asset parsing is practically done, i don't think there are many unknown (non-garbage) values left in the data file (yoda & indy). Save game parsing also works for both games. For Yoda Stories, my script execution works but has some issues. Movement, object dragging & pickup is implemented. World generation works and was validated against samples dumped from the original. I've also implemented a visual editor for zones, actions, characters, etc that can dump new game files. Currently, I'm looking at npc movement patterns and plan on reimplementing those next.

Is the readme up to date? I can provide additional information on the categories marked as needing research.

JS reimplementation: https://github.com/cyco/WebFun C++ reversing environment: https://github.com/cyco/DeskFun Rust-based save game preview generator: https://github.com/cyco/deskfun-preview

Also, someone started a reimplementation for use in ScummVM https://github.com/digitall/scummvm-deskadv

[shinyquagsire23]

@cyco Ooh! OK so most of what isn't "fully understood" on my end is largely a side-effect of not having mapgen working, which I was slowly whittling away in IDA but it was... Pretty slow to be honest. I have like 90% of IACT I think but some commands relied on behavior between maps I think.

I saw digitall's stuff and used a few bits from there as far as script research went, but I never saw yours. Might continue on this just for the sake of me being more comfortable with my own code but I'd love to exchange research bits (though I'm really starting to consider using C++ now that I'm more comfortable with it... But C has its upsides I guess)

[cyco]

Yeah, it took me ages to get world generation right. Working with a golden master log, diffing against my own log and figuring out that it generates an abstract map first helped a lot. I'm not sure how portable these are, but if you're interested you can take a look at my IDC script to dump world samples and add logging for the golden master here https://github.com/cyco/WebFun/blob/master/docs/dump.idc

You probably figured this out as well, each zone has two arrays for items it requires for solving, an array for items it can provide to the player and one for npcs that can optionally be placed to trade these items (stored in IZAX-IZX4). The second array of required items is only used for goal zones. World generation first generates an abstract map that shows where islands, blockades and puzzles, etc will be. Then it fills them with concrete zones for the specific planet type. For each zone one of the valid items is picked and placed in hotspot arguments (types 6,7,8). This also enables the hotspots.

I have not seen any scripts that access zones other the the one currently shown, but as you said, some scripts use the results from world generation. For example, i think the instruction with opcode 0x1e checks if the hero has one of the items required to solve the zone in his inventory. Conditions 0x16 and 0x0e check required / provided items for the current zone and if arg0 is -1 condition 0x0d it checks if the item provided by the zone is in the inventory. If you want to skip world generation for now and get on with the reimplementation i'd suggest you take a look at save games. The format is pretty simple and they contain a raw dump of the map generation result. If your're comfortable with TypeScript this is my entry to save game parsing https://github.com/cyco/WebFun/blob/master/src/engine/save-game/yoda-reader.ts#L25 (after reading 9 bytes file magic). Some of the common functions for reading yoda and indy save games are in this file https://github.com/cyco/WebFun/blob/master/src/engine/save-game/reader.ts#L38 where readInt is 16 bits for Indiana Jones and his Desktop Adventure an 32 for Yoda Stories. This is what world generation produces https://github.com/cyco/WebFun/blob/master/src/engine/save-game/yoda-reader.ts#L103 (10x10 for main world, and 4x4 for dagobah).