Jump to content
  • Advertisement
Sign in to follow this  
sipickles

Passing my whole game as a pointer!

This topic is 4832 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

Hi, My game is getting big now. Lots of classes. Pointers passed here and there! As an experiment, I started passing a pointer to my whole game wrapper class, then letting each class call functions within cGame to get the individual pointers they use ( the ones I was previously passing in the constructor ). Is there anything wrong with this? Is it slow? I am keeping the pointers private and using functions to get em... is that ok? Si

Share this post


Link to post
Share on other sites
Advertisement
I'm doing something like that right now... aside from seeming, as you said, very tidy, I thought it would easier to plug it in to some kind of launcher or menu system.

Share this post


Link to post
Share on other sites
In an objectoriented design your main()-function shouldn't contain more than


#include "application.hpp"

int main()
{
Application myApp;
try
{
myApp.exec();
}
catch( ... )
{
// ...
}
}




so you'll always have a class like cGame that starts the whole thing.

Share this post


Link to post
Share on other sites
but why would you do it that way. I have a game object, it is game.exe, and if it doesn't work my OS manages to recover. You need to think outside the box, and object doesn't necessarily correspond to an instantiation of a class or struct.

Basically a program comes down to three things: function definitions, type definitions, storage definitions. Each of these three is defined in terms of the others. A function has a type (a tuple consisting of its return value and its parameters, including *this if it is a member function), and is used to transform state, meaning it interacts with storage. Storage is defined by the type of data that it holds and it is transformed by functions. Type definitions give shape to storage and functions.

Share this post


Link to post
Share on other sites
Quote:
Original post by ext
In an objectoriented design your main()-function shouldn't contain more than

That's not object oriented -- it's silly.

Object oriented, despite what Java, C#, etc would have you believe, does not mean that functions outside of objects is bad. An "application" or "game" class is silly; I'm tempted to argue it borders on idiocy. It's not something that should be an object. You'll probably never have more than one. (NO, don't make it a singleton. That's even more stupid.) What do you gain by making it an object? Nothing. In a well designed system, none of the other classes should ever even know about this application class.

I know why this "Application class" BS popped up too. It's common when you're working inside generic application frameworks -- MFC, Direct3D, etc. In these frameworks, the application class has a distinct purpose, which is to inherit behaviors from a parent class. Initialization and termination behaviors, basic app management, that sort of thing. Now, if your engine is some kind of generic framework that does that, fine. Then having an application class makes sense. But what the hell is the point of this?

#include "stuff.h"

class MyApp
{
public:
bool Startup( ... ) { ... }
bool Shutdown( ... ) { ... }

void Run() { ... }
};

int main()
{
MyApp App;
try
{
App.Startup();
App.Run();
App.Shutdown();
}
catch( ... )
{
...
}
}


It's confusing and it's a waste of your time. Make all of the functions and application class members into program globals declared at the top of main. And no, you're not breaking the rules of object oriented programming. What you're doing is being simple and straightforward.

Think back to why classes exist, guys. This sort of thing is abuse, not good practice.

Share this post


Link to post
Share on other sites
Yep, I always thought that the idea of Main() being a public static method in C# was lame. In addition, I don't think that Math methods should be in a class; a namespace would do just fine.

[Overall, C# is beautiful]

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Quote:
Original post by ext
In an objectoriented design your main()-function shouldn't contain more than

That's not object oriented -- it's silly.

Hear, hear!

I see too many people hamstrung by OO. It is merely a tool to use to simplify your life. If it isn't doing so, then drop it. Procedural programming can't be all wrong, right? There is no "object-oriented" design rule that specifies, "thou shalt have thine Application class referenced from main()."

As for the OP, you're adding all sorts of unnecessary coupling to your system. Now your graphic system knows about your sound system, input system, etc - basically everything in your game class. You may say, "so what?" but when you go to recompile, you're going to pay for this sort of incestuous subsystem knowledge. Each subsystem should exist in complete isolation of other subsystems as much as reasonably possible.

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!