Comment by andrewallbright | Hacker News Reader

Comment by andrewallbright | Hacker News Reader

andrewallbright

In this critique of unity they say that the back half of making a game is the half of suffering. In my experience, it highlights something else that is a massive problem in the game dev space. The game dev community is stuck in software practices of 2005, leading to naive implementation patterns.

As a hobbyist game developer of ~1year, one thing that struck me was how I have not found many good sources of teaching that explains how to make a maintainable game. How does one make a code base for a video game that has desirable the non-functional qualities like maintainability? That question doesn't really have an answer...

I think it doesn't have an answer because those teaching game development haven't really asked. I'm sure it's due to many factors.

For anecdotal, I've asked about testing and CI/CD for unity in online spaces. There isn't much content on these critical subjects in the video game education space. I usually get a mix of responses but one that stuck out to me is that video games aren't appropriate for tests and it just slows down game creation.

I think that thought process more than anything is what leads to back half issues. I think that the video game industry has lagged behind the rest of the software industry and there is a huge opportunity for disruption.

In 5-10 years people should think it's absolutely outlandish to start a complex software project such as a video game project without a CI/CD engine running a suite of sensible tests. I think today that is true for most software projects, although as a community were still wrapping our heads around "what is a good test?"

My 2cents

As a game developer, there are two main reasons we don’t write tests: A. because the game design is constantly changing, so any tests would slow down iteration time. B. because the game has so much state it would be very hard to accurately recreate it.

You can do a ton of productive testing just by clearly separating different systems, especially game logic from rendering etc. This is just good code hygiene. Better game-specific tools can also be created, as companies like Larian are doing.

It's not really very different from testing other big complex software. Everybody has evolving requirements. But the general culture of game development is to ignore automated testing entirely, which is awful.

This also runs into an issue of scale. AAA games for live service games certainly do have automated testing for some core features like networking or certain simulations. But that kind of testing for an indie title would be overkill unless you're making a game like Factorio (a near deterministic game heavily relying on simulation). It's really hard to unit test "fun" after all.

There isn't as much benefit for a small platformer to test their jump height or physical interaction with the environment, and then change all tests whenever they decide that they need to adjust that height. On the contrary, some beloved glitches/exploits have come from allowing those weird interactions to exist.

Agreed. I think the only way to have good test automation in games is to quite literally develop an AI that plays your game.

If you haven't seen them yet, Factorio has a few Friday Facts that talk about (and show!) their automated tests. It's quite impressive! One advantage they have in this area is that the game is a fully deterministic simulation, so testing is just a matter of setting up initial state and validating output

I have thought about why it is much harder to follow the general best practice of Unity Tests + Automated Tests we find in web development and I think it is because the amount of "state" a video game has.

In the web we have our cursor and it clicks on an element. In video game design the character can widely vary when it interacts with an element such as a "door".

The classic "why doors are hard" might explain why having a "regression suite for happy paths" might be near-impossible.

Though that the core reason for using the Entity, Component, Systems (ECS) in their coming Data Oriented Technology Stack (DOTS) it does help create far more maintainable code.

https://www.vox.com/videos/22661048/video-game-development-d...

https://unity.com/dots

I feel the same trying do develop an enterprise application with Unity. When I worked for Unity I found it fascinating that game devs (not coming from game development) were “locked into” a particular version. I hope the package system can alleviate some of that but there is a real need for some automation and upgradability.

Game companies don't care about "correctness" (aka bugfree games). Bethesda releases buggy garbage all the time and it didn't stop them from being successful.

Spot on.

All the tutorials, articles, etc just cover small bits and nothing addresses the full software dev lifecycle as it pertains to games.

Managing binary assets across even a small team presents a set of challenges the normal web-devs like myself have been unlikely to encounter, as well.

A fair amount of software is about either filling in forms to populate a database or rendering views of a database. In that context, tests and maintainability matters because you're generally implementing business processes.

Traditional games are more like art, or rather more like novels than textbooks, where you write it once and put it out there.

That's of course changing with live service games so I suspect testing and maintainability will become increasingly written about.

Reply on news.ycombinator.com