tuxkart-devel — TuxKart Developers.

Re: [TuxKart-devel] Some crude Kart sketches

[Charles G. <ch...@ve...>]

On Fri, 2004-07-02 at 02:02 +0200, Ingo Ruhnke wrote:
> Ingo Ruhnke <gr...@gm...> writes:
> 
> > Some more:
> 
> http://pingus.seul.org/~grumbel/tmp/eviltux.jpg
> http://pingus.seul.org/~grumbel/tmp/eviltux2.jpg
> http://pingus.seul.org/~grumbel/tmp/eviltux2.blend

You rock Ingo.  Da grumbel is in da house!  Nice work.
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

Re: [TuxKart-devel] Some crude Kart sketches

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

Ingo Ruhnke <gr...@gm...> writes:

> Some more:

http://pingus.seul.org/~grumbel/tmp/eviltux.jpg
http://pingus.seul.org/~grumbel/tmp/eviltux2.jpg
http://pingus.seul.org/~grumbel/tmp/eviltux2.blend

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

Re: [TuxKart-devel] Some crude Kart sketches

[Steve B. <sjb...@ai...>]

Charles Goodwin wrote:

> It's starting to look good.  You say 'Barney' but there has to be a
> cartoon element in the character.  I look forward to seeing the textured
> result which should drop the Barneyness.

Yes. I agree.

Barney is very 'smooth' - having some scaleyness and more colour variation
will help that a lot.

> I still think he'd look better with his tail sticking out behind the
> kart, with the posture either sat down (feet forward, tail backward) or
> lying frontways (feet and tail out behind).

Hmmm - maybe something more like a 'quad bike' that he can sit astride
with his tail able to swish back and forth to splatter people who get too
close behind him.

It's hard to imagine a T-Rex lying down - so sitting upright makes more
sense - but anything stuck behind his butt will obstruct his tail - so
something like a bike saddle is needed - then we don't want two wheeled
bikes because this is a karting game - but a quad bike would fit all those
constraints nicely.

> But then again I'm not the one creating the model.

Indeed.  Ideas are cheap - building models a good as the ones we've seen
takes lots of effort and talent,

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [TuxKart-devel] GUI

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

Em Quarta, 30 de Junho de 2004 21:56, o Ryan Flegel escreveu:
> Just wanted to point out some obvious(?) advantages to SWS approach.
>
> * With the SWS approach we can have previews of what each character
> and each track looks like before choosing. This would be a total mess
> using the MWS approach.

 The only disadvantage a MWS approach would have in that case is that one 
would have to design it before implementing it. Else, yes, it could be a 
mess.

> * For things like multiplayer character select it will be really messy
> having 4 people choose their characters on a screen with all sorts of
> other options there. With the SWS approach we have a nice, intuitive
> way for all players to select their characters.

 It isn't 8 or 80. We can still have a dialog that would allow players to 
change a few stuff, choosing them by turns.

> * After a race is complete, usually the only thing that you want to
> change is the track. While this can still easily be done with the MWS
> approach, it confronts the users with a lot of unecessary options.

 The track change would only happen in the Practice mode. In any other, it 
should only show statistics, and maybe allowing the player to abort.

Ricardo

-- 
You will become rich and famous unless you don't.

Re: [TuxKart-devel] GUI

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

On Wed, 30 Jun 2004 23:13:15 -0500, Steve Baker <sjb...@ai...> wrote:
> 
> Ryan Flegel wrote:
> > Just wanted to point out some obvious(?) advantages to SWS approach.
> >
> > * With the SWS approach we can have previews of what each character
> > and each track looks like before choosing. This would be a total mess
> > using the MWS approach.
> 
> Why?  A scrolling list of tracks or character is easy to do - and common
> even in console games.  I don't see where it's a mess.

it's only a mess if we try to give graphical previews of what each
character/track looks like. This is a really nice option to have,
especially when choosing multiplayer characters (see below).

> > * After a race is complete, usually the only thing that you want to
> > change is the track.
> 
> Again, why?  MWS makes it easy to change any, all or none of those things
> and be back playing again in one more mouse click.  SWS utterly sucks
> if you want to change more than the obvious one or two things the game
> designer THOUGHT you wanted to change.

Yes, you *can* change all those things, but there's no point in
confronting the player with all those options.

> > While this can still easily be done with the MWS
> > approach, it confronts the users with a lot of unecessary options.
> 
> I don't see that's a problem.  If the options are not something
> you want to change, don't change them and they'll be the same they
> were last time you played.

As Ingo pointed out, not all options belong to all the different
playable modes. On top of that, it's still not necessary to confront
the users with all of these options.

I do realize that these arguments aren't hardcore evidence of the way
the menu should be laid out. However, I do believe this(SWS) is the
most *intuitive* way to do the menu, and that it simply doesn't make
sense to use the MWS approach, especially in the case of character
choosing for multiplayer--it becomes a real mess with multiplayer.

-- 
Ryan

Re: [TuxKart-devel] GUI

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

Steve Baker <sjb...@ai...> writes:

> Again, why?  MWS makes it easy to change any, all or none of those things
> and be back playing again in one more mouse click.  SWS utterly sucks
> if you want to change more than the obvious one or two things the game
> designer THOUGHT you wanted to change.

My biggest problem with MWS is that I have no freaking idea how it
should work. If you have TimeTrial, GrandPrix and QuickRace and a
whole bunch of multiplayer modes you have only very few options that
overlap each and every mode and a whole bunch of others that are mode
specific. How do you deal with that, constantly disable/enable,
hide/unhide a bunch of GUI widgets, wouldn't that completly confuse
players?

The other issue is with multiplayer, I want to select my kart myself,
I don't want to talk to the guy at the mouse to select the right one
for me. MWS would really slow this down a lot, compared to SWS where
everybody could select their own kart in paralell.

Even every PC game I know does SWS for character, track selection and
such. 

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

Re: [TuxKart-devel] Some crude Kart sketches

[Charles G. <ch...@ve...>]

On Wed, 2004-06-30 at 23:15 -0500, Steve Baker wrote:
> > http://pingus.seul.org/~grumbel/tmp/dino8.jpg
> > http://pingus.seul.org/~grumbel/tmp/dinoview.jpg
> 
> He needs teeth - he's coming off a bit 'Barney'!
> 
> A lot of the subtelty of a Dinosaur like this one comes
> out around the eyes.  It's going to be hard to tell what
> he'll come out like until he's textured.

It's starting to look good.  You say 'Barney' but there has to be a
cartoon element in the character.  I look forward to seeing the textured
result which should drop the Barneyness.

I still think he'd look better with his tail sticking out behind the
kart, with the posture either sat down (feet forward, tail backward) or
lying frontways (feet and tail out behind).  That could actually make
things look really interesting with a spikey spine, a tail and big
clawed feet waving out the back of the kart.

But then again I'm not the one creating the model.
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

Re: [TuxKart-devel] GUI

[Charles G. <ch...@ve...>]

On Wed, 2004-06-30 at 23:17 -0500, Steve Baker wrote:
> Charles Goodwin wrote:
> > * People expect the SWS approach with games, and will find the MWS
> > approach alien and hence ungame-like.
> 
> These are not console users.  They aren't people of subnormal intellect.
> These are Linux desktop users. Geez!

I hope you're being sarcastic.  It's exactly that attitude that keeps
Linux desktop users being people who do not have "subnormal intellect".
Personally I prefer the term "uneducated with computers".
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

Re: [TuxKart-devel] GUI

[Steve B. <sjb...@ai...>]

Charles Goodwin wrote:

> * People expect the SWS approach with games, and will find the MWS
> approach alien and hence ungame-like.

These are not console users.  They aren't people of subnormal intellect.
These are Linux desktop users. Geez!

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [TuxKart-devel] Some crude Kart sketches

[Steve B. <sjb...@ai...>]

Ingo Ruhnke wrote:
> Ingo Ruhnke <gr...@gm...> writes:

> http://pingus.seul.org/~grumbel/tmp/dino8.jpg
> http://pingus.seul.org/~grumbel/tmp/dinoview.jpg

He needs teeth - he's coming off a bit 'Barney'!

A lot of the subtelty of a Dinosaur like this one comes
out around the eyes.  It's going to be hard to tell what
he'll come out like until he's textured.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [TuxKart-devel] GUI

[Steve B. <sjb...@ai...>]

Ryan Flegel wrote:
> Just wanted to point out some obvious(?) advantages to SWS approach.
> 
> * With the SWS approach we can have previews of what each character
> and each track looks like before choosing. This would be a total mess
> using the MWS approach.

Why?  A scrolling list of tracks or character is easy to do - and common
even in console games.  I don't see where it's a mess.

> * After a race is complete, usually the only thing that you want to
> change is the track.

Again, why?  MWS makes it easy to change any, all or none of those things
and be back playing again in one more mouse click.  SWS utterly sucks
if you want to change more than the obvious one or two things the game
designer THOUGHT you wanted to change.

> While this can still easily be done with the MWS
> approach, it confronts the users with a lot of unecessary options.

I don't see that's a problem.  If the options are not something
you want to change, don't change them and they'll be the same they
were last time you played.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [TuxKart-devel] GUI

[Charles G. <ch...@ve...>]

On Wed, 2004-06-30 at 14:56 -0600, Ryan Flegel wrote:
> Just wanted to point out some obvious(?) advantages to SWS approach.
> 
> * With the SWS approach we can have previews of what each character
> and each track looks like before choosing. This would be a total mess
> using the MWS approach.
> * For things like multiplayer character select it will be really messy
> having 4 people choose their characters on a screen with all sorts of
> other options there. With the SWS approach we have a nice, intuitive
> way for all players to select their characters.
> * After a race is complete, usually the only thing that you want to
> change is the track. While this can still easily be done with the MWS
> approach, it confronts the users with a lot of unecessary options.

* People expect the SWS approach with games, and will find the MWS
approach alien and hence ungame-like.
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

Re: [TuxKart-devel] GUI

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

Just wanted to point out some obvious(?) advantages to SWS approach.

* With the SWS approach we can have previews of what each character
and each track looks like before choosing. This would be a total mess
using the MWS approach.
* For things like multiplayer character select it will be really messy
having 4 people choose their characters on a screen with all sorts of
other options there. With the SWS approach we have a nice, intuitive
way for all players to select their characters.
* After a race is complete, usually the only thing that you want to
change is the track. While this can still easily be done with the MWS
approach, it confronts the users with a lot of unecessary options.

-- 
Ryan

Re: [TuxKart-devel] Ideas for AI

[Charles G. <ch...@ve...>]

On Wed, 2004-06-30 at 18:43 -0500, Steve Baker wrote:
> 5) As the game runs collision detection on the visual model, so it'll
>     also run collision detection on the AI model.  PLIB can return the
>     data for whichever polygons are vertically beneath the kart.  The
>     nearest one of those will provide the 'ideal direction' indication
>     to the AI software for the following frame.

As long as that doesn't confuse carts on jumps - don't want them turning
mid-air.  Other obstacles (loop-the-loops) also need to be thought of.

Definitely on the right track (pun intended) with this one. ;)
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

Re: [TuxKart-devel] Some crude Kart sketches

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

Ingo Ruhnke <gr...@gm...> writes:

> Some more:

http://pingus.seul.org/~grumbel/tmp/dino8.jpg
http://pingus.seul.org/~grumbel/tmp/dinoview.jpg

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

Re: [TuxKart-devel] Ideas for AI

[Steve B. <sjb...@ai...>]

Charles Goodwin wrote:

> I was really (in my mind) giving double-meaning to waypoints, not just
> associating them with single points but also with areas.  Your diagrams
> are an exact illustration of how I visualised it.

Cool - so it looks like we are all in basic agreement.

Let's flesh it out a little so we're all on the same page:

1) In addition to the 'visual' model of each track, we make a separate
    'AI' model.  The two will in general cover the same area of ground
    - but the AI model will usually be *way* simpler...fewer polygons
    that is.

2) For the purposes of visualising this model in blender (or whatever)
    and when debugging - we make a texture map with a bunch of arrows
    pointing up the map. In ASCI art:  [^^^]   :-)

3) In the modeller (blender, whatever) our track designers apply the
    arrow-map to each polygon to reflect the general direction a Kart
    should be driving whilst driving over that polygon.  We could also
    vary the SCALE of the texture in the S and T directions to provide
    additional data (eg: The longer the arrows, the faster the kart
    should attempt to go - the fatter the arrows, the more laxity the
    kart is allowed in choosing a direction. (eg when crossing a narrow
    bridge - short, skinny arrows mean drive slowly and stick closely
    to the desired direction.  Long skinny arrows make him drive faster
    but stay on target, long, fat arrows mean you can drive fast but
    you don't have to stay accurately on direction if there are powerups
    nearby.)   We can probably use the colour of the polygon to store
    yet more data, etc, etc.

4) The game loads this AI model at the same time as the visual model.
    The (s,t) texture coordinate at each polygon vertex can then be
    used to reconstruct the direction that the arrow map was pointing
    and turn that into a 'heading' number for each polygon (and a speed
    and turn 'laxity'.  This should be saved along with the polygon for
    future reference.

5) As the game runs collision detection on the visual model, so it'll
    also run collision detection on the AI model.  PLIB can return the
    data for whichever polygons are vertically beneath the kart.  The
    nearest one of those will provide the 'ideal direction' indication
    to the AI software for the following frame.


-- 
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [TuxKart-devel] Ideas for AI

[Charles G. <ch...@ve...>]

On Wed, 2004-06-30 at 12:58 +0100, Oliver Jeeves wrote:
> This is basically how I would have tried to tackle the problem, although I 
> don't think you've explained it as well as you could have (either that, or 
> you're describing something completely different, and I've misunderstood).

You understood me, but I explained it poorly.  (It's been 5 years since
I last did anything vector related, added to the fact it was 6am and I'd
just finished a monstor programming session.)

> On another note, I think the 'array of arrows' method could _possibly_ be
> improved by instead of having a huge array, splitting the map into 'areas'
> and having directions assigned to each of these areas. If you had an array,
> many adjacent arrows would be pointing in the same direction, and there would
> be a lot of duplicate information. I have attached another diagram. The
> question is whether using this method, you could cut down the amount of areas
> significantly enough so that the extra information used to store the
> boundaries of the areas doesn't make it less efficient...

Yes!  That is exactly the kind of compromise I was alluding to.  That's
probably the ideal solution to our problem.

I was really (in my mind) giving double-meaning to waypoints, not just
associating them with single points but also with areas.  Your diagrams
are an exact illustration of how I visualised it.

Excellent.
-- 
- Charlie

Charles Goodwin <ch...@ve...>
Online @ www.charlietech.com

Re: [TuxKart-devel] GUI

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

Steve Baker <sjb...@ai...> writes:

> Both SWS and MWS can handle that.  Once the game is over, the SWS system can
> pop up yet another widget-screen with something like:
>
>     REPLAY THIS LEVEL?

The classic way would be to have a pause/end menu with:

 * Restart Track
 * Change Driver
 * Change Track
 * Exit

> I'd argue that the benefit of the MWS approach is that you can very
> simply play again - but with more or less laps -

More or less laps are for example a thing that I would leave out, at
least for most game modes, except multiplayer and practice. 

The classic way would be to have GrandPrix mode with a number of races
one after the other, in which it must not be allowed to change
anything, else that would be more or less cheating.

Same goes for TimeTrial, changing the number of laps and such doesn't
make sense here either, since people want to have comparable track
times, just won't work if they can tweak dozens of options.

Practice and multiplayer would allow some more options, but that would
be just one or two screens more, nothing critical.

> In the SWS approach, that's a LOT harder because you have to
> navigate through a stack of menu screens to get to where you can
> change that one thing - then back though a bunch of 'no change
> please' clicks to get back to playing again.

There are just two layers of screens, TrackSelect and CharacterSelect,
in GrandPrix and TimeTrial there isn't a reason to change anything
else, if people want to switch the game mode, they press exit and
start from the main menu again. I don't see how clicking twice is
going to be 'a LOT harder'. MarioKart has worked that way from day one
and I never felt that its to hard or anything.

> So (of course), I maintain that the MWS approach wins hands-down
> (especially if you allow the joystick to steer the pointer as well
> as the mouse and have the joystick's "A" button work like the mouse
> button does.

If you use the joystick to emulate the mouse you end up with an almost
unuseable piece of controlls. If you use the joystick you switch
directly between options (kind of like Tab does in most GUIs) you
don't it to emulate the mouse.

> I still think everyone is grossly over-estimating the number of
> people with joysticks.  I've been playing with this stuff for a
> long time and I *know* it's a rare thing in the Linux population.

Even those without a joystick will use the keyboard to drive the kart,
while there will be almost zero people using the mouse for driving the
kart. The point is that the keyboard or joystick will be the primary
controll device for the game, for which reason it should also be the
primary device for moving around in the menus, else people will have
to constantly switch controlls.

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

Re: [TuxKart-devel] GUI

[Matze B. <ma...@br...>]

(for the record I do not have a joystick and still would prefer having not 
more than 2-3 widgets per page to keep things simple - I doubt the 
intention was to put only 1 widget per page. I think Ingos flowchart on 
the Wiki gives a good example on how a multipage menu could work.)

And finally here's my opinion on this stuff copied from the wiki:

MatzeBraun thinks that this needs more discussion in the mailing list. My 
view of thinks is that grumbels idea is ALOT better than having everything 
on 1 page. You're destroying the simple flow of the game if a user has to 
look at a single page full of widgets and settings and needs to figure 
what does what. Visual feedback and recommendations are harder to give if 
the screen is already full of stuff (because it's hard to tell which 
window previews which thing). After all we should also try to reduce the 
number of settings and options. (I know most coders have problems with 
disabling features that are already coded, but believe me, having a clear 
and intuitive interface is alot better than flooding users with strange 
options like mirror or reverse tracks).

We should also stay away from these "standard-widgets", the current menu 
looks like a funky colored office-application with all these radio 
buttons and sliders.

Perhaps another good guideline for testing the GUIs would be to sit some 
people in front of your computer that are totally unfamiliar with typicall 
user interfaces on windows, etc.   (or at least imagine you'd do that if 
you can't find someone ;-)
You'll easily recognize that this multi-page approach is leading into the 
direction instead of expecting knowledge about GUI elements like 
radio-buttons or sliders.

Greetings,
	Matze

On Wed, 30 Jun 2004, Steve Baker wrote:

> Oliver Jeeves wrote:
> > 
> > I kinda agree with some of what you're saying.
> 
> Damn!  Now the debate isn't over!
> 
> To save typing:
> 
>     Many single-widget screens == SWS  == What the majority(?) seem to prefer.
>     Single many-widget screen  == MWS  == What I want.
> 
> > The GUI should be as simple as possible, after every game, the play should be 
> > able to play again immediatly if there are no changes he/she wants to make, 
> > and changing tracks will probably be something that the player will want to 
> > do often, so this should be readily available too.
> 
> Both SWS and MWS can handle that.  Once the game is over, the SWS system can
> pop up yet another widget-screen with something like:
> 
>     REPLAY THIS LEVEL?
> 
> ...and a single button click gets you off and playing again (but with the
> EXACT same setup).
> 
> With the MWS approach that I favor, you'd just get dumped back into the
> big GUI page with all of the widgets set up how you left them.  So, again,
> a single click on the "PLAY!!" button gets you the same thing...back playing
> with a single button click.
> 
> I'd argue that the benefit of the MWS approach is that you can very simply
> play again - but with more or less laps - or with a different Kart or whatever
> using only one click to change the option and another one to replay.  In the
> SWS approach, that's a LOT harder because you have to navigate through a
> stack of menu screens to get to where you can change that one thing - then
> back though a bunch of 'no change please' clicks to get back to playing
> again.
> 
> So (of course), I maintain that the MWS approach wins hands-down (especially
> if you allow the joystick to steer the pointer as well as the mouse and have
> the joystick's "A" button work like the mouse button does.
> 
> > However, I definatly register my vote for being able to change options via 
> > joystick.
> 
> I never denied that possibility - although you'd have to be doing it by
> steering the mouse cursor around with the joystick...which is certainly
> possible although perhaps not ideal.
> 
> I still think everyone is grossly over-estimating the number of
> people with joysticks.  I've been playing with this stuff for a
> long time and I *know* it's a rare thing in the Linux population.
> 
> ---------------------------- Steve Baker -------------------------
> HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
> HomePage : http://www.sjbaker.org
> Projects : http://plib.sf.net    http://tuxaqfh.sf.net
>             http://tuxkart.sf.net http://prettypoly.sf.net
> -----BEGIN GEEK CODE BLOCK-----
> GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
> V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
> -----END GEEK CODE BLOCK-----
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel
> 

Re: [TuxKart-devel] GUI

[Steve B. <sjb...@ai...>]

Oliver Jeeves wrote:
> 
> I kinda agree with some of what you're saying.

Damn!  Now the debate isn't over!

To save typing:

    Many single-widget screens == SWS  == What the majority(?) seem to prefer.
    Single many-widget screen  == MWS  == What I want.

> The GUI should be as simple as possible, after every game, the play should be 
> able to play again immediatly if there are no changes he/she wants to make, 
> and changing tracks will probably be something that the player will want to 
> do often, so this should be readily available too.

Both SWS and MWS can handle that.  Once the game is over, the SWS system can
pop up yet another widget-screen with something like:

    REPLAY THIS LEVEL?

...and a single button click gets you off and playing again (but with the
EXACT same setup).

With the MWS approach that I favor, you'd just get dumped back into the
big GUI page with all of the widgets set up how you left them.  So, again,
a single click on the "PLAY!!" button gets you the same thing...back playing
with a single button click.

I'd argue that the benefit of the MWS approach is that you can very simply
play again - but with more or less laps - or with a different Kart or whatever
using only one click to change the option and another one to replay.  In the
SWS approach, that's a LOT harder because you have to navigate through a
stack of menu screens to get to where you can change that one thing - then
back though a bunch of 'no change please' clicks to get back to playing
again.

So (of course), I maintain that the MWS approach wins hands-down (especially
if you allow the joystick to steer the pointer as well as the mouse and have
the joystick's "A" button work like the mouse button does.

> However, I definatly register my vote for being able to change options via 
> joystick.

I never denied that possibility - although you'd have to be doing it by
steering the mouse cursor around with the joystick...which is certainly
possible although perhaps not ideal.

I still think everyone is grossly over-estimating the number of
people with joysticks.  I've been playing with this stuff for a
long time and I *know* it's a rare thing in the Linux population.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [TuxKart-devel] GUI

[Oliver J. <ol...@po...>]

On Wed, Jun 30, 2004 at 08:52:32AM -0500, Steve Baker wrote:
>=20
> You're right about that.  It needs to be prettied up with more graphics
> and better layout.  But a full-scale redesign isn't needed IMHO.
>=20

I kinda agree with some of what you're saying.

The GUI should be as simple as possible, after every game, the play should =
be=20
able to play again immediatly if there are no changes he/she wants to make,=
=20
and changing tracks will probably be something that the player will want to=
=20
do often, so this should be readily available too.

If all the options can be kept on the same screen, then I see no reason to=
=20
split them up.

However, I definatly register my vote for being able to change options via=
=20
joystick.

Re: [TuxKart-devel] GUI

[Flash <Fl...@da...>]

thats a 100% aye sir, and agree ;)

On Wednesday 30 June 2004 17:31, Steve Baker wrote:
> OK - opinion is clearly against me here - so I give up.  I don't agree
> with having layer upon layer of single-option pages for the GUI when
> a single page would do the job just as well, but nobody else is
> speaking up for me so I'll shut up and let you guys get on with it.
>
> BUT - you have to do this with the PLIB GUI.   TuxKart builds with
> just one external dependancy - and I want to keep it that way.  I
> already maintain one GUI toolkit - I'm not going to add another.
>
> If you go and stick some other library in there, I'll be the one
> who has to maintain it for years to come, so the very first thing that
> would happen on the day the GoTM would leave would be that I'd have to
> rip it all out again and put back the present GUI.  That's a promise.
>
> So - by all means make your multi-layer joystick-compatible
> GUI - but do it using the PUI library please.  If there is something
> you need that PUI can't do - we'll find a way to do it - but that's
> not likely to happen IMHO.
>
> ---------------------------- Steve Baker -------------------------
> HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
> HomePage : http://www.sjbaker.org
> Projects : http://plib.sf.net    http://tuxaqfh.sf.net
>             http://tuxkart.sf.net http://prettypoly.sf.net
> -----BEGIN GEEK CODE BLOCK-----
> GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
> V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
> -----END GEEK CODE BLOCK-----
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Tuxkart-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxkart-devel

Re: [TuxKart-devel] GUI

[Steve B. <sjb...@ai...>]

OK - opinion is clearly against me here - so I give up.  I don't agree
with having layer upon layer of single-option pages for the GUI when
a single page would do the job just as well, but nobody else is
speaking up for me so I'll shut up and let you guys get on with it.

BUT - you have to do this with the PLIB GUI.   TuxKart builds with
just one external dependancy - and I want to keep it that way.  I
already maintain one GUI toolkit - I'm not going to add another.

If you go and stick some other library in there, I'll be the one
who has to maintain it for years to come, so the very first thing that
would happen on the day the GoTM would leave would be that I'd have to
rip it all out again and put back the present GUI.  That's a promise.

So - by all means make your multi-layer joystick-compatible
GUI - but do it using the PUI library please.  If there is something
you need that PUI can't do - we'll find a way to do it - but that's
not likely to happen IMHO.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [TuxKart-devel] GUI

[Steve B. <sjb...@ai...>]

Oliver Jeeves wrote:

> I think in this case, it's best not to think of Linux as purely a desktop 
> operating system - think of those people who are putting together media 
> computers for their living rooms etc.

Oh - you mean people like *ME* ?!?

I have a dedicated PC that's currently running Freevo (but I'm still
experimenting) to do time-shifting and other PVR functions on my TV.
As with *ALL* such devices, you either use a TV remote with a mouse
function or you use a keyboard with a laptop-style mouse-pad or a
small track-ball.

All of those pointing devices appear to programs as if they were
a MOUSE.  There is no joystick in those systems unless you go out
of your way to track one down.

So - the people you speak of (including me) all have mice but very
few of them have joysticks.  The reason is that you can't use
joysticks with browsers or most other GUI libraries.

Go read the Freevo, MythTV, Revo and other's forums and mailing lists.

You might be interested to know that the guys at Philips Research
(where I used to work) used TuxKart as their premier 3D demo 'game'
as the touted their all-in-one Linux set-top-box around the trade
shows.  They did this 10 years after I last worked there - but were
kind enough to send me a free nVidia card for my efforts!  That's
why there is a Philips advert on the first TuxKart racetrack.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [TuxKart-devel] GUI

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

Steve Baker <sjb...@ai...> writes:

> But on a PC, you were holding the mouse when you clicked the
> icon/menu item to start the game running. You'll have the mouse in
> your hand still when it starts up. Whether you switch to the
> joystick after launching the program - or after setting the options
> within the program is no different.

You click the icon only once to start the game, after that you should
spend at a minimum multiple minutes in the game itself, thus how you
started the game doesn't really matter at all. For the purpose of
debugging having additional mouse controll in the game can be a nice
addition.

> Most of our users will be running anything from 1024x800 to
> 2048x1600 - so we don't have that problem).

And many users will run in 640x480 or 800x600 to play the game on the
TV, I surly will. As said, TV-Out is pretty standard these days on
graphic cards and especially for multiplayer using the TV for gameplay
is going to be much more convenient than trying to got four people
around a tiny computer monitor. I don't mind having additional mouse
support, since it can be convenient to be able to navigate the menus
with a mouse, especially when running in windowed mode while doing
other things beside that, but I would consider making the mouse the
primary control device a fatal mistake.

> Yeah - but people who do that have mouse-emulating devices on their
> IR-connected keyboards. (I have one for my Linux PVR PC which
> connects to the TV so I know this for a fact).

Well, I don't. I don't have a special keyboard for by TV-setup, just a
regular one and a gamepad with a long enough cable. PC setup are
always non-standard, so one can't assume that everybody has a perfect
useable mouse while sitting on a couch.

> With an all-in-one GUI, these are trivial things to add and maintain.

Yes, trivial to add and maintaine, but insane complicated to use. Just
because one can easily add yet-another-option, doesn't mean that it
will improve the game at all.

> If it's separated out into separate questions then getting into the
> game becomes tedious because you have to step through each screen
> even if you are happy with the default.

Stuff like mirror/number-of-laps and such can be stuck into the track
selection screen without much throuble, there isn't a need to have a
special screen for each and every options, just for the major ones, so
that the player doesn't miss them. 

> The whole thing balloons from a real simple single-screen GUI to a
> major programming exercise. GoTM is a TWO MONTH TASK - we can't
> afford to waste effort in areas that aren't buying us anything.

GUI programming is something that can easily be done in paralell to
other task, beside that Robert already offered to do it and he even
has a GUIlib at hand if needed, so I don't see much throuble with that

> Adding new options to a single-screen menu is easy.

Adding a new option to a multi-screen menu isn't much more difficult
either.

> That's nonsense - probably more than half of our users don't even own
> a joystick.

They have a keyboard instead, which works quite good as poor-mans-joypad.

> You have it completely the wrong way around - the Mouse is *essential*,
> the joystick is something that's nice to have. 

The mouse is completly useless in the game itself, I don't see how
forcing the player to constantly switch to it would be a good thing.
Yes, it might easy programming a little bit, but thats it.

> There are MANY (if not most) Linux games that don't support a
> joystick at all.

If the game itself is mouse-driven, there is nothing wrong with making
the menu mouse driven too. However Tuxkart isn't mouse driven, people
drive with joysticks and keyboards and to restart a Race pressing
'ESC, DOWN, DOWN, BUTTON1' is a lote more easy than 'ESC, reach the
mouse, navitage to button, MOUSEBUTTON1, reach back to the keyboard'

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