public void ReplaceDebugMessageGroup(DEBUG_MESSAGE_GID newGid)
{
var index = GameComponentsLookup.DebugMessageGroup;
var component = CreateComponent <DebugMessageGroupComponent>(index);
component.gid = newGid;
ReplaceComponent(index, component);
}
//TODO : how to link to gameobject ?
public GameEntity create_entity(string message, DEBUG_MESSAGE_GID gid)
{
var _entity = _contexts.game.CreateEntity();
_entity.AddDebugMessage(message);
_entity.AddDebugMessageGroup(gid);
return(_entity);
}
//Note1 : 有幾個概念考量
//entity有幾種使用方式, 一種是被create一次就需要destroy
//一種是被create ,然後一直留著, 但裡面的 component 可能會remove掉,或更新掉(並觸發系統)
//在這次的場景, entity是create後被留著, debugMessage component 會一直被新增->移除
//另一個系統會佔用著一個entity , 然後在此entity 裡做事
//但這樣 一個系統就得記住 entity , 老實說,應該就不是一個系統的精神 (系統理應不該存有資料)
//另一個想法是 Service 提供兩種create_entity 的方式
//一種是 create_oneshot_entity : 意即create 後,立刻被消除
//一種是 create_entity : create後會留著,return entity refernce讓call的人記下, 但必須是call的人負責新增和消除(這也代表該人熟悉此系統...)
//不知還有更佳的方法?
//Note2 : entity 跟gameobject的關係
//在ecs system下, entity 跟gameobject 是脫鉤的
//但實際應用上,兩者仍應有連結
//範例做法是 entity 下有 n 個 gameobject的概念->這表示系統起來時, entity 單位會先生成,然後創建gameobjects
//gameobject 會連結它屬於哪個entity
//但會不會有一個unity gameobject,但自身會連結n個 entity?
//一個例子就是, 我想生成幾個 gameobject , 而每個gameobject 會有一個debugmessage entity
//以上觀念可能錯誤
//entity 是一個工廠中的容器, debugmessage 是容器中的component
//以這概念來看, 系統 entity 的生成應該是由一個 initSystem 完成全部entity 的生成
//而裡面的component可以被新增移除
//所以回到原問題 : "會不會有一個unity gameobject,但自身會連結n個 entity?"
//應該是不會有才對
//生成的entity 需要被記著嗎???
//也許 initSystem 可以記著這些entity (execute / resctive system應該禁止不能)
//entity生成後, 內容被新增可能是由 碰撞, UI , 時間, FSM state 來觸發
//一次性生成後消除的entity可能也是會有,所以規劃service 支援
//A service help for create debug message entity
public void create_oneshot_entity(string message, DEBUG_MESSAGE_GID gid)
{
var _entity = _contexts.game.CreateEntity();
_entity.AddDebugMessage(message);
_entity.AddDebugMessageGroup(gid);
_entity.isDebugMessageOneshot = true;
}
public void console_log(string log, DEBUG_MESSAGE_GID gid)
{
string _log_prefix;
switch (gid)
{
case DEBUG_MESSAGE_GID.DEBUG_MESSAGE_GID_0:
_log_prefix = "<color=green> [DebugMessage 0] ";
break;
case DEBUG_MESSAGE_GID.DEBUG_MESSAGE_GID_1:
_log_prefix = "<color=blue> [DebugMessage 1] ";
break;
case DEBUG_MESSAGE_GID.DEBUG_MESSAGE_GID_2:
_log_prefix = "<color=brown> [DebugMessage 2] ";
break;
case DEBUG_MESSAGE_GID.DEBUG_MESSAGE_GID_3:
_log_prefix = "<color=green> [DebugMessage 3] ";
break;
case DEBUG_MESSAGE_GID.DEBUG_MESSAGE_GID_4:
_log_prefix = "<color=gray> [DebugMessage 4] ";
break;
case DEBUG_MESSAGE_GID.DEBUG_MESSAGE_GID_5:
_log_prefix = "<color=lime> [DebugMessage 5] ";
break;
case DEBUG_MESSAGE_GID.DEBUG_MESSAGE_GID_6:
_log_prefix = "<color=navy> [DebugMessage 6] ";
break;
case DEBUG_MESSAGE_GID.DEBUG_MESSAGE_GID_7:
_log_prefix = "<color=olive> [DebugMessage 7] ";
break;
case DEBUG_MESSAGE_GID.DEBUG_MESSAGE_GID_8:
_log_prefix = "<color=orange> [DebugMessage 8] ";
break;
case DEBUG_MESSAGE_GID.DEBUG_MESSAGE_GID_9:
_log_prefix = "<color=purple> [DebugMessage 9] ";
break;
default:
_log_prefix = "<color=yello> [DebugMessage ] ";
break;
}
Debug.Log(_log_prefix + "</color>" + log);
}
