Re: [Plib-devel] Re: KobayashiMaru & plib
Brought to you by:
sjbaker
Menu
▾
▴
Re: [Plib-devel] Re: KobayashiMaru & plib
|
From: Steve B. <sjb...@ai...> - 2000-08-12 17:41:05
|
Alexander Rawass wrote: > > Start simple. Design one game in one genre. Just wait and see what > > actually comes to bite you. Simple things like collision detection, > > best use of the Z buffer and where to place the camera are unbelievably > > I don't have any idea about any Z-Buffer - in my opinion, thats your > part. Tell me how to use it - or just gimme some url doing this. Well, the problem is that the precision of Z (for hidden surface resolution) is finite - and (at least on some graphics cards) only just barely usable. Within one genre of game, you can work on that and find an acceptable range. But if you tried to do: * A deep space game - where you need ranges large enough to display entire planets but fortunately, you can treat things that come within a few klicks specially. ...AND... * A flight sim - where you need ranges only out to perhaps 100km - but objects don't really get closer than perhaps 3 or 4 meters - so you can manage it. ...AND... * A first person shooter where you only need ranges out to perhaps 1km - but you need to resolve Z down to a centimeter precision all the way in to maybe 10cm. Each one of those is do-able. Putting all three into one game is impossible without some MAJOR engineering effort to switch models, switch rendering paradigms, etc. > The point is: if I'm going to concentrate on this one genre, I might > write a good game - and get stuck with it. You can always write another one once you've finished the first one. > I have LONG LONG thought about howto write this Starfighter game > (version 1.0.0) in a way that it can easily extended to v2.0.0 in > some time, but if I would concentrate to this one genre, I had to > completely re-write code and classes to expand it. You'd have to do that anyway because (as I'm *still* trying to tell you) you can't use the same game mechanisms at all those scales and with all those genres. You have to employ different dirty tricks at each level. You could *try* to write all the dirty tricks for all the genres into all the classes - and then somehow switch between them - and switch the models - all at the right time to make it seamless - but it's known that doing that is beyond the abilities of even the largest professional programming teams - who understand ALL the dirty tricks and how they interact. You are probably going to try to tell me that you'll program it all without any dirty tricks - but I'm telling you that to make convincing 3D images AT ALL requires a large collection of dirty tricks. > > or "How do I allow space ships to > > fly into holes in asteroids - as well as have people stay stuck to > > When a Starfighter flies into a hole in an asteroid, there will be sort > of portal and he will get connected to a KobayashiMaru mission > server playing the inside_asteroid Mission. In other words you basically throw out one game of one genre - and load up another. You need different artwork for the same area of the asteroid - all those artworks have to look about the same at different scales from orbit down to low-level "flight" down to walking around in a space-suit. That's an amazingly tall order. Also, you'll get cross-over effects from the various games genres. The guy walking around on the terrain in his space suit sees a space ship flying down about to shoot at him. At his scale of game, he sees a 10 foot high rock - he runs and manages to hide behind it! "<Phew>... I'm safe now!" he thinks. Meanwhile, the game engine for the space ship level of game is hurtling him along at mach 3 over the surface - there isn't enough memory or graphics bandwidth to draw rocks as small as 10 feet high - so the pilot is suprised to see the lone guy crouched down in the wide open space of the asteroid! Meanwhile, at 'deep space' scales, there is a field of asteroids - most of which are too small to render at the scale of this 'genre' of game. ...you see it's practically impossible to blend all these scales seamlessly and still make a good game. > At that moment, calculation gets done by another engine, and the people > on the ground wont see it again until it comes out of another > portal. Won't work - there will be too many 'crossover' events between the scales. > > the ground - and at the same time allow missiles to collide with > > 1,000 polygon spacecraft models"....remember my words. > > If the spaceship is so near that is makes sense to let you see > all 1.000 polygons, it's probaby so near that you wont even have > to think about drawing something other. I wasn't talking about what you *draw* I'm talking about what you *collide* with...VERY DIFFERENT! > > A fancy game engine without good graphics will be *terrible*. Good > > graphics consume 95% of every game development team's time, 95% of > > the time in the CPU, 95% of the disk space the game consumes. If the > > graphics suck - you are back to writing games like Tetris that don't > > *need* fancy graphics. > > How would you rate the graphics of your game? About 50% of what they could be. > I think that it's one of the cutest little open source games I've ever > seen, and that the graphics are great, compared to other open source > games. > > But show Tux to a person who pays 80DM for a commercial game and > is used to graphics like Quake3, he will probably just laugh and > say 'yoz gfx sukkz' or so. But Tux shouldn't be compared with Quake. It should be compared with games like Mario-64, DonkeyKong, Spiro, etc. IMHO, Tux's graphics are as good as Mario - not as good as DonkeyKong. For TuxKart, I deliberately modelled two tracks that are nearly identical in 'look' to two tracks in MarioKart-64. I have to say that "Tux Tollway" looks *MUCH* nicer than "Toads Turnpike" - the textures in my version are nicer - I have more detail in the track than Nintendo do, etc. > No-one of them will play yours or mine. No - but 7 to 12 year old kids (who enjoy Mario'64) think Tux_AQFH is pretty good. > > > No one will of course play such a game, exept the Linux-GPL-Freaks, > > > > ...not even them. > > I do not know a single person other than me to have a working > hardware 3D installed, although other could but - why shutdown > Windows, just to start Quake under Linux - no way for them. Facts: * 15,000 people downloaded TuxAQFH in the first day after it's release. * So far, 50,000 people have downloaded TuxKart - although some of those may have been reloads when more recent versions came out. * 5% of Quake players use Linux. * In a recent (6 months ago) survey on happypenguin.org (a place where only Linux gamers hang out) - 80% of people who voted have a 3D card that works under Linux. * "If you build it they will come." - MANY people boot into Windoze to run games - but would prefer to stay in Linux if the games existed. Many more die-hard Linux users would buy a 3D card if there were more 3D games to use it for. ...there are plenty of potential users out there. > I will be my best player, that I know for sure. If you get the game playable - and promote it to places like happypenguin, I think you'll be amazed at the number of people who play it...but disappointed at the number who contribute. > An actionbased flightsim doesn't need realism or accuracy > at that high rates of speed. (Remember that I design flight simulators for a living - and get paid six figures to do it - and now I'm telling you...) You couldn't be more wrong. > It could of course be that FightGear/Terragear is unsuitable > for my means, because they are rendering too good and not > suitable for this type of game, so I'll have to look elsewhere. Perhaps. > > But collision (at least at the scale of ground-based simulation) requires > > knowledge of where every single polygon is. You can't do that without > > plibssg. > > Yes. > At the moment, collision checking is done on 'Shield' level, meaning > an impact in a sphere around the ship - this can be done without. > The future will give collision checking on 'Hull' level, when the > Shields are down - this will be done with plibssg. Exactly my point. Collision with simple bounding spheres ("Shield level") is *fine* for a space game. But at other levels of play, you need other tricks. In TuxKart, I know how far around the track each car is in "track space" - cars that are not close in track space cannot possibly collide - even if they are nearby in "world space". That's a typical dirty trick that a *racing* game can use to help things along...but a generic engine can't DO that. An utterly generic game engine cannot ever implement TuxKart anything like as well as TuxKart does. > > > The same collision checking will work for cars - only, that the cars are > > > limited in z axis to the HOT they're on. > > > > Not good enough. How will you detect when the car goes under a bridge? Or under > > When a CarObject is inside the radius of a StaticGroundObject, further > collision checking is done with plibssg. A car is *always* within that range of *some* static ground object. There are Armco crash barriers on both sides of the track. > > What happens when your speed is so high that at the start of the frame you > > are cleanly on one side of a brick wall - and at the end of the frame you are > > cleanly on the other - you *should* have hit the wall on the way - but does > > your algorithm solve that? Efficiently enough? > > Nope. This is _exactly_ a problem I already have. Exactly. > possible solutions: i) more framerates by > models with lod > changing the fonts > optimising my code a lot > ii) a mathematical algorithms I yet have not the > slightest idea of. > iii) run the KIs that steer in the ship in a > 'minimum speed' in a seperate task, when > neccessary leaving frames to display off > to have cputime for the engine. Well, in TuxKart, I do collision detection for every half meter the car travels during the frame. Since the cars are a meter across and can travel only a few meters per frame - this is do-able. Translating that to something like your ships moving at 100meters/sec (pretty slow for a spacecraft), would probably work - but at many times the speed of sound - it'll cause you to spend 90% of your CPU time doing collision detection. Each genre needs a different scheme to do it efficiently enough - but with only as much precision as that genre needs. For kart racing, intersecting the sphere around the kart with the terrain is perfectly acceptable. For Quake, it would *suck* and other tricks are needed. > > Think you can solve that? Now apply that algorithm to a spaceship going at > > 0.8 times the speed of light towards another spaceship on a collision course. > > Actually, we're not flying that fast, exept for hyperspace. > A normal starfighter makes 1km in 10secs 360kph? The Cessna's in FlightGear go faster than *that*! A 1970's F16 fighter can go about 5 times that speed. The space shuttle (when in orbit) has to orbit the earth ever 72 minutes. > > Done that? Now worry about how our heroin can get into a small space if she > > crawls - but not if she's standing up. What happens if she crawls into a > > passageway that GRADUALLY gets smaller until she can't fit anymore? > > What happens if you are walking along parallel to a wall - carrying a long > > weapon - and the player pushes the joystick to turn in to face the wall. > > How do you stop the weapon penetrating the wall? Did your collision > > detection even *detect* that situation? > > Nope. All that is done with your lib. Nope. I give you the low level primitive tests - you have to decide what to do with them. > You went public when you were 1.0.0, as you told me. > > I could have chosen to do so, but this would mean to have no > support on questions for half-a-year / a year. I'm not blaming you for going public earlier - that's a perfectly valid thing to do. That's the way (for example) I'm working with the PPE project. I decided to work on Tux and Tuxkart privately because I enjoy working on games and I don't happen to want to share that enjoyment early on in the development. > So I'm out with slow Huds and no optimizations at all - but I'm 0.2.9. There is nothing wrong with that either. What I have trouble with is the grandiose plans to slurp up every possible kind of game into what is currently quite a promising space shooter. > How was your code at that time? You didn't give it to the public > at that time like I did to get contributions and arguments > and improvents and redesign as soon as possible. Tux (and TuxKart) didn't progress in quite that way. I would get all of one aspect of the game working (with none of the rest) then move on to the next section and do all of that. Hence, in TuxKart, I had all of the driving stuff working with all of the graphics finished before I even started on collision detection, scoring, powerups, etc. I don't generally 'rough out a design' and then gradually improve it all... at least not for those two games. But that's just me - you may want to work differently...especially since you are feeling around in the dark for some of this. Just try to limit the scope of what you are attempting down to something you can realistically achieve. Just build a really *good* space shooter *or* a really good low level futuristic air combat game *or* a ground-based shooter...not all at once! -- Steve Baker HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://web2.airmail.net/sjbaker1 Projects : http://plib.sourceforge.net http://tuxaqfh.sourceforge.net http://tuxkart.sourceforge.net http://prettypoly.sourceforge.net |
