Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

103 Neutral

About Jabzor

  • Rank
  1. Thanks for all the feedback. The way I've been handling input currently, (going on the 'escape to quit' example) is like this: int Arc::run() { while(m_stateID != STATE_EXIT) { changeState(); sf::Event event; while(m_window.pollEvent(event)) { if(event.type == sf::Event::Closed || sf::Keyboard::isKeyPressed(sf::Keyboard::Escape)) setNextState(STATE_EXIT); m_pState->VEvents(&event); } m_pState->VLogic(); m_window.clear(); m_pState->VRender(&m_window); m_window.display(); } shutdown(); return m_exitStatus; } As of yet I don't really have a 'input manager', more so I'm simply passing the 'sf::event' (that SFML2 provides) to each component that needs it. On a side note, SFML 2.0 RC just came out and I highly recommend it for 2D game development, if anyone is interested.
  2. Usually, I'll have something like: title_state, menu, level1, level2, pause_menu, for example. But if each component is updating every loop (via the component managers) then surely having a state class with event/update/render functions (which mine have always had) wouldn't be needed since the component managers are being called every loop independently? The only role I can see for my game states now is just to load/remove any game entities relevant for that state. I guess it'll just take a bit of tweaking.
  3. Thanks for all the links, I've found this thread pretty useful. The way I use game states now seems to be vastly different to when I had an inheritance model. Because with that model it would be that each state updates and draws everything relevant to that state. But with the component system, it seems that the 'component managers' will just update every component every loop (independent of the game state), removing the need for separate 'event', 'update' and 'draw' virtual functions per state. It seems the only use for states now is just for loading and unloading game elements into the 'entity manager' every new state. I'm guessing each state should have it's own entity managers and component managers? Does this sounds like the best approach? Thanks.
  4. No problem, that powerpoint sounds interesting might give it a read. You might also find this video helpful: [media][/media] They explain some pros/cons of both designs. Their original engine used an inheritance structure but they've now moved over to a component one.
  5. I've currently been looking into both design structures myself. Like yourself, I found my first games automatically leaning towards inheritance. However after looking into component structure it seems the better way to go (allowing for dynamic creation/modification of game entities at run-time is a big plus for me). The way I see it, is that you should almost certainly use inheritance within a component system if it makes sense to do so. An example of this might be a 'Mover' component, you could have both a 'KeyboardMover' and 'AIMover' that would inherit from Mover and imo I can't see any immediate problems in doing that - I could be wrong on that though. That being said, I haven't had much experience in component design but I'm looking to make my next game using exactly that. If anyone has links to good articles on the subject I would greatly appreciate it.
  6. Thanks for the reply, the component system certainly sounds better. It seems that the code might also be more reusable than that of an inheritance based system. Most of the games I've worked on structure wise has always been a version of my example and it annoyed me the fact that my base structure was different nearly every time. So as for the component, game objects are created by adding (or removing) functional components to that object? Would each component then also be attached to a manager (as you suggested) for that component, ie you might have a RenderComponentManager, which would update/render? So the main loop would look something like this: while(running) { InputComponentManager.updateAll(); RenderComponentManager.updateAll(); }//So rather than updating a specific object, you're just updating the components independently? So each render component would draw it's self to the screen: class Renderable : public component { public: Sprite sprite; Renderable(); ~Renderable(); void Render(){ Engine *tmp = Engine::getInstance(); tmp->getWindow()->draw(sprite); }; void SetSprite(std::string fileName){/*sprite loaded from file here*/}; } Is this the kind of way it would work? Thanks again for the help.
  7. Hi all, My question is on how you use virtual functions within your game. I understand the general concept, for example, you'd have a 'weapon' base class that has a virtual function 'attack', this can then be overridden in derived classes such as a sword or axe where you would write the concrete function for 'attack'. My confusion comes from how best to use it for a 'update' function that the game would call. Say you had a base 'entity' class, which had a virtual 'update' function. Derived from this you could have 'renderEntity' with both an update and a 'draw' function and finally a 'player' class which inherits renderEntity and also has it's own definition of the 'update' virtual function. Should each override of the 'update' virtual function only contain update code relevant to that class, and then call the 'update' function from the class it inherits from? Forming a kind of call chain, ie: class entity { entity(); ~entity(); virtual void update(); }; class renderEntity : public entity { renderEntity(); ~renderEntity(); void draw(); void update(){ draw(); }; }; class player : public renderEntity { player(); ~player(); void update(){/*player specific update code*/ renderEntity::update(); }; //Does player update and then calls the parent update(); }; //Then in your main loop in the update section you'd have something like: void update() { for(int i = 0; i < entities.size(); i++) { entities.update(); } } (sorry for the crude example, but hopefully you'll get the idea.) Is this similar to how you structure your game classes enabling them all with their own update() definition that calls the parent update and so on? I understand there's probably a thousand ways to do this, but I feel my way could be improved. Thanks for reading and thanks in advance!
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!