Jump to content
  • Advertisement
Sign in to follow this  
Tim Lawton

Design Patterns, which ones should I be using?

This topic is 2127 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey there,

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.

In more detail, I've specially been tasked to do the graphics side of the engine, I have 3 years of Object Oriented programming experiences, 2 of which are in C++. I have fairly good knowledge with DirectX11 although granted I'm still a novice. I want something that will let me create graphical objects and shapes in an engine manner.

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!

I hope I wasn't too vague, I'm not 100% sure what I'm looking for as I've never done this before, hopefully someone would of been where I am previously and can shine some light on this.

Thanks! Edited by Xuchilbara

Share this post


Link to post
Share on other sites
Advertisement
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).

Share this post


Link to post
Share on other sites
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 Edited by Xuchilbara

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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. Edited by Nypyren

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
@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.
Edited by Xuchilbara

Share this post


Link to post
Share on other sites
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). Edited by Nypyren

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!