teamhypersomnia / hypersomnia Goto Github PK

Create input functionality for Augmentations or provide entity system demo with one.

resource: http://www.gamedev.net/blog/355/entry-2250186-designing-a-robust-input-handling-system-for-games/
http://gamedev.stackexchange.com/questions/59582/input-management-techniques-in-large-games?lq=1
http://gamedev.stackexchange.com/questions/48315/game-state-and-input-handling-in-component-based-entity-systems
http://gamedev.stackexchange.com/questions/49119/input-handling-in-component-based-design

either luabind or own rolled bindings
http://purplepwny.com/blog/binding_lua_to_c_think_twice_before_eating_that_glue.html

blood, smoke which are just bodies on a different framebuffer with blur, wood parts etc

example: renderable* animation::frame::model -> sprite

remove virtuals that take type_pack as argument - it's inflexible and we can not even properly construct the components

also add an opportunity to construct components on adding - maybe placement new would solve the issue of construction/destruction

consider adding a virtual destructor to base component class - if its POD, compiler should optimize out vftables

should introduce interpolation if we're going to do networking and heavier physics

resources:
http://gamesfromwithin.com/casey-and-the-clearly-deterministic-contraptions

do future step instead of interpolating with previous state: (thought: could be additional component type "futurephysicsstate" or arrays of two elements and a function touching only one at a time)

take information on how to implement double states here:
http://gamesfromwithin.com/casey-and-the-clearly-deterministic-contraptions

probably another component "gun management" or so

also we don't need to use settransform - movement is simulated realistically and rotation does only affect sprite
rotated sprite should act as sensor for bullets

resources:
http://bitsquid.blogspot.com/2009/12/events.html
http://bitsquid.blogspot.com/2011/02/managing-decoupling-part-2-polling.html
http://gamedev.stackexchange.com/questions/1119/entity-communication-message-queue-vs-publish-subscribe-vs-signal-slots

or it will never finish and free the animation slot for lower priority animations (e.g. movement)!

resources:
http://bitsquid.blogspot.com/2011/02/some-systems-need-to-manipulate-objects.html
http://gamedev.stackexchange.com/questions/58693/assemblage-buckets-in-entity-systems

may be necessary for cases where we want to synchronize bullet's death event and receivers impulse from physics

Should add more functionality so the demo is more descriptive - probably high-level input, delta management.

either through callback_component with registering enums or std::function or scripting

will come in handy with stupid interactions like rotating an entity to face crosshair

renderable should have no member variables

http://www.dannybirch.com/simple-2d-lighting-system/
http://www.redblobgames.com/articles/visibility/

let it just live inside physics component

could be repaired by restraining frame rate or kind of distance-based speed, maybe clamping values

or just make damping more deterministic

for overriding simple messaging-necessary dependencies like lookats, chases, animation copying