REPLY TO COMMENT


Leo Friend
What I'm doing and liking:
- not hardcoding resolution. So all graphic positioning is represented in floating point..
- easy regeneration of graphics. Using a 3d editor for each scene, with external references to all reused people\geometry. eg So you can change the way a town looks, and all the scenes that contain that town in the foreground or background, get regenerated.
- loosely coupling graphics to code. This way in the future you can change the amount of images in an animation, and your scripts will play the animation with same timing, but more frames.
- Do timing of animations in the gamescript.
- Declarative gamescript. This makes your scripts focus on what you want the character to do. And leave the engine (now or the future) to figure out the how.
- XML gamescript. This makes future porting, or rearchitecting, just a case of writing an XSLT.
- If you have a good editor, XML also means you can give your editor a schema, and it will give you intellisense for all the commands\elements  at your disposal.
- Using XML selectors for object-verb interactions so that your xml editor will detect things such as doubling up of an object-verb handler in a script.
- All script commands done as animations, so they have a temporal dimension if needed for sequentialization or parallization, and they all have a similar interface eg run\cancel\onComplete\onUpdate.
- have a very simple object model that the animations act on (eg scene is list of objects\ object is list of animations\animation is list of images)
- Unit test all animations, passing in the simple 'mock' object model, and test that the animation modifies the scene in the expected way, when its done - and sometimes when its running.
- Use C64 themes for all your editors, so you get that good simple feeling like in the old days :)