Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

155 Neutral

About Tomsen1410

  • Rank
  1. Thanks. However, this didn't answer my question entirely. I am still confused because of the game states. As I wrote in my first post I've implemented states, which have the following interface: class iState{ ... void Init() = 0; void Update() = 0; void Quit() = 0; ... }; Now I've got two questions:   1.) What exactly should be in the Update() function of a state? As I already have systems that manage the "technical" side of the game, I thought of states as a "container" for the game logic. Therefore the user checks if the player did lose, win, gets to the next level etc. in a states Update() function and handles those situations properly (maybe creating new Entities and so on). I am still concerned about this though, because this doesn't seem like a neat solution.   2.) The second question is related to the first one and may be irrelevant, if the above approach with the states is wrong. How should I handle events created by the controller components? I know that you've already answered this question, but what if the user doesn't want an event to be processed by a system, but rather by a state. Lets say the controller generates an event "AddEnemies" when pressing down a specific key. Well, this event has to be processed in the current states Update() function, because new entities have to be created. This has to happen in a state, as this is part of the game logic.
  2. Thank you for your replies! Sorry I couldn't answer earlier but I didn't have much time. Anyway, I've got a question relating @haegarr 's post:   The InputSystem gets the raw input data. The Controller components then map this data to "events" such as MoveForward, Attack, etc... Now, how should those events get handled? Maybe the user would like to tell the PhysicsSystem to add a value to the entitiys position when the MoveForward event gets created. But maybe he would also like to create a new entity in the current state. I'm a little bit confused, as I don't know if the events should get processed by the systems only or if the user should also be able to process them in the states Update() function...or maybe this is a completely wrong approach.
  3. Hi, I am currently working on a little game engine for learning purposes. I am using OpenGL for rendering and GLFW for the windowing system. Now I would like to use Raw Input as my input gathering system, because this one is the fastest way on Windows as I've heart. Unfortunately I don't know how, as GLFW creates the window and I can't set a WndProc callback function.   So my question is: Is it possible to use Raw Input when I let GLFW(or any other similar library) create the OpenGL context?
  4. Thank you for this great reply L. Spiro and phil_t!   I still have some questions, but first I want to make something clear: I think you misunderstood me. I've never wanted states to be singletons. As you already said that would be just stupid^^ I meant that the singleton design for the INPUT class would be great, because then the user can get (and process) input information really easily inside of a state INSTANCE simply with Input->IsKeyUp(key) and thats it. Nevertheless, after reading your post, I now realize how much better your approach is.     Questions:     1.) So, you stated that the cTimer should have a virtual time value and an actual time value. I don't exactly know what a virtual timer is, but I guess it is similar to the actual timer, but in addition you can "manipulate" it(e.g. stop updating it). Now to my question: Wouldn't it be better just to ignore the states, which aren't on top of the stack rather than processing them with the deltaTime value zero? Then you would save processing time or did I get the whole virtual-timer-thing wrong?   2.) What exactly do you mean with using a state of stack internally?   3.) Why is UpdatePaused() a bad approach? Maybe the user would like to process some other stuff(not the stuff in the original Update() function) when the state is not on the top of the stack?   4.) Why exactly are the logical updates only processed 30-40 times per second? Is this still true when the game runs at 60 fps? Then those "extra" frames wouldn't make much sense or do I miss something again?
  5. Hi, first of all: great site! I am currently creating a game engine for educational purposes.     ECS Design Pattern The first design pattern I've included is the Entity/Component/System pattern. Therefore I've got a base SINGLETON class called cEngine, which contains all systems(PhysicsSystem, GraphicsSystem, etc.) so it can update them on each frame. void cEngine::Run() { while( m_Run ) { m_Timer.Update(); for(int i = 0; i < m_Systems.size(); ++i) m_Systems.at(i)->Update(); //NOTE: I will add a SystemManager to update them in the proper order } } Also, I can create new entities(actually just IDs) and add different components(position, velocity, renderable, ...), which then get saved in the right system. So for example, the position and the velocity components will be saved in the physics system, as this one is responsible for modifying those values. Other systems, however, may have a pointer to those components, because they may need those values(the graphic system for example needs the positional information, but won't modify it).     State Design Pattern The second design pattern I use is a state system: class iState { virtual void Init() {} virtual void Quit() {} virtual void Update() {} virtual void UpdatePause() {} virtual void Obscuring() {} //call when another state gets pushed virtual void Revealed() {} //call when upper state gets poped private: bool m_isActive; //true, when it is at the top of the state stack }; The user will be able to create customable states(overwrite the virtual functions), which then get pushed onto the StateStack. Those functions will be called properly for every state by the StateManager class. class cStateManager { void Init(); void Update(); void Quit(); void PushState( iState* state ); void PopState(); void ChangeState( iState* state ); private: std::vector<iState*> m_stateStack; }; Questions First of all: Is this the right choice? In my opinion this design is pretty good, as it is easy for the user AND it SHOULD have good performance. However, I appreciate suggestions! My second question is related to Input Handling. My design would've been a SINGLETON Input class. class cInput { void Update(); bool wasKeyPressed(int key); bool wasKeyReleased(int key); bool isKeyDown(int key); bool isKeyUp()int key); private: //... } Once again, the engine class would Update() this class every frame, so it would always have the right key information. The huge benefit by not handling this class as a system, but as a segregated singleton class is, that the user simply can create a new state, create some entities in it, and easily handle input in the virtual Update() function of that state. E.g. something like this: //overwriting virtual state functions void Init(){ id = cEngine->AddEntity(); } void Update(){ //add some components, bla bla... //simple input handling if(cInput->IsKeyDown(KEY_W)){ //do something... } if(cInput->WasKeyPressed(KEY_A)){ //do something } } As I've already said, in my opinion this "hybrid" design, which does not see the Input as another ECS system, but as a "independent" class is better and much more comfortable for the user than a "input component". However, I haven't seen this pattern on the internet, which makes me a little bit insecure. Did I miss one huge benefit of an input component? Or a huge disadvantage with this approach? I would really appreciate any answers, as this bothers me for a few days now. Thanks!
  • 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!