super-tux-devel — Development mailing list for Super Tux

Re: [Super-tux-devel] Re: Next version plans

[Ryan F. <rf...@gm...>]

On Wed, 12 May 2004 12:49:27 +0000, matr1x <ma...@sh...> wrote:
> 
> Since there seems to be a general "what should be and shouldn't be" in
> SuperTux milestone 2, I thought i'd add my 2 cents
> 
> I actually only noticed the change in supertux just this week, I'd played all
> the original Kendrick versions, and they were okay, but they didn't feel like
> anything more than a proof of concept.  I really like the change in
> direction, and hope I can contribute to it in some fashion.

Thanks, but next time you reply can you snip out all the other posts
from the digest :)

-- 
Ryan

[Super-tux-devel] Re: Next version plans

[matr1x <ma...@sh...>]

Since there seems to be a general "what should be and shouldn't be" in=20
SuperTux milestone 2, I thought i'd add my 2 cents

I actually only noticed the change in supertux just this week, I'd played a=
ll=20
the original Kendrick versions, and they were okay, but they didn't feel li=
ke=20
anything more than a proof of concept.  I really like the change in=20
direction, and hope I can contribute to it in some fashion.



> > over the webpage: http://super-tux.sourceforge.net/milestone2/index.html
> > ).
> >
> > * Vertical scrolling
> >
> >  Already made, there can be a bug here and there, but it is pretty good.
> >  Now, we only need to make the built-in level editor supporting it...
> > Does FlexLay already supports it?
> >
> > * Auto horizontal scrolling
> >
> >  I believe this is pretty stable by now.
> >  To enable it, just add the line to the level:
> >   (hor_autoscroll_speed 0.5)
> >  Being 0.5 the speed you wish. The velocity is in pixels per the number
> > of frames at defines.h.
> >
> > * Back scrolling
> >
> >  The camera stills needs work. It moves too fast in the beginning what =
is
> > really annoying and distracting.
> >  Anyway, you can already make levels supporting it by adding the
> > following line:
> >   (back_scrolling #t)
> > #t means true and #f false.
> >  Note that you also need to be in debug mode (supertux --debug-mode), in
> > order to enable it!
> >
> > * Smart camera
> >
> >  When the camera movement is improved, we can implement it to show more
> > stuff ahead Tux when he is running.
> >  It should also be possible for Tux to be stuff below and upper when
> > pressing in the Up and Down keys. This would also mean the use of anoth=
er
> > key for jumping.
> >
> > * Butt jump
> >
> >  Ryan already made a simple implementation of this. Currently it destro=
ys
> > the brick in the bottom after a jump and pressing both the Up and Down
> > keys. We still need graphics for it, and also to decide how it will be.=
 I
> > think it should be enabled by keep down pressing after a full jump and =
it
> > would also create a small earthquake in the ground killing enemies in a
> > short distance. Tux would also get stuck for 1.5 second.
> >
> > * Ice flower
> >
> >  In the end of the first world, Tux got the availability of the ice
> > flower...So, we should implement it.
> >  IMHO, it should be a straight fire and the enemy would froze for 3
> > seconds or so, Tux could then kill them or just run away.
> >  I think this should not affect ice enemies... I mean, they are already
> > frozen :D
> >
> >  The hard work will be the creation of graphics for the enemies...
> >
> > * 800x600 resolution
> >
> >  I really would like to go for it, but it would mean a lot of artwork.
> >  We could also just make use of a higher visible area...
> >
> > * Another world
> >
> >  I would go for an industrial world, as Marek suggested.
> >
> > * More bad guys
> >
> >  This is mostly artist work. Coding is pretty simple for this kinda of
> > stuff, graphics are the worse part.
> >
> >
> > Other nice stuff, not really necessary:
> > * Internationalization
> > * Info boxes, as those on Yoshi's and SM World.
> >
> >
> >  Harder work that should go for another release:
> > * sliding, this would be great;
> > * swimming;
> > * bosses;
> > * moving platforms;
> > * certainly there are thousands of other cool stuff.
> >
> >  I would like to see a few flamming about this :)
> >  At least, send a replay to say if you agree or don't.
> >
> > Ricardo Cruz
> >
> >
> > --
> > It's difficult to see the picture when you are inside the frame.
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Sleepycat Software
> > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> > deliver higher performing products faster, at low TCO.
> > http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3
> > _______________________________________________
> > Super-tux-devel mailing list
> > Sup...@li...
> > https://lists.sourceforge.net/lists/listinfo/super-tux-devel
>
> --__--__--
>
> Message: 2
> From: Tobias =3D?ISO-8859-1?Q?Gl=3DE4=3DDFer?=3D <tob...@gm...>
> To: sup...@li...
> Date: Wed, 12 May 2004 15:22:17 +0200
> Subject: [Super-tux-devel] SuperTux 0.1.1 packages
> Reply-To: sup...@li...
>
> Hi all,
>
> it would be great, if Debian, Mandrake, Redhat, SuSe
> and Gentoo (sorry if I forgot your favourite)
> fan boys, contributed properly packaged
> versions of SuperTux 0.1.1 to the project.
>
> Thanks in advance.
>
> Greetz...
>
> Tobias Gl=C3=A4=C3=9Fer
>
>
>
> --__--__--
>
> Message: 3
> Subject: Re: [Super-tux-devel] Next version plans
> From: Keir Lawson <ke...@th...>
> To: sup...@li...
> Date: Wed, 12 May 2004 15:01:51 +0100
> Reply-To: sup...@li...
>
> On Wed, 2004-05-12 at 13:36 +0100, Ricardo Cruz wrote:
> > Hey there,
> >
> >  I would like to discuss with you guys the plans for a future version.
> > Here goes my suggestions (highly influenced by those that Ingo described
> > over the webpage: http://super-tux.sourceforge.net/milestone2/index.html
> > ).
> >
> > * Vertical scrolling
> >
> >  Already made, there can be a bug here and there, but it is pretty good.
> >  Now, we only need to make the built-in level editor supporting it...
> > Does FlexLay already supports it?
> >
> > * Auto horizontal scrolling
> >
> >  I believe this is pretty stable by now.
> >  To enable it, just add the line to the level:
> >   (hor_autoscroll_speed 0.5)
> >  Being 0.5 the speed you wish. The velocity is in pixels per the number
> > of frames at defines.h.
> >
> > * Back scrolling
> >
> >  The camera stills needs work. It moves too fast in the beginning what =
is
> > really annoying and distracting.
> >  Anyway, you can already make levels supporting it by adding the
> > following line:
> >   (back_scrolling #t)
> > #t means true and #f false.
> >  Note that you also need to be in debug mode (supertux --debug-mode), in
> > order to enable it!
> >
> > * Smart camera
> >
> >  When the camera movement is improved, we can implement it to show more
> > stuff ahead Tux when he is running.
> >  It should also be possible for Tux to be stuff below and upper when
> > pressing in the Up and Down keys. This would also mean the use of anoth=
er
> > key for jumping.
> >
> > * Butt jump
> >
> >  Ryan already made a simple implementation of this. Currently it destro=
ys
> > the brick in the bottom after a jump and pressing both the Up and Down
> > keys. We still need graphics for it, and also to decide how it will be.=
 I
> > think it should be enabled by keep down pressing after a full jump and =
it
> > would also create a small earthquake in the ground killing enemies in a
> > short distance. Tux would also get stuck for 1.5 second.
> >
> > * Ice flower
> >
> >  In the end of the first world, Tux got the availability of the ice
> > flower...So, we should implement it.
> >  IMHO, it should be a straight fire and the enemy would froze for 3
> > seconds or so, Tux could then kill them or just run away.
> >  I think this should not affect ice enemies... I mean, they are already
> > frozen :D
> >
> >  The hard work will be the creation of graphics for the enemies...
> >
> > * 800x600 resolution
> >
> >  I really would like to go for it, but it would mean a lot of artwork.
> >  We could also just make use of a higher visible area...
> >
> > * Another world
> >
> >  I would go for an industrial world, as Marek suggested.
> >
> > * More bad guys
> >
> >  This is mostly artist work. Coding is pretty simple for this kinda of
> > stuff, graphics are the worse part.
> >
> >
> > Other nice stuff, not really necessary:
> > * Internationalization
> > * Info boxes, as those on Yoshi's and SM World.
> >
> >
> >  Harder work that should go for another release:
> > * sliding, this would be great;
> > * swimming;
> > * bosses;
> > * moving platforms;
> > * certainly there are thousands of other cool stuff.
> >
> >  I would like to see a few flamming about this :)
> >  At least, send a replay to say if you agree or don't.
> >
> > Ricardo Cruz
>
> something to add:
> visible checkpoints: so you actually know when youve passed them, also
> more of a bug but tux should fall down 1 blocks worth holes unless he is
> running, currently he can walk over them easily
>
> Keir Lawson
>
>
>
> --__--__--
>
> Message: 4
> From: Ricardo Cruz <ri...@ae...>
> To: sup...@li...
> Subject: Re: [Super-tux-devel] gettext, patch
> Date: Wed, 12 May 2004 15:25:08 +0100
> Reply-To: sup...@li...
>
>
> Hey Fred,
>
>  I18n support would be pretty cool, but I don't think your patch should be
> applied right now. First, we need to add support for accent letters or el=
se
> it would be useless for every European language...
>  Benjamin, could you work on that? :)
>  Anyway, I'll keep your patch and it will be used later.
>
>  And could you fix that VERSION thing, thx :)
>
> Ricardo Cruz
>
> Em Quarta, 12 de Maio de 2004 14:05, o Frederic Rodrigo escreveu:
> > Hi, happy SuperTux developer.
> >
> > I have done a patch to make ready the source to support gettext. I have
> > add all necessary "_()"; only on message for user (not error message for
> > developer).
> > In order to done this I have done some code modification
> > - edit the leveleditor.cpp to done help more easier to translate
> > - edit some use of VERSION in order to be translatable
> > To have gettext up, anyone can done the gettextize structure.
> >
> > An other thing, the VERSION macro is not fill. But used in the code:
> > for example "supertux --version" don't give the version.
> >
> >
> > Fred.
> > ---
> > http://f.rodrigo.free.fr/
>
> --
> Civilization is fun!  Anyway, it keeps me busy!!
>
>
> --__--__--
>
> Message: 5
> Date: Wed, 12 May 2004 09:07:23 -0600
> From: Ryan Flegel <rf...@gm...>
> To: sup...@li...
> Subject: Re: [Super-tux-devel] Next version plans
> Reply-To: sup...@li...
>
> On Wed, 12 May 2004 15:14:48 +0200, Tobias Gl=3DE4=3DDFer <tobi.web@gmx.d=
e>
> wro=3D
>
> te:
> > The 0.1.x series is for bugfixing only from now on.
> > The 0.2.x versions will be started now and are equivalent to the 0.0.x
> > series (which means, that new features are a top priority).
> > This efforts will result in the 0.3.x series aka 1.0.x.
>
> I like that idea, but it's too bad we can't have odd-numbered
> y-versions to be the experimental tree (like the Linux kernel). For
> example, the "1.0" release will actually be "1.1" when it's stable.
> Maybe we should jump a few numbers now (ie, skip 0.2.x)?
>
> --=3D20
> Ryan
>
>
> --__--__--
>
> Message: 6
> Date: Wed, 12 May 2004 09:15:12 -0600
> From: Ryan Flegel <rf...@gm...>
> To: sup...@li...
> Subject: Re: [Super-tux-devel] Next version plans
> Reply-To: sup...@li...
>
> On Wed, 12 May 2004 13:36:17 +0100, Ricardo Cruz <ri...@ae...> wrote:
> > * Back scrolling
> >
> >  The camera stills needs work. It moves too fast in the beginning what =
is
> > really annoying and distracting.
> >  Anyway, you can already make levels supporting it by adding the
> > following line:
> >   (back_scrolling #t)
> > #t means true and #f false.
> >  Note that you also need to be in debug mode (supertux --debug-mode), in
> > order to enable it!
>
> Actually, I changed that yesterday. The backscroll code is always used
> now so all you have to do is add (back_scrolling #t) to your level
> file to enable it. --debug-mode is no longer required.
>
> > * Butt jump
> >
> >  Ryan already made a simple implementation of this. Currently it destro=
ys
> > the brick in the bottom after a jump and pressing both the Up and Down
> > keys. We still need graphics for it, and also to decide how it will be.=
 I
> > think it should be enabled by keep down pressing after a full jump and =
it
> > would also create a small earthquake in the ground killing enemies in a
> > short distance. Tux would also get stuck for 1.5 second.
>
> Another result of the earthquake could be that the enemies get flipped
> upside down for X seconds (btw, this should probably make spikies
> vulnerable to jump attack). Tux wouldn't get stuck in this case.
>
> > * Ice flower
> >
> >  In the end of the first world, Tux got the availability of the ice
> > flower...So, we should implement it.
> >  IMHO, it should be a straight fire and the enemy would froze for 3
> > seconds or so, Tux could then kill them or just run away.
> >  I think this should not affect ice enemies... I mean, they are already
> > frozen :D
>
> I agree. The frozen enemies should also be kickable like MrIceBlocks.
>
> > * 800x600 resolution
> >
> >  I really would like to go for it, but it would mean a lot of artwork.
> >  We could also just make use of a higher visible area...
>
> Yeah, this would require a lot of work. I think from now one we should
> get 256x256 xcf files from graphic artists. This way we can always
> resize in the future.
>
> > * Another world
> >
> >  I would go for an industrial world, as Marek suggested.
>
> I would personally like to see an tropical forest-type world. It would
> be a nice change from all the snow :)
>
> >  Harder work that should go for another release:
> > * sliding, this would be great;
> > * swimming;
> > * bosses;
> > * moving platforms;
> > * certainly there are thousands of other cool stuff.
>
> I'd like to see moving platforms and bosses in this release.
>
> Another thing (maybe for future releases) is sublevels.
>
> --
> Ryan
>
>
> --__--__--
>
> Message: 7
> Date: Wed, 12 May 2004 18:19:52 +0200
> From: "Benjamin P. Jung" <bp...@gm...>
> To:  sup...@li...
> Subject: Re: [Super-tux-devel] gettext, patch
> Reply-To: sup...@li...
>
> Ricardo Cruz wrote:
> >Hey Fred,
> >
> > I18n support would be pretty cool, but I don't think your patch should =
be
> >applied right now. First, we need to add support for accent letters or
> > else it would be useless for every European language...
> > Benjamin, could you work on that? :)
>
> Sure!
> I don't think I'm going to extend the "old" ATARI style letters since
> that might get very compliated ... we'll see.
> My handwriting on the other hand should be easily extensible ... maybe
> not today but surely tomorrow or the
> day after tomorrow ... :-) Let you know when I can present you with
> first results...
> I'll be going ahead in usual ASCII order, right?
>
> btw,
> did you check-out my new squished flying snowball graphics?!?! -->
> http://www.phreakzone.com/tmp/index.html
> I also did a nice flying platform (yessss... I know: past Milestone2
> stuff it is) and two signs that could be useful for
> decorating levels.
>
>
>
>
> Benjamin
>
>
> --__--__--
>
> Message: 8
> From: Ricardo Cruz <ri...@ae...>
> To: sup...@li...
> Subject: Re: [Super-tux-devel] Next version plans
> Date: Wed, 12 May 2004 16:12:27 +0100
> Reply-To: sup...@li...
>
>
>  Please, don't compare the Linux development with the SuperTux one.
>  Besides, now without Ingo, our development speed would drop _a lot_!
>
>  Tobias, are you really considering releasing a 1.0, right after the 0.2?
>
> Ricardo Cruz
>
> Em Quarta, 12 de Maio de 2004 16:07, o Ryan Flegel escreveu:
> > On Wed, 12 May 2004 15:14:48 +0200, Tobias Gl=3DE4=3DDFer <tobi.web@gmx=
=2Ede>
> > w=3D
>
> rote:
> > > The 0.1.x series is for bugfixing only from now on.
> > > The 0.2.x versions will be started now and are equivalent to the 0.0.x
> > > series (which means, that new features are a top priority).
> > > This efforts will result in the 0.3.x series aka 1.0.x.
> >
> > I like that idea, but it's too bad we can't have odd-numbered
> > y-versions to be the experimental tree (like the Linux kernel). For
> > example, the "1.0" release will actually be "1.1" when it's stable.
> > Maybe we should jump a few numbers now (ie, skip 0.2.x)?
>
> =3D2D-=3D20
> Everyone is entitled to my opinion.
>
>
> --__--__--
>
> Message: 9
> From: Ricardo Cruz <ri...@ae...>
> To: sup...@li...
> Subject: Re: [Super-tux-devel] Next version plans
> Date: Wed, 12 May 2004 16:09:18 +0100
> Reply-To: sup...@li...
>
> Em Quarta, 12 de Maio de 2004 16:15, o Ryan Flegel escreveu:
> > On Wed, 12 May 2004 13:36:17 +0100, Ricardo Cruz <ri...@ae...> wrote:
> > > * Butt jump
> > >
> > >  Ryan already made a simple implementation of this. Currently it
> > > destroys the brick in the bottom after a jump and pressing both the Up
> > > and Down keys. We still need graphics for it, and also to decide how =
it
> > > will be. I think it should be enabled by keep down pressing after a
> > > full jump and it would also create a small earthquake in the ground
> > > killing enemies in a short distance. Tux would also get stuck for 1.5
> > > second.
> >
> > Another result of the earthquake could be that the enemies get flipped
> > upside down for X seconds (btw, this should probably make spikies
> > vulnerable to jump attack). Tux wouldn't get stuck in this case.
>
>  That's a good idea, but I think I would prefer the behavior i described:
> enemies in a short range would be killed and Tux would get stuck with the
> ass in the ground for a couple of seconds (there has to be a cons, right?=
).
>
> > > * Ice flower
> > >
> > >  In the end of the first world, Tux got the availability of the ice
> > > flower...So, we should implement it.
> > >  IMHO, it should be a straight fire and the enemy would froze for 3
> > > seconds or so, Tux could then kill them or just run away.
> > >  I think this should not affect ice enemies... I mean, they are alrea=
dy
> > > frozen :D
> >
> > I agree. The frozen enemies should also be kickable like MrIceBlocks.
>
>  That could be hard to implement. I suggest to make them just immune to i=
t.
>
> > > * 800x600 resolution
> > >
> > >  I really would like to go for it, but it would mean a lot of artwork.
> > >  We could also just make use of a higher visible area...
> >
> > Yeah, this would require a lot of work. I think from now one we should
> > get 256x256 xcf files from graphic artists. This way we can always
> > resize in the future.
>
>  That's just too much to ask...
>
>  Tobias, do you agree with this transition?
>  If yes, what would be better: resizing images (we would have to resize
> without interpolation and then polish them) or just enlarge the visible
> area?
>
> > > * Another world
> > >
> > >  I would go for an industrial world, as Marek suggested.
> >
> > I would personally like to see an tropical forest-type world. It would
> > be a nice change from all the snow :)
>
>  Maybe for a 3rd world... i vote for an industrial one.
>
> > >  Harder work that should go for another release:
> > > * sliding, this would be great;
> > > * swimming;
> > > * bosses;
> > > * moving platforms;
> > > * certainly there are thousands of other cool stuff.
> >
> > I'd like to see moving platforms and bosses in this release.
>
>  I don't see how we will be able to make it. i mean that would require so=
me
> sort of scripting.
>
> > Another thing (maybe for future releases) is sublevels.
>
>  Oh, i forgot that. Maybe we could implement that in time for the next
> release.
>
> Ricardo Cruz
>
> --
> Women sometimes forgive a man who forces the opportunity, but never a man
> who misses one.
> 		-- Charles De Talleyrand-Perigord
>
>
> --__--__--
>
> Message: 10
> Date: Wed, 12 May 2004 09:57:35 -0600
> From: Ryan Flegel <rf...@gm...>
> To: sup...@li...
> Subject: Re: [Super-tux-devel] gettext, patch
> Reply-To: sup...@li...
>
> On Wed, 12 May 2004 18:19:52 +0200, Benjamin P. Jung <bp...@gm...> wro=
te:
> > I don't think I'm going to extend the "old" ATARI style letters since
> > that might get very compliated ... we'll see.
>
> Yeah.. that might get really complicated. Maybe you could make a
> legible small handwritten font? :P I dunno..
>
> > My handwriting on the other hand should be easily extensible ... maybe
> > not today but surely tomorrow or the
> > day after tomorrow ... :-) Let you know when I can present you with
> > first results...
> > I'll be going ahead in usual ASCII order, right?
>
> Well, the accented chars are higher up in ASCII, but yeah. you might
> want to leave blank a few lines of uncessary chars.. or just remove
> those lines altogether.
>
> > btw,
> > did you check-out my new squished flying snowball graphics?!?! -->
>
> Sure did. Committed it to CVS.
>
> > I also did a nice flying platform (yessss... I know: past Milestone2
> > stuff it is) and two signs that could be useful for
> > decorating levels.
>
> I'd like to see the platforms in milestone2 myself.. we'll see.

Re: [Super-tux-devel] Next version plans

[Ryan F. <rf...@gm...>]

On Wed, 12 May 2004 19:22:46 +0200, Tobias Gl=E4=DFer <tob...@gm...> wro=
te:

> You have to admit, that this solution is way more inconsistent.
> Remember that 0.1.x is also odd numbered.

Yes, it's inconsistent with the past version numbers.

From your other email:
> > The 0.1.x series is for bugfixing only from now on.
> > The 0.2.x versions will be started now and are equivalent to the 0.0.x
> > series (which means, that new features are a top priority).
> > This efforts will result in the 0.3.x series aka 1.0.x.

I guess the point I'm trying to make is that when you get to 1.0.x the
feature releases will be odd numbered (opposite of the way it is now,
unless I'm missing something). So we should make the change now,
rather than later.

ie,

0.0.x -- feature/development releases
0.1.x -- feature freeze, butfixes only
0.2.x -- feature/development releases
1.0.x -- feature freeze, butfixes only
1.1.x -- feature/development releases

Notice that the y-version (x.y.z) changes from odd to even for feature
freeze releases. Maybe this doesn't matter to you, but I think it's
more confusing in the long run.

> Moreover I don't think discussions about version numbering are very
> helpful to our development.

Last email on the subject :)

--=20
Ryan

Re: [Super-tux-devel] Next version plans

[Marek <wa...@gm...>]

>>The ice power should freeze the spinning fireballs and hold them in 
>>place, so Tux can jump on them.
>>    
>>
>i think this would make ice power to powerfull, plus fire melts ice, ice
>doesnt freeze fire
>  
>

Who cares? Penguins don't shoot fireballs... :-)
Also, I don't think it would make ice too powerful. Remember, all icy 
enemies are immune to the ice weapon, and that includes most of our 
current badguys. Spinning fireballs aren't used very often (i.e. only in 
castles) so there aren't many of them anyway. But think of the ways you 
can use this feature; for example, you can build stairs out of frozen 
fireballs that lead to secret places...

    Marek

Re: [Super-tux-devel] Next version plans

[Tobias <tob...@gm...>]

Am Mi, den 12.05.2004 um 11:10 Uhr -0600 schrieb Ryan Flegel:
> On Wed, 12 May 2004 18:53:07 +0200, Tobias Gläßer <tob...@gm...> wrote:
> 
> > CVS is for all unstability you want. Just because 0.2.x will be a series
> > with added functionality it doesn't mean it will be unstable at all.
> 
> Okay, sounds like your mind is made up, but I'll continue my argument anyway :)
> 
> By "unstable" I don't mean crashing all the time, I mean the way 0.0.5
> and 0.0.6 were just progressions towards 0.1.0. I'm just saying that
> we should make 0.3.x releases the progressions towards 0.4.0.
> 
> In short:
>  - 0.1.2 would be a bugfix release for the 0.1.x series
>  - 0.3.x would be progressions towards 0.4.0 (in the same way 0.0.x
> progressed towards 0.1.0)
>  - 0.4.0 would be Milestone2
>  - 0.2.x would be skipped :)
> 
> -- 
> Ryan

You have to admit, that this solution is way more inconsistent.
Remember that 0.1.x is also odd numbered.

A jump to 0.3.x is neither justified nor does it improve the situation
in any way, because it is even more confusing.

Moreover I don't think discussions about version numbering are very
helpful to our development.

Greetz...

Tobias Gläßer (... notes that Linux had pretty much the same jump in its
infancy)

Re: [Super-tux-devel] Next version plans

[Keir L. <ke...@th...>]

On Wed, 2004-05-12 at 18:43 +0200, Marek wrote:
> >
> >
> >>>* Ice flower
> >>>
> >>> In the end of the first world, Tux got the availability of the ice
> >>>flower...So, we should implement it.
> >>> IMHO, it should be a straight fire and the enemy would froze for 3
> >>>seconds or so, Tux could then kill them or just run away.
> >>> I think this should not affect ice enemies... I mean, they are already
> >>>frozen :D
> >>>      
> >>>
> The ice power should freeze the spinning fireballs and hold them in 
> place, so Tux can jump on them.
i think this would make ice power to powerfull, plus fire melts ice, ice
doesnt freeze fire

Keir

Re: [Super-tux-devel] Next version plans

[Ryan F. <rf...@gm...>]

On Wed, 12 May 2004 18:53:07 +0200, Tobias Gl=E4=DFer <tob...@gm...> wro=
te:

> CVS is for all unstability you want. Just because 0.2.x will be a series
> with added functionality it doesn't mean it will be unstable at all.

Okay, sounds like your mind is made up, but I'll continue my argument anywa=
y :)

By "unstable" I don't mean crashing all the time, I mean the way 0.0.5
and 0.0.6 were just progressions towards 0.1.0. I'm just saying that
we should make 0.3.x releases the progressions towards 0.4.0.

In short:
 - 0.1.2 would be a bugfix release for the 0.1.x series
 - 0.3.x would be progressions towards 0.4.0 (in the same way 0.0.x
progressed towards 0.1.0)
 - 0.4.0 would be Milestone2
 - 0.2.x would be skipped :)

--=20
Ryan

Re: [Super-tux-devel] Next version plans

[Ricardo C. <ri...@ae...>]

 Ingo was only working for SuperTux during the GotM period, he is now moving 
for the Pingus project.
 Anyway, that doesn't mean that Ingo will not give a hand once in a while.

Ricardo Cruz

Em Quarta, 12 de Maio de 2004 17:24, o Keir Lawson escreveu:
> > >  Besides, now without Ingo, our development speed would drop _a lot_!
> >
> > You're right :/ But development speed doesn't really come into it.
>
> have i missed something? what happened to Ingo?
>
> Keir
>

-- 
QOTD:
	"It's a cold bowl of chili, when love don't work out."

Re: [Super-tux-devel] Next version plans

[Marek <wa...@gm...>]

>... For example, a
>half-implemented buttjump is in the code right now.
>
...which must not be included in any release version right now, because 
being able to butt-jump destroys some levels (literally, but also 
design-wise :) ). I also suggest that only big tux should be able to 
butt-jump (once he achieved that ability).

    Marek

Re: [Super-tux-devel] Next version plans

[Tobias <tob...@gm...>]

CVS is for all unstability you want. Just because 0.2.x will be a series
with added functionality it doesn't mean it will be unstable at all.

And by the 0.x.x we too signal, that we are in alpha status.
(Which means, that the game is feature incomplete)

Greetz...

Tobias Gläßer

Am Mi, den 12.05.2004 um 10:40 Uhr -0600 schrieb Ryan Flegel:
> On Wed, 12 May 2004 18:29:21 +0200, Tobias Gläßer <tob...@gm...> wrote:
> 
> > Hi,
> > 
> > there is no reason to copy the Kernel development concept.
> > The SuperTux concept worked well and will continue to work
> > well, just because we jump from 0.2.x to 1.0.x or 0.9(beta)
> > it doesn't mean that the achievements will be less or the
> > time to fullfill the aims will be shorter.
> 
> Yes, I know the version numbers are just numbers and don't mean
> more/less features. But that's the problem (very small problem,
> admittedly :), it would be less confusing this way, IMO. I think it
> would be convenient to adopt a versioning system like the linux kernel
> uses. It's almost exactly like the one you described, except it's
> predetermined that odd numbered branches are the unstable branches.
> 
> -- 
> Ryan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Super-tux-devel mailing list
> Sup...@li...
> https://lists.sourceforge.net/lists/listinfo/super-tux-devel
> 

Re: [Super-tux-devel] Next version plans

[Ryan F. <rf...@gm...>]

On Wed, 12 May 2004 17:24:59 +0100, Keir Lawson
<ke...@th...> wrote:

> have i missed something? what happened to Ingo?

He's moved on to the Pingus project (lemmings clone).

-- 
Ryan

Re: [Super-tux-devel] Next version plans

[Marek <wa...@gm...>]

>
>
>>>* Ice flower
>>>
>>> In the end of the first world, Tux got the availability of the ice
>>>flower...So, we should implement it.
>>> IMHO, it should be a straight fire and the enemy would froze for 3
>>>seconds or so, Tux could then kill them or just run away.
>>> I think this should not affect ice enemies... I mean, they are already
>>>frozen :D
>>>      
>>>
The ice power should freeze the spinning fireballs and hold them in 
place, so Tux can jump on them.

Re: [Super-tux-devel] Next version plans

[Ryan F. <rf...@gm...>]

On Wed, 12 May 2004 18:29:21 +0200, Tobias Gl=E4=DFer <tob...@gm...> wro=
te:

> Hi,
>=20
> there is no reason to copy the Kernel development concept.
> The SuperTux concept worked well and will continue to work
> well, just because we jump from 0.2.x to 1.0.x or 0.9(beta)
> it doesn't mean that the achievements will be less or the
> time to fullfill the aims will be shorter.

Yes, I know the version numbers are just numbers and don't mean
more/less features. But that's the problem (very small problem,
admittedly :), it would be less confusing this way, IMO. I think it
would be convenient to adopt a versioning system like the linux kernel
uses. It's almost exactly like the one you described, except it's
predetermined that odd numbered branches are the unstable branches.

--=20
Ryan

Re: [Super-tux-devel] Next version plans

[Keir L. <ke...@th...>]

On Wed, 2004-05-12 at 10:09 -0600, Ryan Flegel wrote:
> On Wed, 12 May 2004 16:12:27 +0100, Ricardo Cruz <ri...@ae...> wrote:
> 
> >  Please, don't compare the Linux development with the SuperTux one.
> 
> 
> I think comparing SuperTux kernel development is a great comparison.
> 
> Kernel: They release a stable version (even-numbered y-versionm, let's
> say 1.0.x) and then make any *necessary* patches/fixes on that branch.
> They then start a new unstable tree (1.1.x) where they add and test
> new features. When the unstable tree becoms stable and has the
> required features they release it as a stable release (1.2.x).
> Development then starts on 1.3.x and only necessary bugfixes are
> applied to 1.2.x.
> 
> SuperTux should work the exact same way. If we release a bugfix
> release for 0.1.1 we don't want it to have all of the buggy code that
> we've been adding for the milestone2 release. For example, a
> half-implemented buttjump is in the code right now. Another thing is
> "what is 0.1.2?" -- is it a bugfix release for 0.1.1 or is it SuperTux
> with the new features added? *We* don't even know yet (ok, we know now
> after tobgle's post).
> 
> >  Besides, now without Ingo, our development speed would drop _a lot_!
> 
> You're right :/ But development speed doesn't really come into it.
have i missed something? what happened to Ingo?

Keir

Re: [Super-tux-devel] Next version plans

[Tobias <tob...@gm...>]

Hi,

there is no reason to copy the Kernel development concept.
The SuperTux concept worked well and will continue to work
well, just because we jump from 0.2.x to 1.0.x or 0.9(beta)
it doesn't mean that the achievements will be less or the
time to fullfill the aims will be shorter.

Every release will continue to have high requirements in
new feature.

Greetz...

Tobias Gläßer

Am Mi, den 12.05.2004 um 10:09 Uhr -0600 schrieb Ryan Flegel:
> On Wed, 12 May 2004 16:12:27 +0100, Ricardo Cruz <ri...@ae...> wrote:
> 
> >  Please, don't compare the Linux development with the SuperTux one.
> 
> 
> I think comparing SuperTux kernel development is a great comparison.
> 
> Kernel: They release a stable version (even-numbered y-versionm, let's
> say 1.0.x) and then make any *necessary* patches/fixes on that branch.
> They then start a new unstable tree (1.1.x) where they add and test
> new features. When the unstable tree becoms stable and has the
> required features they release it as a stable release (1.2.x).
> Development then starts on 1.3.x and only necessary bugfixes are
> applied to 1.2.x.
> 
> SuperTux should work the exact same way. If we release a bugfix
> release for 0.1.1 we don't want it to have all of the buggy code that
> we've been adding for the milestone2 release. For example, a
> half-implemented buttjump is in the code right now. Another thing is
> "what is 0.1.2?" -- is it a bugfix release for 0.1.1 or is it SuperTux
> with the new features added? *We* don't even know yet (ok, we know now
> after tobgle's post).
> 
> >  Besides, now without Ingo, our development speed would drop _a lot_!
> 
> You're right :/ But development speed doesn't really come into it.
> 
> >  Tobias, are you really considering releasing a 1.0, right after the 0.2?
> 
> I think (hope?) that was a typo :P
> 
> -- 
> Ryan
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Super-tux-devel mailing list
> Sup...@li...
> https://lists.sourceforge.net/lists/listinfo/super-tux-devel
> 

Re: [Super-tux-devel] Next version plans

[Ryan F. <rf...@gm...>]

On Wed, 12 May 2004 16:12:27 +0100, Ricardo Cruz <ri...@ae...> wrote:

>  Please, don't compare the Linux development with the SuperTux one.


I think comparing SuperTux kernel development is a great comparison.

Kernel: They release a stable version (even-numbered y-versionm, let's
say 1.0.x) and then make any *necessary* patches/fixes on that branch.
They then start a new unstable tree (1.1.x) where they add and test
new features. When the unstable tree becoms stable and has the
required features they release it as a stable release (1.2.x).
Development then starts on 1.3.x and only necessary bugfixes are
applied to 1.2.x.

SuperTux should work the exact same way. If we release a bugfix
release for 0.1.1 we don't want it to have all of the buggy code that
we've been adding for the milestone2 release. For example, a
half-implemented buttjump is in the code right now. Another thing is
"what is 0.1.2?" -- is it a bugfix release for 0.1.1 or is it SuperTux
with the new features added? *We* don't even know yet (ok, we know now
after tobgle's post).

>  Besides, now without Ingo, our development speed would drop _a lot_!

You're right :/ But development speed doesn't really come into it.

>  Tobias, are you really considering releasing a 1.0, right after the 0.2?

I think (hope?) that was a typo :P

-- 
Ryan

Re: [Super-tux-devel] Programmation of video game

[Ricardo C. <ri...@ae...>]

 Technically, we use C++ as programming language, we might make use of some=
=20
scripting language in the future. SDL is what we use for dealing with the=20
window manager and events. We have two frontends: SDL and OpenGL.
 Our config files obey to the LISP syntax.

 I feel like writting the SuperTux history, so here it goes (someone put th=
is=20
to the homepage, correcting my mistakes before! :)):


 The whole thing started in 2000 when Bill Kendrick released the first game=
 of=20
what he designed to be a Super Mario Bros clone for the Linux platform.=20
Basically, the story was about Gwen (Tux's girlfriend) kidnap with a lot us=
e=20
of computer related environment.

 The game was quite enjoyable, but it was technically inflexible, especiall=
y=20
since Kendrick only had in mind a SM1 clone and a PDA version. Since Kendri=
ck=20
didn't have much more time to spent with it, he decided to open a sourcefor=
ge=20
project and ask for maintainers. This is where Tobias Gl=E4=DFer enters in =
the=20
story :)

 Tobias Gl=E4=DFer, our maintainer, started to re-write the whole game. Thi=
s=20
resulted in a 0.0.5 release and later in a 0.0.6 one.
 I entered in the SuperTux development after the 0.0.5 release. I really wo=
uld=20
like to see a good platform game available for linux, so I decided to=20
contribute to it. Since, the levels were all hand made, I started to develo=
p=20
a built-in level editor, that was shipped later within the 0.0.6 release.

 It was about this time, when Ingo Ruhnke started to get interested in this=
=20
project. I believe there is no need to write any introduction about this fr=
ee=20
software gaming community guru :).
 Anyway, Ingo Ruhnke had this idea about supporting a free game project eve=
ry=20
month, that would be the Game of the Month, that happens over the Linux Gam=
e=20
Tome forums website. Obviously, I would not mention it here, if SuperTux=20
wasn't elected has the very first GotM (Game of the Month).

 The development speed has highly increased since then, and so, there were =
a=20
few decisions that were settled; SuperTux would not try to mimic SMB and th=
e=20
computer theme would be dropped.
 After more than a month, we had a game with a totally different shape, bot=
h=20
internally and external. Internally, there was a C to C++ transition,=20
flexible config files and resources use, world map introduction and so on.=
=20
Externally, all the graphics were remake! There are only two words to=20
describe this success: Ingo Ruhnke :)

 Currently, we expect to make the scrolling more flexible, having camera=20
movement. Scripting and non-square tiles are something to be expected in th=
e=20
future.

=2D Ricardo Cruz


 Uff! Hhope you like it :)
(disclaimer: English is not my native language :D)

Ricardo


Em Quarta, 12 de Maio de 2004 12:38, o Theveneau Hadrien escreveu:
> Hello,
>
> How did you make this so good game? Have you got some guiles for the
> programming? and for use the SDL?
>
> Thanks you!
>
> Bye!
>
>

=2D-=20
It is illegal to say "Oh, Boy" in Jonesboro, Georgia.

Re: [Super-tux-devel] gettext, patch

[Ryan F. <rf...@gm...>]

On Wed, 12 May 2004 18:19:52 +0200, Benjamin P. Jung <bp...@gm...> wrote:

> I don't think I'm going to extend the "old" ATARI style letters since
> that might get very compliated ... we'll see.

Yeah.. that might get really complicated. Maybe you could make a
legible small handwritten font? :P I dunno..

> My handwriting on the other hand should be easily extensible ... maybe
> not today but surely tomorrow or the
> day after tomorrow ... :-) Let you know when I can present you with
> first results...
> I'll be going ahead in usual ASCII order, right?

Well, the accented chars are higher up in ASCII, but yeah. you might
want to leave blank a few lines of uncessary chars.. or just remove
those lines altogether.

> btw,
> did you check-out my new squished flying snowball graphics?!?! -->

Sure did. Committed it to CVS.

> I also did a nice flying platform (yessss... I know: past Milestone2
> stuff it is) and two signs that could be useful for
> decorating levels.

I'd like to see the platforms in milestone2 myself.. we'll see.

-- 
Ryan

Re: [Super-tux-devel] Next version plans

[Ricardo C. <ri...@ae...>]

Em Quarta, 12 de Maio de 2004 16:15, o Ryan Flegel escreveu:
> On Wed, 12 May 2004 13:36:17 +0100, Ricardo Cruz <ri...@ae...> wrote:
> > * Butt jump
> >
> >  Ryan already made a simple implementation of this. Currently it destroys
> > the brick in the bottom after a jump and pressing both the Up and Down
> > keys. We still need graphics for it, and also to decide how it will be. I
> > think it should be enabled by keep down pressing after a full jump and it
> > would also create a small earthquake in the ground killing enemies in a
> > short distance. Tux would also get stuck for 1.5 second.
>
> Another result of the earthquake could be that the enemies get flipped
> upside down for X seconds (btw, this should probably make spikies
> vulnerable to jump attack). Tux wouldn't get stuck in this case.
>
 That's a good idea, but I think I would prefer the behavior i described: 
enemies in a short range would be killed and Tux would get stuck with the ass 
in the ground for a couple of seconds (there has to be a cons, right?).

> > * Ice flower
> >
> >  In the end of the first world, Tux got the availability of the ice
> > flower...So, we should implement it.
> >  IMHO, it should be a straight fire and the enemy would froze for 3
> > seconds or so, Tux could then kill them or just run away.
> >  I think this should not affect ice enemies... I mean, they are already
> > frozen :D
>
> I agree. The frozen enemies should also be kickable like MrIceBlocks.
>
 That could be hard to implement. I suggest to make them just immune to it.

> > * 800x600 resolution
> >
> >  I really would like to go for it, but it would mean a lot of artwork.
> >  We could also just make use of a higher visible area...
>
> Yeah, this would require a lot of work. I think from now one we should
> get 256x256 xcf files from graphic artists. This way we can always
> resize in the future.
>
 That's just too much to ask...

 Tobias, do you agree with this transition?
 If yes, what would be better: resizing images (we would have to resize 
without interpolation and then polish them) or just enlarge the visible area?

> > * Another world
> >
> >  I would go for an industrial world, as Marek suggested.
>
> I would personally like to see an tropical forest-type world. It would
> be a nice change from all the snow :)
>
 Maybe for a 3rd world... i vote for an industrial one.

> >  Harder work that should go for another release:
> > * sliding, this would be great;
> > * swimming;
> > * bosses;
> > * moving platforms;
> > * certainly there are thousands of other cool stuff.
>
> I'd like to see moving platforms and bosses in this release.
>
 I don't see how we will be able to make it. i mean that would require some 
sort of scripting.

> Another thing (maybe for future releases) is sublevels.

 Oh, i forgot that. Maybe we could implement that in time for the next 
release.

Ricardo Cruz

-- 
Women sometimes forgive a man who forces the opportunity, but never a man
who misses one.
		-- Charles De Talleyrand-Perigord

Re: [Super-tux-devel] Next version plans

[Ricardo C. <ri...@ae...>]

 Please, don't compare the Linux development with the SuperTux one.
 Besides, now without Ingo, our development speed would drop _a lot_!

 Tobias, are you really considering releasing a 1.0, right after the 0.2?

Ricardo Cruz

Em Quarta, 12 de Maio de 2004 16:07, o Ryan Flegel escreveu:
> On Wed, 12 May 2004 15:14:48 +0200, Tobias Gl=E4=DFer <tob...@gm...> w=
rote:
> > The 0.1.x series is for bugfixing only from now on.
> > The 0.2.x versions will be started now and are equivalent to the 0.0.x
> > series (which means, that new features are a top priority).
> > This efforts will result in the 0.3.x series aka 1.0.x.
>
> I like that idea, but it's too bad we can't have odd-numbered
> y-versions to be the experimental tree (like the Linux kernel). For
> example, the "1.0" release will actually be "1.1" when it's stable.
> Maybe we should jump a few numbers now (ie, skip 0.2.x)?

=2D-=20
Everyone is entitled to my opinion.

Re: [Super-tux-devel] gettext, patch

[Benjamin P. J. <bp...@gm...>]

Ricardo Cruz wrote:

>Hey Fred,
>
> I18n support would be pretty cool, but I don't think your patch should be 
>applied right now. First, we need to add support for accent letters or else 
>it would be useless for every European language...
> Benjamin, could you work on that? :)
>  
>
Sure!
I don't think I'm going to extend the "old" ATARI style letters since 
that might get very compliated ... we'll see.
My handwriting on the other hand should be easily extensible ... maybe 
not today but surely tomorrow or the
day after tomorrow ... :-) Let you know when I can present you with 
first results...
I'll be going ahead in usual ASCII order, right?

btw,
did you check-out my new squished flying snowball graphics?!?! --> 
http://www.phreakzone.com/tmp/index.html
I also did a nice flying platform (yessss... I know: past Milestone2 
stuff it is) and two signs that could be useful for
decorating levels.




Benjamin

Re: [Super-tux-devel] Next version plans

[Ryan F. <rf...@gm...>]

On Wed, 12 May 2004 13:36:17 +0100, Ricardo Cruz <ri...@ae...> wrote:

> * Back scrolling
> 
>  The camera stills needs work. It moves too fast in the beginning what is
> really annoying and distracting.
>  Anyway, you can already make levels supporting it by adding the following
> line:
>   (back_scrolling #t)
> #t means true and #f false.
>  Note that you also need to be in debug mode (supertux --debug-mode), in order
> to enable it!

Actually, I changed that yesterday. The backscroll code is always used
now so all you have to do is add (back_scrolling #t) to your level
file to enable it. --debug-mode is no longer required.

> * Butt jump
> 
>  Ryan already made a simple implementation of this. Currently it destroys the
> brick in the bottom after a jump and pressing both the Up and Down keys.
>  We still need graphics for it, and also to decide how it will be. I think it
> should be enabled by keep down pressing after a full jump and it would also
> create a small earthquake in the ground killing enemies in a short distance.
> Tux would also get stuck for 1.5 second.

Another result of the earthquake could be that the enemies get flipped
upside down for X seconds (btw, this should probably make spikies
vulnerable to jump attack). Tux wouldn't get stuck in this case.

> * Ice flower
> 
>  In the end of the first world, Tux got the availability of the ice
> flower...So, we should implement it.
>  IMHO, it should be a straight fire and the enemy would froze for 3 seconds or
> so, Tux could then kill them or just run away.
>  I think this should not affect ice enemies... I mean, they are already
> frozen :D

I agree. The frozen enemies should also be kickable like MrIceBlocks.

> * 800x600 resolution
> 
>  I really would like to go for it, but it would mean a lot of artwork.
>  We could also just make use of a higher visible area...

Yeah, this would require a lot of work. I think from now one we should
get 256x256 xcf files from graphic artists. This way we can always
resize in the future.

> * Another world
> 
>  I would go for an industrial world, as Marek suggested.

I would personally like to see an tropical forest-type world. It would
be a nice change from all the snow :)

>  Harder work that should go for another release:
> * sliding, this would be great;
> * swimming;
> * bosses;
> * moving platforms;
> * certainly there are thousands of other cool stuff.

I'd like to see moving platforms and bosses in this release.

Another thing (maybe for future releases) is sublevels.

-- 
Ryan

Re: [Super-tux-devel] Next version plans

[Ryan F. <rf...@gm...>]

On Wed, 12 May 2004 15:14:48 +0200, Tobias Gl=E4=DFer <tob...@gm...> wro=
te:

> The 0.1.x series is for bugfixing only from now on.
> The 0.2.x versions will be started now and are equivalent to the 0.0.x
> series (which means, that new features are a top priority).
> This efforts will result in the 0.3.x series aka 1.0.x.

I like that idea, but it's too bad we can't have odd-numbered
y-versions to be the experimental tree (like the Linux kernel). For
example, the "1.0" release will actually be "1.1" when it's stable.
Maybe we should jump a few numbers now (ie, skip 0.2.x)?

--=20
Ryan

Re: [Super-tux-devel] gettext, patch

[Ricardo C. <ri...@ae...>]

Hey Fred,

 I18n support would be pretty cool, but I don't think your patch should be 
applied right now. First, we need to add support for accent letters or else 
it would be useless for every European language...
 Benjamin, could you work on that? :)
 Anyway, I'll keep your patch and it will be used later.

 And could you fix that VERSION thing, thx :)

Ricardo Cruz

Em Quarta, 12 de Maio de 2004 14:05, o Frederic Rodrigo escreveu:
> Hi, happy SuperTux developer.
>
> I have done a patch to make ready the source to support gettext. I have
> add all necessary "_()"; only on message for user (not error message for
> developer).
> In order to done this I have done some code modification
> - edit the leveleditor.cpp to done help more easier to translate
> - edit some use of VERSION in order to be translatable
> To have gettext up, anyone can done the gettextize structure.
>
> An other thing, the VERSION macro is not fill. But used in the code:
> for example "supertux --version" don't give the version.
>
>
> Fred.
> ---
> http://f.rodrigo.free.fr/

-- 
Civilization is fun!  Anyway, it keeps me busy!!

Re: [Super-tux-devel] Next version plans

[Keir L. <ke...@th...>]

On Wed, 2004-05-12 at 13:36 +0100, Ricardo Cruz wrote:
> Hey there,
> 
>  I would like to discuss with you guys the plans for a future version. Here 
> goes my suggestions (highly influenced by those that Ingo described over the 
> webpage: http://super-tux.sourceforge.net/milestone2/index.html ).
> 
> * Vertical scrolling
> 
>  Already made, there can be a bug here and there, but it is pretty good.
>  Now, we only need to make the built-in level editor supporting it... Does 
> FlexLay already supports it?
> 
> * Auto horizontal scrolling
> 
>  I believe this is pretty stable by now.
>  To enable it, just add the line to the level:
>   (hor_autoscroll_speed 0.5)
>  Being 0.5 the speed you wish. The velocity is in pixels per the number of 
> frames at defines.h.
> 
> * Back scrolling
> 
>  The camera stills needs work. It moves too fast in the beginning what is 
> really annoying and distracting.
>  Anyway, you can already make levels supporting it by adding the following 
> line:
>   (back_scrolling #t)
> #t means true and #f false.
>  Note that you also need to be in debug mode (supertux --debug-mode), in order 
> to enable it!
> 
> * Smart camera
> 
>  When the camera movement is improved, we can implement it to show more stuff 
> ahead Tux when he is running.
>  It should also be possible for Tux to be stuff below and upper when pressing 
> in the Up and Down keys. This would also mean the use of another key for 
> jumping.
> 
> * Butt jump
> 
>  Ryan already made a simple implementation of this. Currently it destroys the 
> brick in the bottom after a jump and pressing both the Up and Down keys.
>  We still need graphics for it, and also to decide how it will be. I think it 
> should be enabled by keep down pressing after a full jump and it would also 
> create a small earthquake in the ground killing enemies in a short distance. 
> Tux would also get stuck for 1.5 second.
> 
> * Ice flower
> 
>  In the end of the first world, Tux got the availability of the ice 
> flower...So, we should implement it.
>  IMHO, it should be a straight fire and the enemy would froze for 3 seconds or 
> so, Tux could then kill them or just run away.
>  I think this should not affect ice enemies... I mean, they are already 
> frozen :D
> 
>  The hard work will be the creation of graphics for the enemies... 
> 
> * 800x600 resolution
> 
>  I really would like to go for it, but it would mean a lot of artwork.
>  We could also just make use of a higher visible area...
> 
> * Another world
> 
>  I would go for an industrial world, as Marek suggested.
> 
> * More bad guys
> 
>  This is mostly artist work. Coding is pretty simple for this kinda of stuff, 
> graphics are the worse part.
>  
> 
> Other nice stuff, not really necessary:
> * Internationalization
> * Info boxes, as those on Yoshi's and SM World.
> 
> 
>  Harder work that should go for another release:
> * sliding, this would be great;
> * swimming;
> * bosses;
> * moving platforms;
> * certainly there are thousands of other cool stuff.
> 
>  I would like to see a few flamming about this :)
>  At least, send a replay to say if you agree or don't.
> 
> Ricardo Cruz
something to add:
visible checkpoints: so you actually know when youve passed them, also
more of a bug but tux should fall down 1 blocks worth holes unless he is
running, currently he can walk over them easily

Keir Lawson