Helldivers 2 and Palworld devs wish players understood that 'easy' additions and updates are sometimes really hard: 'That's half a year's work. That takes six months'
-
menu system
I think you are vastly underestimating how complicated menu systems and UI in games are. I have a friend who works as a professional game developer in a small studio and far as I heard, he's spent most of his time just working on their UI/menus.
Changing these things is neither easy nor fast.
wrote last edited by [email protected]The ROR2 new game menu has only a few elements:
- Character select
- loadout select
- difficulty select
- artifact select
- DLC select
That's it.
I know it isn't completely trivial, but as someone with many years of experience making (small) indie games, I know for a fact that a menu like that it should only be changing a few global variables. It's a frontend with very little backend to consider.
Something like that is not a year's work. I could agree with a month, and even at that, most of it will be testing, not design.
And tbh - the main problem with it isn't even its design (the design is fine) just its controls. You inexplicably have to use the D-pad for character select, but the analog stick for everything else, apart from switching to difficulty select with R2. Why not navigate the whole menu with either D-pad or left stick? That should only take a week to fix at the absolute maximum, unless they've managed to tie the code in a spaghettified knot that's unnecessarily coupled with actual game mechanics.
-
I dont think anyone will claim that destructible terrain is an easy addition.
wrote last edited by [email protected]Sure it is, you just implement depth map deformation into the static terrain, totally doable! Then you just tie in a strain system to all the game's models so they fall when they don't have enough support, then add destruction animations for every static model and falling animations for every character. Totally easy, they had that back when the original Red Faction came out for PS2, the devs are just lazy! /s
-
In the real world there is no entirely reasonable code base. There's always going to be some aspects of it that are kind of shit, because you intended to do X but then had to change to doing Y, and you have not had time or sufficient reason to properly rewrite everything to reflect that.
We tend to underestimate how long things will take, precisely because when we imagine someone doing them we think of the ideal case, where everything is reasonable and goes well. Which is pretty much guaranteed to not be the case whenever you do anything complex.
I agree, real code always has tradeoffs. But there's a difference between a conceptually simple change taking 3 weeks longer than planned and 6 months. The reality is game code is almost always junk and devs have no incentive to do better.
Getting a feature functional and out for launch day is the priority because you don't have any cash flow until then. This has been exacerbated with digital distribution encouraging a ship-now-fix-later mentality.
This means game devs don't generally have experience with large scale, living codebases. Code quality and stability doesn't bring in any money, customer retention is irrelevant unless you're making an mmo.
-
I agree, real code always has tradeoffs. But there's a difference between a conceptually simple change taking 3 weeks longer than planned and 6 months. The reality is game code is almost always junk and devs have no incentive to do better.
Getting a feature functional and out for launch day is the priority because you don't have any cash flow until then. This has been exacerbated with digital distribution encouraging a ship-now-fix-later mentality.
This means game devs don't generally have experience with large scale, living codebases. Code quality and stability doesn't bring in any money, customer retention is irrelevant unless you're making an mmo.
And games are usually one and done, so there's even less motivation to write sustainable code.
-
In large scale online games you have issues ranging from obscure things causing memory leaks based on drivers, hardware combinations, etc. and all the way to basic things getting overlooked. One of my favorite examples being GTA5 online.
They forgot to update a function from early testing, and it was in the game for about a decade before someone else debugged the launch process. And then realized that it was going through the entire comparison file for each item it checked on the local list. So "changing a few lines" ended up reducing initial load times by up to 70% depending on the cpu and storage media.
EDIT: I've been drinking and probably misreemebred parts, so here is the post about how he found the issue
That's kind of a funny example because, on a quick skim, nothing he did was exceptionally clever or unusual (other than workarounds for not having source code). R* basically paid him 10k for some basic profiling that they never bothered to do.
-
menu system
I think you are vastly underestimating how complicated menu systems and UI in games are. I have a friend who works as a professional game developer in a small studio and far as I heard, he's spent most of his time just working on their UI/menus.
Changing these things is neither easy nor fast.
If you're spending months on your menu system, you're doing something wrong. Bang it out in a few days and revisit just prior to launch. It's really important because it's the first thing players use, but it can also be overhauled late in development because it doesn't impact much.
I would understand if it was a complex in-game menu system for a grand strategy or 4x game or something, not for a game launch menu. Get your UX team to iterate a bit during development and have devs throw it together once the major features are ready and it's mostly time for bug fixing and polish.
-
6 months doesn't sound unrealistic for re-doing a menu system. Designing, reworking art, re-programming workflows and then testing everything can take several months. Even just the logistics of releasing it after it's done, that alone can take a month.
Yes, it is possible to setup everything in a very generic way that is data-driven, but that also is a lot of work that has to be prioritized with the scope of the project and the team members available.
it is possible to setup everything in a very generic way that is data-driven, but that also is a lot of work
Sure, but it can also be reused in future games. Separate styling from behavior and you can make it look unique for every game with minimal code changes.
-
If you're spending months on your menu system, you're doing something wrong. Bang it out in a few days and revisit just prior to launch. It's really important because it's the first thing players use, but it can also be overhauled late in development because it doesn't impact much.
I would understand if it was a complex in-game menu system for a grand strategy or 4x game or something, not for a game launch menu. Get your UX team to iterate a bit during development and have devs throw it together once the major features are ready and it's mostly time for bug fixing and polish.
revisit just prior to launch
This is simply not feasible - menus include pause menus, talent trees, inventories, all that kind of stuff. All of that is necessary for proper gameplay testing. You can't just "bang that out in a few days".
I'm sorry, but this idea that any of this is easy enough to do in a few days and not crucial enough to iterate on throughout development instead of just doing it at the end, is exactly the kind of naive attitude that the Helldivers and Palworld devs are talking about.
-
Lol hunt takes six months dev time to make the ui twice as worse
UI is incredibly complex under the hood. Cryengine is also difficult to work in. There are tons of reasons games with distinct outstanding features don't switch engines, though, and it's usually due to the specific features said engine provides, no matter how difficult it becomes to work with as a legacy system over the years.
-
When a dev with game dev experience says something should be easy to fix, it's under the assumption of a reasonable code base. Most games are built off of common engines and you can sometimes infer how things are likely organized if you track how bugs are introduced, how objects interact, how things are loaded, etc...
When something is a 1 day bugfix under ideal conditions, saying it will take 6+ months is admitting one of:
- The codebase is fucked
- All resources are going to new features
- Something external is slowing it down (palworld lawsuit, company sale, C-suite politics, etc...)
- Your current dev team is sub par
Not that any of those is completely undefendable or pure malpractice, but saying it "can't" be done or blaming complexity is often a cop out.
I agree with you, but I'd also like to add the caveat that even with commonly-used engines shit can still be incredibly complex.
-
Absolutely, it's impossible to know how much. But it's a lot easier to grasp that it's rarely just "changing a few lines" when it comes to these types of situations.
Specially since many programmers have encountered clients, managers, etc. who think it's that simple as well.
-
Diablo4 has memory leak issues. As a software engineer myself, I just don't see any excuse for a game this long in production to have memory leak problems.
There is no doubt that a lot of games are getting rushed without being properly tested.
-
The ROR2 new game menu has only a few elements:
- Character select
- loadout select
- difficulty select
- artifact select
- DLC select
That's it.
I know it isn't completely trivial, but as someone with many years of experience making (small) indie games, I know for a fact that a menu like that it should only be changing a few global variables. It's a frontend with very little backend to consider.
Something like that is not a year's work. I could agree with a month, and even at that, most of it will be testing, not design.
And tbh - the main problem with it isn't even its design (the design is fine) just its controls. You inexplicably have to use the D-pad for character select, but the analog stick for everything else, apart from switching to difficulty select with R2. Why not navigate the whole menu with either D-pad or left stick? That should only take a week to fix at the absolute maximum, unless they've managed to tie the code in a spaghettified knot that's unnecessarily coupled with actual game mechanics.
wrote last edited by [email protected]AAA gamedev here. I agree in principle with the gamefeel critiques, but I'd like to bring up that scale absolutely matters here. Every degree of complexity your codebase adds can cause cascading issues, which is one of the million reasons indie devs are told by everyone to keep their game scope small. Not saying these kinds of games shouldn't improve, but it's not as trivial as it might appearr.
-
My Helldivers gripe is that the war bonds cost too much for the casual player. 1000 super credits takes a while to gather, and even grind. Paying actual money for them is about $25aud per war bond. I think there's eight war bonds now? That's a full day's income, and you still need to collect medals to unlock the contents of the warbond.
Edit: You all don't need to explain this to me, I'm aware of the options for getting super credits. None of that changes how I feel about the game and that I'm losing interest because of it.
It's 15 AUD, not 25.
As for myself. I play maybe on average 2-3 missions per day.
So 70 ish missions per month. Collect an average of 10sc per mission. That's 700sc + the 300 you get from the previous warbond.
That sounds very reasonable to me for an average playtime of 1h per day.
-
revisit just prior to launch
This is simply not feasible - menus include pause menus, talent trees, inventories, all that kind of stuff. All of that is necessary for proper gameplay testing. You can't just "bang that out in a few days".
I'm sorry, but this idea that any of this is easy enough to do in a few days and not crucial enough to iterate on throughout development instead of just doing it at the end, is exactly the kind of naive attitude that the Helldivers and Palworld devs are talking about.
menus include pause menus, talent trees, inventories, all that kind of stuf
Right, which is why I specifically said there's an exception for menu-heavy games like 4x and grand strategy. If we're mostly talking about launch and pause menus (which was my intent), that's a small scope of work, as in weeks, not months.
You can absolutely build that in a few days, and then redo it later once UX has decided what needs to go there. It's pretty similar game to game, so build it properly once to be data driven, and then tweak the UX and options a bit for each game. Optimization is generally done pretty late in the dev cycle, so those options don't need to exist until later in development anyway, and that's like half the work.
The important thing is to have your UX team iterate on it before your devs get involved, so it's ready. And have them build it out while optimizing things for release. Your menu systems don't need a ton of testing relative to the actual mechanics and gameplay.
-
This post did not contain any content.
I was once building a game where a dinky little neon space fighter zips around the field shooting down enemies that spawn in until the boss. Everything was going great, the engine was handling large number speeds, the parallax background I custom coded with an rng star map worked perfect, right up until I tried to implement enemy tracking of the player: that shit would not work no matter how hard I tried.
I was about to share the old demo for you dudes to try but looks like I've lost the .pck file associated with the Godot executable or the embedded pck is no longer recognized.
-
AAA gamedev here. I agree in principle with the gamefeel critiques, but I'd like to bring up that scale absolutely matters here. Every degree of complexity your codebase adds can cause cascading issues, which is one of the million reasons indie devs are told by everyone to keep their game scope small. Not saying these kinds of games shouldn't improve, but it's not as trivial as it might appearr.
Scale absolutely matters, but the scale of the new game screen is (or should be) very minor compared to the game itself. That one scene should only be setting the variables for new play, not interacting with anything outside of it.
And, to be clear, the main concern is simply the input handling in that scene. The UI itself doesn't really need to be changed, just which buttons change the highlight focus.
I can imagine it was likely thrown together quickly, perhaps with some unnecessary coupling, or maybe reading the inputs using action names that also relate to gameplay, so it becomes awkward changing it out.
I'm not so experienced with Unity, but in UE and Godot, adding and mapping inputs is fairly trivial - select the "up" button and map it to "ui_focus_up", etc. I can't see it being much more complex in Unity.
-
UI is incredibly complex under the hood. Cryengine is also difficult to work in. There are tons of reasons games with distinct outstanding features don't switch engines, though, and it's usually due to the specific features said engine provides, no matter how difficult it becomes to work with as a legacy system over the years.
wrote last edited by [email protected]There is NO reason for hunts UX to as fucking terrible as it is. They literally took it from bad to straight up awful. Believe me, I know how hard to design and implement a good UI can be, I'm a software engineer. I'm not just handwaving "make it better, duh". It's flawed from the user requirements up. It's like they never used their own ui before. It's stunning how thoroughly they don't comprehend how people have a terrible time navigating the game menus.
-
Yeah, you're probably right, the video game you personally made is probably better and we're just lazy. BTW I demand 20 hours of brand-new content to be released next week, and it better be cutting-edge, uniquely interesting and creative, bug-free and $4.99, or else you're a lazy dev, too.
It's genuinely funny watching these people learn absolutely nothing when slapped in the face with hard facts.
Lazy and salty hell of a combo
-
Lazy and salty hell of a combo
wrote last edited by [email protected]Dumb and annoying is worse.
I mean, some of the most experienced and successful devs in the world are telling you (some random guy) these things bluntly in the article, and you are proving their point for them by acting how you're acting.
Congrats on being a sentient stereotype with a keyboard and access to the internet, I guess?
