I was reading through the two Game Programming Gems books I have, and one of the gems describes a game entity factory. To understand this gem, you have to understand a few design patterns, including flyweight. I never learned exactly what a flyweight was or how I would use it. I still have a slight understanding that you would use a flyweight if you have data that is constant between different entities. Ask me anything else about it, and I’ll struggle. The Gang of Four book isn’t much of a help. It’s a reference book, which means it will be a better tool when I already understand it, but it is almost useless for learning.
I pulled out the Design Patterns Explained book, but it doesn’t have flyweight listed; however, there were a few interesting chapters on design principles. It’s been years since I cracked this book open, and I might have used it for class. I thought it was just a more in-depth version of Design Patterns, so I never found the chapters titled “How Do Experts Design?” and “The Principles and Strategies of Design Patterns”. The book refers to Christopher Alexander, the original author on design patterns. He was writing about physical buildings and architecture. While his approach doesn’t directly map to software design, his principles apply quite well.
One of the things I learned is that trying to put a bunch of pre-made components together to create software is not ideal. You should have a big picture of your project, and then you can decide what smaller components you’ll need. I never thought about the effects of trying to reuse components before thinking of the full scope of the project.
Another thing I learned was the principle of designing from context. I would periodically become stressed when thinking about the best way to design a class or relationship between classes. I don’t have nearly enough experience to be able to make judgement calls about the best way to design a project. I think I have enough of a grasp of programming that I can implement anything once I decide on a good design; I just need more practice with getting to that good design. I learned, however, that you can’t know how a pattern will be implemented until you understand the context in which it exists. For example, if you have a facade pattern, you can’t know how to implement it until you know what interfaces you need to link together. Essentially, you can’t just ask, “What’s the best way to implement XYZ?” You need to ask, “Under what circumstances will implementation A be a better fit than implementation B? How do those circumstances match up with my actual circumstances?”
I still don’t think I quite grasp the flyweight or its place in the game entity factory, but software design became a bit less mysterious. Heck, William Willing’s comments on a Timeless Way of Game Design make more sense to me now!
Also, since I’ve been researching design, especially software design, I found this helpful game engine design link: Object-Oriented Game Design: A Modular and Logical Method of Designing Games
You still haven’t read The Timeless Way Of Building, though, have you?
To be honest, I doubt object-oriented design is the way to go for an indie game developer. For large game projects with multiple programmers working on it, it’s probably a fine choice, but for smaller games with only one or two programmers, a more imperative design is easier and faster.
Note that I’m not saying that you shouldn’t use an object-oriented language or that you should shun objects all together. It’s very convenient to keep data together in a structure and add methods to the structure that act on the data. But that doesn’t mean you need to actually use object-oriented design with stuff like inheritance and patterns and whatnot. It’s another case of ‘keep it simple’, I guess.
Left by William Willing on March 9th, 2006