This wiki has been moved to into the mediawiki branch.

Difference between revisions of "Meeting 2010-02-27"

From SuperTux
Jump to: navigation, search
(Project management: Versioning schema)
m (Project management: markup)
Line 18: Line 18:
***: People listed at as "admins" can upload to BerliOS.
***: People listed at as "admins" can upload to BerliOS.
*** Update download page
*** Update download page
***: Probably sik0fewl
***: Probably ''sik0fewl''
*** Announce on '''' (Project there by AnMaster?)
*** Announce on '''' (Project there by AnMaster?)
***: ''AnMaster'' and ''WolfgangB''
***: ''AnMaster'' and ''WolfgangB''

Revision as of 08:33, 27 February 2010

The 2010-02-27 meeting was held on Saturday, February 27th at 15:00 UTC on IRC.

Present were:


Project management

  • (Unstable) Release - how?
    • octo has a release tarball that needs testing.
    • Tasks to be done (by who?):
      • Upload tarball to file server (BerliOS? Google? Lethargik?)
        People listed at as "admins" can upload to BerliOS.
      • Update download page
        Probably sik0fewl
      • Announce on (Project there by AnMaster?)
        AnMaster and WolfgangB
      • Announce on
        Can be done by everybody
      • Update bug tracker
        → octo'll do it
      • Binary packages?
        • According to WolfgangB, SuperTux did provide Linux autopackage and Windows binaries along the source tarballs.
        • Previous Windows binaries were built by "Delta" / "Sommer"
  • Last chance to change Versioning scheme
    • Nobody felt it necessary to discuss this again. Mathnerd314, who put it on the agenda, wasn't there anymore.
  • Next meeting date and time - every Saturday at 15:00 UTC?


  • Feedback for the Yeti level.
    • Postponed (again) because Mathnerd314 wasn't there.
  • New tiles from grumbel - which are useful?
    • grumbel: nightcave is good, the rest is crap
    • grumbel: Make "Crystal cave" into a background tileset
    • grumbel: the snowmountain stuff needs to be repainted
    • WolfgangB, octo: If tilesets should be removed, do this ASAP (before they are used in levels by 3rd parties)
  • Milestone 1-like worldmap - do now or later (which ideas to keep from the new one?)
    • "Now" meaning before the release?
    • octo has a version of the Milestone 1 worldmap in Milestone 2 syntax. Use that or work on the current version?
    • The worldmap has been changed just before the meeting (revision 6419) by Mathnerd314.
    • WolfgangB: in a stable release the worldmap should fit with the levels e.g. some mountains on the map for cave levels
  • Screw the forest? Keep for now? Don't delete ever?
    • Motion: Restore the Milestone 1 worldmap and add the intro and Yeti levels. There will be no passage to/from the Forest and the Forest / World 2 will be moved to contributed levels.
      • In favor: octo, grumbel
      • Opposed: nobody
      • No opinion: AnMaster
  • New names for badguys. Which to rename and (if applicable) which name to use?:
    AnMaster: in general I prefer the older names there. well, maybe not for "Kamikaze Snowball"
    WolfgangB: if grumbel thinks the badguys need new names do it
    octo: I don't like "Avior" nor "Dex". With the other names I don't have much preference
    grumbel: what we want is good and interesting names. finding them is the hard part
    MMlosh: The only change I agree with is Flying snowball rename. Snowshot is good, "Bouncy" has too strong association to java game shipped with nokia phones
    Avior and Dex are off the stove. Kamikaze Snowball will be renamed to Snowshot. The other names are postponed until later.

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)


To do.