Im not well versed in game programming, however I have some knowledge on how to properly structure your software architecture in other domains.
In regards to third party dependencies I agree with what Uncle Bob says, which is to keep them as far away from your stuff as possible. Only introduce a hard dependency if you have to. In my current project I have been doing that and I enjoy the flexibility that this gives me.
For example I can exchange the DI framework for the whole project in a matter of days if need be.
Which leads me to my question with the Unity debacle.
Is it not possible in game development to also structure your architecture that way ?
Is the extra work not justified if you have deadlines ?
Or is there just a lack of common interfaces that can serve as proper abstraction ?
I am really interested if someone with more insight on game development could shed some light on that.
In regards to third party dependencies I agree with what Uncle Bob says, which is to keep them as far away from your stuff as possible. Only introduce a hard dependency if you have to. In my current project I have been doing that and I enjoy the flexibility that this gives me.
For example I can exchange the DI framework for the whole project in a matter of days if need be.
Which leads me to my question with the Unity debacle.
Is it not possible in game development to also structure your architecture that way ? Is the extra work not justified if you have deadlines ? Or is there just a lack of common interfaces that can serve as proper abstraction ?
I am really interested if someone with more insight on game development could shed some light on that.
Thanks.