It depends on what you're doing, some games are more complex than others. Mine has around twice the amount of classes yours has and I am not even near half of what I need to have. Smaller games need less code, as simple as that. There are of course classes that all games must have, such as a holder for textures and/or images, a game state manager, main menu, movable object base class and many such.
Don't feel too bad I'm still beating my head against the wall on an objectmanager class.
so here's a list of classes I think my craps game program will containYou have to be careful that you don't overdo OOP and put everything into classes. Most of your classes have verbs as names, which may be an indicator that they had better be functions. If there is no state, there will usually be no reason for a class.
There are of course classes that all games must have, such as a holder for textures and/or images, a game state manager, main menu, movable object base class and many such.
Don't feel too bad I'm still beating my head against the wall on an objectmanager class.You both have a rather conservative view, especially concerning the managers and the movable base classes. Sometimes, approaches different from the classical entity hierarchy prove more appropriate. The article Evolve Your Hierarchy (http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/) explains an interesting alternative.
Programming in "C++" with all the classes seems to be a lot harder than programming in "C" many years ago. Composing in C++ needs so much tabbing between different files. (I'm using Visual C++ 2010 Express)Interesting criterion for the difficulty of programming ;D
You have to be careful that you don't overdo OOP and put everything into classes. Most of your classes have verbs as names, which may be an indicator that they had better be functions. If there is no state, there will usually be no reason for a class.
class GameWindow {
public:
void showErrorMessage(...);
protected:
enum Mode {kPlaying, kShowingErrorMessage, ...};
Mode mode;
};
> grep -Rh "class [A-Za-z]* {" src\mm
class FileSystemWatcher {
class Profiler {
class Registry {
class Game {
class Widget {
class InputSystem {
class SensorTracer {
class BackgroundRenderer
class BlockSpriteManager
class Camera {
class Console {
class FunctionProfileVisu
class ImageResourceLoader {
class LightingManager {
class Renderer {
class SpriteLoader {
class Entity {
class FluidManager {
class ISystemBase {
class ItemManager {
class LuaSpecLoader {
class ResourceManagerListener {
class ResourceManagerBase {
class ResourceHash {
class ResourceManager {
class ResourceLoader {
class ResourcePackage {
class Root {
class ScriptManager {
class SoundManager {
class SubRegistry {
class SplitRegistry {
class SystemRegistry {
class BlockManager {
class SubChunkArray {
class ChunkArray {
class World {
class WorldGenerator {
> C:\dev\moonman>grep -Rh "struct [A-Za-z]* {" src\mm | wc -l
74
What does ShowError do? If its not an object and its fairly simple then it can just be brought into your main window/UI class. Of course it depends on various things but typically an error message would be a mode of your program. Hence the main class that handles all the UI business might look like: ... snip ...
ShowError in my program is a class that takes a string as an argument.
First it closes the game's SFML window and then opens a small SFML window. Then it displays the string argument (error message) in the small SFML window and waits for the user to either click the close 'X' or press ESC. Then it returns with a negative value which signals the main loop to exit. ShowError can be called from any class. For now, its primary purpose is if "LoadFromFile" cannot find a .PNG image ...
// loader.cpp
void loadStuff(){
sf::Image img;
bool success = img.loadFromFile("somejunk.png");
if (!success){
ShowError("Can't load file somejunk.png"); // ????
}
}
You mean the constructor? Or is a static class?
Ah right, so am I right in assuming you basically have this:Code: [Select]// loader.cpp
If so... then this looks bad, and it will be tricky to trace the execution of the program. A better approach would be to either return an error code or struct, or to throw an exception. Then at the top level (e.g., in main.cpp) you grab the error, create the error window, etc. This also has the benefit that you loadStuff() etc. don't need to know about ShowError() anymore.
void loadStuff(){
sf::Image img;
bool success = img.loadFromFile("somejunk.png");
if (!success){
ShowError("Can't load file somejunk.png"); // ????
}
}