Thread: [TuxKart-devel] GUI
Status: Alpha
Brought to you by:
sjbaker
Menu
▾
▴
tuxkart-devel
|
From: Robert K. <rob...@gm...> - 2004-06-29 13:26:19
|
Hey folks, I'm looking for a way to contribute to this GotM. I'm rlk on Game Tome, the author of Neverball. I propose to take over responsibility for the 2D GUIs in Tuxkart... the menuing, the configuration, the high score display, the in-game HUD, etc. I propose to adapt Neverball's existing GUI code for this purpose. This is a very generic 2D GUI system, and it scales up well. It provides a number of widget building blocks and renders them using TrueType fonts. It uses an autolayout mechanism that allows the coder to describe the relationships between widgets, and it lays them out on-screen automatically. It adapts this layout to whatever screen resolution or font size you enable. You send it mouse, button, and joystick events and it handles the rest. I'll contribute this code, and port in into Tuxkart. I'll create whatever GUIs need to be done for the game. What say you? -- Robert Kooima |
|
From: Charles G. <ch...@ve...> - 2004-06-29 17:04:36
|
On Tue, 2004-06-29 at 09:26 -0400, Robert Kooima wrote: > I propose to take over responsibility for the 2D GUIs in Tuxkart... > the menuing, the configuration, the high score display, the in-game > HUD, etc. I propose to adapt Neverball's existing GUI code for this > purpose. > > This is a very generic 2D GUI system, and it scales up well. [snip] > I'll contribute this code, and port in into Tuxkart. I'll create > whatever GUIs need to be done for the game. What say you? Rather than simply porting the GUI code into Tuxkart, why not look at making it a GUI library (nevergui?) that Tuxkart can use, then you only have a single codebase to maintain rather than duplicate sources. It sounds like a good GUI library - may as well make it available to other open source games. ;) -- - Charlie Charles Goodwin <ch...@ve...> Online @ www.charlietech.com |
|
From: Ryan F. <rf...@gm...> - 2004-06-29 17:43:14
|
On Tue, 29 Jun 2004 09:26:18 -0400, Robert Kooima <rob...@gm...> wrote: > I'll contribute this code, and port in into Tuxkart. I'll create > whatever GUIs need to be done for the game. What say you? Well, I think Steve would rather use PUI (part of PLIB; http://plib.sourceforge.net/pui/), since that is what the project currently uses and PLIB is another one of Steve's project. Guess you'll have to wait for his input on it though. -- Ryan |
|
From: Ricardo C. <ri...@ae...> - 2004-06-29 17:49:18
|
I believe that TuxKart uses PUI, the Plib's GUI engine... =2D Ricardo Em Ter=E7a, 29 de Junho de 2004 14:26, o Robert Kooima escreveu: > Hey folks, I'm looking for a way to contribute to this GotM. I'm rlk > on Game Tome, the author of Neverball. > > I propose to take over responsibility for the 2D GUIs in Tuxkart... > the menuing, the configuration, the high score display, the in-game > HUD, etc. I propose to adapt Neverball's existing GUI code for this > purpose. > > This is a very generic 2D GUI system, and it scales up well. It > provides a number of widget building blocks and renders them using > TrueType fonts. It uses an autolayout mechanism that allows the coder > to describe the relationships between widgets, and it lays them out > on-screen automatically. It adapts this layout to whatever screen > resolution or font size you enable. You send it mouse, button, and > joystick events and it handles the rest. > > I'll contribute this code, and port in into Tuxkart. I'll create > whatever GUIs need to be done for the game. What say you? =2D-=20 Therefore it is necessary to learn how not to be good, and to use this knowledge and not use it, according to the necessity of the cause. -- Machiavelli |
|
From: Matze B. <ma...@br...> - 2004-06-29 17:56:28
|
Having a good GUI lib is nice, however what need even more would be a plan and some sketches on how the GUI should look and feel. Greetings, Matze On Tue, 29 Jun 2004, Robert Kooima wrote: > Hey folks, I'm looking for a way to contribute to this GotM. I'm rlk > on Game Tome, the author of Neverball. > > I propose to take over responsibility for the 2D GUIs in Tuxkart... > the menuing, the configuration, the high score display, the in-game > HUD, etc. I propose to adapt Neverball's existing GUI code for this > purpose. > > This is a very generic 2D GUI system, and it scales up well. It > provides a number of widget building blocks and renders them using > TrueType fonts. It uses an autolayout mechanism that allows the coder > to describe the relationships between widgets, and it lays them out > on-screen automatically. It adapts this layout to whatever screen > resolution or font size you enable. You send it mouse, button, and > joystick events and it handles the rest. > > I'll contribute this code, and port in into Tuxkart. I'll create > whatever GUIs need to be done for the game. What say you? > > -- > Robert Kooima > > > ------------------------------------------------------- > 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 > > |
|
From: Steve B. <sjb...@ai...> - 2004-06-29 22:11:46
|
Matze Braun wrote: > Having a good GUI lib is nice, however what need even more would be a plan > and some sketches on how the GUI should look and feel. Yes. If it's something PUI can't handle - then we could consider using a different GUI toolkit - but frankly, the grief that would entail would make me inclined to hit up my buddies who maintain PUI and have them add whatever functionality we need. I doubt we'll find anything like that though. PUI is pretty capable. ---------------------------- 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----- |
|
From: Steve B. <sjb...@ai...> - 2004-06-29 21:57:25
|
Robert Kooima wrote: > I propose to take over responsibility for the 2D GUIs in Tuxkart... > the menuing, the configuration, the high score display, the in-game > HUD, etc. I propose to adapt Neverball's existing GUI code for this > purpose. Why? Why bring in another GUI system when we already have a perfectly good one already? PLIB/PUI is an extremely mature GUI with a ton of widgets. You can also do stuff like binding your own rendering routines to the buttons to make them look however you want. Fonts are just textures so they can be arbitarily coloured, etc, etc. > I'll contribute this code, and port in into Tuxkart. I'll create > whatever GUIs need to be done for the game. What say you? I don't see a need. The present GUI can handle any 'look' I can think of - and it's already part of the PLIB library that we use for EVERYTHING else. GUI redesign wasn't on our GoTM 'ToDo' list - but even if it was, I can't see any justification in ripping apart something that's working OK. I'd really appreciate some help from an experienced game designer like you - but just not in the area of GUI design. ---------------------------- 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----- |
|
From: Matze B. <ma...@br...> - 2004-06-29 22:10:22
|
On Tue, 29 Jun 2004, Steve Baker wrote: > Robert Kooima wrote: > > > I propose to take over responsibility for the 2D GUIs in Tuxkart... > > the menuing, the configuration, the high score display, the in-game > > HUD, etc. I propose to adapt Neverball's existing GUI code for this > > purpose. > > Why? Why bring in another GUI system when we already have a perfectly > good one already? PLIB/PUI is an extremely mature GUI with a ton of widgets. > You can also do stuff like binding your own rendering routines to the > buttons to make them look however you want. Fonts are just textures so > they can be arbitarily coloured, etc, etc. > > > I'll contribute this code, and port in into Tuxkart. I'll create > > whatever GUIs need to be done for the game. What say you? > > I don't see a need. The present GUI can handle any 'look' I can > think of - and it's already part of the PLIB library that we use > for EVERYTHING else. > > GUI redesign wasn't on our GoTM 'ToDo' list - but even if it was, > I can't see any justification in ripping apart something that's > working OK. Well regardless on how we do it. I think the current tuxkart gui BADLY needs to be improved. All these menus, radiobuttons, list ... make me feel like a funky colored office app, but not like a game. Make it simpler by using more screens, add some effects, like a preview of selected tracks and drivers, ... You could place a driving tux in the background and blend the GUI over it, to have some more action... Greetings, Matze |
|
From: Robert K. <rob...@gm...> - 2004-06-29 22:17:15
|
On Tue, 29 Jun 2004 16:59:41 -0500, Steve Baker <sjb...@ai...> wrote: > I don't see a need. The present GUI can handle any 'look' I can > think of - and it's already part of the PLIB library that we use > for EVERYTHING else. Ok by me. Just tossing it out there. I do feel that joystick control of the GUI is a significant thing, especially since joystick control is the primary mode of game interaction. It seems hackish to have to reach for the mouse to select a level. Is this an issue we can address within PUI? > GUI redesign wasn't on our GoTM 'ToDo' list - but even if it was, > I can't see any justification in ripping apart something that's > working OK. Certainly a great deal of GUI work needs to be done, yes? Configuration, high score lists, etc? Are these on the ToDo list? > I'd really appreciate some help from an experienced game designer like > you - but just not in the area of GUI design. Great, as I'd like to help I offered to take on GUIs because GUI work is mundane and boring and I expected it to fall by the wayside as people clambered to do sexy stuff like physics, graphics, and AI. Where would you like me to contribute? -- Robert Kooima |
|
From: Steve B. <sjb...@ai...> - 2004-06-30 02:13:36
|
Robert Kooima wrote:
> I do feel that joystick control of the GUI is a significant thing,
> especially since joystick control is the primary mode of game
> interaction. It seems hackish to have to reach for the mouse to
> select a level. Is this an issue we can address within PUI?
Yes - easily - although I've never seen a game that did that.
PUI doesn't read input devices itself - it relies on the
application to pass on mouse or keystrokes. PLIB's Joystick
routines are entirely separate - so it would be a snap to
pass joystick events and positions into the PUI widget tree
in order to make it run.
We could even make it so that either joystick *or* mouse
would work - or both together.
But I'm still suprised you'd think that was important.
> Certainly a great deal of GUI work needs to be done, yes?
> Configuration, high score lists, etc? Are these on the ToDo list?
Yes. 'A great deal of GUI work' would be something like the application
that our principle PUI maintainer wrote - I havn't seen it - but I'm
told it has over 150 'pages' of GUI widgets!
> Great, as I'd like to help I offered to take on GUIs because GUI work
> is mundane and boring and I expected it to fall by the wayside as
> people clambered to do sexy stuff like physics, graphics, and AI.
> Where would you like me to contribute?
Well, I think we have a couple of AI volunteers. Graphics is mostly
to do with:
1) 3D model building - if you can handle Blender or have AC3D - then
there is an endless pit of 3D models for karts, tracks, decoration
(trees, carniverous plants, squirrels in trees, dancing mushrooms,
*ANYTHING* that you could imagine in a 'cute' game).
Anyone who can model needs to model.
2) Special effects - smoke, flame, animation, sparks, rocket trails,
...anything we can add in the realm of eye-candy. This is programming
PLIB/SSG's particle systems - plus putting together some textures to
stick onto the particles.
3) *PERHAPS* we need a better way to get models from Blender into the game.
We kinda sorta have a physics volunteer - I think we'll need two physics
people - one for dynamics and one for collision detection.
There will be a big pile of integration bits to glue everything
together. I kinda suspect that should be my job (because I know
the software better than anyone - I'd rather be doing some of the
fun stuff).
---------------------------- 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-----
|
|
From: Robert K. <rob...@gm...> - 2004-06-30 12:11:22
|
On Tue, 29 Jun 2004 21:15:30 -0500, Steve Baker <sjb...@ai...> wrote: > We could even make it so that either joystick *or* mouse > would work - or both together. > > But I'm still suprised you'd think that was important. Here's the distinction in our thinking: you're looking at it from an application GUI point of view. I'm advocating looking at from a game GUI point of view. Think of it as if you were programming for a console. Would a GameCube game use tiny scrollbars and radio buttons? No, it would use big bold simple obvious widgets with gamepad control. -- Robert Kooima |
|
From: Steve B. <sjb...@ai...> - 2004-06-30 12:21:24
|
Robert Kooima wrote: > Here's the distinction in our thinking: you're looking at it from an > application GUI point of view. I'm advocating looking at from a game > GUI point of view. Think of it as if you were programming for a > console. Would a GameCube game use tiny scrollbars and radio buttons? > No, it would use big bold simple obvious widgets with gamepad > control. Yeah - but we aren't as horribly limited as they are on a GameCube. But do you think they'd still do it that way if they had a mouse attached to the system? Because the mouse is a really nice pointing device (and a joystick sucks for accurate pointing because it's a relative motion device not an absolute position device) - so if you have a mouse, you can dispense with all those layer-upon-layer menu's with easily forgotten options. It's much simpler IMHO to just lay out all the options on a single page and let the person see all of them. They can verify that everything is how they want it - and when it is, click the "GO" button. We don't regard a joystick as a good GUI device for other applications, why would we use if here? Well - it doesn't really matter. We can certainly make the joystick work the GUI if that's what everyone wants. Aside from improving the general look and layout of the GUI widgets (which is easily done) - I'm not sure I'd want to spend a lot of additional effort on it. The main things it needs (IMHO) is a pictorial indication of the tracks rather than the present list of text names and a pictorial (preferable 3D, rotating slowly) image of the kart you have selected. ---------------------------- 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----- |
|
From: Ingo R. <gr...@gm...> - 2004-06-30 13:14:16
|
Steve Baker <sjb...@ai...> writes: >> Would a GameCube game use tiny scrollbars and radio buttons? No, it >> would use big bold simple obvious widgets with gamepad control. > > Yeah - but we aren't as horribly limited as they are on a GameCube. > > But do you think they'd still do it that way if they had a mouse > attached to the system? I hope so, constantly switching controlling devices just isn't something that will improve the experience, but just something that will annoy the player. Beside that having the computer additionally attached to a TV is getting more an more popular, so having the game 'TV-ready', like a console game, would be strongly prefered, mice just don't navigate all that good on a couch. > Because the mouse is a really nice pointing device (and a joystick > sucks for accurate pointing because it's a relative motion device > not an absolute position device) Thats why you don't use a joystick as pointing device, but just have widets to which you switch via up/down/left/right instead of navigating a pointer to them manually. > - so if you have a mouse, you can dispense with all those > layer-upon-layer menu's with easily forgotten options. It's much > simpler IMHO to just lay out all the options on a single page and > let the person see all of them. They can verify that everything is > how they want it - and when it is, click the "GO" button. Having everything layed out on a single page is really a bad idea, it will just lead to people forgetting to turn some option and such and so having to quit go back to the menu again. Seperating all options (track-select, player-select and such) to different screens will do a much better job here. > We don't regard a joystick as a good GUI device for other > applications, why would we use if here? Because there is only a rather limited number of options that the player has, just which game-mode (gp, time trial), which track, which character, rest is driving in game. The GUI should be keept as simple as possible, there is no need to have screenfulls of buttons and stuff. > Well - it doesn't really matter. We can certainly make the joystick > work the GUI if that's what everyone wants. The joystick/keyboard should be considered the primary input device for all of the GUI and so it should make sure that it works good and well and doesn't feel emulated or whatever (moving a pointer with the joystick and such). Mouse is something that is nice-to-have, but not something that anybody would miss if the game itself is 100% joystick controlled. > Aside from improving the general look and layout of the GUI widgets > (which is easily done) - I'm not sure I'd want to spend a lot of > additional effort on it. The current GUI might be more or less functional, but it neither looks good nor feels 'right', just extending it with more widgets and stuff just isn't doing the game any justice. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Steve B. <sjb...@ai...> - 2004-06-30 13:50:20
|
Ingo Ruhnke wrote: > I hope so, constantly switching controlling devices just isn't > something that will improve the experience, but just something that > will annoy the player. 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. (The other reason game consoles like this approach is that the TV has *crappy* resolution - about 640 horizontal by 512 vertically - but since 1 pixel vertical features flicker, that's really only 256 vertically. On such a low resolution screen, the graphical widgets have to be HUGE in order to be legible. Most of our users will be running anything from 1024x800 to 2048x1600 - so we don't have that problem). > Beside that having the computer additionally attached to a TV is > getting more an more popular, so having the game 'TV-ready', like a > console game, would be strongly prefered, mice just don't navigate all > that good on a couch. 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). >>We don't regard a joystick as a good GUI device for other >>applications, why would we use if here? > > Because there is only a rather limited number of options that the > player has, just which game-mode (gp, time trial), which track, which > character... What? No way! Difficulty level? (Easy, Medium, Hard) How long should the race be? (5 laps, 10, whatever) How many players? (1, 2, 3, 4) Player's name? (for high-score and game save options) Network play? (and then someplace to enter the servername) Mirror the track? (Yes/No) Reverse the track? (Yes/No) [ie race anticlockwise instead of clockwise] Music volume Sound Effects volume I'm sure we'll come up with others as time progresses. With an all-in-one GUI, these are trivial things to add and maintain. 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. 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. Adding new options to a single-screen menu is easy. ...all of this to support an unnecessary feature that many people don't have (joysticks are dying out fast). > The joystick/keyboard should be considered the primary input device > for all of the GUI and so it should make sure that it works good and > well and doesn't feel emulated or whatever (moving a pointer with the > joystick and such). Mouse is something that is nice-to-have, but not > something that anybody would miss if the game itself is 100% joystick > controlled. That's nonsense - probably more than half of our users don't even own a joystick. 100% of people have a mouse (or a mouse emulated with a trackball or something if they have a laptop or a 'TV controller'). You have it completely the wrong way around - the Mouse is *essential*, the joystick is something that's nice to have. There are MANY (if not most) Linux games that don't support a joystick at all. > The current GUI might be more or less functional, but it neither looks > good nor feels 'right', just extending it with more widgets and stuff > just isn't doing the game any justice. 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. ---------------------------- 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----- |
|
From: Oliver J. <ol...@po...> - 2004-06-30 15:59:29
|
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. |
|
From: Robert K. <rob...@gm...> - 2004-06-30 13:32:40
|
On Wed, 30 Jun 2004 07:23:41 -0500, Steve Baker <sjb...@ai...> wrote: > Yeah - but we aren't as horribly limited as they are on a GameCube. > > But do you think they'd still do it that way if they had a mouse > attached to the system? Yes they would, because players can't use a mouse when they're sitting on the couch. A gamepad is a device that fits in your hands and affords full control of the game without the need for a desk and a chair. > We don't regard a joystick as a good GUI device for other applications, > why would we use if here? A game doesn't require a GUI of the same density as, say, a word processor. You shouldn't look at a simplified GUI as a limitation, you should see it as a liberation. > The main things it needs (IMHO) is a pictorial indication of the > tracks rather than the present list of text names and a pictorial > (preferable 3D, rotating slowly) image of the kart you have selected. Exactly. You don't have to have 100 widget types because you don't need them. What you've described here can be implemented with 1 type of widget, in such a way that is easily controlled with only a D-pad and a single button, in a style which has already been well established by hundreds of games. -- Robert Kooima |
|
From: Oliver J. <ol...@po...> - 2004-06-30 14:51:18
|
On Wed, Jun 30, 2004 at 07:23:41AM -0500, Steve Baker wrote: > Because the mouse is a really nice pointing device (and a joystick > sucks for accurate pointing because it's a relative motion device > not an absolute position device) - so if you have a mouse, you can > dispense with all those layer-upon-layer menu's with easily forgotten > options. It's much simpler IMHO to just lay out all the options > on a single page and let the person see all of them. They can verify > that everything is how they want it - and when it is, click the "GO" > button. 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. (admitedly, I wouldn't think there are too many of these). After sitting around with some friends playing some TuxKart, it seems a shame to force them to get up and find the mouse inbetween games as opposed to staying where they are and setting up the next game with whatever input device they happen to be holding at the time. Obviously a joystick sucks as a pointing device, so joystick control should just cycle through options - controling a pointer with a joystick is a bad idea. |
|
From: Steve B. <sjb...@ai...> - 2004-06-30 15:18:34
|
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----- |
|
From: Ingo R. <gr...@gm...> - 2004-06-30 15:09:39
|
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 |
|
From: Steve B. <sjb...@ai...> - 2004-06-30 15:29:21
|
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----- |
|
From: Flash <Fl...@da...> - 2004-06-30 15:58:17
|
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 |
|
From: Steve B. <sjb...@ai...> - 2004-06-30 16:20:13
|
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-----
|
|
From: Matze B. <ma...@br...> - 2004-06-30 16:40:43
|
(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 > |
|
From: Ingo R. <gr...@gm...> - 2004-06-30 17:06:45
|
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 |
|
From: Ryan F. <rf...@gm...> - 2004-07-01 02:41:09
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X