This wiki has been moved to into the mediawiki branch.


From SuperTux
Revision as of 23:50, 4 April 2005 by Sik0fewl (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Milestone 2

Documents and ideas: Milestone 2 esp. Forest world


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?

Code Refactoring/Cleanup/Optimisation

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

Beyond Milestone2

  • 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.
C++ build/linux/src/bla.o
C++ build/linux/src/blup.o
C++ build/linux/src/error.o
Error on line xx in error.o: This source contained an error
g++ -Wall .... -o build/linux/src/error.o src/error.cpp