Post-Morterm — Hands-on Game Development with Unity 2019
Overview
When completing a project, sharing your experience in the form of a post-mortem is a valuable contribution for yourself and others. When I was younger, I remember spending hours reading the post-mortem section of the Game Development magazine. I found them fascinating, but I was always impressed by the level of honesty of those involved.
And so, I’m this post with the same intention; I want to share my own experiences while writing my first book named Hands-on Game Development with Unity 2019. It’s a book received by readers with mixed reviews, and it didn’t hit the mark of quality that individual readers were expecting.
Now that I’m writing the 2nd edition based on reader reviews and feedback, I think it’s an excellent time to explore what went well and what went wrong.
Context
Hands-On Game Development Patterns in Unity 2019 was a book commissioned by my publisher based on a conference that I did several years back at the Montreal Unity User Group. The subject matter of the discussion was about design patterns. At that time, I had worked on several Unity projects, and I started to notice that the codebases were often too reliant on Singletons and Manager classes, including my own.
For example, I had codebases that every core game system was globally accessible thru a manager class that acted like a Facade. This approach is valid and functional; I found it lacking sophistication and made it very difficult to implement acceptable practices like unit testing.
And so, I started to research how I could adapt classical software architectural patterns into Unity’s unique coding model, patterns like the Visitor, Command, and State. At that time, the Unity engine was still young and new, developers were still figuring out how to best work with it. So it was a great time to start experimenting with design patterns and develop new best practices adapted to Unity.
And this is the core reason that my publisher commissioned me to write this book.
Intention
The original intention of the project was to write a book that would introduce readers to design patterns and present how to use them in Unity.
Specifications
I’m going to present a list of specifications that will give more context to the production process of the book:
- The book at a minimum length of 250 pages
- The project had a 6-month production timeframe
- I wrote it on a part-time schedule (night and weekends)
- I had the support of a full editorial team, including technical reviewers
- I couldn’t use any copyrighted material, including code that I wrote for other projects
What went well
- We were able to deliver the book to release the book on time. So I was able to maintain a consistent delivery schedule for each chapter.
- Several reviewers indicate the patterns where well explained. So the theory sections seem to have been well presented.
- New developers seem to have appreciated the simplicity of the book.
What went wrong
- The number one recurrent negative feedback is that the code examples were not practical, contextual, or were not adapted correctly to Unity’s coding model.
- Some readers didn’t appreciate the tips and tricks nuggets that I added in every chapter. Some seem to have found the advice given to be idiotic or incompatible with their own experiences.
- Readers pointed out that they felt that the book didn’t give enough examples of how they can use patterns to build game features, mechanics, and features.
Analysis
From all the feedback I gathered, the book’s main issue is that the code presented in the book is over-simplified, not optimized, and not practical. The root cause is that I took a very lean approach to the book’s content because of time constraints. But also because I wanted to keep the content very easy to understand for beginner programmers.
My intention was too present each pattern in it’s simplest form and not confuse them with too much information. I might have overdone it and have taken the time to explain the usefulness of each pattern in the context of developing specific game systems or features.
Another issue in the book is the superfluous content like the general tips and tricks “nuggets” that I included in the book as unnecessary content. Because they were short, I might have been accidentally controversial. For example, the following triggered some negative feedback: “The most important skill that a game programmer should acquire is mathematics. Being knowledgeable about design patterns is necessary to get into the industry, but it’s not as important as a deep understanding of advanced mathematics.”
I was trying to express that from experience; I noticed that the best programmers I have worked with seem to have strong math skills. But merely using the “advanced” I might have given the wrong impression to some readers.
So when writing a technical book about abstract subjects like design patterns, you have to be precise in your explanations and your examples. There’s not a lot of room to leave for interpretation. Programmers are looking for precision and solutions to the problems that they are currently trying to resolve.
Conclusion
For the next edition, I will be changing my approach by doing the following:
- Each example in the book is based on code from an actual game that’s in production.
- The code examples will stay simple, but I will explain when and how to build various systems and features with specific patterns.
- All superfluous information will be removed to maintain focus on core content and avoid misinterpretations.
- Focus on offering solutions to common design problems Unity.
