Big applications (games) overall design?

Started by
0 comments, last by Kylotan 16 years, 7 months ago
Greetings, I am working on a 1st person DirectX9 adventure game that will be the biggest project I have done thus far. It will be composed of various elements, such as rendering, level geometry, objects, sounds, input etc. Now what I am wondering about is how to best implement such elements, on the global scale. I mean I could go ahead with an approach I think would work, but I would rather educated myself in some solid methods, dos or do nots etc. of this sort of things. Just to give you an example of a few big questions that are on my mind: * Error Logging: how to best implement that? I am guessing one, perhaps global "error logger" class that every single object in my program includes and refers to whenever errors occur. Or is there a better way? * Rendering engine: on one hand I want to keep it separate from the gameplay and mechanics, on the other, I am having problems figuring out how. Lets take my cLevelGeometry class for example. I could easily create a Draw function that would draw it based on parameters, but then I have each class drawing itself, instead of a unified draw engine. But to create a drawing engine, it would need access to private members of all my displayable classes, which I don't really like either. * Object manipulation and interaction: should they all be self sufficient (Block.Move(), Block.CheckCollisions() etc.) or should I have a controlling class that takes all my elements and manipulates them? In the former case, each object must know everything about the game world, I would need to effectively pass a list of all objects into each of its functions. In the latter, I run into the problem with the render engine, where such manipulator would need to access the private members of each of my objects. And if I use something like "friend class cManipulator" then each of my objects needs to know about the manipulator class, which creates a lot of dependancies and makes the code less reusable / self-contained. * Inheritance: what's the best way to even start thinking about my inheritance tree? Should ALL my objects originate from a common cObject class, or is that too excessive? * Player interaction: how to effectively implement a player class without creating a lot of "hacking" of code to make it work or something that doesn't fit very well with the rest of the code? These are just examples of some of the dillemas I am facing. If anyone could recommend some indepth reading (preferably online, but print in worst case scenario) I would be very appreciative.
Comrade, Listen! The Glorious Commonwealth's first Airship has been compromised! Who is the saboteur? Who can be saved? Uncover what the passengers are hiding and write the grisly conclusion of its final hours in an open-ended, player-driven adventure. Dziekujemy! -- Karaski: What Goes Up...
Advertisement
Error logging - what sort of errors do you anticipate logging? If they're code logic errors, that's what ASSERT is for. If you just need to output some diagnostics at various points, there's nothing all that wrong with a global iostream that you write messages to when needed.

Rendering engine - there's no right way of doing this, only several ways which carry their own pros and cons. Your example doesn't really shed much light on what you plan to do. Typically I like anything which is renderable to carry around the details of what it looks like, which the rendering engine can query for. As long as the renderer isn't having to call a variety of functions on an object to get all those details, it's not a big deal.

Don't stress over private members. Private data is there to make your life easier, by separating implementation (variables in the private area) from the interface (functions in the public and protected area). It's not there for you to feel obliged to make everything private and then need to ask on a forum about how to access it!

Object manipulation and interaction - You don't need to pass a list of all objects into all functions to have an object manage itself. You pass in a reference to the world, and the world object contains the list. The world object can also tell an object which other objects are nearby, whether it's currently touching another object, etc.

Inheritance - forget the inheritance tree. Inheritance is a code tool to make your life easier. It's not a religion that you need to subscribe to before you even understand why you need it. Do you have multiple classes that share the same interface? What about common functionality that is required across multiple classes? Answer those questions before you think about inheritance.

Player interaction - your problem is quite vague. Why should the existence of a player intrinsically mean hacked code? Generally the main difference between a player and a non player is that the player has a different update system, taking information from the input subsystem instead of from some sort of AI system.

This topic is closed to new replies.

Advertisement