• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Tim Lawton

Design Patterns, which ones should I be using?

20 posts in this topic

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
0

Share this post


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

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

[quote]
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
0

Share this post


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

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
0

Share this post


Link to post
Share on other sites
[quote]
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.
2

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
0

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
0

Share this post


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

Share this post


Link to post
Share on other sites
[quote name='yckx' timestamp='1354386087' post='5006062']
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
[/quote]
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).
0

Share this post


Link to post
Share on other sites
[quote name='Xuchilbara' timestamp='1354302750' post='5005793']
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

[quote]
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
[/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):
[code]public void View (enum ViewType, int? distance, int? rotateAngle)
{
// ....stuff
}

enum ViewType
{
FPS = 0,
TPS, // third person
RPG, // above the world
}[/code] Edited by Alpha_ProgDes
0

Share this post


Link to post
Share on other sites
[quote name='Xuchilbara' timestamp='1354301934' post='5005782']
I've recently grabbed a copy of the book "Design Patterns Elements of Reuseable Object-Oriented Software".
[/quote]

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 [i]some[/i] 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.
0

Share this post


Link to post
Share on other sites
Small-team + generic-as-possible = dumb.
Back to the drawing-board.

Design patterns are not even an "in sight" problem. Edited by Shannon Barber
1

Share this post


Link to post
Share on other sites
[quote name='jwezorek' timestamp='1354564738' post='5006745']
You shouldn't go out looking to use any particular pattern; but sometime in the future you may [i]find yourself[/i] 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.
[/quote]

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

Share this post


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

Share this post


Link to post
Share on other sites
[quote name='Shannon Barber' timestamp='1355887975' post='5012314']
Small-team + generic-as-possible = dumb.
Back to the drawing-board.
[/quote]
From reading the description the OP provided in a subsequent post, it sounds like this is a pre-defined requirement of the (academic?) project. So the drawing board isn't really something they can revisit.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0