Comment on 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'

• sugar_in_your_tea@sh.itjust.works ⁨10⁩ ⁨months⁩ ago

  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.

  source

  • SorteKanin@feddit.dk ⁨10⁩ ⁨months⁩ ago

    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.

    source

    • sugar_in_your_tea@sh.itjust.works ⁨10⁩ ⁨months⁩ ago

      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.

      source
• irmoz@lemmy.world ⁨10⁩ ⁨months⁩ ago

  The ROR2 new game menu has only a few elements:

  • Character select
  • loadout select
  • difficult select
  • artifact select
  • DLC select

  That’s it.

  I know it isnt completely trivial, but as someone with many years of experience making (small) indie games, I know for a fact that a menu like that is only 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 analogy stick for everything else, apart from switching to difficult 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.

  source

  • digitalnuisance@infosec.pub ⁨10⁩ ⁨months⁩ ago

    AAA gamedev here. I agree in principle with the gamefeel critiques, but I’d like to bring up that scale absolutely matters here. You should know as a guy who works in the space that every degree of complexity your codebase adds can cause cascading issues, which is one of the million reasons indie devs are told to keep their game scope small.

    source

    • irmoz@lemmy.world ⁨10⁩ ⁨months⁩ ago

      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.

      source
• digitalnuisance@infosec.pub ⁨10⁩ ⁨months⁩ ago

  Correct. Once again, Gamers take developers for granted because something LOOKS like it’s simple, but it rarely ever is. It’s hella frustrating to deal with this every day as a dev, but I guess that’s what you sign up for in this line of work.

  source