• Create Account

### #ActualJuliean

Posted 14 May 2013 - 12:05 PM

Again, I have a thing against duplication/caching of state. So instead of having an active unit counter that is added to when a unit is created and subtracted from (via UnitDied message) when a unit dies, I might instead have logic in the spawn system to calculate the current number of active units each frame (or possibly this could be done in another system that is already enumerating through all active entities anyway). That way if I ever added new places in the code where units could be added/killed I wouldn't need to worry/think about updating this number (also coming back to the (irrelevant) save game thing here, I wouldn't need to write any special code to set the "active unit counter" on loading a saved game).

I somehow start to see this asa very convenient. I actually tried my solution with the polling approach you suggest, and while it still worked, I did think it was a bit "ugly", as in non-engine-conformant (this also holds true for my old signal-based query solution, just to clarify). So I actually went ahead and implemented a system similar to what you described you did with your messages, just aside from my regular messaging system. I now have an additional struct called "Query", and I can issue such a query to the manager (currently the system manager, think I'm going to implement a "QueryManager" later). One system can respond to this via overloading the "RecieveQuery"-function. Only real difference is that only one system can respond to a query, and "RecieveQuery" being const, can't be used to transfer information into the system.

What do you say to this? I like this solution, as it offers a way to implement the "interface" into the engine itself rather than the game (reusable code is what, at least I, want, but I quess I'm not alone on this ;) ), plus it won't matter now for the game whether I cache or create state on demand. Only downside I see is that my actual implemented gui is now more depending on the entity-system as it was before with my IGameQuery - interface, but since I'm building the game on this entity/component-system anyway, this shouldn't matter, should it? Here is the code I've got now:

void StateCtrl::Update(void)
{
ecs::GoldQuery query;
if( m_pSystems->Query(query) )
{
m_goldLabel->SetText( conv::ToText(query.gold) );
}
}

bool PlayerSystem::RecieveQuery(ecs::BaseQuery& query) const
{
if(GoldQuery* pGold = query.Convert<GoldQuery>() )
{
if(m_pPlayer)
{
pGold->gold = m_pPlayer->GetComponent<Player>()->m_gold;
return true;
}

return false;
}

assert(false); // should never reach this line
}


Any more thoughts on how to possibly improve this?

### #1Juliean

Posted 14 May 2013 - 12:04 PM

Again, I have a thing against duplication/caching of state. So instead of having an active unit counter that is added to when a unit is created and subtracted from (via UnitDied message) when a unit dies, I might instead have logic in the spawn system to calculate the current number of active units each frame (or possibly this could be done in another system that is already enumerating through all active entities anyway). That way if I ever added new places in the code where units could be added/killed I wouldn't need to worry/think about updating this number (also coming back to the (irrelevant) save game thing here, I wouldn't need to write any special code to set the "active unit counter" on loading a saved game).

I somehow start to see this asa very convenient. I actually tried my solution with the polling approach you suggest, and while it still worked, I did think it was a bit "ugly", as in non-engine-conformant (this also holds true for my old signal-based query solution, just to clarify). So I actually went ahead and implemented a system similar to what you described you did with your messages, just aside from my regular messaging system. I now have an additional struct called "Query", and I can issue such a query to the manager (currently the system manager, think I'm going to implement a "QueryManager" later). One system can respond to this via overloading the "RecieveQuery"-function. Only real difference is that only one system can respond to a query, and "RecieveQuery" being const, can't be used to transfer information into the system.

What do you say to this? I like this solution, as it offers a way to implement the "interface" into the engine itself rather than the game (reusable code is what, at least I, want, but I quess I'm not alone on this ;) ), plus it won't matter now for the game whether I cache or create state on demand. Only downside I see is that my actual implemented gui is now more depending on the entity-system as it was before with my IGameQuery - interface, but since I'm building the game on this entity/component-system anyway, this shouldn't matter, should it? Here is the code I've got now:

void StateCtrl::Update(void)
{
ecs::GoldQuery query;
if( m_pSystems->Query(query) )
{
m_goldLabel->SetText( conv::ToText(query.gold) );
}
}

void PlayerSystem::RecieveQuery(ecs::BaseQuery& query) const
{
if(GoldQuery* pGold = query.Convert<GoldQuery>() )
{
if(m_pPlayer)
{
pGold->gold = m_pPlayer->GetComponent<Player>()->m_gold;
return true;
}

return false;
}

assert(false); // should never reach this line
}


Any more thoughts on how to possibly improve this?

PARTNERS