this post was submitted on 22 Jun 2024
31 points (100.0% liked)

Games

16806 readers
1127 users here now

Video game news oriented community. No NanoUFO is not a bot :)

Posts.

  1. News oriented content (general reviews, previews or retrospectives allowed).
  2. Broad discussion posts (preferably not only about a specific game).
  3. No humor/memes etc..
  4. No affiliate links
  5. No advertising.
  6. No clickbait, editorialized, sensational titles. State the game in question in the title. No all caps.
  7. No self promotion.
  8. No duplicate posts, newer post will be deleted unless there is more discussion in one of the posts.
  9. No politics.

Comments.

  1. No personal attacks.
  2. Obey instance rules.
  3. No low effort comments(one or two words, emoji etc..)
  4. Please use spoiler tags for spoilers.

My goal is just to have a community where people can go and see what new game news is out for the day and comment on it.

Other communities:

Beehaw.org gaming

Lemmy.ml gaming

lemmy.ca pcgaming

founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] tal@lemmy.today 5 points 5 months ago* (last edited 5 months ago)

"One of the biggest things with Unity and Unreal is that they're constantly trying to grow. And to grow means they're constantly adding new features because they want to add more user types. That ends in a polluted engine in terms of features. If you go to the bar at the top, you will see a lot of features and they have so many use cases. And now they're also building for industrial digitisation, so they need to support that. So suddenly you have this large code, and maybe somebody is only using just 40% or 30% of it, but you need to make sure it's stable and doesn't crash.

Yes. But on the flip side, you also have a lot more resources to debug that codebase.

I think that there's a fair argument that Unity or Unreal might not be ideal for a given game. But:

  • I am skeptical that game studios are generally better-off writing their own engine, particularly with graphically-spiffier games.

  • I think that the main case where doing one's own engine is useful is when someone wants to do something that a game engine simply cannot do. I don't think that just having one game studio implement 30%-40% of a shared engine from scratch with the goal of having a codebase that's 30%-40% the current size makes a lot of sense in terms of saving development time. And even if new functionality is required, I'd still argue that if that functionality is at all reusable, it'd be a good idea into looking into spreading those costs over a number of games.