Skip to content

Instantly share code, notes, and snippets.

@steviegt6

steviegt6/holocure_yyc.md

Last active November 16, 2024 21:16
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save steviegt6/170423eb92e9e55d3aae771ecac22516 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save steviegt6/170423eb92e9e55d3aae771ecac22516 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
holocure_yyc.md

HoloCure is moving to YYC

Just to be clear: Kay Yu isn't trying to kill modding, this is all just a result of an otherwise beneficial change.

HoloCure, which is made in GameMaker, is moving from targeting the GameMaker virtual machine (VM) to the YoYo Compiler (YYC). This is a big deal.

VM? YYC?

HoloCure currently uses the VM target, which includes compiled bytecode1. In the upcoming 0.6 update, Kay Yu has made the decision to switch to targeting YYC, which compiles GML to machine code (through means not important in this discussion).

Switching means that we'll do longer have the means to easily reverse-engineer and modify the game's code. There are still ways to do it, and it won't be the end of the world, but it will harm the modding scene greatly (as well as impact datamining just as much).

In the following screenshot, you can see the chunks in a copy of Monolith's WAD2 and HoloCure 0.5's WAD. Monolith, a game targeting YYC, is missing three chunks that HoloCure 0.5 (which targets VM) has:

  • Code (CODE),
  • Variables (VARI),
  • Functions (FUNC),
  • and also Code locals, which isn't its own chunk and is stored in FUNC.

Monolith vs. HoloCure chunk comparison

For the unaware: these all have to do with code. The observant reader may notice that "Scripts" (SCPT) is still there, which is because script names are still referenced by things like game objects, which are still included in the WAD. This means some behavior is also still determined by the WAD, and the native executable is still a runner2.

This also means there are still ways to find the now-compiled scripts and hook them, albeit with difficulty (see: YYTK).

This sounds bad! Why would Kay Yu do this?

It's quite simple: because it isn't bad—far from it!. For nearly all intents and purposes, this change is good, maybe even great. Targeting YYC brings with it significant performance benefits (Kay Yu reports a 100+% performance increase), which is incredible. Even Linux users running the game under WINE shouldn't be impacted!

Unfortunately, it really impacts modding and datamining. As a game developer, that isn't too important, but it's something that I feel is very important to acknowledge. Even ignoring modding, datamining is crucial for delivering accurate information on game wikis and other resources.

This change is probably here to stay, and expecting Kay Yu to change his mind on this is a bit silly given how greatly beneficial it is, but we can at least hope (and ask3) for some form of compromise or solution.

What do we do now?

Earlier, I briefly mentioned something called "YYTK". YYToolkit is a neat native application which supports modding GameMaker games at runtime, and is probably out greatest hope going forward, though it currently doesn't support the most modern runtime versions.

I have more to say, especially about what to do moving forward, but that'll come later.

Footnotes

  1. On the VM target, GML gets compiled to an easily-interpretable bytecode, which is a simplified set of instructions for the purpsoses of this document. ↩

  2. The executable (.exe) file you get with GameMaker games is the "runner", which consumes the WAD file (usually data.win on Windows releases) in order to run the game. ↩ ↩2

  3. https://twitter.com/tomatdev/status/1681423091547934721, I will update this gist if I get a response. ↩

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment