Search Results

Search found 2 results on 1 pages for 'rivten'.

Page 1/1 | 1 

  • Is my class structure good enough?

    - by Rivten
    So I wanted to try out this challenge on reddit which is mostly about how you structure your data the best you can. I decided to challenge my C++ skills. Here's how I planned this. First, there's the Game class. It deals with time and is the only class main has access to. A game has a Forest. For now, this class does not have a lot of things, only a size and a Factory. Will be put in better use when it will come to SDL-stuff I guess A Factory is the thing that deals with the Game Objects (a.k.a. Trees, Lumberjack and Bears). It has a vector of all GameObjects and a queue of Events which will be managed at the end of one month. A GameObject is an abstract class which can be updated and which can notify the Event Listener The EventListener is a class which handles all the Events of a simulation. It can recieve events from a Game Object and notify the Factory if needed, the latter will manage correctly the event. So, the Tree, Lumberjack and Bear classes all inherits from GameObject. And Sapling and Elder Tree inherits from Tree. Finally, an Event is defined by an event_type enumeration (LUMBERJACK_MAWED, SAPPLING_EVOLUTION, ...) and an event_protagonists union (a GameObject or a pair of GameObject (who killed who ?)). I was quite happy at first with this because it seems quite logic and flexible. But I ended up questionning this structure. Here's why : I dislike the fact that a GameObject need to know about the Factory. Indeed, when a Bear moves somewhere, it needs to know if there's a Lumberjack ! Or it is the Factory which handles places and objects. It would be great if a GameObject could only interact with the EventListener... or maybe it's not that much of a big deal. Wouldn't it be better if I separate the Factory in three vectors ? One for each kind of GameObject. The idea would be to optimize research. If I'm looking do delete a dead lumberjack, I would only have to look in one shorter vector rather than a very long vector. Another problem arises when I want to know if there is any particular object in a given case because I have to look for all the gameObjects and see if they are at the given case. I would tend to think that the other idea would be to use a matrix but then the issue would be that I would have empty cases (and therefore unused space). I don't really know if Sapling and Elder Tree should inherit from Tree. Indeed, a Sapling is a Tree but what about its evolution ? Should I just delete the sapling and say to the factory to create a new Tree at the exact same place ? It doesn't seem natural to me to do so. How could I improve this ? Is the design of an Event quite good ? I've never used unions before in C++ but I didn't have any other ideas about what to use. Well, I hope I have been clear enough. Thank you for taking the time to help me !

    Read the article

  • Basic SDL2 Code which "Stop working" when calling SDL_Quit() [migrated]

    - by Rivten
    So I got into SDL2 with C++ quite recently and I did this very simple code : int main(int argc, char** argv) { SDL_Event *event; bool done = false; if(SDL_Init(SDL_INIT_VIDEO) != 0) { std::cerr << "Problèmes pour initialiser la SDL : " << SDL_GetError() << std::endl; return 1; } SDL_Window *window = 0; window = SDL_CreateWindow("Mopion", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, WIDTH, HEIGHT, SDL_WINDOW_SHOWN); if(window == 0) { done = true; } while(!done) { while(SDL_PollEvent(event)) { switch(event->type) { case SDL_QUIT: done = true; break; case SDL_KEYUP: if(event->key.keysym.sym == SDLK_q) { done = true; } break; default: break; } } } SDL_DestroyWindow(window); SDL_Quit(); return 0; } While that code executes at first quite well, when I hit the "Q" key, the window closes but I got a Windows Error Window saying that "My program stopped working." which is not very convenient. Using the debugger, I found that everything is fine until SDL_Quit() is called. Anyone has any idea why this is going on ? Thanks a lot !

    Read the article

1