Comment by mrkeen
9 months ago
> My priorities are reasonable performances and the fastest iteration time possible.
I bought Mount & Blade II Bannerlord in 2020-03-30. I love it to death, but come on...
// 2024-02-01
$ curl https://www.taleworlds.com/en/News/552 | grep "Fixed a crash that" | wc -l
29
// 2023-12-21
$ curl https://www.taleworlds.com/en/News/549 | grep "Fixed a crash that" | wc -l
6
// 2023-12-14
$ curl https://www.taleworlds.com/en/News/547 | grep "Fixed a crash that" | wc -l
101
Maybe feeling like you're iterating fast isn't the same as getting to the destination faster.
Edit: Lol guys calm down with the down-vote party. I was counting crashes, not bugs:
$ curl https://www.taleworlds.com/en/News/547 | grep "Fixed a bug that" | wc -l
308
Does your C++ not crash, just theirs?
That game (currently) has 88% positive reviews on steam and a 77 metacritic score with over 15.5k people playing the game right now (according to steamcharts.com)
Thats a lot of happy customers.
I can't really comment on the quality of the game or experience or how buggy it feels because I've never played it, but I will say that counting fixed crash situations is a somewhat arbitrary and useless metric. If each of those crashes affected and was reported by a single person or even nobody because no regular person could really encounter it is a vastly different situation than if each of those crashes was experienced by even 1% of the users.
The criteria by which something is decided to mention in the patch notes is not always purely because the users care. Sometimes it's because the developers want to signal effort to user and/or upper management.
Maybe Mount and Blade was super boggy in the past and is still super buggy now so all the crashes fixed are just an indicator of how large the problem is for them and how bad the code still is. I dunno, you didn't really give any information to help on that front.
Mount & Blade 2 was released very early and despite constant improvement (they keep patching it at a strong pace), it's only slowly evolving.
It was even downright unfinished on release, with many game systems claiming to be doing something actually being simply unimplemented.
But despite all that it was and is still fairly playable and enjoyable, even at release. A game only needs a great core gameplay loop to succeed, even if large parts of it are completely broken.
Interestingly, Taleworlds make their own engine with fairly unique capabilities. 200 players can fight in fast paced, precise melee combat on a single server. Even more than in fast-paced shooters, it can be extremely frustrating for players when the game doesn't behave in exactly the way that you would expect (for example, standing undefended just a few centimeters away from the reach of an opponent's swing, or relying on interrupting their attack with your own landing 100 milliseconds before). They've made their own scripting language for everything related to policy. So this scripting language is what modders interact with. And it is absolutely atrocious as a language, but it serves the purpose well enough.
> If each of those crashes affected and was reported by a single person or even nobody
Then do you really think they'd be spending time fixing it?
(Actually, you know what, they probably would.)
That's why I had a paragraph mentioning different reasons things might be mentioned. I don't think it's uncommon to find a bug that could cause a crash while working something else, confirm it does crash, and then fix it. If the culture is to mention those things in patch notes even if you're not sure it actually ever caused a user problem, then it will be listed.
That doesn't mean all, or even any, of the listed crashes were like that, but it does illustrate that it's hard to know what they actually mean without additional info.
(for what it's worth, I'm a long time Tarkov player, so I'm definitely familiar wroth buggy games and apparent development problems with rushing, so this is more a devils advocate position on my part)
With Rust and the exact time iteration times, management and deadlines, you end up with the same amount, just theyre panic!() instead. Thats an improvement, sure, but its fighting a symptom.
There are a bunch of useful clippy lints to completely disable most forms of panicking in CI. We use this at my work since a single panic could cost millions of $ in our case.
With modern languages that take safety more seriously, it's a lot easier to spot places where the code 'goes wrong'.
In an older language, you have nothing to tell you whether you're about to dereference null:
Even if you've coded it 100% correctly, that line of code still looks the same as code which will segfault. You need to look elsewhere in codebase to make sure the right instructions populated those fields at the right time. If I'm scrolling past, I'll slow down everytime to think "Hey, will that crash?"
Compare that with more safety focused languages where you can see the null-dereferences on the page. Unwrap() or whatever it is in Rust. Since they're visually present, you can code fast by using the unsafe variants, come back later, and know that they won't be missed in a code review. You can literally grep for unsafe code to refactor.
I love Rust, but a crashing released game is better than a half-finished "perfect" game, or a game where you couldn't iterate quickly, and ended up with a perfectly tuned, unfun game.
> a crashing released game is better than a half-finished "perfect" game
For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.
> For who? I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long.
Evidence suggests otherwise. Of all demographics, gamers appear to be the most tolerant of buggy software.
I'm playing a 2020 game right now that has (in about 30 hours of gameplay):
1. Crashed twice 2. Froze once 3. Has at least ONE reproducible bug that a player would run into at least once every mission (including the first one).
Since this game is now so old it's not getting any more patches, these bugs are there for all eternity, because they just do not move the needle on enjoyment by the gamer.
Searching forums for Far Cry 5 Bugs gives results like this: https://www.reddit.com/r/farcry/comments/1ai4jzx/has_far_cry...
Gamers just don't care about bugs unless it stops them playing the game at all!
In order for bugs to have an effect on gamer enjoyment, it literally needs to make the game unplayable, and not just make the player reload from the last savepoint.
2 replies →
The problem is we would have a lot less games and the games we would get would not be as fun. Rust appears to have the following problems:
1) As the article pointed out, game developers are less productive in Rust. This is a huge problem.
2) Game budgets are not going to get bigger. This means that if Rust reduces productivity, games are going to be less polished, less fun, etc. if they are written in Rust.
3) Game quality is already fine. 99% of the games I play have very few noticeable bugs (I play on an Xbox Series X). Even the games with bugs are still fun.
Basically, gamers are looking for fun games which work well. They are not looking for perfect software which has no bugs.
9 replies →
Hell no. Lots of these games take 5-7 years to make. You want to turn that into 10-14? I can live with the rare crash bugs.
2 replies →
No, the game doesn’t take twice as long. It just gets abandoned half-finished.
The world is full of half-finished games, it takes time and money to push to a finish.
1 reply →
It's a chicken-egg problem. You won't even see 10% of the bugs lurking in your game without releasing it to a wider audience, no matter how long you worked on it or how good your QA process is (that's what Steam's Early Access is for after all). YMMV depending on the complexity of the game of course.
But even if your game code is perfect and completely bug free, there are so many weird PC configs and buggy drivers in the wild that your game will crash for some users. And for the affected users it doesn't matter whether that crash is caused by crappy game code, or some crappy 3rd party software interfering with your game. For the user it's always the game's fault ;)
1 reply →
perfect is the enemy of good. You never release anything thats perfect.
Perfect is impossible.
1 reply →
> I, and I'm pretty sure most other gamers, would rather a fully-finished "perfect" game that took twice as long
I have recently completed Cyberpunk Phantom Liberty. The game crashed 4-5 times during 100-150 hours of gameplay. The crashes were pretty much painless because I quick save often.
The game was amazing.
The development of the game started in 2012, 12 years ago. I’m not sure you or most gamers would rather want a fully-finished "perfect" Cyberpunk 2077 game released in 2036.
1 reply →
Photoshop does crash. Trust me if you do enough image editing you'll know it's not even a super rare event. They're generally doing a poor job handling the situations where you have no enough storage or RAM.
It didn't stop Adobe from being worth 200B.
Hard to know what TaleWorlds are actually optimising for because half the features of Bannerlord feel like they’ve never been played by a dev let alone iterated on.
How many of those crashes were caused by memory safety issues though?
A lot of those crashes might simply be called a "panic" in Rust.
And yet the fact that Bannerlord game logic is entirely in C# makes this possible:
https://github.com/int19h/Bannerlord.CSharp.Scripting
which in turn makes it a lot easier and more convenient to mod. Try that with Rust...
Yeah this is a common problem in the industry, we rarely have enough time to refactor what should be considered prototype-level code into robust code.
The game dev industry could form a consortium to launch its own dedicated general purpose language built from scratch to compile very fast like V or Go, run predictability, be much safer, be more reusable, and be extremely productive with the lessons learned from C, C++, C#, and more.
Also, I think LLMs will be able to run against code bases to suggest mass codemods to clean things up rather than having humans make a zillion changes or refactoring fragile areas of tech debt. LLMs are already being applied to generate test cases.
Jonathan Blow’s Jai is an attempt at something like this. It’s looking promising so far!
2 replies →
C# is that language (see Godot, Stride, FNA, Monogame).
3 replies →
I believe that better tooling can help, yes. With refactoring, debugging, creating performance and style reports, updating documentation and a ton of other stuff.
This comment is nonsense
My impression is that this is due to their non-robust programming style. They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.
> My impression is that this is due to their non-robust programming style.
It's been 50+ years. I don't think that it's worthwhile just telling the programmer to do a better job.
> They do not add fallback behavior when e.g. receiving a null object. It would still be a bug, but could be a log entry instead of crash.
This is a pretty big feedback loop:
If you don't do the first step, you don't get stuck doing the others either.
50+ years and people still fail to grasp this.
You have to put something (an optional, or a default constructed object in a useless state) and all you did was to skip the null check. In case of optional, you introduced a stack rewind or a panic. Everything else stayed the same. Maybe that default even deleted the hard drive instead of crashing.
Coding is hard. "just don't code" is not the answer. You can avoid something, that doesn't mean it won't show up in some other fashion.
2 replies →
Arbitrary recovery to null pointers isn't a good way to do robust programming. I recommend doing the exact opposite actually.
https://en.wikipedia.org/wiki/Crash-only_software
https://medium.com/@vamsimokari/erlang-let-it-crash-philosop...
A crash of an actor in BEAM is incomparable to a crash of a video game.
3 replies →
I dare you to board a plane whose software was written that way.