This wiki has been moved to https://github.com/SuperTux/wiki into the mediawiki branch.

Next Meeting Agenda

From SuperTux
Revision as of 18:18, 5 March 2010 by Octo (Talk | contribs)

Jump to: navigation, search

The next developer's meeting will (probably) be held on Saturday, March 6th 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

Attention: If you have anything to add, just click the "Edit" link and add some text

  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)
  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)