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!

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.

@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).