Design Patterns Applied?

I am just starting along the path, but you may end up using the following design patterns in these ways:

FactoryMethod: A resource manager that returns whatever type of object you need. The resource manager can then dispose of the objects for you.

Command: Use input events that are passed around. Instead of passing a number of arguments to a function, you can pass one Command that can describe the event. This is especially useful if you decide to expand the way you use commands.

Chain of Responsibility: The aforementioned input events might be passed down a chain of SubSystems (Menu, Console, Game, [Logger]) until one of them consumes it and does something with it.

Facade: In order to make your engine reusable, you may wrap OpenGL calls into one object that exposes those functions. You can then swap that object out with another library, provided you can make it inherit the same interface.

Iterator: Numerous uses. One use could be in the Chain of Responsibility mentioned above.

Flyweight: You have a swarm of entities in your game and you don't want to address them individually, but instead as a collective. Flyweight encapsulates the swarm which are just a collection of data points and operates on the collective as a whole. I will provide a pseudo-code example for this one:

-- Instead of this:foreach entity in swarm  entity.Attack(player1)end-- We use this:swarm.Attack(player1)

Admittedly, I approached the easier ones and this may not be the best sampling of uses, but from another "beginner"'s perspective, I think these illustrate some approachable and likely uses for each of these patterns.

Quote:

Original post by Low Bias I'm just now learning the GoF design patterns. I'm not going to go out of my way to apply any of them, but somebody suggested I study them so that I could apply them where it makes sense, and I agree. Could any of you more experienced people speak to how you may have applied design patterns in your games? I'm not expecting code, but ideas and applications. I'm sure there are plenty of people who could benefit from a discussion on design patterns and how they may have been applied.

You're probably already applying some design patterns without even knowing it.
Among many I've used the Decorator pattern for a GUI I'm making. It's almost impossible to code OO without using the Delegator pattern. etc.

Quote:

Original post by blackdot Command: Use input events that are passed around. Instead of passing a number of arguments to a function, you can pass one Command that can describe the event. This is especially useful if you decide to expand the way you use commands. Chain of Responsibility: The aforementioned input events might be passed down a chain of SubSystems (Menu, Console, Game, [Logger]) until one of them consumes it and does something with it.

All very good examples, but these two I can see providing more elegant solutions to specific problems I have dealt with in the past.

Quote:

Original post by blackdot Flyweight: You have a swarm of entities in your game and you don't want to address them individually, but instead as a collective. Flyweight encapsulates the swarm which are just a collection of data points and operates on the collective as a whole. I will provide a pseudo-code example for this one: -- Instead of this:foreach entity in swarm entity.Attack(player1)end-- We use this:swarm.Attack(player1)

Unless I miss my guess, that's not a flyweight pattern. At least, I recall that the GoF book defined the flyweight pattern much differently.

Sneftel, right you are. In GoF, a flyweight is used for entities that occur in such masses so that an individual handling is too costly. The example given was about attributes on characters in a text paragraph, as I remember correctly, so that one could/would not store several thousands of attribute objects for a somewhat lengthy text ...

The thing w/ patterns is (at least in _my_ practicing) that when I get a new problem to solve, it may occur that I have a though like "uh, its a >set any individual pattern here< category of problem, so its solution is typical." I do not search for a problem for that pattern XYZ can be applied. The problems come by itself, and for several of them the solution comes also by itself if one knows enough patterns.

So I totally agree to learn patterns also if not having an explicit problem at hand. However, there _are_ typical usages, of course: Composite pattern and Iterator or Visitor for a scene graph, the Command pattern as mentioned by blackdot or for deferred application if a time slice is already overcrowded w/ action, Facade for hiding little things (like a swarm's individuals ;-), Decorator and Moderator for 2D GUI elements, and so on.

Quote:

Original post by blackdot -- Instead of this:foreach entity in swarm entity.Attack(player1)end-- We use this:swarm.Attack(player1)

Looks more like the Encapsulate Collection refactoring pattern to me...

I think that I may not have gone into the benefits of using the pattern well enough. It was implied that the swarm would share certain data that would be redundant over the group of items, but yes, that should be explained.

I think a better example of a flyweight pattern for games would be resource management. For example, if you have a lot of mobs running around with the same model, then you just have one instance of that model, and utilize the extrinsic properties (position, animation keyframe, etc) to render it correctly in the context it is in.

This is something that I was using before reading Design Patterns - it makes sense to only have one object for resources such as textures and models shared based on what context they are in.

That's a very good example, kevmo.

Anyone else have examples for some of the other patterns not already mentioned?

I used a variant of observer in a scripting engine once. The script had a "pointer" variable type, pointers to the game objects. If the object was removed in the game instead of having an invalid pointer it was notified and automatically set to a NULL pointer.

I also tend to use State quite often as game states. Each state (playing, menu, etc...) has its own state object with a common interface managed by the main game class.

That last post was me. I was logged out for some reason.