Difference between revisions of "Next Meeting Agenda"

Revision as of 09:19, 6 March 2010

The next developer's meeting will (probably) be held on Saturday, March 6^th starting at 15:00 UCT. Anybody interested in SuperTux is invited to participate. The discussion will be held on IRC, network freenode, channel #supertux. Minutes of the meeting will be made available at Meeting 2010-03-06.

The following are topics we would like to discuss. Since it's possible that we cannot address all the below issues, we might postpone some issues for a later meeting.

Discussion

1. Project management
   • …
2. Gameplay
   • Badguys
     • Haywire has been implemented by octo. He'd like to get some feedback.
     • Basic Snowman code exists, but the body simply disappears after he's hit. A graphic of only his body is needed.
     • Krush (2x2 icecrusher) has been implemented. What about his big brother, Krosh? Which size? What graphics? (Resize existing graphics?)
     • What badguys to implement next?
   • Supertux Accessibility: is support for visually impaired gamers feasible?
     • How could such a support look like? Something like zooming the graphics so they are displayed larger? --octo 01:18, 6 March 2010 (UTC)
     • I guess this is about http://lists.lethargik.org/pipermail/supertux-devel-lethargik.org/2010-March/002847.html --Superdev 17:19, 6 March 2010 (UTC)
3. Source code
   • Split physics, drawing, etc. apart
     • Which design pattern to use?
   • Find some way to change object constants without recompiling (sprites, Yeti bounds, velocities of various things, …)
   • Proposal - merge src and data of objects/enemies together so that all content is in only a single folder (i.e., folder data/mrtree/ would contain mrtree.?pp, mrtree.sprite, mrtree.ogg, left-*.png, etc.)
     • Slightly harder to build and distribute packages (exclude *.?pp from data directory in binary builds)
     • Easier to take out/add objects, because there's less to keep track of
   • Switch to some physics engine?
     • Features needed for everything to work:
       1. tilemaps (or a good broadphase and efficient collision data format)
       2. static constraint solver (so Tux doesn't get stuck on tile edges; problem in Box2D/Chipmunk)
       3. raycasting (ispy)
       4. kinematic objects (HitResponse FORCE_MOVE)
       5. AABB queries (Drawing to screen)
       6. custom collision callbacks/handlers/listeners/filters (all that collision code in MovingObject)
       7. wheel joints (bicycle platform, unused except for test levels)
       8. sliding joints (pneumatic platform, also only a test level)
       9. path constraints/motors (for moving tilemaps/platforms)