super-tux-devel Mailing List for Super Tux (Page 91)
Brought to you by:
wkendrick
Menu
▾
▴
super-tux-devel — Development mailing list for Super Tux
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(237) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(150) |
Feb
(100) |
Mar
(276) |
Apr
(355) |
May
(749) |
Jun
(302) |
Jul
(240) |
Aug
(463) |
Sep
(171) |
Oct
(148) |
Nov
(169) |
Dec
(74) |
| 2005 |
Jan
(77) |
Feb
(85) |
Mar
(90) |
Apr
(74) |
May
(49) |
Jun
(7) |
Jul
(7) |
Aug
(2) |
Sep
(2) |
Oct
(4) |
Nov
(6) |
Dec
(8) |
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(5) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2009 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ingo R. <gr...@gm...> - 2004-05-14 14:01:25
|
Keir Lawson <ke...@th...> writes: > i dont think having a bunch of cave levels in a row is the problem, > after all this kind of makes sense, Just because it 'makes sense' doesn't mean its fun, actually the inverse is pretty much true most of the time. > i think whats needed is more variety within those levels (movig > plaforms, more badguys etc) While more varity helps of course, it are still all cave levels and that just gets pretty boring, after all they all play and look almost the same, while snow levels play quite a bit different, since they are open, no roof to bounce against. Just shuffeling the cave levels with the snow one alone would already provide a reasonably amount of more varity. Doing that with more tiles, more enemies, etc. would of course also be possible, but it would be a whole lot more work to get even close to the added varity one gets by just mixing the levels. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Keir L. <ke...@th...> - 2004-05-14 13:46:32
|
On Fri, 2004-05-14 at 15:16 +0200, Ingo Ruhnke wrote:
> Marek <wa...@gm...> writes:
>
> > From a level designer's point of view, these should be the next steps
> > in development:
> >
> > 1) Choose a theme for world 2 (I suggest a factory/industrial theme)
>
> I would go for forest theme.
i agree
> > 3) Build lots of levels
>
> First we would need to have a set of features that would be present in
> Milestone2, for example if we get sliding, level design might differ a
> lot, same with moving platforms or other kinds of special items. There
> is also the question of which items should be introduced in which
> level and such, in Milestone1 this was a bit to random.
>
> Another thing to keep in mind, one of the most frequent critic on
> Milestone1 was the lack of varity and I think its a very valid critic.
> For example having all cave levels in a row was really not such a good
> idea, it should have been more mixed, bridge levels might have been
> better placed at the transition points from one mini-island to the
> other, instead of all at the end of the world and such. There was also
> a lot of misuse of tiles in the first milestone1, foreground tiles in
> the background and such which could be solved a lot better.
>
> Last not least there are stuff like sublevels and secrets which needs
> to be better integrated into the game, instead of more or less
> randomly thrown at the player ('woo, a bug, I can walk in this
> wall...').
i dont think having a bunch of cave levels in a row is the problem,
after all this kind of makes sense, i think whats needed is more variety
within those levels (movig plaforms, more badguys etc)
Keir
|
|
From: Ingo R. <gr...@gm...> - 2004-05-14 13:23:10
|
Ryan Flegel <rf...@gm...> writes: > I'd like to someow merge all GameObject's into a single list (or something) > > I hate seeing stuff like this: /me too Biggest problem with merging them is that the drawing order will break completly, one can now try to fix it back up by sorting the list of GameObjects, but I have found that quite throublesome in the long run (ie. it doesn't work with objects that have to be both in the foreground and background like the iglo, so if you have to break it apart to mulitple objects and such). Clean solution would be to either switch to OpenGL only and use the z-buffer for the sorting of the drawing or to create a 'GraphicContext' class that records all drawing operations and sorts them before evaluting them, instead of having Surface class directly call SDL_Blit(). -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Ingo R. <gr...@gm...> - 2004-05-14 13:16:42
|
Marek <wa...@gm...> writes:
> From a level designer's point of view, these should be the next steps
> in development:
>
> 1) Choose a theme for world 2 (I suggest a factory/industrial theme)
I would go for forest theme.
> 2) Create tilesets
Having a list of needed tiles would help here.
> 3) Build lots of levels
First we would need to have a set of features that would be present in
Milestone2, for example if we get sliding, level design might differ a
lot, same with moving platforms or other kinds of special items. There
is also the question of which items should be introduced in which
level and such, in Milestone1 this was a bit to random.
Another thing to keep in mind, one of the most frequent critic on
Milestone1 was the lack of varity and I think its a very valid critic.
For example having all cave levels in a row was really not such a good
idea, it should have been more mixed, bridge levels might have been
better placed at the transition points from one mini-island to the
other, instead of all at the end of the world and such. There was also
a lot of misuse of tiles in the first milestone1, foreground tiles in
the background and such which could be solved a lot better.
Last not least there are stuff like sublevels and secrets which needs
to be better integrated into the game, instead of more or less
randomly thrown at the player ('woo, a bug, I can walk in this
wall...').
I would also prefer to reduce the number of levels in the next
Milestone, 26 levels with not much varity where a bit to much, would
have been better to have less, but better tested/polished levels. The
rest of the levels could then just go to Cntrib.
Just for the record, frequent IRC user will already know these artical
about Game Design, however still a good read for the rest:
http://www.greggman.com/pages/game.htm
http://web.archive.org/web/20001001040632/www.obsession.se/balance/intro.html
--
WWW: http://pingus.seul.org/~grumbel/
JabberID: gr...@ja...
ICQ: 59461927
|
|
From: Marek <wa...@gm...> - 2004-05-14 11:38:56
|
Hi Guys!
I'm feeling a little unemployed right now... I tried to work on new
music, but I need a break on that to get new inspiration.
From a level designer's point of view, these should be the next steps
in development:
1) Choose a theme for world 2 (I suggest a factory/industrial theme)
2) Create tilesets
3) Build lots of levels
4) Add level features to the engine
5) Goto 3) :-)
I uploaded a new song you can use for inspiration on tilesets/themes.
Unfortunately, I suck at creating tiles. :)
Marek
|
|
From: Ingo R. <gr...@gm...> - 2004-05-14 11:09:31
|
"Benjamin P. Jung" <bp...@gm...> writes: > I really think that Tux's jump behavior must be changed ... it's > annoying to see Tux fall into death just because one pressed the > jump-button to early while still in mid-air. Double jumps are nearly > impossible with the current implementation and I really think that > It'd be more intuitive to have back the old bahavior where you could > make Tux "prepare" for his 2nd jump when pressing jump ANYTIME > during his 1st jump. *NO* jump'n run game I know does it that way and I find that behaviour extremly weird and unresponive (after all you can press the button a long time before the jump really happens). Increasing the tile-threshold or doing it with a timer instead might be a good thing, but return to this 'press button whenever you want' would pretty much ruin the game. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Ryan F. <rf...@gm...> - 2004-05-14 10:09:41
|
On Fri, 14 May 2004 13:06:06 +0200, Benjamin P. Jung <bp...@gm...> wrote: > > Hi all, > > I really think that Tux's jump behavior must be changed ... it's > annoying to see Tux fall into death just because one pressed the > jump-button to early while still in mid-air. Double jumps are nearly > impossible with the current implementation and I really think that It'd > be more intuitive to have back the old bahavior where you could make Tux > "prepare" for his 2nd jump when pressing jump ANYTIME during his 1st jump. > > What do you think? I think the same thing :) I'm now used to the current jumping style, but it still annoys me with the way the jump behaviour works right now. Even though I'm now used to it I still get caught sometimes and die because if it. "Jump" shouldn't be very complicated to use. Also, my sister had the same complaint. I'm for changing back to the way Benjamin desribed. -- Ryan |
|
From: Benjamin P. J. <bp...@gm...> - 2004-05-14 10:03:20
|
Hi all, I really think that Tux's jump behavior must be changed ... it's annoying to see Tux fall into death just because one pressed the jump-button to early while still in mid-air. Double jumps are nearly impossible with the current implementation and I really think that It'd be more intuitive to have back the old bahavior where you could make Tux "prepare" for his 2nd jump when pressing jump ANYTIME during his 1st jump. What do you think? Benjamin |
|
From: Ryan F. <rf...@gm...> - 2004-05-14 09:54:16
|
On Fri, 14 May 2004 11:47:02 +0200, Moritz Muehlenhoff <jm...@in...> wrote: > Ah, okay, I missed that one. In that case it's better to ignore mine > and wait for the one uploaded to master to propagate to sid. I'll > use my packages privately :-) Ah, okay. Thanks anyway :) -- Ryan |
|
From: Moritz M. <jm...@in...> - 2004-05-14 09:46:06
|
Ryan Flegel wrote:
> I'm not exactly sure but I think supertux has already been uploaded to
> Debian. I'm not exactly sure how Debian works, but here is a
> transcript from #supertux:
Ah, okay, I missed that one. In that case it's better to ignore mine
and wait for the one uploaded to master to propagate to sid. I'll
use my packages privately :-)
Cheers,
Moritz
|
|
From: Ryan F. <rf...@gm...> - 2004-05-14 09:32:25
|
On Fri, 14 May 2004 11:16:17 +0200, Moritz Muehlenhoff <jm...@in...> wrote: > > Hi, > great game. I've built Debian packages, which I'll try to get > in the main archive soon. They can be fetched from: > http://www.informatik.uni-bremen.de/~jmm/debian/ > > They are built for the current Debian development version, but > I can build packages for current stable as well. Oops.. hit send too soon. We'll add the debian packages to SF (well, tobgle will). I dunno.. what *should* they be built for? I don't use Debian. -- Ryan |
|
From: Ryan F. <rf...@gm...> - 2004-05-14 09:29:27
|
On Fri, 14 May 2004 11:16:17 +0200, Moritz Muehlenhoff <jm...@in...> wrote: > > Hi, > great game. I've built Debian packages, which I'll try to get > in the main archive soon. They can be fetched from: > http://www.informatik.uni-bremen.de/~jmm/debian/ > > They are built for the current Debian development version, but > I can build packages for current stable as well. Hey, I'm not exactly sure but I think supertux has already been uploaded to Debian. I'm not exactly sure how Debian works, but here is a transcript from #supertux: May 12 11:00:47 <tarzeau> hehe supertux got uploaded May 12 11:00:56 <tarzeau> it needs manual something until it appears in sid though... May 12 11:01:10 <tarzeau> i can work on the new release meanwhile May 12 11:01:17 <sik0fewl> tarzeau: uploaded where May 12 11:01:25 <tarzeau> to debian May 12 11:01:50 <litespeed> tarzeau: wow! :-) May 12 11:01:55 <tarzeau> that means it appears someday in buildd.debian.org and is tried built on all archs debian sup -- Ryan |
|
From: Moritz M. <jm...@in...> - 2004-05-14 09:15:25
|
Hi, great game. I've built Debian packages, which I'll try to get in the main archive soon. They can be fetched from: http://www.informatik.uni-bremen.de/~jmm/debian/ They are built for the current Debian development version, but I can build packages for current stable as well. Cheers, Moritz |
|
From: Ryan F. <rf...@gm...> - 2004-05-14 06:50:10
|
> > They look good, but they are not repetitive. So, could you fix that? > > > > Ricardo Cruz > > yep. working on it. thats the hard part :) A tip (if you don't already know it): In gimp; Image->Transforms->Offset... Offset x,y by x/2, y/2 and make sure "wrap around" is selected. You should be able to see the advantage here. All outside pixels match up and you now just have to fix the middle cross. -- Ryan |
|
From: matr1x <ma...@sh...> - 2004-05-14 06:34:37
|
On May 14, 2004 03:19 am, sup...@li... wro= te: > Content-Type=3Dmessage/rfc822 > Content-Description=3Dembedded message > From: Ricardo Cruz <ri...@ae...> > To: sup...@li... > Subject: Re: [Super-tux-devel] made some tiles > Date: Thu, 13 May 2004 10:17:05 +0100 > Reply-To: sup...@li... > > > =A0They look good, but they are not repetitive. So, could you fix that? > > Ricardo Cruz yep. working on it. thats the hard part :) |
|
From: Ryan F. <rf...@gm...> - 2004-05-14 05:29:41
|
On Thu, 13 May 2004 18:15:30 -0700, Nathan McCoy <nm...@oz...> wrote: > > I've created some new sounds, based on the current ones. It's not a huge > improvement, but I prefer them to the others. We still need some good > power-up sounds, though. Hey, thanks. I committed your sounds to CVS for everybody to try out. - I didn't hear much difference between the fall.wav's. - In shoot.wav there is a small, noticable difference. I think I like the old one better, hard to say. - I really like the one-up (lifeup.wav) sound, good job. - I like the coin sound (distro.wav) sound, too. Do you think you could make it a touch quieter/softer. It seems to be a little louder than the other sfx. Yeah, powerup sounds would be nice. We need to get rid of that gargling sound :) "Excellent!" is pretty funny though. -- Ryan |
|
From: Nathan M. <nm...@oz...> - 2004-05-14 04:59:31
|
Ryan Flegel wrote: >On Thu, 13 May 2004 18:15:30 -0700, Nathan McCoy <nm...@oz...> wrote: > > > >>I've created some new sounds, based on the current ones. It's not a huge >>improvement, but I prefer them to the others. We still need some good >>power-up sounds, though. >> >> > >Great. Could you post a URL to the sounds? > > > I intended to, but hit Send too soon. http://www.oz.net/~nmccoy/newsounds.zip |
|
From: Ryan F. <rf...@gm...> - 2004-05-14 04:45:50
|
Just curious.. why did we remove the --disable-sound option that was in 0.0.6? -- Ryan |
|
From: Ryan F. <rf...@gm...> - 2004-05-14 04:30:34
|
On Thu, 13 May 2004 23:37:56 -0400, Michael George <mi...@ge...> wrote: > | I think inheriting could get kinda messy.. who knows. > > Inheriting in this scheme would be dead simple. Start with a copy of > the parent and just replace the new fields. Yeah, I suppose. > | > | As for movement, I was thinking it would be nice if it could actually > | be *scripted* in the badguy/object defnition file. It would handle the > | basic things like velocity, direction, collisions, flying, not walking > | off platforms, etc. > | > > While scripting would be cool, I really can't think of how it can be > done without exposing a lot of the internal code to the scripting > language. Yeah, you're probably right. > Also, in this scheme we would encapsulate the movement behaviors on the > C++ which would make it easy to create new ones (albeit not as easy as > scripting) Good point. > I think moving platforms are more amenable to scripting (as opposed to > just mixing pre-defined behaviors) than the bad guys, but at any rate I > think it would be a weird abstraction to try and mix the two. I agree > that it would be good to have scripted game objects though. Well, it's *not* weird abstraction to mix the two though :) Internally, all objects inherit from the GameObject class, this includes the player, badguys, powerups, etc. Maybe a good (great?) way to do it would be to have predetermined movements like you mentioned. Later on, if we wanted to, we could add a "custom" movement-style which would then read a script. > | You should stop by #supertux on irc.freenode.net. I'm there now > | (sik0fewl) and probably will for most of the day. > | > > Sorry that I didn't make it. No problem. But just so you know I'll probably be there for several more hours. No class tomorrow :P -- Ryan |
|
From: Michael G. <mi...@ge...> - 2004-05-14 03:38:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ryan Flegel wrote: - ---snip--- | | I think inheriting could get kinda messy.. who knows. Inheriting in this scheme would be dead simple. Start with a copy of the parent and just replace the new fields. | | As for movement, I was thinking it would be nice if it could actually | be *scripted* in the badguy/object defnition file. It would handle the | basic things like velocity, direction, collisions, flying, not walking | off platforms, etc. | While scripting would be cool, I really can't think of how it can be done without exposing a lot of the internal code to the scripting language. That's why I feel like exposing a pre-defined set of actions would be ideal - it's the KISS principle. Also, in this scheme we would encapsulate the movement behaviors on the C++ which would make it easy to create new ones (albeit not as easy as scripting) | Probably don't need editor-picture. I agree | | |>Anyway, let me know if you think this is worthwhile and I'll code up an |>implementation. | | | I think something like this is definitely worth while, but I think we | should figure out the specifics first. Also, if it's done this way, | things like moving platforms (and future objects) would have object | files just like these badguy files. | I think moving platforms are more amenable to scripting (as opposed to just mixing pre-defined behaviors) than the bad guys, but at any rate I think it would be a weird abstraction to try and mix the two. I agree that it would be good to have scripted game objects though. | You should stop by #supertux on irc.freenode.net. I'm there now | (sik0fewl) and probably will for most of the day. | Sorry that I didn't make it. - --Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFApD8TrJDiig1GCW0RAsj3AKCHBaauTSLtqLQAtp4UYkcfXT5XLwCdF/vw Z0CtzgVrbRNMaE8lZKxD9XY= =AMH6 -----END PGP SIGNATURE----- |
|
From: Ryan F. <rf...@gm...> - 2004-05-14 02:58:29
|
Tobias, Here are a couple packages to add to SF. Autopackage: http://bylands.dur.ac.uk/~mh/supertux-0.1.1.package - Submitted by Mike Hearn http://www.cpsc.ucalgary.ca/~fuhrer/supertux/supertuxOSX.tar.gz - Submitted by yosemite - (not uploaded yet as of this posting) -- Ryan |
|
From: Ryan F. <rf...@gm...> - 2004-05-14 02:10:08
|
On Thu, 13 May 2004 18:15:30 -0700, Nathan McCoy <nm...@oz...> wrote: > I've created some new sounds, based on the current ones. It's not a huge > improvement, but I prefer them to the others. We still need some good > power-up sounds, though. Great. Could you post a URL to the sounds? -- Ryan |
|
From: Nathan M. <nm...@oz...> - 2004-05-14 01:15:42
|
I've created some new sounds, based on the current ones. It's not a huge improvement, but I prefer them to the others. We still need some good power-up sounds, though. |
|
From: Ryan F. <rf...@gm...> - 2004-05-13 21:25:33
|
Hi all, MrIceBlock now breaks bricks when he is kicked into them. Go to the Gradient test level to try it out. -- Ryan |
|
From: Ryan F. <rf...@gm...> - 2004-05-13 20:15:03
|
Hi,
I'd like to someow merge all GameObject's into a single list (or something)
I hate seeing stuff like this:
//---------------------------------------------------
/* (Bouncy bricks): */
for (unsigned int i = 0; i < bouncy_bricks.size(); ++i)
bouncy_bricks[i]->draw();
for (BadGuys::iterator i = bad_guys.begin(); i != bad_guys.end(); ++i)
(*i)->draw();
tux.draw();
for (unsigned int i = 0; i < bullets.size(); ++i)
bullets[i].draw();
for (unsigned int i = 0; i < floating_scores.size(); ++i)
floating_scores[i]->draw();
for (unsigned int i = 0; i < upgrades.size(); ++i)
upgrades[i].draw();
for (unsigned int i = 0; i < bouncy_distros.size(); ++i)
bouncy_distros[i]->draw();
for (unsigned int i = 0; i < broken_bricks.size(); ++i)
broken_bricks[i]->draw();
//---------------------------------------------------
And there is similar things for action(), etc. It makes it annoying
and messy to add new objects (ie, moving platforms). In the future,
when/if objects become more scriptable this may have to be changed
anyway.
Anyways, suggestions/comments?
--
Ryan
|
84 messages has been excluded from this view by a project administrator.
