tuxkart-devel Mailing List for Tux Kart (Page 21)
Status: Alpha
Brought to you by:
sjbaker
Menu
▾
▴
tuxkart-devel — TuxKart Developers.
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(8) |
Jul
(46) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2002 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(192) |
Jul
(199) |
Aug
(137) |
Sep
(59) |
Oct
(28) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Oliver J. <ol...@po...> - 2004-06-29 22:14:25
|
On Tue, Jun 29, 2004 at 06:11:22PM +0000, Charles Goodwin wrote: > > I also don't believe we should make each driver in the race be of > increased difficulty so it is hard to get to #1. Some people aren't > game wizards and they'll find it frustrating if they can't win on easy. I'm not exactly sure what you mean here, but I think there should be an approach similar to Mario Kart - where the AI ahead of you becomes weaker, and the AI behind you becomes stronger (or maybe just adjust the speed). This causes the karts to bunch a bit more and means that a good player always has a threat of being overtaken, and a weak player always has a chance to overtake. > As for determining strong AI vs weak AI, if you could classify actions > as "good, bad, or normal", where strong AI will use a mix of good and > normal, medium AI use mostly normal actions, and weak AI a mix of bad > and normal actions, and an invincible AI that only makes good choices. But how do you define good choices? Is it better to take the corner in the fastest possible way, or to take it in a slower way that leads to collecting a powerup? Basically, what you're saying is that we need to define some heuristics to determine what actions to take. It's not as simple as good/bad/normal decisions. For example, taking a slower route to collect a powerup makes less sense if you are in the lead. |
|
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: 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: Steve B. <sjb...@ai...> - 2004-06-29 22:08:50
|
Ryan Flegel wrote:
> Well, I think we should have all inputs configurable. Have it possible
> to use the keyboard as much as the user wants (and let them define the
> keys). If they want to try to use more than two people on the
> keyboard, good luck to them :) Alternate inputs would be each attached
> joystick. As for mouse, I think that would be a bitch to use.
I'm guessing you didn't read the document I pointed you guys at:
http://www.sjbaker.org/steve/omniv/keyboards_are_evil.html
If you let the players configure their own keys - then Very Bad
Things Will Happen for two or more players...but you'll have to
read the document to understand why.
It's possible to very carefully choose sets of characters for
two people to play with - but they tend not to be very ergonomic
or memorable...for three or four players, it's almost impossible
to find enough usable sets to avoid the problem.
---------------------------- 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: Charles G. <ch...@ve...> - 2004-06-29 21:53:10
|
On Tue, 2004-06-29 at 16:44 -0500, Steve Baker wrote: > Penguins natural enemies are: Skua's (who eat their eggs), Leopard Seals and > Killer-Whales. I think a Killer Whale character would rock. Later on this evening I'll draw up a summary of contributed character ideas thus far and post it to the list. -- - Charlie Charles Goodwin <ch...@ve...> Online @ www.charlietech.com |
|
From: Steve B. <sjb...@ai...> - 2004-06-29 21:49:59
|
Ryan Flegel wrote: > On Mon, 28 Jun 2004 16:27:27 -0500, Steve Baker <sjb...@ai...> wrote: > > >>Everyone who even THINKS about speaking against ODE should DEFINITELY >>download a copy and try out the little 3 wheeled kart demo. *PLEASE* >>give this a try. It's exceedingly compelling. > > > Sorry.. I must be retarded.. where can I find the demo? :) Assuming you downloaded ODE, unzipped and untarred it, it's in the 'ode/tests' directory. It's called 'test_buggy.cpp' ---------------------------- 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: Ryan F. <rf...@gm...> - 2004-06-29 21:46:55
|
On Tue, 29 Jun 2004 16:44:45 -0500, Steve Baker <sjb...@ai...> wrote: > > Ricardo Cruz wrote: > > Those characters just rock! :) > > I just didn't like the Mr. Ice Block. Don't think it fits in the game... What > > about a polar bear? It's from Antarctica as Tux... > > Not that it matters - but polar bears come from the North pole - Penguins from > the South! > > Penguins natural enemies are: Skua's (who eat their eggs), Leopard Seals and > Killer-Whales. Yeah, I think seals, albatrosses and whales are pretty much the only other antarctic creatures in addition to penguins :) -- Ryan |
|
From: Steve B. <sjb...@ai...> - 2004-06-29 21:44:45
|
Ricardo Cruz wrote: > Just to point out that a lot of special effects and crazy stuff doesn't make > the game necessarily fun. No - but it's a part of player's expectations these days. That final 'gloss' is what makes a game impressive. > btw. would be cool if players would look at sides, when turning and stuff. :) Yeah - different camera angles are on my 'To Do' list. ---------------------------- 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:42:36
|
Ricardo Cruz wrote: > Those characters just rock! :) > I just didn't like the Mr. Ice Block. Don't think it fits in the game... What > about a polar bear? It's from Antarctica as Tux... Not that it matters - but polar bears come from the North pole - Penguins from the South! Penguins natural enemies are: Skua's (who eat their eggs), Leopard Seals and Killer-Whales. ---------------------------- 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: Ryan F. <rf...@gm...> - 2004-06-29 19:54:24
|
On Tue, 29 Jun 2004 14:55:54 -0400, Aly Merchant <mer...@ac...> wrote: > > On Tue, Jun 29, 2004 at 11:38:37AM -0600, Ryan Flegel wrote: > > On Tue, 29 Jun 2004 10:21:14 -0400, Aly Merchant <mer...@ac...> wrote: > > > > > 3. Knowledge of World > > > > > > Again tied to decision making. I am thinking that the AI would only > > > know about things it can "see". It could keep a list of points along > > > the boundaries as checkpoints it has to pass through, and it would > > > have a list of points of interest for stuff like other cars, > > > obstacles, herrings, etc. Are there other suggestions, or is there > > > any compelling reason to know about the entire track? > > > > As far as the road goes, AI should know *exactly* where to go. We > > should assume that the AI player has played each track hundreds of > > times and knows it off by heart. Even after I play a track for 5 laps > > (depending on size) I know every single turn by the last lap. If the > > AI players are still having trouble remember turns after I've played > > the game a hundred times, it'll probably be quite easy to beat. Of > > course low-level difficulty can be a little sloppy on this. > > > > Not sure if this is exactly what you meant by entire track, but they > > should know about turns in advance (because human players will). > > What I mean is how much knowledge it actually requires to do whatever it > needs to do. The way I see it the AI will probably only care about the > track it will reach in the next 5 seconds, or maybe it will track up to > the next 2 turns in the road. It's not going to be doing a full search > on the entire course -- so what does it need to know about to be a > decent AI? Yeah, I think two turns ahead is all that is needed. I can't see the computer needing to know any farther in advance. -- Ryan |
|
From: Ingo R. <gr...@gm...> - 2004-06-29 19:04:32
|
Ricardo Cruz <ri...@ae...> writes: > Anyone knows Skunny Kart? :) Looks like a rip-off of Wacky Wheels, which in turn of course got heavily inspried by MarioKart. > Just to point out that a lot of special effects and crazy stuff > doesn't make the game necessarily fun. Yep, I agree on that. I personally prefer the first MarioKart quite a bit for everything that come after it, to many hills and jumps, just kind of spoil the fun that drifting and driving on a simple flat track can make. -- WWW: http://pingus.seul.org/~grumbel/ JabberID: gr...@ja... ICQ: 59461927 |
|
From: Aly M. <mer...@ac...> - 2004-06-29 18:54:36
|
On Tue, Jun 29, 2004 at 11:38:37AM -0600, Ryan Flegel wrote: > On Tue, 29 Jun 2004 10:21:14 -0400, Aly Merchant <mer...@ac...> wrot= e: >=20 > > 3. Knowledge of World > >=20 > > Again tied to decision making. I am thinking that the AI would only > > know about things it can "see". It could keep a list of points along > > the boundaries as checkpoints it has to pass through, and it would > > have a list of points of interest for stuff like other cars, > > obstacles, herrings, etc. Are there other suggestions, or is there > > any compelling reason to know about the entire track? >=20 > As far as the road goes, AI should know *exactly* where to go. We > should assume that the AI player has played each track hundreds of > times and knows it off by heart. Even after I play a track for 5 laps > (depending on size) I know every single turn by the last lap. If the > AI players are still having trouble remember turns after I've played > the game a hundred times, it'll probably be quite easy to beat. Of > course low-level difficulty can be a little sloppy on this. >=20 > Not sure if this is exactly what you meant by entire track, but they > should know about turns in advance (because human players will). What I mean is how much knowledge it actually requires to do whatever it needs to do. The way I see it the AI will probably only care about the track it will reach in the next 5 seconds, or maybe it will track up to the next 2 turns in the road. It's not going to be doing a full search on the entire course -- so what does it need to know about to be a decent AI? In my opinion considering the entire track on each decision would be a waste of time, it should be able to get away with making a decision based on its current surroundings. In the implementation we're probably just going to keep the track in memory, but here I'm just talking about the algorithm. Aly --=20 Aly Merchant mer...@ac... http://cobe.dyndns.org |
|
From: Matze B. <ma...@br...> - 2004-06-29 18:33:09
|
As we're quiet a few people who want to discuss tuxkart game design now, it would be quiet conveniant to have some place where we can gather and write down our results. Discussions are better done in the mailing list, but the results or longer texts and proposals can be placed in the wiki easier (and combined with images). This is an experimental I've setup while coding on supertux: http://netpanzer.berlios.de/supertux I could setup something similar for tuxkart (or someone else could do it, installing phpwiki is relatively easy). Greetings, Matze |
|
From: Jacob P. <st...@ap...> - 2004-06-29 18:33:06
|
On Tuesday 29 June 2004 05:07, Steve Baker wrote: > Jacob Persson wrote: > > I just join this list and I'm interested in working on the ai-system. > > Excellent! Welcome. > > Give me your sourceforge account name and I'll get you developer > privilages. > > ---------------------------- 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----- My account name is 'straver' -- Name: Jacob Persson Homepage: www.apollo.nu/~straver/ |
|
From: Charles G. <ch...@ve...> - 2004-06-29 18:10:51
|
On Tue, 2004-06-29 at 10:21 -0400, Aly Merchant wrote: > 2. Difficulty > > This will have something to do with the decision making code but in > general I was thinking that the AI would probably pick sub-optimal > actions at random and this factor could be varied for different > difficulty levels. I'm wondering if there might be a better way, any > ideas? The difficutly should also dictate the speed at which the AI drives. I also don't believe we should make each driver in the race be of increased difficulty so it is hard to get to #1. Some people aren't game wizards and they'll find it frustrating if they can't win on easy. Each driver should have particular strengths suited to particular types of level so that they are more prone to success on certain levels. Of course, there should be weak opponents too. As for determining strong AI vs weak AI, if you could classify actions as "good, bad, or normal", where strong AI will use a mix of good and normal, medium AI use mostly normal actions, and weak AI a mix of bad and normal actions, and an invincible AI that only makes good choices. -- - Charlie Charles Goodwin <ch...@ve...> Online @ www.charlietech.com |
|
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: 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: Ryan F. <rf...@gm...> - 2004-06-29 17:48:51
|
On Tue, 29 Jun 2004 00:27:24 -0500, Steve Baker <sjb...@ai...> wrote: > > (CVS commit emails don't seem to be working...Doh!) Hopefully they will be soon. SF can be a bit slow at times. :) > We could make it work with four joysticks (but who owns four > joysticks?)...or two people using the keyboard, one the mouse > and another the joystick. Well, I think we should have all inputs configurable. Have it possible to use the keyboard as much as the user wants (and let them define the keys). If they want to try to use more than two people on the keyboard, good luck to them :) Alternate inputs would be each attached joystick. As for mouse, I think that would be a bitch to use. -- Ryan |
|
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: Ryan F. <rf...@gm...> - 2004-06-29 17:38:39
|
On Tue, 29 Jun 2004 10:21:14 -0400, Aly Merchant <mer...@ac...> wrote: > 3. Knowledge of World > > Again tied to decision making. I am thinking that the AI would only > know about things it can "see". It could keep a list of points along > the boundaries as checkpoints it has to pass through, and it would > have a list of points of interest for stuff like other cars, > obstacles, herrings, etc. Are there other suggestions, or is there > any compelling reason to know about the entire track? As far as the road goes, AI should know *exactly* where to go. We should assume that the AI player has played each track hundreds of times and knows it off by heart. Even after I play a track for 5 laps (depending on size) I know every single turn by the last lap. If the AI players are still having trouble remember turns after I've played the game a hundred times, it'll probably be quite easy to beat. Of course low-level difficulty can be a little sloppy on this. Not sure if this is exactly what you meant by entire track, but they should know about turns in advance (because human players will). -- Ryan |
|
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: Aly M. <mer...@ac...> - 2004-06-29 14:19:53
|
Here are a few ideas for features in the AI: 1. Decision Making =20 Here are a few ways I've thought of handling decisions for the AI. Basic behaviours: The AI would have a list of higher level actions to choose from, something like "visit point of interest", "make wide turn", "make sharp turn" as opposed to something like "go left", "go right", "fire". Value map: All points of interest on the map have a value associated with them, these values radiate outwards and overlay on top of each other. And the car just follows the path of optimal value. Modeling certain things might be tricky, e.g. getting the car to fire at another car might involve modeling the other car as a good point of interest if it is moving faster than you and you have missiles, otherwise they are to be avoided. 2. Difficulty This will have something to do with the decision making code but in general I was thinking that the AI would probably pick sub-optimal actions at random and this factor could be varied for different difficulty levels. I'm wondering if there might be a better way, any ideas? 3. Knowledge of World Again tied to decision making. I am thinking that the AI would only know about things it can "see". It could keep a list of points along the boundaries as checkpoints it has to pass through, and it would have a list of points of interest for stuff like other cars, obstacles, herrings, etc. Are there other suggestions, or is there any compelling reason to know about the entire track? Aly --=20 Aly Merchant mer...@ac... http://cobe.dyndns.org |
|
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 |
2 messages has been excluded from this view by a project administrator.
