[HN Gopher] I learned to love testing game code
___________________________________________________________________
I learned to love testing game code
Author : ChadNauseam
Score : 36 points
Date : 2022-09-11 19:15 UTC (3 hours ago)
(HTM) web link (chadnauseam.com)
(TXT) w3m dump (chadnauseam.com)
| charcircuit wrote:
| >the benefit of automated testing is that it scales in O(1) with
| respect to number of code changes, while playtesting is O(n)
|
| This isn't true. Running more tests takes more time even with
| automated tests.
| stuckinhell wrote:
| I've been looking into Unity and game development in my spare
| time. It seems writing tests for game code is incredibly
| dependent on the style used to develop the game.
|
| If you are doing everything by hand in C#, its super easy. The
| moment you introduce editor workflows or third party libraries, I
| have no idea how anybody can write sensible tests.
|
| Using Unity is like a weird mix of no code tools and code.
| guzik wrote:
| > Using Unity is like a weird mix of no code tools and code.
|
| Haha, great summary of my 5 years experience in Unity. Whenever
| I am too lazy I am switching to ECS/MonoBehaviour, then I
| regret of not having properly testable architecture.
| Jaxkr wrote:
| ECS is a competing system to supersede MonoBehavior
| andrewallbright wrote:
| Writing automated tests for video games is some of the most fun
| programming I do.
| Goz3rr wrote:
| The author mentions Sea of Thieves and Mindustry, but I think
| Factorio is worth a mention too (seemingly as usual when
| something game related comes up on HN). They do TDD and talk
| about their automatic tests in several blogs:
|
| https://factorio.com/blog/post/fff-366
| https://factorio.com/blog/post/fff-288
| https://factorio.com/blog/post/fff-186
| https://factorio.com/blog/post/fff-62
| Jasper_ wrote:
| Riot Games also has an automated testing framework:
| https://technology.riotgames.com/news/automated-testing-leag...
|
| I still think the best combo is a mix of automated and QA.
| Software in general went through a large decline in quality
| after QA was laid off across the industry, and in my
| experience, automated testing just tends to find different
| kinds of issues. Also, playtesting is also not the same thing
| as QA, but I digress :)
| 0xCMP wrote:
| This kind of reminds me of making UIs in SwiftUI which requires a
| way to render in the editor so you need to provide test data and
| I thought it was neat because it sort of acts like a test.
| jasonjmcghee wrote:
| Really enjoyable read!
|
| A small note, the code samples are a rather large font size on
| mobile. Setting the size to 0.9em for mobile widths works well
| for me!
| Jensson wrote:
| > Bevy uses the ECS pattern to organize game code, and it
| occurred to me that ECS substantially alleviates the spaghetti-
| code problem that makes testing in Unity and Unreal so terrible.
|
| Both Unreal and Unity uses ECS.
| keyle wrote:
| Thanks, I rolled my eyes and had an issue with the author's
| statement.
|
| My guess is what he meant was that the Bevy approach is cleaner
| to test upon.
| harles wrote:
| Can you point me to what part of Unreal uses an ECS approach?
| I've never seen this. I know Unity DOTS added ECS features,
| but that still lives in a hybrid world.
| lfowles wrote:
| This surely isn't what was meant in previous conversation,
| but Unreal Engine 5 added MassEntity which is uh... an
| Entity Fragment Processor approach. (Because Components are
| already an object that exists, it probably would have been
| an extra special kind of confusing if it adopted typical
| ECS naming.)
|
| https://docs.unrealengine.com/5.0/en-US/overview-of-mass-
| ent...
| guzik wrote:
| Seems like the author never truly worked with these engines?
| Also, I never had problem with unit testing on Unity in pure
| C#. Even when it comes to complicated scenario there is always
| a way to separate your GameObjects from game logic.
| harles wrote:
| I think this comment and its parent have misunderstood what
| ECS is.
| tarsiel wrote:
| Unity at least isn't a true ECS architecture, more just Entity-
| Component. You can write game logic in an entity with Unity,
| whereas in ECS that would have to live in a System
| Jasper_ wrote:
| This is where the unfortunately-chosen name "Entity-Component-
| Systems" (ECS) comes back to bite us. Unity's GameObjects are
| Entity-Component (EC): you have an Entity (GameObject), onto
| which you attach Components (MonoBehavior). Unreal is similar:
| you have an Entity (UActor), onto which you attach Components
| (UActorComponent), though you can also have plenty of code
| living outside the UActorComponent system in Unreal. Entities
| are objects, and Components are code/data.
|
| Entity-Compontity-System (ECS) uses these nouns differently; an
| Entity ends up being little more than an identifier for a large
| number of Components, which are data structures, and Systems
| are the code that modify groups of Components. "System" here is
| a noun, not a descriptor of the practice. The usual analogy is
| similar to a relational database (in fact, the point of the
| system is to achieve wide-scale performance like RDSes do):
| Entities are rows, identified by a primary key, Components are
| columns, and Systems are the SELECT/INSERT/UPDATE/DELETE
| queries which acts on the data.
|
| Unity has a new-ish ECS framework under the DOTS initiative;
| Unreal has no parallel. Very few games are using these.
| Jensson wrote:
| In unity the methods "Update", "Start" and so on are the
| system part of ECS. That you write their implementations
| alongside the data doesn't really matter.
| forrestthewoods wrote:
| Sorry, you're wrong on this one.
|
| ECS has come to mean a very particular style of
| architecture. It's not a great name, but it's what the
| industry has converged on. Naming things is hard.
|
| Unity's MonoBehavior framework uses GameObjects and
| Components. You don't have to squint hard to see that it
| contains Entities, Components, and arguably Systems.
| However ECS has come to mean an architecture that is quite
| different from MonoBehavior. So different infact that Unity
| is writing an ECS framework called DOTS!
|
| Both DOTS and MonoBehaviors containing entities,
| components, and functions that operate on them. However the
| two Unity systems are extremely different. MonoBehaviors
| are not an ECS.
| Jensson wrote:
| ECS is fundamentally about having id references and
| components being attached to entities via such references
| instead of pointers or inheritance or other clunkier
| systems. This lets you write systems that can query
| components and entities. Both Unity and Unreal uses this
| architecture for their standard workflows.
|
| Then some people started talking about a single
| implementation style of ECS as if that was all ECS is,
| Unity DOTS is an example of that, but the base Unity is
| still ECS at its core.
| forrestthewoods wrote:
| Strong disagree. I suspect the number of people in the
| world who agree with your definition is vanishingly
| small.
|
| Unreal's framework is a mix of inheritance and
| components. It's clunky AF. AActor I'm looking at you!
|
| Neither Unreal nor Unity provide a mechanism to cleanly
| query such as "give me all gameobjects in the world
| contain this set of components". And they definitely
| don't provide a mechanism to perform that query quickly.
|
| Unity will let you search from components within a
| GameObject, in children, or in scene. These queries are
| also slow as fuck and should generally be avoided.
|
| The type of code you write in Unity and in a Bevy-style
| ECS is quite different. I think ECS is overrated in some
| ways as it's actually pretty difficult and non-obvious
| how to accomplish a lot of tasks.
|
| I don't love the name ECS. It's just not a great name.
| However I've come to terms with it. ECS has colloquially
| come to mean something that is extremely distinct from
| MonoBehaviors. You're welcome to keep fighting the
| community accepted definition if you want. I don't think
| it's useful or helpful to do so.
| Jasper_ wrote:
| What you're describing is an Entity-Component (EC)
| architecture. ECS specifically requires that third noun,
| Systems.
|
| But yes, everyone admits the names are confusing. But at
| no point does Unity or Unreal say their architecture is
| an ECS one.
| LudwigNagasena wrote:
| The major difference between a true ECS paradigm and
| MonoBehaviours (EC minus S) is that Systems aren't local,
| ie you can select and aggregate various entities and change
| their states based on the results of your aggregations.
|
| A proper system, for example, would be able to add a new
| enemy entity every 5 seconds and switch the flag that the
| level is cleared once the total count of present enemies is
| 0. In fact, it would be quite trivial to implement it. But
| in Unity you would need some sort of an architectural
| solution to bypass inherent limitations of EC-S.
| metadat wrote:
| What is ECS? Assuming it's not AWS Elastic Container Service :>
| keyle wrote:
| Around 2007 I believe the game industry came up with a semi
| standard way of building games that somehow alleviated a lot
| of issues in producing complex games... aka spaghetti loops
| of hell.
|
| There are a few ECS approach and to this day it's still vague
| who does it best (depends on your goals).
|
| One I found interesting is the "sparse entity component
| system".
| worble wrote:
| Entity component system
| [deleted]
| harles wrote:
| Based on many of the comments here, it seems like there's a lot
| of misunderstanding of what an ECS is - unfortunately the name
| does this no favors as it should probably be written as
| entity/component/system paradigm or renamed entirely. It's not
| just a system that contains entities and components (that's not
| what "system" refers to in the ECS name).
|
| ECS is a paradigm where entities are the data-free IDs,
| components contain data associated with entities, and the systems
| operate on entities and components in batch, usually with
| database-like queries.
|
| I have yet to find a good ECS reference, but Unity's intro[0]
| gives some decent flavor for it. Note that only the DOTS subset
| of Unity (part of it anyways) uses an ECS. The default
| GameObject/MonoBehavior way of writing code in Unity isn't part
| of an ECS.
|
| [0]: https://learn.unity.com/tutorial/entity-component-system
| Buttons840 wrote:
| So your saying _everything_ is a entity, and that entities have
| components, and the systems operate on entities (possibly based
| on their components). Do I understand that correctly? That
| understanding is definitely worth the time it took to read.
| pmichaud wrote:
| This is essentially correct, yes.
| reidjs wrote:
| That's my understanding too. Think of super Mario.
|
| Entity is Mario, the koopa troopers, the coins, the clouds,
| the floor tiles, the spikes, the mushrooms. All the proper
| nouns.
|
| Component is the XY location in the world, ability to jump,
| sprite image, the height, are they affected by gravity. All
| the adjectives.
|
| System is gravity - all entities with weight drop at the same
| rate until they hit ground. Another system may be the
| collision mechanic - if a mario entity lands on a koopa
| entity, the Koopa dies and some sound effects plays.
| forrestthewoods wrote:
| I would not describe it quite that way.
|
| Functionally, an Entity is an ID. A Component is Data. A
| System is a function that operates on a set of Components.
|
| In a sense "that's it". Having the hard separation between
| data (components) and code (functions) leads to some
| interesting consequences. For example the ability to more
| easily multi-thread System updates because each System
| clearly defines what Component type it needs const or
| mutable access to.
| [deleted]
| Nition wrote:
| It gets particularly confusing because the standard Unity
| paradigm is still one of entities and components, as I believe
| was first promoted by Dungeon Siege at GDC 2002[0]. But it's
| not quite the same as what is called an ECS.
|
| [0] https://www.gamedevs.org/uploads/data-driven-game-object-
| sys...
___________________________________________________________________
(page generated 2022-09-11 23:00 UTC)