Questions

[tehmichael]

Hiya @reconSuave!

I came across this project looking for the code that Fred might've shared back in the day when he shutdown ffiends.com. Where did you come across these files? Have you been able to run this at all? Thanks!

[reconSuave]

Hiya @reconSuave!

I came across this project looking for the code that Fred might've shared back in the day when he shutdown ffiends.com. Where did you come across these files? Have you been able to run this at all? Thanks!

Hi,

Well, the short answer is all of the files were scraped from archive.org and I have indeed gotten the app to run.

But the longer and more contextual answer sounds a bit less like great news, though not necessarily terrible either.

The wayback machine has a lot of the material from Ffiends.com, but no single snapshot has all of the Dragon Court files - they are spread across all of them. And, unfortunately, I think there are a few (maybe 2 or 3) that just aren't archived.

What I ended up doing is automating the process and basically just downloading every single thing from the ffiends.com domain that was on wayback. That seems like overkill, probably was, but the website technology is ancient and I felt like I needed to get it all laid out in front of me to figure out what was going on, how it worked, etc. I can't honestly say I'm 100% there, but I understand the gist of it.

For this I coded some scraping tools, there are some open-source tools already available (e.g. waybackpack, wayback-downloader), most are pretty good, but the wayback machine is not always so consistent. There are a lot of files, particularly binary files, cgi-bin stuff, miscellaneous scripts, that don't seem to show up on the API. The way to get all of those is from the table on the web interface that lists all files by type (or allows sorting by type), and using something like BeautifulSoup you can pull them by their type-specifier tag.

Then I made copies of all the binary files in the directory tree (I kept the structure intact so I could see how everything fit together), and went about decompiling the Java files. There are a lot of great Java decompilers out there, but DCourt's ancient syntax made it not straightforward to decompile, most decompilers just think it's invalid code and they can't parse it to abstract syntax, so they can't decompile it.

When confronted with this sort of problem, you might decide to use Ghidra to tackle it, but, as the saying goes: "now you have two problems..."

The jetbrains one is the ticket, though. It's a plug-in for their Java IDE.

Now, the million-dollar question: does it run? The answer is Yes! 😃 But, like, no! 🥹 lol. Here's the rub: modern browsers don't have a Java api, and modern Java doesn't have any equivalent to applets.

I have grappled with this question, even produced a mostly working browser extension that essentially adds a Java API back in by creating JavaScript bindings and mocking an api, which was sort of an awful task lol, like installing a screen door on a submarine. Or sewing a foot to a head ... for some reason. But I digress, basically there are better existing options already, CheerPJ is a good one - all of them are proprietary, though, and need to be modified to handle some features specific to DCourt, like interacting with the database. In most cases this runs afoul of the license and it's not advisable to share the work.

So these are the 3 things that I know for sure are required to get DCourt running in a browser:

• a Java api of some sort, or a Java-something, the most reasonable option seems to be a browser extension like CheerPJ.

• a database, SQLite was used in the original DCourt, and for personal use that's probably still the natural choice.

• CGI binaries, or some modern equivalent. Ffiends.com used a custom CGI scheme consisting of windows executables, I'm fairly sure this was pre-ASP, but I should note that the CGI binaries on archive.org are not really CGI binaries at all, they contain either the html output of the CGI binaries themselves, or they are just empty placeholders, so all I can really say about the CGI system is that it existed, and also it did stuff. Basically all of that stuff could probably be done pretty easily in flask now, maybe even with minimal JavaScript, if you dropped the Java and just did a rewrite. The super luxurious (but also super cool) option would be websockets, imagine a smooth and flowing websocket DCourt, ...but websockets are always one of those sounds great in your head things, and then they ...become painful...😒

But this is the honest conclusion I came to, and not because of laziness or lack of desire for a working DCourt, but just because it became obvious to me after wrestling with this project for a while: Dragon Court probably should not be updated to modern Java, it would be like putting a Cadillac engine in a golf cart or something, if DCourt were written today it would probably be written in JS or Python (as a flask web app or even a PyGame app).

I think it really needs a complete re-write in a modern language. I just can't see much value in dragging ancient Java along for the ride, and it would require so much tinkering that even the historical value of the resulting program would be highly questionable, it wouldn't be the same and actually the obsolete technology might detract from the historical aspect, for what it's worth (just my opinion), if the goal is a faithful presentation of the original (and I'm not completely convinced that's the best approach, but it could be), I think the best way is with a modern web-framework, along with an attitude of being a bit more artistic than technical, keeping in mind that it's all really subjective and a faithful representation of the original is probably more about capturing the mood or spirit of the game than anything else.

DCourt was a product of its time and place like everything else, even at the time I remember thinking it was not impressive from a technical perspective, very unpolished. But it was a GREAT game, like 👍👍👍👍👍👍👍👍👍 9 thumbs up, truly epic, maybe even perfect. It had all the things: adventure, uncertainty, a goofy sensibility that was really funny but sometimes lapsed into a darker, stranger, almost menacing energy. I guess what I'm saying is that it was really art, greater than the sum of its parts.

But anyway, long post is long, I'll wrap it up. But thanks for dropping a note, the project admittedly is mostly dead but I've always planned to get back to it, so pull requests, issues, etc are always welcome and forking is strongly encouraged. I'll try to find some miscellaneous tools and other work I've done relative to DCourt, too, i'll post that sort of stuff as I come across it, just so it's here.

Best regards,
ReSu

[jason-allen-oneal]

Ive got a port going for Typescript. Maybe we can collab.