Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 11 Feb 2012
Offline Last Active May 10 2014 12:59 AM

Topics I've Started

Pacman game smooth movement collision against a 2D Tile Map

09 May 2014 - 08:43 AM

This is my first time working on a Pacman game and I have come to a difficulty that has stopped me from being able to go further in my project. My Objects (Pacman and Ghosts) were moving too fast, so I thought I would add time based movement for them but I can't get the collision working quite right. Here is my TileMap:

// 1 -> Wall, 0 -> Empty, 6 -> Base Gate, 2 -> Base, 7 -> Portal, 5 -> Pacman Start position


Here is the update code: http://ideone.com/SRIymz


EDIT: I couldn't embed the code in this editor. After 4 failures, I added a link; sorry about that.




Here is the full source code with the demo: http://projects.gasimzada.net/pacman/dev


I want to make the pacman to be at the center with regard to the other plane. So if the pacman is moving in direction UP and DOWN. I want the pacman to be center in LEFT-RIGHT direction. Also, If I hit a wall, I need it to stay at one tile behind it instead of getting inside the walls. I know it has something to do with the Game.roundPos but cannot figure out how to implement it. Any advice will be appreciated? What other methods can I use to round the position to the next correct tile?


Thank you for your time!

Is Window Manager a part of an engine?

18 January 2014 - 10:19 AM

I am designing window management for my engine and I have a dilemma. I don't know if I should make the Window Manager part of the engine, or keep Window Manager as an gateway between user and the engine which sends window events to the engine. And the engine does all the work.


In my current design, there is an Engine object, which on its own is a FiniteStateMachine, so its responsible for changing the game states. It also performs the main loop in my game. Then I attach a WindowInterface to my engine (can be SFML or SDL or whatever). The MainLoop of an engine is implemented this way:

int Engine::run() {
    Timer timer;
    while(running) {
        auto event = window->pollEvents();
        if(event) {
            if(event->getName() == "closed") stopRunning();
    return 0;

But I am thinking maybe this design would be vise-versa, where the window sends events to the Engine instead of Engine receiving them from the Window, and the loop happens through the window instead of the engine.


So, every simple implementation (whether its SDL or SFML or something else), the "run" function must be implemented over and over; from programmer point of view it sounds more work. But It makes more sense to have something similar to that from Engine Design point of view, instead of more code writing point of view.


Please give me advice on this situation. I don't know how to keep it. Its not about anything but the actual Engine design.



Gasim Gasimzada

"Proper" state management for CBE

08 January 2014 - 10:10 AM

I have asked a question similar to this before but I cannot move forward with my engine without fixing the State Machine. In my old design, the systems hold the needed components and updated them as needed and the states hold the systems they need. Like "Play" holds graphics,physics,input,ai,gui; the "MainMenu" holds gui,input. Also, the states are not hard written to the engine; one can create any type of a system they want with the needed components. The problem was that new systems are created for each state; for example there would be multiple input systems in the lifecycle of the application if more than one state has input system.


As my engine become more complex, I decided to change the design to something similar to Artemis Framework. So, here is the new design:


The systems are created ONCE only and their pointers are passed to the needed states. Each state holds a component map. The first parameter of the component is the pointer of the system. The second parameter is of type ComponentHolder. A component holder is basically an abstract class of different lists of components. For example a GraphicsComponentHolder holds 3 lists {list<GraphicsComponent*>, list<CameraComponent*>, list<LightComponent*>}


Example Snippet:

class GameState {
   std::map<Controller*, ComponentHolder*> mControllers;
   std::map<View*, ComponentHolder*> mViews;

   void update(Real time) {
     for(auto &controller : mController)
        controller.first->update(time, controller.second);

   void render() {
     for(auto &view : mViews)

class HordeCameraController : public Controller {
   void updateNode(SceneNode * node) {

   void update(Real dt, ComponentHolder * holder_) {
      auto holder = static_cast<HordeComponentHolder*>(holder_);
      for(auto graphics : holder->getGraphicsComponents())

      for(auto camera : holder->getCameraComponents())

      for(auto light : holder->getLightComponents())

class HordeCameraView : public View {
   void render(ComponentHolder * holder_) {
      auto holder = static_cast<HordeComponentHolder*>(holder_);
      for(auto camera : holder->getCameraComponents())

Is there another way I can build this? Or should I do it this way? Should I just update the component holder when state changes or do something different. I am very noob at state management, so I really need help on designing on.




Game State Machine with Component Based Entity Design

06 December 2013 - 02:22 PM

I have implemented game state machine (Main Menu, Play game etc) into my engine. I have some questions regarding the relation of the states to the entity design that I have:




  1. There are 3 base interfaces: Entities that hold components, Components that holds and manipulate data, and systems that all the hard work
  2. Components can communicate between each other through messaging or straight referencing. I use referencing for inner operations, where dependencies are strict; while events are used for decorative purposes. One example would be sending event walk, which will play walk sound and walk animation; if you completely disable both animation and sound, the system will still work properly but uglier (hence the name "decorative").
  3. Systems have direct access for particular components (like PhysicsSystem holds PhysicsComponents but can also manipulate PositionComponent (if you have one)), components can sometimes talk to systems through messaging but it should be very rare. I haven't implemented it yet, but I am thinking of creating an event queue and then go though all the events in the update/render. Additionally, systems don't communicate with each other directly. And systems should be stored in a certain order, therefore all the systems have a unique ids that are in ascending order.


In my current draft implementation, each state holds a list of systems that need to be updated,rendered,or used for input. For example:


The "gameplay" state holds Physics System, Graphics System, and Input System, while the "main main" state holds GUISystem and InputSystem. The input systems do not hold the same address. They are created separately and hold the components they need for each other. This way when I call update, only the needed systems get updated. So far, everything seems to be making sense...


But I have one problem with connecting these states to components. I need that for one reason: Sometimes components can talk to the systems. For instance, the components get added to their corresponding systems during entity initialization (the initialize function gets called. And from there I can write whatever I want in that function).


When I had an engine with only one system manager, it was easy to handle systems. Currently, the active state is stored in the entities the moment an entity gets created. But what if the state gets changed when there was an entity getting created? The Entity will be added to a system in a wrong state or if the state doesn't have the system the game will crash. Also, wouldn't it be inefficient in terms of memory to store all the resources of the inactive states?


Design wise this system makes sense to me but efficiency-wise i don't know. What do you think? Is this approach even good? I know there is usually no universally accepted way of doing this but I don't want this system to be horribly bad. So, please criticize it as much as you can.

Bullet physics undefined behavior with a dummy simulation

06 December 2013 - 08:59 AM

I have asked this question couple days ago. I thought I fixed the issue since I don't keep my program on the moment I start it but I found something I can't fix.


Here is the scenario:

  • I have a sphere object thats centered at (0.0, 2.0, -5.0). It has a 1KG mass and has a Sphere Collision Shape with zero radius.
  • The world gravity force is (0,0,0). I know for a fact that the object is just "sitting in the emptiness"
  • There are three input events I attach to my object: if I press 'W' the rigid body's linear velocity is set to (0.0,0.0,-10.0);
  • I added a "profiler" to check out the position and linear velocity of the object every frame, and linear velocity during key press.​​​​
    • ​For each frame it prints "ID. posX posY posZ LinearVelocityX LinearVelocityY LinearVelocityZ" (ID is for keeping count)
    • For each input event it prints "new velocity: LinearVelocityX, LinearVelocityY, LinearVelocityZ"

The problem:


When I constantly move the object, there is no problem; everything works fine. However, the object doesn't move if I keep it idle for around 5 seconds or more.


The test and results:


I run the program. Wait for 5 seconds and then press "W" the linear velocity gets zeroed out after the simulation step even if the linear velocity was set during the event firing:

240. 0 2 -5 0 0 0
241. 0 2 -5 0 0 0
242. 0 2 -5 0 0 0
new velocity: 0, 0, -10
243. 0 2 -5 0 0 0
244. 0 2 -5 0 0 0
245. 0 2 -5 0 0 0
246. 0 2 -5 0 0 0
247. 0 2 -5 0 0 0

The code:

Physics system update:

 void BulletPhysicsSystem::update(double dt) {
        //This is the profiling
        btTransform transform; btVector3 v(mComponents[0]->mRigidBody->getLinearVelocity());
        std::cout << ++i << ". " << transform.getOrigin().x() << " " << transform.getOrigin().y() << " " <<transform.getOrigin().z() << " ";
        std::cout << v.x() << " " << v.y() << " " << v.z() << "\n";

Main loop:

sf::Clock clock;

while(mRunning) {
      //This function updates the physics
      mRenderWindow.clear(); mRenderWindow.pushGLStates();
      mCurrentState->render(); mRenderWindow.popGLStates(); clock.restart(); mRenderWindow.display();

A video from my scene with the problem in it:



Additional notes:

The input and Graphics works in my system which gets the position from the rigid body of the bullet physics component. But from what I see that the problem is in my time step but I don't know how to fix it. Even a fixed time step doesn't seem to show a result that at least moves the object. What am I doing wrong?


I am so desperate to fix this issue. If any more information is needed please tell me.