Design Patterns, which ones should I be using?

If I were you, I would start with Use cases first. That helps you understand what it really is you need, and what the requirements are (if you don't have them already).

What specific problem are you trying to solve?

The requirements are quite vague, they just want us to show that we are able to create an engine which can develop multiply different games, so I'm looking for a design pattern which is as abstract as possible.

We gain more more points for having a decent working design pattern, also software functionality and technical quality

This game engine will be used to develop three game prototypes of different genres. The computer game
prototypes will be used as a vehicle to demonstrate the versatility of the game engine. Groups may create
any game type they wish, including but not limited to Role Playing Games, Motor sport racing, simulation,
first person shooter or platform. It is your responsibility to ensure that your prototype runs on your chosen
target execution platform
[/quote]

If you guys still require more information to assist me with my problem, I can link pretty much the entire documention

I advise you not to see the GoF book as a compendium of good to go DP, but as a way of tackle problems that will eventually arise when writing software.

Ok then, but the problem now arises, I have no idea how to start this engine. I guess my main problem for me doing the graphics, is to not have any concrete classes or methods. I need to allow the user to texture different shapes, of different sizes, and allow them to apply textures, lighting, colour to then, at the same time, I need the guy whos doing psychics to be able to apply collision, wind, force to them etc..

I know how to create a shape in C++/DirectX11 and add texture to it, but the problem is, once its coded the user gets no say in it, its stuck like that, you could maybe add input to change the position and size of the object, but the texture and lighting is pretty much set in stone. So I need a system which allows a user to just create objects on the fly like it's 3D Studio Max (but obviously not as good), to create a small game.

Things like the camera could just set in stone, I dont see it ever needing to be modified in real-time, apart from its position and where its focusing.

I hope this clears up what Im trying to do

OOP is a means to organize your code. But if you have no code yet, what is the point of thinking about OOP? Organizing your ideas into a class hierarchy before you've written any actual code has a major problem: Your ideas will not translate into code perfectly; you always need to provide much more detail in the code than your ideas start with, and some ideas will have to be changed a LOT when converted to code.

Designing OOP patterns around your ideas instead of code just adds more constraints to your problem of converting your ideas into code. The more constraints you have, the harder it will be to actually write your program. The more constraints you have when solving a problem, the more likely it becomes that you'll end up violating some of them intentionally or accidentally.

My suggestion is to start writing your code *without* thinking about OOP. Do the minimal amount of coding to get something working. Use OOP when it's necessary. Choose a small subset of your overall goal first, and implement it. Don't spend too long organizing it; focus on getting it to function.

After you have something working, review your code, thinking about what you will need to do to add all of your other features. Look for ways to organize it. At this point you will have a much better understanding of how your ideas translate into code, so you can begin applying OOP to the code, rather than your ideas.

Design Patterns, which ones should I be using?
[/quote]

All but the singleton.

But all of them need to be adapted to your needs and applied where appropriate. Dogmatic use will lead to problems.

@Nypyren

Ok thanks, I get it better now.

I do have some code currently, a graphics manager class, which handles all my graphical components, such as Direct3D, Camera, Light, Textures and Models as a starting point, I have it all working to the point where I can hard code a cube to the screen with a texture and some lighting. Although the only way I can change the textures, lighting, colour etc is by changing the code within my Graphics::Render() Function... And like I said previously it should be in such a way that the user can use the engine's interface to create a game, by being able to new shapes.

So I kind of need user input to create a new model/object. And the user would be prompted to creating a new shape, and given options, such as what shape (cube, sphere, pyramid), what textures, what lighting etc. How would I go about doing this?

It may just be my idea of a game engine is, is completely wrong

I may be asking the wrong questions here, lets forget the design patterns for now, how should I go about creating a game engine from the graphics programming point of view? I have DirectX initialized already, Direct3D good to go, Light, colour, textures, Zbuffer all setup. Anything I draw to the screen at this point is set in stone.

Let's take XNA as an example. There is a main loop which runs at a specific framerate (let's say 60 times a second for example). The main loop has a reference to a list of GameObjects. Each of those GameObjects can also have a list of children, so that the GameObjects form a tree. The GameObject class contains two important methods: Update and Draw. This is an example of the "Composite" pattern.

The main loop periodically walks the entire tree and calls Update on each node. Then it walks the entire tree and calls Draw on each node. (The main loop is flexible and might decide to call Update multiple times if the Draw calls are taking too long or something).

The game developer then makes classes derived from GameObject and overrides the Update and Draw methods to do whatever custom gameplay (in the Update method) and rendering (in the Draw method).


This lets you handle almost all of the per-frame gameplay and rendering code. Input handling is different.

With input handling, typically you pass all input to one GameObject which then looks at what state the game is in, and then forwards the input to the appropriate handler (if a menu is open, send the menu-controller GameObject the input, otherwise send input to the player's character GameObject).


This is only one way of handling this. There are a LOT of variations on the idea (using components inside GameObjects instead of derived GameObject classes is one example).

It seems to me that you're conflating the tool chain and the engine. A game engine isn't really used to make assets. if you're tasked with the graphics system, all you should be concerned with (IMHO) is using existing assets (meshes, textures, sharers, maybe text) and game object data (position, orientation, whatever) to draw the world and HUD. Models can be created in existing midelling software and exported into a standard data format, which can then be read by your engine using a library such as assimp. If you're already able to draw hardcoded models, it shouldn't be too difficult to leverage your code to drawing arbitrary models.

I've recently been asked (in a team of 3) to create a small game engine, generic as possible. I've recently grabbed a copy of the book "Design Patterns Elements of Reuseable Object-Oriented Software". So far I'm learning alot of new design patterns, although I've NEVER used a design pattern before, or created an engine.

It's a wrong question, a bit like asking what new bricolage tools you should buy because a large hardware store just opened. The proper approach to design patterns (and design in general) is starting from a specific problem and finding a specific solution; the GoF book clearly states that the design patterns they describe have consequences that can only be evaluated in a concrete context (often it's the trade-off of making something easier to change, efficient, robust, etc. by making something else harder to change, complex, etc.: only you can tell if it's what you need).

It's unfortunately less explicit about OO design principles (one of the main ones in the book is being very careful with concrete classes and leveraging interfaces to do something fancy with multiple implementations thereof, but it's mostly implicit in the treatment of Adapter, Proxy, Decorator, Composite, most cretional pattern, etc.) and about how one should apply those principles in a concrete, real-world design.
The design patterns are pure and simplified abstractions of what many different problems and solutions have in common (often mere C++ or Smalltalk tricks and idioms that might not occur to everybody, most infamously how to write a Singleton), not directly applicable advice; you'll have to combine design patterns you have read about, advice and code about your specific problems, good ideas of your own and endless details to write your game engine.

So my question is, could somebody point out the best design patterns to use, I was leaning on going with the factory method. Also wheres a good starting point for creating an engine, UML diagrams would help me alot if anyone knows of any that could apply to said design pattern method that could help me!
[/quote]
Maybe factory methods are going to be a valuable ingredient of your design; maybe not, and the point is learning enough about your game engine to know what you need. Think of other approaches and how each approach fits your needs (maybe with experimental prototypes), and you'll be able to make informed decisions.

You should start from a high level "shopping list" of requirements (e.g. storing certain asset types in archives so that they can be updated from the network) and use cases (e.g. when does an update take place, and what happens in case of error) and think of how each requirement could be met; it's the only way to put your design decisions in context.

A game engine isn't really used to make assets. if you're tasked with the graphics system, all you should be concerned with (IMHO) is using existing assets (meshes, textures, sharers, maybe text) and game object data (position, orientation, whatever) to draw the world and HUD

I'm quoting this for emphasis.

If the task is to make something genre-agnostic (although graphics are somewhat genre-agnostic already) then just create a graphics component that can consume data files to render a game scene. Data-driven is as wide-use as you can get. Especially when you start thinking about engines that provide a robust scripting interface (script files being just another data file to consume).

To the extent that 'design patterns' are useful at all, they are useful generally when talking about code that already exists because they give you a common vocabulary that you can expect other programmers to know covering many technical abstactions that had no "official" names before the notion of design patterns came in to prominence.

You shouldn't go out looking to use any particular pattern; but sometime in the future you may find yourself using one if you practice good design. At that point, if you need to explain the architecture of something to someone you can refer to its usage of the decorator pattern or whatever.

The requirements are quite vague, they just want us to show that we are able to create an engine which can develop multiply different games, so I'm looking for a design pattern which is as abstract as possible.

We gain more more points for having a decent working design pattern, also software functionality and technical quality

This game engine will be used to develop three game prototypes of different genres. The computer game
prototypes will be used as a vehicle to demonstrate the versatility of the game engine. Groups may create
any game type they wish, including but not limited to Role Playing Games, Motor sport racing, simulation,
first person shooter or platform. It is your responsibility to ensure that your prototype runs on your chosen
target execution platform

If you guys still require more information to assist me with my problem, I can link pretty much the entire documention
[/quote]

It seems to me that Design Patterns aren't the issue. But the flexibility of the game is. For instance, if your game should support: FPS, RPG, and Racing, then that tells me that your camera [class] should be flexible enough to handle those different views. From the start or even on the fly.

Something like (note - this is just pseudocode, pure pseudocode):
public void View (enum ViewType, int? distance, int? rotateAngle)
{
// ....stuff
}

enum ViewType
{
FPS = 0,
TPS, // third person
RPG, // above the world
}

[quote name='Xuchilbara' timestamp='1354301934' post='5005782']
I've recently been asked (in a team of 3) to create a small game engine, generic as possible. I've recently grabbed a copy of the book "Design Patterns Elements of Reuseable Object-Oriented Software". So far I'm learning alot of new design patterns, although I've NEVER used a design pattern before, or created an engine.

It's a wrong question, a bit like asking what new bricolage tools you should buy because a large hardware store just opened. The proper approach to design patterns (and design in general) is starting from a specific problem and finding a specific solution;
[/quote]

Bingo. Any time in programming when you find yourself asking the question:

What [effect] should I make with [cause]?

You're putting the cart before the horse. The best way to learn a design pattern is to read about it, implement a small (100 lines?) example, read about it again, and then leave it alone. Later when you're working on coding something you'll suddenly go, "Oh, hey! I can use [X] here!"

I've recently grabbed a copy of the book "Design Patterns Elements of Reuseable Object-Oriented Software".

I'd say a MUCH better book for learning design patterns is Head First Design Patterns. The GoF book is more of a design patterns reference. The Head First book not only teaches the patterns, but provides some guidelines for when to use them. In particular, it establishes that design patterns are not an end goal themselves, but merely a means to an end. That end being good OO principles. Understanding those principles is a prerequisite to understanding when and where to use design patterns.

So your question really should be What OO principles should I be adhering to when designing/developing my game engine?
Once you understand what those principles are, and how they influence the design of your engine, you can start thinking about what design patterns can be used to apply those principles to the development of your game engine.

Small-team + generic-as-possible = dumb.
Back to the drawing-board.

Design patterns are not even an "in sight" problem.

You shouldn't go out looking to use any particular pattern; but sometime in the future you may find yourself using one if you practice good design. At that point, if you need to explain the architecture of something to someone you can refer to its usage of the decorator pattern or whatever.

I wish I could +1 this harder, and beat lazy interviewers over the head with it.

Another +1 I guess...
As others have said, you look at it backwards. You don't force your problem into any particular design pattern.
You use whatever design pattern models your problem best.
And if you have done any programming, you have used some design pattern, you just didn't know it had a name.