Game Design Geek / Technical

Design Concepts I Just Learned

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

10 replies on “Design Concepts I Just Learned”

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.

No, I haven’t read it yet. B-(

Still, the idea that better software results from identifying relationships at a high level instead of trying to slap together separate components makes a lot of sense to me. And trying to figure out the “best” way to implement something is silly since it depends on the context. I had been bumping into that problem for a long time.

As for OOD in games, I have generally been hacking at things procedurally since Applesoft BASIC on an Apple ][ c+. Reading about how to do things in different ways has been eye-opening, even if it isn’t ideal. It’s like learning ML. Who uses it in real-life? Nobody, but it opens your eyes to different possibilities when you go back to whatever language you do use.

And if the OOD in Games article is correct, having the system would actually be simpler, especially when it comes to changes and tweaks you might make to the gameplay later in a project.

The principle of designing from context sounds like it has some relation to TDD. The test is the context for how the class you are developing will be used. And you don’t have to design using the facade, flyweight, or other pattern, they fallout as a consequence of refactoring. You may think you’re going to need to use a strategy pattern, but unless you really need it your code will be an over-engineered beast.

Remember my comment a few entries back about “write it once, realize you’re going to write it a second time, refactor immediately”? Yep, it applies here. πŸ™‚

There’s nothing wrong with OOD for games, large or small. OOD makes it easier to program a framework that is used to implement a game rather than just write a game straight through, which is my preferred method of working (not just for games, in fact I don’t write games, but for any programming anything).

What’s that framework? Draw yourself a big picture. Get that working in your mind. Now write the highest level of it. You’ll see where you need to do certain things. Now write one of the next level down pieces with that knowledge, keeping in mind what it will have to do with the next level down. Notice a problem higher up, or a way to make that higher layer more streamlined, efficient, or flexible? Refactor it to do so right now. Lather, rinse, repeat. Your framework will find itself, if you can think abstractly enough.

I need to do more research on freely available and easy to use C++ unit testing frameworks. I should also read more about Test Driven Development. I know it is more than writing tests, but I probably have the same grasp of the concept as I do about A Timeless Way of Building. B-)

This past week I’ve been implementing some of the things I’ve learned into a quick text-based game. Aside from the fact that I don’t yet have a finished game, I’m pleased with the results so far. Things just kind of fell together. When I return to Oracle’s Eye, I’ll do so with an eye towards making it easier to design the game.

When it comes to OOD, I’d like to make a definite distinction between the framework your game is built on and the game itself. Your framework will benefit from OOD, but for your game it’s probably overkill.

One impression I have when reading about how you approach game development, is that you worry about the programming part too much. I guess that’s only natural, since you haven’t done enough game programming yet to feel comfortable with it. I had the same problem a while back. Another part of the problem is that you need to choose a toolset (and learn to use it), but you have too little experience to do so.

I’m quite confident that you could program a game with animated players that kick around a ball in just a single weekend if only 1) you had a toolset that was simple enough to use and 2) you wouldn’t worry about the way your code looked at all. Point 2 is why I’m saying: OOD is overkill for your game. Just about any kind of design is overkill in your case.

A short while back I asked you when you were going to start on the first game you actually intend to sell. You might feel that your not up to that yet, but in my experience, the best way to learn about these things, is to work on a real-life project. You’ll be motivated to learn as much as necessary about the toolset you are using and you’re more likely to focus on the end result instead of the design.

Hopefully, I don’t come over too aggressively. I’m genuinly trying to be helpful. πŸ™‚

ItÒ€ℒs like learning ML. Who uses it in real-life? Nobody, but it opens your eyes to different possibilities when you go back to whatever language you do use.

I couldn’t agree more. At the moment I’m actively developing (different projects) in C++, Lua, C# and Python. When I get around to it, I try to play around with Haskell a bit, too. Knowing (about) so many languages makes it easier to think about a problem in a language-independent way, i.e. on to worry about the programming itself.

William: Actually, my wording was careless. I meant the design of the code for the project, not the game design itself. Compared to this text-based game, the codebase for Oracle’s Eye is restrictive. I can’t easily do some of the things I want to do to make the game. I think changing the code would allow my game design to map to development more easily.

And I don’t take your comments as aggressive or mean. I find you genuinely helpful. B-)

Oracle’s Eye will become my first commercial game. I didn’t do market research or any of the things you’re supposed to do before starting a project, but I figure that I can get started setting up the GBGames website, the payment processor, and the like. I can get as many kinks in the process worked out so that if OE is a flop, which is likely, I know that I won’t have to start from scratch with whatever my second game will be.

Comments are closed.