This wiki has been moved to https://github.com/SuperTux/wiki into the mediawiki branch.
High priority H: milestone goals that should be implemented for next milestone
Medium priority M: would be nice to have for next milestone, but should be secondary to high priority goals
Low priority L: things that should be fixed sometime
?: Things that need to be discussed to determine whether or not they should be implemented
Collision detection rewrite
- implement ability to cary mriceblock (and other objects) around - delayed for after big commit...
- smoke clouds are too fast
- rethink slopes collision feedback... tux becomes too slow when walking up and starts jumping when walking down
- think about an attachement mechanism for moving platforms
- implement paths for the moving platform, implement simple moving platforms
- fix bullet speed/behaviour
- check if unducking is actually possible or if something is in the way
- what to do when stuck under tiles (after using duck-sliding)
- do we want multi hit scores again?
- H: make the title using GameSession instead of reimplementing all the stuff
- L: rename gameloop. files to gamesession.
- L: rename GameObject::action to GameObject::update()
- L: use physfs for loading files
- L: change physics class y-velocity-coordinate to be like all other y-coordinates again (positive y to go down)
- L: rename files like tile_manage.* to TileManager.* because they contain a class named TileManager not tile_manager. Eventually use .hpp instead of .h to indicate the usage of c++
- M: harmonize to 1 single gameloop that switches between title, worldmap, ingame mode and eventually leveleditor mode
- M: Make the gamelogic run in a fixed logical framerate
- M: (or H:?) implement quadtree or grid to speedup collision detection
- M: Use refcounting for GameObjects and implement a remove_listener function, so that you can keep track when GameObject get added/removed to the Sector. (refcounting is needed here, otherwise we'll get into trouble when 1 of the listener objects dies before it gets notificated). Unregistering in the destructor would be an alternative solution but an error prone one.
- H: Buttjump:
- enable buttjump again
- Should kill enemies with a certain range (Done--now needs to be tweaked - Eventually we only want to "stun" the enemies...)
- Animation (need images)
- Should be available when tux is big
- Should break bricks if Tux is on top of bricks.
- H: Flapping:
- should be modeled after Yoshi's Island flapping
- Try if it is good that you can reach highe places with flapping
- We need animations
- H: Blowflyer
- Should be temporarily there for a single sector. Or timeout after tux gained it.
- We don't know yet how tux could gain that ability. Probably some non-movable objects in the level. (helium bottles were rejected, should be something more "abstract")
- H: Bring back stay on platform flag
- H: Reimplement fish
- H: Do something with the wingling
- ?: Do something with the tree?
- H: Create a "sound object" that is an object or area, that can be placed on the map and constantly plays a .wav file to improve game athmosphere. Good examples would be a water sound which can be placed at waterfalls, a kuckoo sound that can be placed into the wood, bubling sound for lava... The sound object should be configurable:
- To be position independent (always play);
- to have a spot position so that it gets louder when tux gets nearer to the spot (or a rectangular area instead of the spot?).
- You should be able to configure the sound to be constantly looped or to be played in some random fashion (ie. play and then 5-10 seconds pause).
- H: Create a "sign" object, ie an object that can be placed on the level and contains messages (like the run sign we have at the moment but programmatically created so that we can translate it)
- H: Add a simple rock object that can be carried around
- H: Add a rope object on which tux is able to climb, also add a ? block that emits a rope when hit
- H: redo trampolines
- ?: think about how to implement scripting, and how to make a simple and easy to use api for the scripting interface
- language will probably be lua - just have to figure out how well we can do without OO support in the scripting language. Other candidates are python, squirrel, ruby and less likely java, mono/.net, surely no own invention, perl or 1 of these c-like scripting languages
- ?: Think about icebullet specifics
- M: Save score on per-level basis to make high-score
- M: Save time on per-level basis to make low-time-score
- M: Add bonus score for extra time left when finishing a level
- L: when bumping a special with 2 blocks at once, it won't change direction
- L: tux get killed if he kicks a iceblock while at the same time bouncing on
- L: The camera does some nasty little jumps if you jumped up on a higher place where the camera didn't completely follow yet and you fall down directly again. This will suddenly raise the camera up.
- L: Allow any object to be inside of a [?] box, ie. trampoline or badguy. Not sure if this would be gameplay wise.
- L: There is a report that the joypad is always used on windows and more severe it generates random up/down events, though it is callibrated correctly.
- H: Graphics+Animations for the Yeti (see also http://netpanzer.berlios.de/supertux/index.php/Yeti)
- H: Graphics for the 5 keys in the forest world, graphics for the castle door with 5 key holes
- H: New tiles for the forest worldmap
- H: Create a graphics to visually present reset points. (Maybe a bell that starts swinging once tux touched it?)
- M: Add graphics for ropes
- L: Create graphics for bubbles and soap (not necessary for milestone2)
new enemies need to be designed and added
- More things than just levels on the worldmap (similar to SMB3)
- if we have a logical framerate we could record/play demos by simply storing the pressed keys in each frame... *
We can just stay with jam for now. Compared to scons jam is at least faster and doesn't suffer from the problems below.
- H: Add an install target - done (however scons is creating stupid .sconsign files at the install location :-/, see SConsignFile for possible fix)
- M: improve opengl check to work on win32 and eventually more strange systems again
- H: Make sure compilation on win32 and cross-compilation works
- M: compile some test executables to test for SDL, SDL_mixer and SDL_image. Also test for version of SDL_mixer and SDL_image
- M: Create a distclean target
- M: Create a dist target
- M: Add instructions to the README
- L: If all of the H and M issues are fixed, remove autoconf/automake
- L: Take a look if it is possible to make it a bit more quiet. (Similar to linux kernel, samba or jam output would be optimum, ie.
Error on line xx in error.o: This source contained an error
g++ -Wall .... -o build/linux/src/error.o src/error.cpp