Official 2 new e-books to help you write cleaner code are now available

Great resources which I could have used at the start of my Unity journey!
I have used the Singleton pattern a lot, but it has its downsides for testing in particular as you say. But you do not suggest any alternative like dependency injection, is there any more you could add about avoiding Singleton use or what you do internally?

 

It's super useful to see your sample projects.
One pattern that would be useful is to extend your MVC pattern to include the scriptable object architecture from https://unity.com/how-to/architect-game-code-scriptable-objects / Ryan Hipple's 2017 talk as it helps solves the Unity specific MVC scene agnostic architecture, and further extended using ideas from Yousician's UI talk to cut out a lot of spagetti / singleton issues for more scalable UI workflows. I put an example of this sort of reactive menu and prefab workflow on github.

 

This is really great. Good work!

Some minor feedback:

Dependency injection

There's so much to say on this topic, but, broadly speaking I think the best thing to do would be to refer to a more definitive guide (eg. Adaptive Code: Agile coding with design patterns and SOLID principles by Microsoft press) on the topic. I would specifically call out two points: 1) DI is useful for tests, and 2) specifically in unity (and this is unity we're talking about, with property based DI), using interfaces is an antipattern. You should use concrete base classes, because that allows you to specify injected properties in the editor. Using interfaces prevents you from doing this, making it impossible to 'manually wire-up' you DI property chain.

Indeed, the power of DI becomes apparent in unity when combined with prefabs and properties, because assigning a prefab to a slot when that prefab already has its dependencies assigned, allows you do high level 'poor mans DI' by manually wiring up the dependency graph. You've... kind of missed the boat on this one.

The factory pattern

As above; there's an irony in putting this pattern immediately after the section on dependency inversion.

You should note here that obvious problem that a factory is an incompetent solution if it fails to manufacture the dependencies of the object it's creating, which can be over come by using prefabs.

States and state machines

Please refer people to additional work by other people on this topic. It's big. It's hard. "AI for Games" by Ian Millington is an excellent resource on this topic and people who want to know more should read it.

tldr; state machines are an specifically a very trivial and outdated way of handling AI state. Don't do that. It's bad. If you want to write an AI, please use the 'Decision Tree' and 'Blackboard' patterns.

...or at least mention that the world has moved on from using FSM's for AI...

Missing pattern: Actor / Controller

A 'controller' that handles input and controls the 'actor' or 'player' in the game world is a common pattern worth mentioning; the new input system is specifically designed around this and it feels like an oversight to not mention it.

I know there's a limit to the space on what you can put in, but this felt like it was egregiously missing.

More patterns...

Double buffer? Byte code? With a one-liner of some vague hand-wavey stuff about how they might be relevant?

Is it really a programming pattern for a unity developer to write their own scripting language? Hm.

That was a slightly disappointing finish to the book.

...

Still, overall, lots of really valuable stuff in here! Great work!

 

These are great guides, distilling a lot of good information into small packages!

My feedback:

While reading the section about dependency inversion it felt to me like some critical information was missing, with there being no mention about how the actual dependency injection could be handled.

As @xshadowmintx already touched on, in the example script the old implementation made it easy to inject any Door instance by dragging-and-dropping one in using the Inspector. The new implementation felt half-baked in comparison, just having a public ISwitchable field and that's it; it felt like the last paragraph talking about dependency injection was missing.

There was even a section about interfaces versus abstract classes, and I was expecting this to at least briefly mention something about interface field serialization or DI frameworks or something, but it just ignored (what in my mind was) the elephant in the room.

 

I would like to explain the contents of this book in Japanese on YouTube, is that okay?
https://www.youtube.com/channel/UCDunz_CPkqkQT5ljKXcYkhg

 

Is it just me or the link for the ebook does not work ?

 

It doesn't work for me either

 

@doutho It's working now

 

Skip the 2nd book and instead learn the most important topic that is dependency injection with Zenject or https://github.com/hadashiA/VContainer

 

Hi, just noticed p91 of the game programming patterns ebook that there seems to be a typo (maybe due to automatic formatting ?) : I'm guessing the setter of CurrentHealth should read

currentHealth = value;

and not

current-Health = value;

?

 

The PDF crashes my current gen Kindle reader and causes errors on the graphical pages specifically. I opened the PDF for editing and found those blue graphical pages (title and section transitions) have a gazillion objects on them. If at all possible can a version be released with these pages pared down to something that isn't going to explode my e-reader? I don't want to have to edit this thing myself just to read it on a Kindle.

PS. I'm about half way through the book and this is, by far, the best explanation of solid and design patterns I've ever read. I strongly disliked Robert C Martin's books; they're full of overly complex examples and extraneous detail.

 

This is some nonsense right here. If your AI is as trivial too you can use State Machines just fine. Other possibility is to combine FSM with BTs. What do "blackboards" have to do with this is even bigger question since they are just a way to store information and can be used with BTs, FSMs and Utility AIs all the same

Patterns are a tool for the job and to use them or not depends on what kind of job you want to do. Saying that using X is always bad under any circumstances ever is rarely an answer to programming design questions

 

The books seem to aim for code architecture in general, not just in unity, ( @thomas_jacobsen_unity can correct me if I'm wrong.) I think it would be bad to put prefabs in it.
It would make more sense have another book like "Game architecture in Unity" or anything like that.

@xshadowmintx actually I agree about most of your comment, but, it is crucial to a developer to know these patterns.

About interfaces
Interfaces are not an antipattern. Indeed it's uses may be limited on small projects (or by newcomers), but there is a more advanced part of programming that needs interfaces in order to function.

One example is the Ultimate_Unity-AAR_Plugin. It would be impossible to make such connections back and forth between C# and Java without it. The Java (AAR) plugin doesn't know that C# exists, it just knows there is an interface, just like this guy:


About machine states
We might agree that Machine States are out of fashion for AI, but it can solve problems like:

Someone needs to make an App that can read GPS data from the internal hardware or from a Serial connection, or USB. You could just start a state machine and just ask for the data, the current machine will return the right data.

So yeah, you have to know machine states, their main purpose is not for AI, Ai is just an easy way to learn how to use it.

About factory pattern
Most of the time it's not useful, most of the time it will be ugly and people will judge you for using it. But there is an 1% of the cases it might be the best approach.

Knowing the patterns will help a programmer to choose the best one on each step (or which ones to avoid). It will also make you able to do more complex things

I will later devour the books and give a complete feedback.

 

Just wanted to say a big thanks for the book, I enjoyed it a lot. I think most beginners would benefit from starting with design patterns quite early, as they can help to be so much more efficient, even in very small projects. And it's fun

I think you found a good balance between theory and practice and I also enjoyed that the Singleton was included but with enough warnings. I think it's good to stay open minded and not dismiss certain things because of their draw backs.With infinite possible scenarios I like to have a large variety of tools.

 

I've read it. The patterns are explained in a good way, it's easy to follow along, it's very applicable on the Unity scenario.

It's awesome to give the newcomers some knowledge on the most common practices (good or bad). It's very cool that you mentioned things like Singletons, explained how they work and then why you shouldn't use them.

That book is a jewel to self learners, when you study by yourself you can miss a lot of important things.
Good job

 

I didn't like the book. The book's more like reference material, not a textbook. You can't really learn anything from it if the topic is new to you. A good textbook has to be something like the Head First series, they try really hard to explain every detail.

 

If the concepts broached in the book - and coding in general - is new to you, you're better of just focusing on learning coding in general before thinking too hard on overall code architecture and design patterns too much.

It's definitely more oriented towards those who already have solid coding knowledge. It's not the book's place to explain to you what interfaces are and how polymorphism works, but it is in its place to tell you how and in what situations to use them.

Still reading it should plant a lot of 'idea seeds' in your head that should slowly grow along with your general coding knowledge.