OOP Game Design Theory

I've tried to develop a 2D game with C++ in the past using mere objects, however, in the design process I don't know how and what parts of the engine I should split into smaller objects, what exactly they should do and how to make them interact with each other properly. I'm looking for books, tutorials, papers, anything that explains the game eng开发者_StackOverflowine design in detail. Thanks.

Mandatory reading: http://scientificninja.com/advice/write-games-not-engines

Why do you think you need a game engine? Write the code you need in order to implement your game. Modify it along the way as requirements change. And when you have a complete game, take a step back and look at what the result looks like.

You can't, and shouldn't, lay out a complete class diagram at the start. Sketch out a rough idea of what general components you want, and what their responsibilities should be, and then try to code it. Start out with the classes you're sure of. Sooner or later, some of them will get big and unwieldy, so you split it into multiple smaller ones. Sometimes, you may find that several classes are basically doing the same thing, so you merge them back together. Hopefully, sooner or later, you'll end up with a design that works, which is more than you'd get if you tried to design a game engine up front.

If you haven't made a game before, how can you make an engine? There's tons of free engines out there or you will be spending 20 years trying to get something done because you will be rewriting over and over again.

There are two important types of objects in a game. There are objects that contain processes, and there are objects that interact with the environment and the user.

For those objects that run a process like changing the opacity of objects you'll want them to be independant of any class level variables. They should simply take in value(s) and return value(s). If you have a process to calculate gravity, the process should take in the object that it gravity is being calculated on, and return the the amount of gravity that the object is experiencing, and the direction of gravity if the game takes place in space.

The second more important types of objects are those that interact with the user and the environment. These objects should all inheret of the same base class. The base class will require an image, and the x and y position, and can have variables that perform specific processes like changing the speed or direction of the variable. With this base class in place you can then perform proccesses like the gravity proccess mentioned earlier using every objects "built-in" variables like speed, direction, and x and y position.

You will also want to set up your objects to run peices of code under certain conditions. It may be a good idea to have your base class provide functions that get run when one of these conditions are met. Some useful conditional functions are a conditional function to go of when an object is first created and when it is destroyed. A conditional function to go of after a timer is set. A conditional functional to go of continually where you can place code to draw images on the screen. A conditional function to go off When a keyboard or mouse button is pushed. A conditional function to go off a set amount of times per second to calculate things like gravity on an object.

This framework has worked very well for me when creating games. It works for any type of game, and works horribly for other types of programs. Sorry if my writin is unclear, I'm typing on my iPod and It would be hard for me to go back and edit things on here.

Eberly's 3D Game Engine Architecture and 3D Game Engine Design are rather heavy on the theory, but cover all of the bases quite well.

http://fivedots.coe.psu.ac.th/~ad/jg/

This guy lays out a good oop style and through the book helps you build an engine frame. It's spot on good stuff.

If you want to code a simple 2d game, a good way to get an idea of what you#re actually trying to do is to:

• write a simple game loop, that simply displays a frame buffer in the resolution you want

• render a simple sprite with a a given direction and velocity bouncing off the screen edges

• ensuring that your logic and display code are decoupled

If this sounds like a a lot of work, or if it contains ideas/ terms you're not 100% sure what they mean: Take a look at one or two of the existing game engines.

If you just want to get an idea of how it's done, coding something is a great way to learn.

If you're more interested in developing a game, I strongly recommend something like Unity as a base, so you can actually work on the game. And since it is an engine, you'll learn over time how many different parts there are, and how they interconnect.