i dont even think he did much there. i havent found a single record of him being seen
He's likely setting something up with Khronos, networking and using it as cover during the June patch release.
This was my first feeling on the matter as well. However, couldn't he pick someone else from his endless list of sycophants? Seeing as Khronos is mainly remembered as the person who puffed up Maldavius into his falsely grounded legal frenzy, I don't see him having the community goodwill necessary to act as the parachute stream, so to speak.
It's a codependent situation. If Khronos falls, Jason is left without a second-in-command. If Jason falls, Khronos is unemployed and loses legitimacy/reputation.
I don't either, but what I imagine is that Khronos is one of the people most dependent on Jason's success after quitting his old job to be a better head janny and has expressed concern of either the possibility or even current reality of his janny income dwindling, so Jason is trying to do him a solid with "I'll help you network and signal boost your streaming career so you can make a little extra when I'm not streaming".
My guess is that Khronos streaming is not going to go well; I don't see existing viewers of Jason tuning into a diet Jason who hasn't even worked at Blizzard, much less new viewers. Considering his part in the Pvt. Parts incident, Kronos may even provide some funny spergouts of his own in response to being hassled by the chat.
Like above; but the fact Khronos is preparing to stream will change their partnership in a few ways. Naturally, he'll be competing in the same space. To mitigate this I presume they've organised streaming schedules and content that don't overlap. Jason is trying to build an empire and he's doing it quickly. But he's building it on sand despite the diversity in scope (Ferret Rescue, events, Heartbound, community donations, Twitch, Minecraft MMO, mushroom vlogs...).
What is so dam critical that you need to load everything so dam often that 20% faster is meaningful? Maybe I don't understand GameMaker, and I know you can not do fun memory shenanigans like in C++.
The engine is single-threaded and lacks low-level memory control like C++, which forces developers to be conscious of every bit of processing time, especially if they aim to support low-end hardware. While other engines allow for fine-tuning memory usage and parallel processing, GameMaker's reliance on GML means devs must manually manage logic flow and data access efficiency within a restricted scripting environment. Ironically, despite this constraint, Jason appears to work with an outdated version of the GameMaker IDE, which misses out on newer performance profiling tools and engine-level improvements.
In the case of Heartbound, he uses a global data structure to track all player decisions and dialogue states (it's not like an mutable dynamic list, but more an immutable dictionary matrix... you can probably see the problems for development now). This makes the narrative flexible and persistent but also introduces performance overhead, especially when that data is accessed frequently during gameplay, dialogue rendering, and persisting across scenes. Because that global system is inherently inefficient, Jason is forced to aggressively “optimise” everything else just to keep performance acceptable. This includes micromanaging instance creation (there are many), obsessing over draw call reductions, and pre-parsing data. Not because these are elegant solutions, but because they’re
necessary compensations for the weight of an overburdened global state machine. The "20% performance gain" isn’t a sign of thoughtful engineering: it’s a patchwork fix to a self-imposed problem.
Rather than rethinking the architecture or adopting more modern, maintainable practices, he doubles down on brute-force cleanup, making the system brittle, harder to scale, and increasingly reliant on manual performance babysitting just to function on an already outdated IDE.
GameMaker has built-in support for JSON, which performs the same task as YAML, albeit faster and more challenging to read.
The YAML being referenced was actually his Minecraft MMO mod, but since we're talking about datasets:
Despite GameMaker's native support for efficient JSON handling, Mald's game relies on a bloated, monolithic global array to track player state and dialogue. As we've discussed ad nauseum, this is a deeply inefficient and short-sighted design choice that sacrifices scalability, maintainability, and performance. Instead of using proper data structures (again: GameMaker has
native JSON support) or external configuration files, the game hard-codes logic into a fragile, manually-managed system turning every expansion into a technical liability and forcing needless micro-optimisations elsewhere to keep the game from buckling under its own weight.
He's not using YAML for ShartBound, it's for """his""" Minecraft """""MMO""""" (that can only support like 20 concurrent players or something), and as far as anyone knows most of the useful work is being done by another dude (and the authors of all the plugins they're using), while Mald is is just copy/pasting some item stats or whatever.
Every time I've seen him stream his development for the Minecraft mod (and yes, some dude named "Jake" appears to be pushing a majority of the updates), he's interacting with YAML and configs using Notepad++. In green font. On a black background. No syntax highlighting, linting, even commenting. Just raw tinkering. It's painful to watch. He avoids Java like it's some moon-rune language and prefers to do basic scripting and config statements.
But yes, the whole "20% faster" is completely irrelevant.
Irrelevant because his codebase mitigates whatever performance underhead is carried by the GameMaker engine. He's fighting against the engine.
The question is, why would you need 20% faster for loading of states, how badly has he fucked up the system where 20% would be meaningfully.
From my reading in GameMaker, using JSON as your save system, it should be O(n) to load a state..
The real question isn’t why 20% faster matters. It’s:
"How is the system so inefficient that 20% even makes a difference in the first place?"
In GameMaker, using the built-in JSON system for saving and loading state is typically O(n) in complexity, meaning it should scale linearly and perform fine even with hundreds or thousands of keys. The use of a massive global array for tracking all player flags introduces unnecessary overhead by design while at the same ignoring inbuilt advantages of the engine to
avoid exactly that.
There’s no structured data separation, no schema, no serialisation logic that isolates critical paths; just one sprawling, manually-managed global dictionary. If optimisation load times by 20% is "necessary" here, it suggests the system is already bloated, misarchitectured, or being abused far beyond what GameMaker's internal systems were meant to handle. It's not a triumph of micro-optimisation it's a red flag that the foundational design is broken.
didn't know any other way to handle the need for a data structure that can grow from one end as he needs more flags/values to be stored
It looks like he didn't (or chose not to) implement a scalable, structured data system, so he defaulted to a giant, ever-growing immutable global array/dictionary, effectively treating it like a poor man's dynamic database. This kind of design can work early on, but it turns into technical debt and eventually you're going to have to rebase the entire game using different data systems. Instead of organising flags into nested structures (e.g. "dialogue.chapter1.fucked_ferret = true"), namespacing them, or loading them modularly, he just keeps appending new keys to a flat global scope. He designed a more inefficient, harder to work with system
than the one GameMaker encourages devs to use.
Did the kitboga collab get cancelled?
No it was boring. There was no tech shit going on, and there was a chatter holocaust.
gotta love the dislike ratio
Keep in mind the dislikes are only shown by people using the same dislike extension installed, so it's unreliable. It could be more, could be less.
Working on the battle intro for Pirate Software
Nice.
