Jump to content

  • Log In with Google      Sign In   
  • Create Account

Dominik2000

Member Since 12 Jul 2013
Offline Last Active Dec 23 2014 04:24 PM

#5197536 Camera movement in input system or not

Posted by Dominik2000 on 11 December 2014 - 02:18 AM

I have a component based system. For camera I have a camera component (clipping range, ...) and a position component. There is a input sytem also, which converts the input to a key enum from my engine, and routes the input to the different key input handlers. For every action I have a handler. The handler checks in its queue, if a specific button is pressed (maybe with a modifier) and calls a function in a class through std::bind.

 

Now my question should I move the camera (edit position component) directly in the input system (input handler recognises W key -> MESSAGE::MOVE_CAMERA_FORWARD -> move function in input system will be called with MESSAGE::MOVE_CAMERA_FORWARD), or should this be a completly different system (movement system)? A movement system is responsible to move other entities too, so I need it anyway, or?

 

Thanks

Dominik




#5093736 Component based architecture and messaging

Posted by Dominik2000 on 13 September 2013 - 02:36 AM

I have edited the diagram, now I have a render manager, and a render system component. It's better I think, what I don't know is, if the waypoint system should be a system or manager. It' has notihing to do with the entity itself... Hmm....

 

http://i39.tinypic.com/oqg4sy.png




#5093530 Component based architecture and messaging

Posted by Dominik2000 on 12 September 2013 - 06:12 AM

 

I have thought about a basic architecture, what I need in my game. I want a car to go to different points controlled by AI.

 

So I think I have following low level systems: Render system, Physic system (optional), Position system, AI system, Waypoint system.

High level system would be exactly one Entity sytem, which has references to all the low level systems, because it needs to know everything from above.

 

Is this correct? Is a component system structured this way?

 

I'd say a bit of this is a matter of taste. 

 

There is no right or wrong answer on how to design a component system because while games are starting to shift and ship with some component system like concepts, it's still something that depending on the development team and architect who is at the helm of the design process; it all varies and sometimes significantly.

 

I generally prefer the idea that the entity framework is a core component to the engine.  The entity framework exposes an entity manager along with a component system interface.  The developers create derived classes of the component system interface for whatever logic they want to implement for the designers.  These component systems are then registered with the entity manager at start-up, allowing the entity manager to build a repository of meta data about the available components, properties associated with the components (useful for editors), etc.  

 

The beauty is that with the entity manager having all this metadata at it's finger tips, the engine simply exposes the entity manager to the remainder of the application.  Internally, the entity manager can delegate creation and destruction of components to the appropriate component systems without the developer having to find the right system and call it directly.  Our component system interface is also designed so that the component system can interact with our core engine framework and submit jobs to the task manager, register themselves as callback listeners to various systems, etc.

 

 

I like your architecture and edited my architecture diagram to this:

http://i40.tinypic.com/2wggbuu.png

 

So I think, it's very similar to your description.




#5093249 Component based architecture and messaging

Posted by Dominik2000 on 11 September 2013 - 05:42 AM

I have thought about a basic architecture, what I need in my game. I want a car to go to different points controlled by AI.

 

So I think I have following low level systems: Render system, Physic system (optional), Position system, AI system, Waypoint system.

High level system would be exactly one Entity sytem, which has references to all the low level systems, because it needs to know everything from above.

 

Is this correct? Is a component system structured this way?




#5092987 Component based architecture and messaging

Posted by Dominik2000 on 10 September 2013 - 06:30 AM

I think, one great possibility is to go the third way, because every system can take the event that it can consume, but how can I implement this, without one big switch in every system. I think this is a very bad solution. Should I static_cast the event parameter?

In my event system (unbufferd) I have function calls, so it's easy to have the right parameter. But a solution with a big switch and a static_cast is simply ugly I think.

 

I think you have this event queue in the game loop class?




#5092675 Component based architecture and messaging

Posted by Dominik2000 on 09 September 2013 - 05:28 AM

Hello,

 

I have a component based architecture with subsystems, which hold the component data and implement the game logic. Now a great problem is, how to implement a messaging system.

 

I have a message dispatcher system, with template where every message type registers it's own eventhandler. On Dispatch every function in the list will be called. I don't like this, because it's hard to delete one listener and I don't get how a message queue could be implemented.

 

So I think of a design like that every subsystem has it's own queue and a high level system (e.g. world manager, ...) write to this queue if anything needs to be updated. One problem is, I think, that every high level system needs to know about the low level systems.

 

Is this a good approach? How do you think about coupling/decoupling, because coupling would be the case in my idea.

 

Dominik




#5080671 Component based game engine architecture

Posted by Dominik2000 on 26 July 2013 - 01:01 AM

I want to create a component based game engine with subsystems which do the work, entities which are simply a list of components and position and rotation properties (because every object will have that), and components which hold data (e.g. mesh component which holds the filename of the mesh and the name).

In addition I want the subsystem to create the components for the entity (the entity has a list of component types and the subsytem creates them.) Is that an acceptable approach?

The subsystem has to be notified if an entity is added to the world. I think the best way is the observer pattern, my scene manager notify every subsystem. And here I get stuck: When the scene manager notifies, should this be a function pointer or a abstract system class with handle message? In the first case, how can I get this work with a variable count of parameters?

I tried to implement this but I am very confused, on google there is too much information, so I can't find whats right for me. Here a example how I tried this:

 

My component class:

/*
* Component.hpp
*
* Created on: Jul 15, 2013
* Author: dominik
*/

#ifndef COMPONENT_HPP_
#define COMPONENT_HPP_

#include "System.hpp"

#include <string>
#include <vector>

class Entity;

typedef enum
{
MESH_COMPONENT,
POSITION_COMPONENT,
} m_ComponentTypes;

class Component
{
public:
Component(m_ComponentTypes type, Entity *parent) { m_Type = type; m_pParent = parent; };
virtual ~Component();

void addObserver(System *system) { m_Observers.push_back(system); };
void removeObserver(System *system)
{
std::vector<System*>::iterator itr;

for(itr = m_Observers.begin(); itr != m_Observers.end(); itr++)
{
if((*itr)->getType() == system->getType())
{
m_Observers.erase(itr);
break;
}
}
};

void notify()
{
std::vector<System*>::iterator itr;

for(itr = m_Observers.begin(); itr != m_Observers.end(); itr++)
{
(*itr)->handleMessage(this);
}
};
protected:
Entity *m_pParent;
m_ComponentTypes m_Type;

std::vector<System*> m_Observers;
};

#endif /* COMPONENT_HPP_ */

And my system class:

/*
* System.hpp
*
* Created on: Jul 15, 2013
* Author: dominik
*/

#ifndef SYSTEM_HPP_
#define SYSTEM_HPP_

#include <string>

class Entity;
class Component;

class System
{
public:
virtual ~System() {};

virtual void initialize() = 0;
virtual void update(double timeSinceLastFrame) = 0;

virtual void handleMessage(Component *component) = 0;

std::string getType() { return m_sType; };
protected:
std::string m_sType;

std::map<Entity*, Component*> m_Components;

System() {};
};


#endif /* SYSTEM_HPP_ */

And my entity class:

/*
* Entity.hpp
*
* Created on: Jul 15, 2013
* Author: dominik
*/

#ifndef ENTITY_HPP_
#define ENTITY_HPP_

#include "Component.hpp"

#include <string>
#include <vector>

class Entity
{
public:
Entity(int uniqueId) { m_UniqueId = uniqueId; };
~Entity();

void addComponent(Component *comp);
void removeComponent(Component *comp);

Component *getComponent(m_ComponentTypes type);

int getID() { return m_UniqueId; };
protected:
std::vector<Component*> m_Components;
int m_UniqueId;
};

#endif /* ENTITY_HPP_ */

This approach with an abstract class is not my favorite, I think function pointers are better.

I think of this case: My position component will be edited from the position system, so my system or my component have to notify the render system.

There are more solutions:

1.) I can create a message with Vector parameters

In this case I need a observer pattern and a message system.

2.) I can have a list of observers in the component

Good approach I think, but if the position component notifies I have 3 float parameters(x, y, z). The mesh component needs only one string parameter. How should I handle this?

3.) I can have a list of observers in the system

Is there a advantage to 2? What is better?

Do I really need the component list in the entity?

Thank you, I hope everything is clear, if not ask, my english is not so good.

Dominik




PARTNERS