> 3D is an illusion in this sense in every game, with the potential exception of space combat simulators.

In almost all general-purpose game engines, most game objects are modeled as 3D polygonal meshes and placed in the world using three coordinates. They can be scaled and rotated freely. The world can be viewed from any position and angle and with any projection (disregarding some of the limitations imposed by rasterization). Object movement and physics are continuous and handled uniformly regardless of direction. Whether or not this is an illusion is a question of philosophy, but I can't think of a way this could reasonably be more "real".

> And they can only make it work by pretending inertia doesn't exist.

This hasn't been true for decades. The Elite series has done this since the 90s, and the latest entry Elite Dangerous implements physics-based space dogfighting with momentum and inertia, though you need to disable Flight Assist to get the full simulation. For a more grounded simulation, Kerbal Space Program implements enough orbital mechanics to support satellites in different orbits, and is realistic enough to enable many real-world spaceflight techniques. And I also have to mention Outer Wilds and its small solar system with simulated spherical explorable planets and moons. All of these games would be fundamentally impossible without 3D.

> You can fly in World of Warcraft, but all of the content is on the ground, and the designers keep griping about how they don't want you to fly because it makes them feel bad when you skip their content.

This is a statement about Blizzard's game design, rather than anything fundamental about 3D. Yes, giving players the ability to fly requires a different approach to world design. That doesn't make WoW any less 3D. You can have a bridge, and one player can walk on it while another is under it. And a third player could be flying over it with a flying mount.

> You can jump in Quake. You can't jump in Doom. This makes no difference. Level layout is the same.

Doom levels are 2D with added height information. Quake levels are actually 3D. This imposes many fundamental limitations on Doom level design. You can't build a multi-floor building in Doom where you can see down to the previous floors. You can't have a pit in the middle of a room and leave the pit via a tunnel, because you can't have two walkable surfaces laid vertically on top of each other. You can't walk on top of a building and then enter it, or have floating platforms, walk under a bridge, have a spiral staircase that overlaps itself, etc.

> Elevation is real in both games; you can always walk up a ramp. There are three dimensions whether you can jump or not.

Doom has heights, but it cannot represent arbitrary 3D geometry, only a very limited subset.

RuneScape is somewhere between Doom and Quake, with its own set of limitations. While the game uses actual 3D models and therefore can display any 3D shape, much like Doom the world consists of top-down 2D levels with per-tile & object height information. The game does enable "rooms over rooms" by having up to four floors / layers per tile, used for things like multi-floor buildings. The player can't walk between floors; they must use an object like a ladder, a portal or agility shortcut to teleport to another floor.

This is also not their first Unreal game, as they just released the 1.0 version of RuneScape Dragonwilds, their survival-crafting multiplayer game that has been both a critical and commercial success. It appears that RS4 is to some extent an expansion of Dragonwilds into a proper MMO.

Besides, if they're going to create a brand new big-budget MMO, what else other than Unreal could they realistically use? Graphics aren't the primary reason to replace the RS engine with Unreal - the reason is gameplay.

Their internal engine that they use for RS3 (and OSRS) is only suitable for games like current RS. Even RS3 is still fundamentally based on a 1 square meter grid, gameplay-wise 3D is an illusion (no jumping, climbing or flying), and most importantly game logic updates only once every 600ms, which is about one tenth of even World of Warcraft. They've made two pretty good games despite those limitations throughout the decades, but it can't scale to anything that feels more "modern".

Comments URL: https://news.ycombinator.com/item?id=49152023

Points: 245

# Comments: 109

Distributing binaries should not matter. If the binary is just compiled from the source code, the binary is just an (non-)infringing as the source code.

> They also allegedly violated a EULA

Meaningless. EULAs are not the law.

Comments URL: https://news.ycombinator.com/item?id=48606640

Points: 6

# Comments: 0

But yes, at launch Cities Skylines 2 was very heavily GPU bound, due to very unoptimized meshes and a poor culling implementation. I haven't profiled it afterwards, but from what I've read they've optimized it enough that on most systems the limiting factor is now the CPU.

I have been working on an incremental decompilation-based reimplementation (basically how OpenRCT2 was done) of Worms Armageddon for the past 2 months with a lot of help from LLM tools; primarily Claude Code and Ghidra MCP. I've worked on it almost every day, reaching Claude Code Max 5x's 5 hour session limit multiple times every day. Suffice to say as a software rendered, sprite-based 90s PC game, Worms Armageddon is several orders of magnitude simpler than MGS2. Despite that, I think it will be 2-3 more months of work before I can compile a fully independent version of the game.

This is despite the game being an almost ideal candidate for automated RE, as it uses deterministic game logic with built-in checksum checks in replays and multiplayer. I've downloaded all the speedruns I could find for the game (as replay files) and I've retrofitted the replay system into a massively parallel test framework, which simulates over 600 games in about 30 seconds. So Claude can port all game logic independently without much need for manual testing; the replay tests can almost guarantee perfect correctness.

MGS2 doesn't have anything like that, so every ported function requires extensive manual testing. Even with LLM tools, an accurate decomp could take years (unless you're willing spend thousands of $currency per month on it).