Timeline for Do retail games use "inversion of control" and "dependency injection"?
Current License: CC BY-SA 2.5
28 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 8, 2021 at 3:45 | comment | added | Ash | The huge benefit of IOC for larger games is being able to run specific parts of your game quickly and easily by mocking out the rest of the game. When you run these "tests" you're almost never looking for "correctness" (you rarely even need Asserts), you most often checking if a some result of this code is "good", (if not, tweak code, run again). Another benefit is performance testing of just that part of the code. | |
| Jan 8, 2021 at 3:45 | comment | added | Ash | A game can't be "correct", it's simply either fun and stable or it isn't. People are confusing QA/play testing with unit testing, using IOC only helps unit testing (and some integration testing) , it has no impact on the need for other testing. | |
| May 30, 2019 at 0:41 | comment | added | Jimmyt1988 | Testing is so important. Saves money, prevents bugs, helps developers test pre QA so doesn't waste time and money. It's an important tool in the developer toolbox. TDD is a great way of coding! Be pragmatic, ofcourse... But be wise of the benefits. Once you start, it's hard to stop. | |
| May 29, 2019 at 22:26 | comment | added | Kylotan | @Jimmyt1988: tell what to Rare? They are known as being a bit of an outlier in the gamedev world for being extremely process-heavy, and the result is quite slow development times. It's 9 years on from when I wrote this original answer and there is still no significant movement towards IoC/DI in game development. | |
| May 23, 2019 at 21:42 | comment | added | Jimmyt1988 | Hm. Well, tell that to Rare, who have implemented extensive use of patterns for testing their game as a service - youtube.com/watch?v=KmaGxprTUfI&t=1s | |
| Feb 21, 2018 at 15:08 | comment | added | Kylotan | Or it makes code much harder to understand because you've added an extra layer of indirection to everything whether you needed it or not. | |
| Feb 15, 2018 at 18:46 | comment | added | Ian Warburton | Regardless of testing and interchangeability, it makes code much more simple because instantiation of dependencies is moved to a single location elsewhere. | |
| Apr 25, 2016 at 14:16 | comment | added | Kylotan | @Sprague: to be fair, the original question was 'do retail games use this' and the answer is 'no, barely at all'. We're going to have to agree to disagree on whether explicit IoC/DI is frivolous over-engineering (I too work on web apps, and would never use an IoC container) while at the other end of the spectrum there's no debate that some degree of modularity is good. Regarding your specific question, the fact there's a game loop and periodic updates has no relation to how objects get constructed or services get located so there isn't much game-specific to talk about here. | |
| Apr 24, 2016 at 11:27 | comment | added | Sprague | I'm surprised to see this answer rated so highly. I've used DI in web-based business applications and the is certainly NOT just frivolous over-engineering in that context. I was hoping to read about pros and cons from a game engine perspective (where the architecture is based upon a loop updating state and drawing a screen), as opposed to a blanket criticism if the pattern. | |
| Sep 2, 2011 at 9:17 | comment | added | Engineer | +3 for very clear-headed answer... if only. | |
| Sep 1, 2011 at 13:46 | comment | added | Andy | I personally enjoyed this thorough answer. Just wanted to say that. I think that Kylotan makes an excellent point, and often IoC does overly complicate things. There are cases where it makes a lot of sense (when a lot of DI makes sense), but wrapping everything in a proxy just for the sake of doing so should be considered bad practice. | |
| Jul 27, 2011 at 22:44 | comment | added | BlueRaja - Danny Pflughoeft | XNA has an IoC container built-in. | |
| Sep 20, 2010 at 9:08 | vote | accept | Iain | ||
| Aug 27, 2010 at 16:17 | comment | added | Kylotan | @Alex Schearer: I'm afraid I can't ever accept that needing to use a formalised IoC container system and typically creating additional constructor arguments or factory classes to facilitate testing is, in any way, making the code better factored, and certainly not making it looser coupled. In fact it pretty much tramples on encapsulation, a key aspect of OOP. Instead of relying on TDD to drive their design and hope that a good result emerges, people could just follow SOLID principles in the first place. | |
| Aug 27, 2010 at 16:11 | comment | added | Kylotan | @Mike: we're going round in circles here. If you can meaningfully test an object without changing the interface, great. That's a case where the testing costs you little and buys you a lot. But we were talking specifically about changing interfaces to permit dependency injection purely for testing purposes. Obviously if your language supports swapping components out without imposing any restriction on how you make the aggregate object (eg. Python does), that's a different matter, and doesn't require explicit IoC containers or any of that fluff. | |
| Aug 27, 2010 at 16:08 | comment | added | Alex Schearer | It sounds like people don't understand the goal of unit testing. Testing a unit of behavior will never prove the entire system correct, it says nothing about how different pieces of the system will interact, and it's too low level for scenario testing. If you want QA write scenario or integration tests. The reason why people advocate TDD and unit testing is because by following the process you end up with code which is better factored, more loosely coupled, and closer to single responsibility. The act of placing a piece of code under test forces the author to make better design decisions. | |
| Aug 27, 2010 at 15:34 | comment | added | Mike Strobel | A component's code needn't be made more complicated to facilitate testing. And the point isn't necessarily to prove correctness, but to help identify regressions or subtle, unintended changes in behavior. | |
| Aug 27, 2010 at 10:31 | comment | added | Kylotan | I know it doesn't try to prove anything. But software can be proven correct, and the simpler it is, the more practical that is. Testing, although valuable in itself, should not require the code to be made more complicated to facilitate it. | |
| Aug 26, 2010 at 18:32 | comment | added | dash-tom-bang | @Kylotan the concept of a test never tries to prove anything. It tries to demonstrate that the behavior with given inputs is as expected. The more behavior is shown to be correct, the greater your belief that overall function is correct but it's never 100%. The statement that a minimal interface proves anything is ludicrous. | |
| Aug 26, 2010 at 10:19 | history | edited | Kylotan | CC BY-SA 2.5 | grammar... |
| Aug 26, 2010 at 10:17 | comment | added | Kylotan | @Mike Stroble: I had hoped I'd covered that with my 2nd paragraph. | |
| Aug 26, 2010 at 10:16 | comment | added | Kylotan | @Thomas Dufour: the concept of a test can never prove anything. It's just a data point. You can have a test pass 100000 times without proving that it will pass on run 100001. Proof comes from logical analysis of the subject matter. I would argue that these IoC containers and the like make testing easier at the expense of making proving correctness harder, and I believe that is a bad thing. | |
| Aug 26, 2010 at 7:41 | comment | added | Thomas Dufour | In my experience, if unit tests only prove themselves correct, they are not good unit tests and you should rewrite them. And DI at least (the principle of decoupling "new" calls from client code, not necessarily any framework) goes a long way to making code simpler and good unit ests easier to write. | |
| Aug 25, 2010 at 15:33 | comment | added | drxzcl | Indeed, YAGNI comes to mind. | |
| Aug 25, 2010 at 15:25 | comment | added | Iain | I never called it "diligent software development" - I said the developers were diligent, i.e. the kind of people who care about the quality of their code. Also, I did specifically say software developers not game developers. Personally, I don't see where it would fit into gamedev, but I wanted to know what AAA studios were doing. | |
| Aug 25, 2010 at 14:47 | comment | added | Mike Strobel | The idea isn't necessarily that you'll need to swap out different implementations in production, but that you might want to inject special implementations to facilitate automated testing. In that regard, DI/IoC can certainly be useful in games, but you want to keep it reasonably scoped. You shouldn't need more than a few one-time service resolutions at a high level--you don't want to be resolving services for every little object in the game, and certainly not every frame or anything like that. | |
| Aug 25, 2010 at 14:25 | comment | added | Chris Howe | +1 - I agree that the Java community seems to have vastly over-complicated what seems to be a very simple idea. | |
| Aug 25, 2010 at 14:20 | history | answered | Kylotan | CC BY-SA 2.5 |