scrimpycat / commongamekit

A collection of utilities to aid in the creation of games

CommonGameKit

CommonGameKit is a collection of utilities to aid in the creation of games. While this is mostly for my own personal use, some of the things it provides are:

• Entity Component System (ECS)
  • Animation system
  • Input abstraction system
  • Rendering system
• Scripting language
• GUI
• Rendering abstraction interface (GFX)
  • OpenGL support
  • Metal support
• Asset manager
• Text rendering/manipulation

commongamekit's Issues

Make component register and lookup use dictionary

Use a dictionary for internal management of registered components.

Make component register create IDs at runtime

Let the system internally manage IDs instead of explicitly supplying them.

CCComponentRegister should now return the ID for the registered system.

Add deserializer for text blobs

Add a CCComponentExpressionArgumentType for handling (text: "") and ((text: "")) expressions. These should return a list of CCTextAttribute.

Document components

Add docs to components

• CCAnimationComponent
• CCAnimationInterpolateComponent
• CCAnimationKeyframeComponent
• CCInputMapComponent
• CCInputMapGroupComponent
• CC/inputMapControllerComponent
• CCInputMapControllerAxesComponent
• CCInputMapControllerButtonComponent
• CCInputMapKeyboardComponent
• CCInputMapMouseButtonComponent
• CCInputMapMouseDropComponent
• CCInputMapMousePositionComponent
• CCInputMapMouseScrollComponent
• CCRelationParentComponent
• CCSpatialTransformComponent

Make ECS data oriented

Current state of ECS was built around taking care of multi-threaded considerations. The data layout of the components was not focused on. Currently some degree of data orientedness could be achieved by providing specific allocators for the different components, however it will still result in sparse distribution of components (so a lot of cache misses).

Later the component layout should be restructured to be optimised for cache locality. Current idea is to probably have all components of a type laid out contiguously in memory, but because components can be added/removed, the array should support skip indices (and keep track of removed indices). More thought needs to be given to this, however it should perform much better.

Make system register create IDs at runtime

Let the system internally manage IDs instead of explicitly supplying them.

CCComponentSystemRegister should now return the ID for the registered system.

Consider changing add/remove locks in the ECS over to the lock-free queue

Once game is in a state that I can make meaningful profiling of realistic usage, see if changing the add/remove functionality in the ECS to a lock-free interface is more performant or not. Currently thinking it won't be (as locks are quite light wait, and I doubt enough threads would be trying to access it at the same time/doubt it'd be highly contested), but is worth a try.

ECS sync points

Add the concept of sync points to systems. These would allow for communication of specific data between systems to be optimised for delivery (compared to the lock-free messaging). E.g. The render system would depend on the new information from the update system. The sync point here would allow for the system to have the last copy of the state, while the update system is writing to the new state. The concept of sync points is essentially buffered data, where the the sync step simply needs to be an atomic operation to change which page has the newly written data (could either be an exchange or a counter/index).

Places this is most appropriate is for communication between update thread to render thread, and update thread to/from physics thread.