Liz England is a game designer who writes about game design work, best known for her essay on the many tasks hidden in doors.
HN commenters cite "The Door Problem" as a good example of hidden detail and complexity, in games and in organizations generally.
The Art of Game Design is a very good jumping off point; it's how i got my start, and it gives you a lot of windows to look through.
A few years after getting that book, I started to work professionally with people building games, mostly white-labelled projects or contract work, which was the studio's bread and butter. But actually working with people developed my understanding of a) the relative value that artists, designers, and animators bring to the project, relative to my own set of skills and b) how to solve the sorts of problems that ship games. I am a programmer, and I use my programmer skills to give designers and artists what they ask for.
All of that to say: the best next step is working with folks, ideally some who have had experience. Book learning will only get you so far.
That being said, here are a few more books I have seen recommended in my sphere:
- The Timeless Way of Building by Christopher Alexander (this is not about games, but design generally)
- Finite and Infinite Games by James P. Carse
- Game Engine Architecture by Jason Gregory (this is a technical book about modern game engines)
Finally, Liz England (a designer who lowkey helped me not lose hope when I was breaking into the industry) has/had a blog where she talks about game design books. I cannot personally vouch for the titles, but I trust Liz England [1]
[1] https://lizengland.com/blog/game-design-library/
Some more links of how bureaucracy inevitably creeps in as organizations get larger:
- http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html
- http://www.lizengland.com/blog/2014/04/the-door-problem/
Another famous anecdote was Google CEO Larry Page firing all of his project managers during its early startup days because he felt they just got in the way of his programmers getting things done. But his executive team convinced him to reverse his decision. Think about that, even the powerful owner of Google couldn't get rid of the layers of bureaucracy. He eventually relented.
No non-trivial project has come up with a way to coordinate a large # of programmers where the participants themselves don't complain about the bureaucracy. In other words, learn to love Jira -- because it's inevitable?!?
There is an excellent example of this type of fiddly detail in Liz England's 2014 blog post about the problems of doors in video games [0]. She identifies about 20 questions you can ask about as a door (as a game designer) and then about 30 different roles (from sound designers [1] to monetization director[2]) who might be involved. Her post works really well because the example is so mundane but the questions are very valid.
[0] http://www.lizengland.com/blog/2014/04/the-door-problem/
[1] "I made the sounds the door creates when it opens and closes."
[2] "We could charge the player $.99 to open the door now, or wait 24 hours for it to open automatically"
Another area of hidden complexity is doors in video games. Almost no game has life sized doors because they introduce gameplay issues, almost all doors in video games are at least 30% bigger than in real life and you see an overabundance of sliding doors vs swinging doors because of the complexity swinging doors bring to video game physics.
https://lizengland.com/blog/the-door-problem/
https://www.ign.com/articles/putting-doors-in-video-games-is-a-nightmare-say-developers
It's both sad and funny. Saw similar comments for "fman", a simple file manager. Simple, until you start thinking about the details: https://www.catnapgames.com/2018/11/20/fman/
See also: The Door Problem - https://lizengland.com/blog/2014/04/the-door-problem/
An essay about game development professions that uses doors as the main example: https://lizengland.com/blog/2014/04/the-door-problem/
Edit: mentioned in the end of the video, of course :)