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!