super-tux-devel

[Super-tux-devel] SuperTux's future (that brilliant?)

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

Hello,

 While implementing a new bad guy, I could see how much the code sucks for 
extensability. Really, how do we expect to have scripting, lots of great 
enemies and scoped tiles, if all stuff is hard coded!
 It took me half an hour just to add a basic bad guy. Really, it was damn hard 
to found the right places in gameloop and level editor (and the names do not 
help at all). And it really pisses me off to see lots of hard coded values 
and duplicated code. Don't make me starting to talk about the readability of 
the code!

 Tobias told me in the IRC that he was not thinking about a C++ port. That was 
my last hope for a redesign of SuperTux and I really felt like abandoning the 
boat. Sure, SuperTux already uses a object oriented approach, but at what 
cost?
 There is a tentative to make Badguys and Player to share the same functions 
via Physics. In C++, a base class for both would clear the code.
 A lot of stuff would be so much easier to do in C++, just as managing tiles 
and eliminating duplications, for instance in Badguys code.

 I guess what I am trying to say is "does this worths it?". I mean, have a 
look at the code and say sincerely that he is flexible, extensible and easy 
to read.

 These months are crucial for SuperTux, if it doesn't improve it will probably 
die. I don't think there is anyone willing to start it over and over again. 
In my opinion, we should focus our attention in releasing the next version by 
putting the gameplay as it was before and adding a few levels. This way we 
will create a community of users and the motivation earned will be precious.
 Next thing, is to freeze the code and to do a section on the webpage for a 
redesign. Porting to c++, automatizing everything by the use of files, 
merging files, make decent names and indentation.

 To sum up, I don't really want to bash anyone's work and much less to make 
destructrive criticism, I'm just upset with the current situation and 
wouldn't like to pledge myself in a worthless project.

Take care,
 Ricardo Cruz

-- 
MMM-MM!!  So THIS is BIO-NEBULATION! 

Re: [Super-tux-devel] SuperTux's future (that brilliant?)

[Bill K. <nb...@so...>]

On Thu, Mar 11, 2004 at 03:35:57AM +0000, Ricardo Cruz wrote:
> These months are crucial for SuperTux, if it doesn't improve it will probably
> die.

Hehe, I think that's funny, since I wrote the original code in a few days
back in 2000, and it got resurrected now. :^P

;^)

-bill!

Re: [Super-tux-devel] SuperTux's future (that brilliant?)

[Ingo R. <gr...@gm...>]

Ricardo Cruz <ri...@ae...> writes:

>  While implementing a new bad guy, I could see how much the code
> sucks for extensability. Really, how do we expect to have scripting,
> lots of great enemies and scoped tiles, if all stuff is hard coded!

I don't think that scripting will ever be usefull for coding enemies.
Scripting can however be very usefull to customize enemies (change
there speed, etc.), but it becomes useless for coding them. After all
an enemy can do all kinds of weird things in the engine when required,
you can't get that from scripting unless you start to export every
damn little bit of the engine, but then you spend much more time with
wrappering than with scripting the enemies, so you'd better code them
in C in the first place. I think scripting will mainly be usefull for
custom events in the levels, ie. have dialog-boxed pop-up when the
enemy approaches, for scripting little in-game cut-scenes and such
stuff that can't be all that easily done in C and especially shouldn't
be done in C, since its artistic content and doesn't belong in the
core engine. 

>  It took me half an hour just to add a basic bad guy.

Half an hour doesn't sound that bad.

>  Tobias told me in the IRC that he was not thinking about a C++
> port.

At this current point it would really makes no sense to port to C++,
the engine is up an running (well, almost) and we should care about
content, levels and getting the gameplay right, not about which
languaged was used to implement the stuff.

> That was my last hope for a redesign of SuperTux and I really felt
> like abandoning the boat. 

After milestone1 we can do whatever we want, we can throw the whole
engine away and use wolfman8k's python engine or reuse the windstille
engine (which btw. is from a gameplay point of view far behind
Supertux) or recode supertux in C++ or whatever, but that is something
to decide after milestone1, not right now.

If somebody wants to just compile with C++ and use std::string instead
of frickling around with char* I am all for it, but that something
else then rewriting everything as classes.

>  These months are crucial for SuperTux, if it doesn't improve it
> will probably die. I don't think there is anyone willing to start it
> over and over again. In my opinion, we should focus our attention in
> releasing the next version by putting the gameplay as it was before
> and adding a few levels.

Yep, exactly, we should focus to get the basic gameplay right now, not
about how we can extent the engine with some super-duper-thingy which
I can't currently even think of. As far as it looks like for me at the
moment all enemies planed for Milestone1 should be doable with the
current engine, after all, most of them are pretty similar to the
current ones, just with little modifications in the behaviour and the
look. My only goal at the moment is to get milestone1 good enough, if
after that all people agree that the codebase is unusable for
extension we have to find a solution, but we aren't there yet, so we
should better stop discussion this and get back to work.

-- 
WWW:      http://pingus.seul.org/~grumbel/ 
JabberID: gr...@ja... 
ICQ:      59461927

Re: [Super-tux-devel] SuperTux's future (that brilliant?)

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

Em Quinta, 11 de Mar=E7o de 2004 09:51, o Ingo Ruhnke escreveu:
> Ricardo Cruz <ri...@ae...> writes:
> >  While implementing a new bad guy, I could see how much the code
> > sucks for extensability. Really, how do we expect to have scripting,
> > lots of great enemies and scoped tiles, if all stuff is hard coded!
>
> I don't think that scripting will ever be usefull for coding enemies.
> Scripting can however be very usefull to customize enemies (change
> there speed, etc.), but it becomes useless for coding them. After all
> an enemy can do all kinds of weird things in the engine when required,
> you can't get that from scripting unless you start to export every
> damn little bit of the engine, but then you spend much more time with
> wrappering than with scripting the enemies, so you'd better code them
> in C in the first place. I think scripting will mainly be usefull for
> custom events in the levels, ie. have dialog-boxed pop-up when the
> enemy approaches, for scripting little in-game cut-scenes and such
> stuff that can't be all that easily done in C and especially shouldn't
> be done in C, since its artistic content and doesn't belong in the
> core engine.
>

 I never meant to script the enemies, but you should edit only a couple of=
=20
file, instead of opening the all code.
 C'mon, there should be a define with the number of different enemies and t=
he=20
level editor should use that number to add them automatically. You should n=
ot=20
be forced to add a button for every of them.
 Their graphics should not be loaded in the middle of some other file... An=
d=20
they should have the info for the number of frames and size, instead of bei=
ng=20
everything hard coded.
 Also everything using ifs to see what enemy kind is it, is not a good=20
programming practice, cases are faster and cheaper, in code lines, i mean.

> >  It took me half an hour just to add a basic bad guy.
>
> Half an hour doesn't sound that bad.
>

 I mean, half an hour just to make a badguy's skeleton.

> >  Tobias told me in the IRC that he was not thinking about a C++
> > port.
>
> At this current point it would really makes no sense to port to C++,
> the engine is up an running (well, almost) and we should care about
> content, levels and getting the gameplay right, not about which
> languaged was used to implement the stuff.
>

 I just think that a C++ port would be a pretty banal thing to do, with the=
=20
only expense of time (not much if it was a team effort) and it would surely=
=20
improve the design overall.

> > That was my last hope for a redesign of SuperTux and I really felt
> > like abandoning the boat.
>
> After milestone1 we can do whatever we want, we can throw the whole
> engine away and use wolfman8k's python engine or reuse the windstille
> engine (which btw. is from a gameplay point of view far behind
> Supertux) or recode supertux in C++ or whatever, but that is something
> to decide after milestone1, not right now.
>
> If somebody wants to just compile with C++ and use std::string instead
> of frickling around with char* I am all for it, but that something
> else then rewriting everything as classes.
>

 Have a look at a few code, like the menu.*, and you'll notice that it=20
wouldn't be hard, in fact, you can currently kind of program like if it was=
=20
C++.
 But there a few things, especially code readability and interaction betwee=
n=20
objects, that would benefit much more from a C++ design.

> >  These months are crucial for SuperTux, if it doesn't improve it
> > will probably die. I don't think there is anyone willing to start it
> > over and over again. In my opinion, we should focus our attention in
> > releasing the next version by putting the gameplay as it was before
> > and adding a few levels.
>
> Yep, exactly, we should focus to get the basic gameplay right now, not
> about how we can extent the engine with some super-duper-thingy which
> I can't currently even think of. As far as it looks like for me at the
> moment all enemies planed for Milestone1 should be doable with the
> current engine, after all, most of them are pretty similar to the
> current ones, just with little modifications in the behaviour and the
> look. My only goal at the moment is to get milestone1 good enough, if
> after that all people agree that the codebase is unusable for
> extension we have to find a solution, but we aren't there yet, so we
> should better stop discussion this and get back to work.

 SuperTux is really polished right now; the menu is really shining, the lev=
el=20
editor works like a champ and we have two frontends.
 But this is a game and the fact is that the main game code has much less=20
quality than the rest.
 And I don't mean just that fps bug, have a look at the collision.c file, f=
or=20
instance. The test for checking if a player is bumping into a enemy is to=20
look if the Y speed velocity is superior to zero! This is obviously=20
non-sense, since you can be both falling and you just need to go into it. I=
=20
don't really know any better way, but I am sure there are, like having also=
=20
positions into consideration.

Ricardo Cruz


=2D-=20
Pretend to spank me -- I'm a pseudo-masochist!

Re: [Super-tux-devel] SuperTux's future (that brilliant?)

[Bill K. <nb...@so...>]

On Thu, Mar 11, 2004 at 12:43:11PM +0000, Ricardo Cruz wrote:
>  Also everything using ifs to see what enemy kind is it, is not a good 
> programming practice, cases are faster and cheaper, in code lines, i mean.

Function pointers are faster. ;^)
Maybe we should look into that?


-bill!

[Super-tux-devel] More amusing sketches.

[Christopher A. W. <cr...@li...>]

Nothing major, but you can see the progress I'm making on the wingling. 
There wasn't supposed to be this much work put into it, but apparently
there is :)  I'm making sure that the wings move smoothly.  The problem
with this is that the wings were not designed logically.... they
maintain an optical illusion of smoothness, but notice... you can't tell
if they're flat or thick in any area.  In fact, they are both at once.
The sane individual would just toss out the wings and redo them.  I'm
not sane.
Instead, I've developed a clever scheme on paper to figure out how I can
maintain this optical illusion and still make the wings flap in four
frames, as grumbel reccomended.  It's a bit like trying to rotate one of
Picasso's paintings, but I think I've gotten it to work.  You can look
at some of my sketches here:
http://www.lingocomic.com/gfx/goodies/supertux/wingling_concepts.xcf
Highlighted throughout all that is this really interesting skeletal
structure of the wingling.  Follows the wingling's design in everything
but the wings.
http://www.lingocomic.com/gfx/goodies/supertux/wingling_undead.png
The rest of the sprites I develop shouldn't take me nearly as long as
this one is.  Hope you enjoy!

Christopher Allan Webber


|
The bottom line