Hacker News Reader

Comment by thurn | Hacker News Reader

It can be quite hard to come to game development from a web programming background, because "good architecture" for a React app means a set of best practices (e.g. one way data flow, immutability, discrete mutations and events) which don't always cleanly map over to a realtime environment. It might be good to talk about mapping over concepts you're already familiar with.

View on HN

Especially since the Unity docs encourage bad architecture! Like putting all of your game logic directly in untestable Monobehaviours and writing total spaghetti code. For me, the most useful thing that Unity docs or tutorials never taught me is that your complex logic shouldn’t necessarily be in the Monobehavior itself. If you instead put logic in plain C# classes that implement interfaces it becomes far easier to test and mock game logic. I’ve seen people having to manually test things like running out of ammo by clicking 30 times because they had the logic in the Monobehaviour and they couldn’t unit-test it.

If you use Microsoft’s DI Extension it gets even easier.

The Unity example code is laughably bad.

But don't use dependency injection. Unity's Scene/Prefab load/instantiation is already a form of DI. Using another causes issues with juggling multiple lifecycles.

You also lose the ability for Unity to prefetch assets because Unity can't inspect the dependency graph if it's not done through the asset system. Instead you hit situations where you're loading several objects and running DI code over several frames when unity could have loaded everything at once.

You can use unity-aware dependency injection with extenject: https://github.com/svermeulen/Extenject

Yep, totally agree about the docs and tutorials promoting bad practices, it’s almost impossible to find up to date, modern examples.

I am not a game dev, more app/audio/web, but our app uses Unity for the 3D and interactive video lesson playback parts and recently I’ve been refactoring the video part, which is a perfect candidate for building out with unit and integration tests. It took a lot of digging to work out how to use the Unity unit test stuff effectively as there are really just a few toy examples out there, same with async/await (and the unit test runner still cannot handle async/await in tests!).

I guess maybe it’s a culture thing to some extent, unit testing maybe isn’t as prevalent in games for whatever reason? Once I worked out, as you say, that I could move most of the logic into plain C# classes and test them much the same way I would any old business logic, things became much easier to deal with.

I did think about using DI but in the end found that passing GameObjects in via the IDE and public members as the other comment says sufficed for anything which is a GameObject, and the other (plain class) dependencies I am new’ing up in a top level Manager class and passing down through the constructor, and using NSubstitute to pass in mocks in the unit tests.

I might write up my experience/findings some time when the work is complete.

On the whole, I do think Unity is great, I’ve seen how fast we were able to build out a great looking experience and it’s pretty easy to figure out. C# is a really nice language too. Just a shame that more “modern” dev practices are not actively promoted, and parts like async/await and unit testing seem to be left half-finished.

Oddly enough, I was looking into grabbing a Unity book earlier this week. Any recommendations would be welcome.

One thing I noticed from just skimming the tutorials is there is a lot of Unity editor specific creation of stuff. How much of that is the actual game programming? Maybe web dev is headed in that direction if we ever eventually map Figma to components, where you kind of define it via a GUI. Seeing that felt a little off putting since I’m used to working with a tight scaffold that’s mostly code.

Godot looked less GUI intensive so I was thinking about digging into that instead.

I guess another way to pose this question is, do I need to get over this and accept this is how games are made?

There is a market for purely code-generated games, and especially so with procedurally generated games. But honestly, for most cases, yes I think the 90th percentile answer is to get over this.

I kind of wrote about "keeping it all in code" and why it isn't desirable in the second installment: https://blog.eyas.sh/2020/10/unity-for-engineers-pt2-six-pra...

But once you get the placement / connection / injection right, you'll still be spending the bulk of your non-testing development time in the code editor.

Hah, you literally addressed my concerns in the article. Will sub, thanks for the read.

Totally agree! It's also actually a bit harder, I think, because making games is a bit creative/artistic. You'll often see forum posts/answers on "getting something to work" rather than "good architecture" (there are a few exceptions).

The second installment (already published) talks about some of these best practices, but it doesn't quite dig into architecture just yet.

Good architecture for Unity is one way data flow, immutability, discrete mutations.

Any insights on articles on how to do that in Unity? Your way sounds better than the status-quo, but it's not what's on the documentation, nor what the community recommends.

Reply on news.ycombinator.com