2009-09-28 08:57:29 +00:00
|
|
|
notes:
|
|
|
|
|
|
|
|
|
|
* keeping with a view/logic separation, although this is quite different to
|
|
|
|
|
the hexagon game. the main advantages:
|
|
|
|
|
- just a divide and conquer strategy for staying sane
|
|
|
|
|
- able to debug the logic without the view, or vice versa
|
|
|
|
|
- the logic can be ticked at a lower frequency - or even different
|
|
|
|
|
parts at different rates, whereas the view needs ticking every frame
|
|
|
|
|
|
|
|
|
|
* need to try to keep all the intensive 'every thing vs every thing' checking
|
|
|
|
|
in the logic side, where it can be done over many frames (i'm thinking the
|
|
|
|
|
lags involved with things like nutrients getting absorbed may not matter
|
|
|
|
|
too much in this game)
|
|
|
|
|
|
|
|
|
|
* using a message passing system to formalise the passing of information on
|
|
|
|
|
the logic side. this makes it possible to have objects sending messages
|
|
|
|
|
at any point, and have them automatically collected up and dispatched to
|
|
|
|
|
the view
|
|
|
|
|
|
|
|
|
|
* these messages are also converted to xmpp messages and sent out over the
|
|
|
|
|
network
|
|
|
|
|
|
|
|
|
|
* line segments are computed in the logic side, and can be represented any
|
|
|
|
|
way by the view - maybe the players plant will be geometry and everyone
|
|
|
|
|
elses will be ribbons (stoopid LOD)
|
|
|
|
|
|
|
|
|
|
* in the same way, the line segments can be created in any way by the logic
|
|
|
|
|
side - eg. lsystem, or different methods per plant (or per twig even)
|
