Best Practices?

[Irony]

Hey folks,

So I'm designing this new, ultra cool, massively multiplayer game where players get to hit a little ball with two paddles on either side of the screen!

So yeah, I'm making "Pong." I'm trying something simple in order to try and figure out how this game design thing works. I'm using C++ and SDL; kind of loosely following the "Lazy Foo'" tutorials. However, I'm kind of new to making game engines, so I had some questions:

Is it "bad" to make everything load or initialize with the constructor? Or should I use a separate function(s)? In the tutorials I've been following, they haven't been using OOP, but they do use different functions to load/initialize different things.

While we're at it, should engines in general have multiple classes? I doubt I'll need more than one for pong, but as I said I'm kind of new to this.

Should I build all the SDL into the engine class itself, or should I build it into the game objects? i.e. I'm going to need a render function to render the balls and paddles, so should that be in some abstract class that other objects can inherit from, or should that be part of the engine class?

Thanks in advance!

[D-e-X]

If this is your first game, wouldn't it be better that you start off by writing individual classes to make up for a whole game, instead of starting right on designing an engine, COM and etc? Then when you understand SDL better AND how designing a game works, it would be better to start on something harder, like designing your own engine or something?

[MrDeathNote]

If this is your first game, wouldn't it be better that you start off by writing individual classes to make up for a whole game, instead of starting right on designing an engine, COM and etc? Then when you understand SDL better AND how designing a game works, it would be better to start on something harder, like designing your own engine or something?

I think that might be taking things a little fast. You don't just go from pong to writing an engine, there need to be a few intermediate steps, but I get where you're coming from.

Is it "bad" to make everything load or initialize with the constructor? Or should I use a separate function(s)? In the tutorials I've been following, they haven't been using OOP, but they do use different functions to load/initialize different things.

It's always a good idea to encapsulate different tasks. It's really a readability and maintenance issue. If you want to change something you don't want to trawl through hundreds of lines of code to find what you're looking for.

While we're at it, should engines in general have multiple classes? I doubt I'll need more than one for pong, but as I said I'm kind of new to this.

Hell yes!! An engine may have hundreds of classes. This is really a question of design. And even in pong you shouldn't just put all your code in one class. You could have a class for the paddle, a class for the ball, etc.

Should I build all the SDL into the engine class itself, or should I build it into the game objects? i.e. I'm going to need a render function to render the balls and paddles, so should that be in some abstract class that other objects can inherit from, or should that be part of the engine class?

That's really up to you, but i would have a draw() function in each game object class that gets called in the engine. From your post i take it that you may not be all that familiar with oo design, you may want to read up on it before attempting a larger project, it'll make the job of desgning/coding so much easier.

[N64vSNES]

If this is your first game, wouldn't it be better that you start off by writing individual classes to make up for a whole game, instead of starting right on designing an engine, COM and etc? Then when you understand SDL better AND how designing a game works, it would be better to start on something harder, like designing your own engine or something?

I think that might be taking things a little fast. You don't just go from pong to writing an engine, there need to be a few intermediate steps, but I get where you're coming from.

Is it "bad" to make everything load or initialize with the constructor? Or should I use a separate function(s)? In the tutorials I've been following, they haven't been using OOP, but they do use different functions to load/initialize different things.

It's always a good idea to encapsulate different tasks. It's really a readability and maintenance issue. If you want to change something you don't want to trawl through hundreds of lines of code to find what you're looking for.

While we're at it, should engines in general have multiple classes? I doubt I'll need more than one for pong, but as I said I'm kind of new to this.

Hell yes!! An engine may have hundreds of classes. This is really a question of design. And even in pong you shouldn't just put all your code in one class. You could have a class for the paddle, a class for the ball, etc.

Should I build all the SDL into the engine class itself, or should I build it into the game objects? i.e. I'm going to need a render function to render the balls and paddles, so should that be in some abstract class that other objects can inherit from, or should that be part of the engine class?

That's really up to you, but i would have a draw() function in each game oblect class that gets called in the engine. From your post i take it that you may not be all that familiar with oo design, you may want to read up on it before attempting a larger project, it'll make the job of desgning/coding so much easier.

This^

[Irony]

First off, thanks for the quick replies!

I must be seriously misusing the term "engine." All my "engine" is is a manager class that handles most of the game logic. I'll consult Google about that and OOP. Any resources that you guys would recommend?

If this is your first game, wouldn't it be better that you start off by writing individual classes to make up for a whole game, instead of starting right on designing an engine, COM and etc? Then when you understand SDL better AND how designing a game works, it would be better to start on something harder, like designing your own engine or something?

Again, perhaps my terminology is what is causing confusion. The classes I'm making are an abstract "Game Object" class, a "Ball" class and a "Paddle" class which inherit from it, and then the GameManager class. Do I need more than that?

[MrDeathNote]

First off, thanks for the quick replies!

I must be seriously misusing the term "engine." All my "engine" is is a manager class that handles most of the game logic. I'll consult Google about that and OOP. Any resources that you guys would recommend?

If this is your first game, wouldn't it be better that you start off by writing individual classes to make up for a whole game, instead of starting right on designing an engine, COM and etc? Then when you understand SDL better AND how designing a game works, it would be better to start on something harder, like designing your own engine or something?

Again, perhaps my terminology is what is causing confusion. The classes I'm making are an abstract "Game Object" class, a "Ball" class and a "Paddle" class which inherit from it, and then the GameManager class. Do I need more than that?

For pong you should be ok with just those classes maybe a few more. As for what we mean by game engine have a look here:

http://books.google.com/books?id=LJ20ts ... &q&f=false

This is a great book, it's probably a lot more than you need right now but the first few chapters are enough to give you an idea.

[XianForce]

As for using constructors to initialize/load, in some cases I'd say it's fine to do, but typically I have a separate initialization function. The reason being that constructors have no return value. So let's say in your initialization method, you initialize/load a bunch of stuff... Well most of that code may or may not be successful. In cases like this, it's great to have a return value, making debugging easier .