The next developer's meeting will (probably) be held on a Saturday 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.
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.
Attention: If you have anything to add, just click the "Edit" link and add some text
Next Meeting ?
There is most on the time someone on our IRC chanel on Freenode (#supertux) but it is easier to meet us on regular meeting, click following link to know when the next will take place:
- Who is making levels? Can they be improved enough to make main game levels?
- Haywire, Short Fuse, Owl, and SkyDive have been implemented by octo.
- Feedback from grumbel:
- Short fuse is good
- Haywire is missing some "umph", needs to be more crazy
- Owl should fly in a sinusoidal shape instead of straight
- Owl should slow before dropping so SkyDive flies straight down
- 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?
- 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
- Add non-hacky two player mode and remove supertux-coop patch
- Remove global variables that prevent this from happening
- Change references to lists
- 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, …)
- Suggestion: keep around lisp parse tree and use it to hold constants
- Switch to some physics engine?
- Features needed for everything to work:
- tilemaps (or a good broadphase and efficient collision data format)
- static constraint solver (so Tux doesn't get stuck on tile edges; problem in Box2D/Chipmunk)
- raycasting (ispy)
- kinematic objects (HitResponse FORCE_MOVE)
- AABB queries (Drawing to screen)
- custom collision callbacks/handlers/listeners/filters (all that collision code in MovingObject)
- wheel joints (bicycle platform, unused except for test levels)
- sliding joints (pneumatic platform, also only a test level)
- path constraints/motors (for moving tilemaps/platforms)
Scripting in level
- New scripts suggestions
- a script for active level
- a script for get position of Tux
- a script for get position of camera
- a script for set position of Tux
- a script for get/set tilemap tiles
- a script for get atributes of tilemap tiles
- a script which returns solid(unisolid) of target point
- a script for create object
- a script for delete object
- suggestion: defining of own objects without changing the source code of SuperTux