Monthly Log 2014. 10.
### October 2014
#### 2014-10-02 Researching...
* Concurrent programming
* Scripting/Moding.
#### 2014-10-03 Actor and Event system.
* Engine
* TryDeq() added to LockFreeQueue
* Game
* Adding Actor + ActorComponent system
* Added EventManager.
* Want to re-structure everything.... but let's postpone it for the second game. minimizing modifications.
* Researching
* Scripting / Modding.
* +1206, -29 cannot run.
#### 2014-10-05 Script system.
* Engine
* Added lua interactive mode for console - type '>>>' to enter lua mode and '<<<' for exit.
* Game
* Added ProcessManager
* pushing and popping custom types(like Vec3, std::string) from lua stack
* Events added. NewActor, DestroyActor and GameInitialized events
* Registering events to the scripts.
* Added ActorManager
* Adding ActorComponents - GameObjComponent, SpatialComponent and TargetingComponent.
* Defining Actor xml files and ship lua files.
* +1878, -176
#### 2014-10-06 ActorComponents
* Engine
* Added LuaObject which creates a copy from lua variables in the stack into the registry
* Added a generic function to call lua function.
* Game
* Completed script event system
* Added actor components
* SpatialComponent
* EngineComponent - for movement.
* CrewComponent
* ScriptComponent
* Adding actor components
* PlayerComponent
* ModularShipComponent
* +2057, -139
An actor can be defined in a xml file or a lua script. I think if I use a lua script to define an actor, the advantage is hot-reloading. Just change the lua script and run it again in runtime might be enough to apply the modification. xml also can be reloaded by responding file modification notice but additional storage could be required to hold the archetype data.
UI system also can be defined in a script. Maybe I don't need to write any cpp code for UIs, if I can retrieve all the information which UIs need to display.
#### 2014-10-07 Adding components
* Engine
* Added a few utility methods into LuaObject like IsTable() IsFloat(), GetFloat(), GetString()...
* Game
* Added components
* ModelComponent which handles visual stuff. - MeshObject, MeshGroup...
* SeatComponent which actors can seat. to bind crews and ship. Crew can be bound any actors that have this component.
* ShipComponent which hold a properties of a ship like HullPoint, DestroyEffect, Upkeep....
* Added GameStateEvent triggered when the game state is changed.
* More convinient way to generate events. - now one can create an event by EventName:Create(args...)
* Adding WeaponSystemComponent and WeaponComponent
* +2213, -296
#### 2014-10-08 WeaponSystem and Weapon Components.
* Engine
* Added Lua Sequence iterator
* fixed Vec3 push bug
* Displaying different prompt while in lua interaction mode.
* Game
* UI visibility control in lua
* Added WeaponSystemComponent and WeaponComponent
* Actor hierarchy
* Spatial Component hieraracy
* Added ActorLinkEvent
* +1346, -453
#### 2014-10-09 ModularShip Components
* Engine
* Retrieving Vec2 and Vec3 from LuaObject
* LuaWrapper is modified a little bit for debugging purpose.
* Collada importer's profiler got more informative output.
* Game
* Worked on ModularShipComponent and ModuleComponent
* Added ModularModelComponent which handles model representation of modular ships.
* WorldInitialization and moving spots via lua scripts
* Exporting Enum values to the script.
* Added whole components list text file to help writing actor scripts.
* +1228, -251, No memory leak
After changed to Actor-Component model, messaging between components became more important. For example I have SpatialComponent which handles transformation stuff and also I have ModelComponent taking responsibility to display visual models on the screen. Whenever transformation in Spatial component changed, the new transformation should be propagated to the ModelComponent. Since ModelComponent located in higher level project which are using the lower level project in where the SpatialComponent resides. Lower level projects can not reference higher level projects so messaging system is required to make the lower level project be independent to the higher one.
Currently I got three kinds of messaging system. The first one is for global events like 'level initialized', or 'game state changed'. This system also can send and receive events to and from the lua scripts.
The second messaging system is for inter-actor messaging. It dispatch a certain message with a target actor Id and delay time. This is good for delayed messaging since it always checks whether the target actor is available at the time the delayed message dispatched. But it has overhead of checking cost.
These two messaging system is not suitable for inter-projects communication. The first one is not for instance-instance communication and the second one cannot solve the inter-projects dependency problem.
So I was weighing other systems. The candidates were 'adopting UI event system for components' and 'Manual listener registration'. The first one may be good if I have a lot of events and the almost all components need to dispatch events. But it also has some overhead to search the map of event callback functions and evaluate function pointers from the function object.
In speaking of 'Manual listener registration' the most formidable advantage of it is speed. It will hold a listener function address directly so can call it with the minimum cost. In case of Spatial components, they dispatch a transform event almost every frame, in this scenario the speed is more important criterion. So, I'm thinking the second one might be better than the first one although I need to define Listener interfaces manually for every occasion when the components need to dispatch events.
#### 2014-10-11 applying original codes....
*Added evets
* ActorEvent, ModuleEvent, ItemEvent, ResourceEvent, WaveEvent
* Worked on Input Handler
* Added JumpDriverComponent.
* Modification original codes for new object model.
* +3579, -665
A lot of modifications for applying previous codes onto the new Actor-Component model. A lot more left. OTL
working order
* UIs - just make it compile
* Module manipulation
* FlockSimulation
* ShipMovement
* Jumping
* Removing original codes.
#### 2014-10-13 adopting original ui codes.
* Added lua quaternion
* Added effect manager
* Destroying ships using a Process(DestroyProcess)
* Portrait for ModelComponent
* Worked on CrewListUI, CrewUI, ModuleContextUI, ResourceUI, ShipListUI, ShipUI, SpecialModulesUI, StationContextUI
* Polished boarding
* Added PlayerEvent - construction started, processed, finished
* Construction codes move to ModularShip
* Added Shield component
* +2173 -672
#### 2014-10-14 UI.
* UI compilation done
* Model highlighting.
* Worked on MarkManager, MessageDispatcher.
* working on save/load
* +2180, -1454
#### 2014-10-15 shader cache
* Engine
* Added dist shader cache. - it boosts start up significantly.
* Added a simple FileSystem
* LuaObject bug fixes
* Game
* Loading using .lua - overriding original archetypes.
* Crew initialization
* Exporting class embeded enumeration to the script.
* +1304, -447, no memory leak.
#### 2014-10-16 AI base structure.
* Engine
* fixed lua stack error
* Added r_UseShaderCache and r_GenerateShaderCache commands.
* Game
* Assembling ModularShip, weapon attachment and upgrade.
* Module stock ui.
* Added ManufactureComponent, PowerComponent, ResearchComponent
* Added ScriptProcess, FighterBrain and States
* +1377 -388
#### 2014-10-17 EagleAi and Weapons.
* Game
* Reviving WeaponSystem - finding targets, tracking, firing, cosuming power.
* Moving eagles ai to the script
* worked on FighterAI.lua, FighterBrain_Player.lua, DecisionNodes.lua, CommonStates.lua, FighterStates.lua
* +1220 -293
There are two extream methods working with lua(or any scripting languages). The first one is that using it intensively so almost all codes reside in lua with this method. Good way to start using this method is that you just consider the cpp game codes as an interactive lua interpreter and game data visualization tool. On the other hand, in the second method the usage of the scripting is very minimized. You may ignore scripting system while you are developing your game until you find you find a portion of your codes that are changing very rapidly in short duration of time in the restrict part of your code. you can exports these part to lua to boost the development time.
Presumably somewhere middle of thease two extream method may be good, but need to be cautious that you may confuse which part of data or algorithm reside in scripting languge and which aren't when you taking this balanced method.
I'm taking the second extream method(not that extream but somewhat), but interested in the first extream method apart from the efficiency and performance. Just curious.
#### 2014-10-18 FighterBrain
* Game
* CreatActor function now receives direction and team information
* Pointers returned from / sent to a function are now StrongPtr.
* Almost all case we need to call lock() when using WeakPtr, so StrongPtr is more convenient.
* When the pointer need to be stored, usually using WeakPtr.
* Polishied EffectManager
* Worked on WeaponComponent
* Added AmmoComponent
* Added draft of experience graph(leveling)
* Added LaunchProcess which handles launching delay of eagles.
* Added serveral scripts interfaces for ships.
* Testing FighterBrain script.
* +1727 -582
#### 2014-10-20 fighter, bomber ai.
* formation
* fighter, bomber ai.
* +2020 -495
#### 2014-10-22 Rotating weapons, save/load via lua.
* Engine
* Added Lua debugging features. printing callstack, local variables.
* Lua security : redirecting io.open()
* Game
* save/load game data to/from lua table.
* changed 'for each' statements to 'for' statements
* Revived yaw-pitch seperated weapons.
* Random rotation for yaw-pitch seperated weapons to give an impression watching the enemies.
* Weapons consume power.
* Seperated actor storage for ammos. not to check collisions.
* fixed the case NaN value is generated in the flock simulation.
* Added 'RunAway' and 'Leave' states.
* +1574 -391
#### 2014-10-22 Line of sight, frigates, cruisers
* Engine
* Line rendering before the transparent pass
* Game
* Rendering line of sights of rotating weapons.
* Revived laser frigate and missile cruiser
* Added Cruiser.lua, CruiserBrain.lua, CruiserStates.lua
* Added Frigate.lua FrigateBrain.lua, FrigateStates.lua
* Added WeaponLaserFrigate.lua, WeaponRocketCruiser.lua
* Added AmmoLaserFrigate_1.lua, AmmoRocketCruiser_1.lua
* Revived space station
* +1509 -500
#### 2014-10-23 UI - Lua binding. Research UI.
* Engine
* Moved hot-reloading point to the end of frame.
* Adding multiline font rendering.
* Game
* Adding research ui.
* UI system
* Initializing UI and event handling with lua.
* Added TEXTURE_FILE, KEEP_IMAGE_RATIO ui properties.
* Added TextBox UI component.
* +848 -65
#### 2014-10-24 Research System
* Defined Research Items.
* Working on ResearchUI.
* +2638 -55
#### 2014-10-26 Research UI.
* Engine
* Multiline text rendering and aligning.
* Game
* Research UI.
* +1798, -816
#### 2014-10-27 ResearchUI and BuildUI
* Game
* Worked on Research UI.
* Working on Build UI.
* UI
* smooth scrolling
* +1367 -473
#### 2014-10-29 Construction.
* Game
* Lua Input Event Listener
* Adding eagles from the script.
* Building now consumes build point.
* Adding Worker vessel and Stationary turret : Added brains and decision tree for them
* Adding Weapon Drill
* Added decision node : ConstructionNeededNode, IsCargoFullNode, GetAttakcedNode
* Added a process : BuildProcess
* UI
* Now default visibility is false.
* Added OnHide event
* Controlling visibility for individual components.
* Added UIProperty: INHERIT_VISIBLE_TRUE
* +1431 -147
#### 2014-10-30 Asteroid and Harvesting.
* Engine
* RayCast to meshes.
* Game
* Added MouseEvent and ShipEvent.
* Fixed mesh scaling bug.
* Added Asteroid.
* Harvesting.
* Added CargoComponent / CargoItem
* Added rotational acceleration concept.
* Tweaking FlockSimulation.
* Added object tooltip ui.
* +3134 -298
#### 2014-10-31 New version 2014 Oct released.
* Download and change log : https://github.com/fastbird/fastbirdEngine/releases
#### 2014-10-02 Researching...
* Concurrent programming
* Scripting/Moding.
#### 2014-10-03 Actor and Event system.
* Engine
* TryDeq() added to LockFreeQueue
* Game
* Adding Actor + ActorComponent system
* Added EventManager.
* Want to re-structure everything.... but let's postpone it for the second game. minimizing modifications.
* Researching
* Scripting / Modding.
* +1206, -29 cannot run.
#### 2014-10-05 Script system.
* Engine
* Added lua interactive mode for console - type '>>>' to enter lua mode and '<<<' for exit.
* Game
* Added ProcessManager
* pushing and popping custom types(like Vec3, std::string) from lua stack
* Events added. NewActor, DestroyActor and GameInitialized events
* Registering events to the scripts.
* Added ActorManager
* Adding ActorComponents - GameObjComponent, SpatialComponent and TargetingComponent.
* Defining Actor xml files and ship lua files.
* +1878, -176
#### 2014-10-06 ActorComponents
* Engine
* Added LuaObject which creates a copy from lua variables in the stack into the registry
* Added a generic function to call lua function.
* Game
* Completed script event system
* Added actor components
* SpatialComponent
* EngineComponent - for movement.
* CrewComponent
* ScriptComponent
* Adding actor components
* PlayerComponent
* ModularShipComponent
* +2057, -139
An actor can be defined in a xml file or a lua script. I think if I use a lua script to define an actor, the advantage is hot-reloading. Just change the lua script and run it again in runtime might be enough to apply the modification. xml also can be reloaded by responding file modification notice but additional storage could be required to hold the archetype data.
UI system also can be defined in a script. Maybe I don't need to write any cpp code for UIs, if I can retrieve all the information which UIs need to display.
#### 2014-10-07 Adding components
* Engine
* Added a few utility methods into LuaObject like IsTable() IsFloat(), GetFloat(), GetString()...
* Game
* Added components
* ModelComponent which handles visual stuff. - MeshObject, MeshGroup...
* SeatComponent which actors can seat. to bind crews and ship. Crew can be bound any actors that have this component.
* ShipComponent which hold a properties of a ship like HullPoint, DestroyEffect, Upkeep....
* Added GameStateEvent triggered when the game state is changed.
* More convinient way to generate events. - now one can create an event by EventName:Create(args...)
* Adding WeaponSystemComponent and WeaponComponent
* +2213, -296
#### 2014-10-08 WeaponSystem and Weapon Components.
* Engine
* Added Lua Sequence iterator
* fixed Vec3 push bug
* Displaying different prompt while in lua interaction mode.
* Game
* UI visibility control in lua
* Added WeaponSystemComponent and WeaponComponent
* Actor hierarchy
* Spatial Component hieraracy
* Added ActorLinkEvent
* +1346, -453
#### 2014-10-09 ModularShip Components
* Engine
* Retrieving Vec2 and Vec3 from LuaObject
* LuaWrapper is modified a little bit for debugging purpose.
* Collada importer's profiler got more informative output.
* Game
* Worked on ModularShipComponent and ModuleComponent
* Added ModularModelComponent which handles model representation of modular ships.
* WorldInitialization and moving spots via lua scripts
* Exporting Enum values to the script.
* Added whole components list text file to help writing actor scripts.
* +1228, -251, No memory leak
After changed to Actor-Component model, messaging between components became more important. For example I have SpatialComponent which handles transformation stuff and also I have ModelComponent taking responsibility to display visual models on the screen. Whenever transformation in Spatial component changed, the new transformation should be propagated to the ModelComponent. Since ModelComponent located in higher level project which are using the lower level project in where the SpatialComponent resides. Lower level projects can not reference higher level projects so messaging system is required to make the lower level project be independent to the higher one.
Currently I got three kinds of messaging system. The first one is for global events like 'level initialized', or 'game state changed'. This system also can send and receive events to and from the lua scripts.
The second messaging system is for inter-actor messaging. It dispatch a certain message with a target actor Id and delay time. This is good for delayed messaging since it always checks whether the target actor is available at the time the delayed message dispatched. But it has overhead of checking cost.
These two messaging system is not suitable for inter-projects communication. The first one is not for instance-instance communication and the second one cannot solve the inter-projects dependency problem.
So I was weighing other systems. The candidates were 'adopting UI event system for components' and 'Manual listener registration'. The first one may be good if I have a lot of events and the almost all components need to dispatch events. But it also has some overhead to search the map of event callback functions and evaluate function pointers from the function object.
In speaking of 'Manual listener registration' the most formidable advantage of it is speed. It will hold a listener function address directly so can call it with the minimum cost. In case of Spatial components, they dispatch a transform event almost every frame, in this scenario the speed is more important criterion. So, I'm thinking the second one might be better than the first one although I need to define Listener interfaces manually for every occasion when the components need to dispatch events.
#### 2014-10-11 applying original codes....
*Added evets
* ActorEvent, ModuleEvent, ItemEvent, ResourceEvent, WaveEvent
* Worked on Input Handler
* Added JumpDriverComponent.
* Modification original codes for new object model.
* +3579, -665
A lot of modifications for applying previous codes onto the new Actor-Component model. A lot more left. OTL
working order
* UIs - just make it compile
* Module manipulation
* FlockSimulation
* ShipMovement
* Jumping
* Removing original codes.
#### 2014-10-13 adopting original ui codes.
* Added lua quaternion
* Added effect manager
* Destroying ships using a Process(DestroyProcess)
* Portrait for ModelComponent
* Worked on CrewListUI, CrewUI, ModuleContextUI, ResourceUI, ShipListUI, ShipUI, SpecialModulesUI, StationContextUI
* Polished boarding
* Added PlayerEvent - construction started, processed, finished
* Construction codes move to ModularShip
* Added Shield component
* +2173 -672
#### 2014-10-14 UI.
* UI compilation done
* Model highlighting.
* Worked on MarkManager, MessageDispatcher.
* working on save/load
* +2180, -1454
#### 2014-10-15 shader cache
* Engine
* Added dist shader cache. - it boosts start up significantly.
* Added a simple FileSystem
* LuaObject bug fixes
* Game
* Loading using .lua - overriding original archetypes.
* Crew initialization
* Exporting class embeded enumeration to the script.
* +1304, -447, no memory leak.
 |
| Welcome back! It takes a lot of time to chage the game structure. It was a step backward that comes before taking two steps... |
#### 2014-10-16 AI base structure.
* Engine
* fixed lua stack error
* Added r_UseShaderCache and r_GenerateShaderCache commands.
* Game
* Assembling ModularShip, weapon attachment and upgrade.
* Module stock ui.
* Added ManufactureComponent, PowerComponent, ResearchComponent
* Added ScriptProcess, FighterBrain and States
* +1377 -388
#### 2014-10-17 EagleAi and Weapons.
* Game
* Reviving WeaponSystem - finding targets, tracking, firing, cosuming power.
* Moving eagles ai to the script
* worked on FighterAI.lua, FighterBrain_Player.lua, DecisionNodes.lua, CommonStates.lua, FighterStates.lua
* +1220 -293
There are two extream methods working with lua(or any scripting languages). The first one is that using it intensively so almost all codes reside in lua with this method. Good way to start using this method is that you just consider the cpp game codes as an interactive lua interpreter and game data visualization tool. On the other hand, in the second method the usage of the scripting is very minimized. You may ignore scripting system while you are developing your game until you find you find a portion of your codes that are changing very rapidly in short duration of time in the restrict part of your code. you can exports these part to lua to boost the development time.
Presumably somewhere middle of thease two extream method may be good, but need to be cautious that you may confuse which part of data or algorithm reside in scripting languge and which aren't when you taking this balanced method.
I'm taking the second extream method(not that extream but somewhat), but interested in the first extream method apart from the efficiency and performance. Just curious.
#### 2014-10-18 FighterBrain
* Game
* CreatActor function now receives direction and team information
* Pointers returned from / sent to a function are now StrongPtr.
* Almost all case we need to call lock() when using WeakPtr, so StrongPtr is more convenient.
* When the pointer need to be stored, usually using WeakPtr.
* Polishied EffectManager
* Worked on WeaponComponent
* Added AmmoComponent
* Added draft of experience graph(leveling)
* Added LaunchProcess which handles launching delay of eagles.
* Added serveral scripts interfaces for ships.
* Testing FighterBrain script.
* +1727 -582
#### 2014-10-20 fighter, bomber ai.
* formation
* fighter, bomber ai.
* +2020 -495
#### 2014-10-22 Rotating weapons, save/load via lua.
* Engine
* Added Lua debugging features. printing callstack, local variables.
* Lua security : redirecting io.open()
* Game
* save/load game data to/from lua table.
* changed 'for each' statements to 'for' statements
* Revived yaw-pitch seperated weapons.
* Random rotation for yaw-pitch seperated weapons to give an impression watching the enemies.
* Weapons consume power.
* Seperated actor storage for ammos. not to check collisions.
* fixed the case NaN value is generated in the flock simulation.
* Added 'RunAway' and 'Leave' states.
* +1574 -391
#### 2014-10-22 Line of sight, frigates, cruisers
* Engine
* Line rendering before the transparent pass
* Game
* Rendering line of sights of rotating weapons.
* Revived laser frigate and missile cruiser
* Added Cruiser.lua, CruiserBrain.lua, CruiserStates.lua
* Added Frigate.lua FrigateBrain.lua, FrigateStates.lua
* Added WeaponLaserFrigate.lua, WeaponRocketCruiser.lua
* Added AmmoLaserFrigate_1.lua, AmmoRocketCruiser_1.lua
* Revived space station
* +1509 -500
#### 2014-10-23 UI - Lua binding. Research UI.
* Engine
* Moved hot-reloading point to the end of frame.
* Adding multiline font rendering.
* Game
* Adding research ui.
* UI system
* Initializing UI and event handling with lua.
* Added TEXTURE_FILE, KEEP_IMAGE_RATIO ui properties.
* Added TextBox UI component.
* +848 -65
#### 2014-10-24 Research System
* Defined Research Items.
* Working on ResearchUI.
* +2638 -55
#### 2014-10-26 Research UI.
* Engine
* Multiline text rendering and aligning.
* Game
* Research UI.
* +1798, -816
#### 2014-10-27 ResearchUI and BuildUI
* Game
* Worked on Research UI.
* Working on Build UI.
* UI
* smooth scrolling
* +1367 -473
#### 2014-10-29 Construction.
* Game
* Lua Input Event Listener
* Adding eagles from the script.
* Building now consumes build point.
* Adding Worker vessel and Stationary turret : Added brains and decision tree for them
* Adding Weapon Drill
* Added decision node : ConstructionNeededNode, IsCargoFullNode, GetAttakcedNode
* Added a process : BuildProcess
* UI
* Now default visibility is false.
* Added OnHide event
* Controlling visibility for individual components.
* Added UIProperty: INHERIT_VISIBLE_TRUE
* +1431 -147
#### 2014-10-30 Asteroid and Harvesting.
* Engine
* RayCast to meshes.
* Game
* Added MouseEvent and ShipEvent.
* Fixed mesh scaling bug.
* Added Asteroid.
* Harvesting.
* Added CargoComponent / CargoItem
* Added rotational acceleration concept.
* Tweaking FlockSimulation.
* Added object tooltip ui.
* +3134 -298
Asteroids and Orbitting ships.
Space Atmosphere and HDR rendering
#### 2014-10-31 New version 2014 Oct released.
* Download and change log : https://github.com/fastbird/fastbirdEngine/releases
댓글
댓글 쓰기