u/SuperV1234

One aspect that is often overlooked when criticizing Marathon is the technical one. I love the game and enjoy playing it, despite how poorly made it is.

---

First of all, the performance is absolutely abysmal. I have a high-end PC (i9-13900k, RTX 4090, 64GB DDR5 RAM), and I can barely hit stable 120FPS with everything on lowest. Even DLSS doesn't help, and it introduces noticeable latency (unlike in other games).

This is absolutely unacceptable -- I can run games that are more visually impressive than Marathon at 240+ FPS on high settings, and I can play VR titles at 120+ FPS on the same machine.

---

The game also constantly crashes for me -- no other game presents the same issue on this machine. I keep getting "ERROR CODE: broccoli" or "Graphics Runtime Detected a Crash or Loss of Device" random crashes. Neither my CPU nor GPU are overlocked. Drivers have been updated. I tried all the usual fixes such as DDU and so on.

This is the only game that has these issues. I've lost runs and valuable loot because of random crashes. It's even more infuriating because the game already runs like shit, and it also crashes on top of that.

---

From the perspective of a software engineer and hobbyist game developer, the game has some baffling bugs. The most common and most frustrating one is the loadout value calculation bug: basically, switching your shields or equipment in the vault screen causes your loadout value to be miscalculated.

This is especially annoying when trying to join a lobby with a minimum value requirement (e.g. Cryo or Ranked). I am forced to completely empty my backpack, fill it again, and pray that I do not need to switch something. Massive waste of time for me and my crew stuck waiting for me.

This bug is absolutely insane. The simplest way of calculating the loadout value would be something like this, that even someone with zero programming experience would understand:

loadout_value = 0

for item in current_loadout:
    loadout_value = loadout_value + value_of(item)

return loadout_value

This is such a trivial and ridiculously cheap operation that you could do it thousands of times per frame with absolutely no performance loss. Yet the developers decided to use some weird caching system that doesn't work at all. Why? How was this not caught during playtesting, and why isn't an hotfix released yet?

This is absolutely dumbfounding.

---

I've encountered plenty of other issues and bugs, but those are the major ones. This game needed one more year in the oven: playtesting would have not only revealed these issues but also revealed how bad the experience was for new players. I think Marathon is really something special, but it is hard to be sympathetic when it was released in such a terrible state and with clearly no effort put into testing.

I finished writing an article today on how C++20 coroutines are unsuitable for gamedev.

One of the main issues I have with them, apart from the unavoidable heap allocation, is that the state of the coroutine is completely opaque.

If I want to use coroutines to define game logic, I won't be able to serialize/deserialize the state of a coroutine to support quicksave/quickload, network sync, and save states/introspection for debugging and prototyping.

What is the current situation with Rust coroutines? Is there a way to portably serialize their state/progress?

If not, was this issue raised before?