Re: [Plib-devel] Re: KobayashiMaru & plib
Brought to you by:
sjbaker
From: Alexander R. <a_r...@in...> - 2000-08-11 23:26:54
|
Hi, > Alexander Rawass wrote: > > > > You just need to practice and learn GIMP. It's not that hard to draw things > > > like instruments, little icons and such like. > > > > No way. Not for me. Better a good game with bad graphics than to take > > this big big leap. > > You don't have to do it full-time. It's not like a maor career change - but I've today drawn my first image, see my 3D math help page ;-) > this is something you'll find to be an increasing necessity. Drawing > things like your radarscope out of lots of little OpenGL commands just > doesn't make sense and expecting someone to come along and say "This game > that runs like a pig and looks terrible could be greatly improved if I > spend a few hours painting some pictures for him"...well, it's just > naive. In my opinion, all Hud-instruments you can see in my game suck. They are yet slow since they are still using glut. They are ugly. They are not stylish/transparent. They are functional. They are to be replaced by either myself in the future or by someone other by accessing the HudObject-API > > it is commercially better to write a gaming engine and make 1,2,3,4 games > > out of it and sell them all for a high price, than to write the > > universal gaming engine that sells just once. > > Well, commercially, the games industry made 7.2 billion dollars last year, > but only one game in 35 actually turned a profit. By contrast, the Holliwood > movie industry made 7.4 billion and one in ten films turned a profit. I don't wanna make profit. > Game making is a **HUGE** and extremely risky business. If you manage to > make a success out of game #1, you'll certainly be making game #2 with > pretty much the same themes/engine/etc. Exactly. > Utterly universal game engines don't exist because they can't exist. > There is a galaxy of difference between a first person shooter game > engine like Quake or Doom and a flight simulation engine like FlightGear. > The idea that you can just change the model and program some different > behaviours in is very naive. > > > I am pissed of by ST Armada, I've seen it on a friends computer, > > the graphics are great but I haven't seen any feature that KobayashiMaru > > version 2.0.0 is not yet designed to have. > > When you actually *have* all that working, I'll be impressed - but in the > meantime, it sounds very much like vaporware. As your first 3D game, > it's unlikely that you could master one genre - let along three or four > in a single title. I'm talking about version 2.0.0, which is far away from 0.2.9 > > You told me in a former mail, that the abstraction layer between the game > > and plib costs time, put I am big in abstraction this times, > > and if you write a simple starfighter game, you suddenly lean back for > > a while, abstracting even more and more, and then you'll have a thing > > that can handle anything. > > No - you won't. You'll have an unimplementable design. > > 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. > subtle - and DRASTICALLY different in every genre. Also, that little thing > "performance" doesn't just appear from an abstraction layer - it has to > be tightly engineered at the lowest levels - the way you make a FPS run > fast is TOTALLY different than a space game or a flight sim. > > > Just wait. > > I don't have to. I just hope I can pursuade you to make your first project > something remotely achievable so you don't get discouraged when it won't all > come together at the end. The point is: if I'm going to concentrate on this one genre, I might write a good game - and get stuck with it. 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. V1.0.0 will be a good starfighter game, with all possibilities to extend it. It will be better than XwA,XwT or WC, but it will probably not be better than SpaceThing or glWars, from which I've heard today. > > I have come to the conclusion that all these games are 'the same'. > > Really, you couldn't be more wrong. FLightGear, TuxAQFH, TuxKart, TuxRacer > and others I have worked with couldn't be more different in approach. > > > Lean back and abstract. > > But eventually - just try to implement it all! Takes time. > > I am only a 3D beginner, and these problems have either been solved > > already or will be solved with your help, but I think that I am > > very well capable in designing that huge game and writing it. > > Well - I'm trying my very best to explain it to you - but you keep coming > up with grandiose plans - and my best advice as someone who'se been programming > this kind of thing for 27 YEARS is that you need to come down from this > ethereal plane and actually implement a couple of more tightly focussed > designs before you leap off into the void as you are about to do. > > If you think you'll get a lot of help from me when I can clearly see what's > going to happen here - you have another think coming. I'll quickly lose > patience and you'll end up on my mail filter list. I hope that I'll hear at least a *PLONK* ;-) > You are asking for advice - and I'm giving it. Choose to ignore me if > you like - but don't expect more help if you do! I need your advise and help for 3D-related matters. > When you start to ask things like "How the heck to I draw Laura Croft's > boobs at a range of 10 centimeters - as well as the spiral arm of > galaxy XYZ-34 in the background?" Easy: the boobs are SO big, you wont ever see the galaxy. Besides, who will notice the galaxy, if he has the opportunity for the other thing? > 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. 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. > 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. These things you mentioned will happen _either_ , but not on the same display. > > I've got so many ideas, I don't know where to start next. > > It'll get *MUCH* worse before it gets better. If you mean 'lower framerate' with worse, you are true at the moment, since I concentrate on other ideas. > > > Remember that *very* likely you'll be doing it single-handedly with no > > > artistic or music input? > > It will surely a game that will be a lot better than other commercial > > games, but I also think that graphics and sound will suck. Relatively. > > 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? 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. No-one of them will play yours or mine. > > 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. I will be my best player, that I know for sure. > > My friends told me the same - time will show, on which classes I'll > > continue working. > > OK - so *everyone* is telling you the same thing. People with 20 times They don't have the experience, so I igonored it. > the experience in this stuff are telling you. But I won't ignore it from you. I'd like to come to your town and explain KobayashiMaru to you, I just need a ticket, a big blackboard and some hours of talking time. > > No more than in Flightgear itself. You'll wonder how slow > > 'several times the speed of sound' can be in an action-type based game. > > No - I won't - unless you have terrain that covers literally millions of > square miles and doesn't look 'sameish'. > > > Or: the resolution of the terrain has to be decreased. > > ...at which point, the amount of 'optical flow' (tekky flightsim > term) will fall off - and it'll feel like you are going about 50 mph. > > The Apollo 11 astronauts were flying faster than any man has travelled > before or since. However, between the earth and the moon, the > resolution of the "terrain" is pretty poor - and they felt like they > were stationary. > > When you get the amount of data up to where it *feels* really fast, > you'll need so much data that you'll have to page it in from disk in > realtime (that's what FlightGear has to do - and most of it's planes > fly at about 200mph!). When you can't pump this amoun from data from disk, either reduce it , or wait with that part until cpus are faster, or don't shove it from disk but create it 'on the fly' An actionbased flightsim doesn't need realism or accuracy at that high rates of speed. 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. > You can help this out by designing the high level game play to > make it undesirable or impossible to fly in a straight line for > more distance than the terrain you can hold in RAM - but now > your high level abstraction has to be bent to fit the ugly > facts of life. > > You can't "abstract" your way past that in your game design. > > You see there are *so* many things you don't know that FUNDAMENTALLY > affect the design of the game. You'd have gotten all the way into > implementation before you realised that this was your problem - and then > you are suddenly faced with a MAJOR redesign so you can page stuff in from a > background task. If I'd been you, I'd answered as simple like that: There is a TerraGear project to do this, and yes, it is in principe possible, BUT TerraGear is constructed for a very detailed viewing of the landscape at the speed of slow airplanes, so you'd get low framerates from this, better look somewhere else. (I didn't asked if it will run fast, just if it _can_ be possible) > > > That's *VERY* naive. Have you thought about collision detection yet? > > > > At the moment, collsision checking in KobayashiMaru isn't done in > > plibssg level but on my intern logical level. > > 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. > > 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. > the place where the bridge joins the terrain and there isn't enough room to > go under the bridge - but the side-walls are just to high to drive *over*. I dont get which situation you mean here. > 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. 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. When I had realized that problem, I didn't continue to work on that but decided to wait until i) has been solved > 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 > 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. > If the camera accidentally penetrates the wall, you'll see what's on the > other side of it. Do you prevent that (very hard) or do you simply > design the high level game play so it never really matters? There are situation where this does matter , other not. Now they dont. > This stuff is *HARD*. Picking just one genre helps you to get through it. > > > I _can_ do all the game logic - but I have to rely on 3D on people who > > know better, like you. > > No! You *can't* do all the game logic because it's horribly intertwined > with the 3D that you don't know enough about *yet*. Maybe? > Look dude - I'm sick of these long posts where I tell you that you are > a newbie who doesn't understand how hard it is...then you tell me that > you have it all solved in your head somewhere. Then I tell you that > I've been there and done that and it's HARD - and you wave the magic > "abstraction wand" so you don't have to think about it. It is true that you could say the things shorter, but on the other hand I like this discussion, you're the first one I have to respect, since all others who have yet doubted can program less than me , it's great to talk with someone who knows what he's talking about. > If you don't want to come down to ground level and think rationally I'd rather fly than be tied to the ground. > about what you can actually achieve (*especially* with no desire to > learn art skills) - then I'm not interested in talking to you anymore > because any attempt at help is just wasted effort. I mean, it took > like FOUR posts to convince you that all that font stuff was the cause No, only one. I immediatly worked on that part, and I have seen that it was true, the other wouldn't probably have been needed. But it took me some days to implement it and CONVICE me. Would I have reacted faster, I would have BELIEVED you, but now I am even convinced, and thats a lot better. > of your slowness and *not* PLIB. If you ask for advice, take it with > good grace or get out. The HudObjects will still use glut, until I think its time to go for that problem. *PLEASE* remember this: 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. So I'm out with slow Huds and no optimizations at all - but I'm 0.2.9. 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. You published a neat fine game, while I am publishing sort of junk that has to evolve about some time until it will be declared 1.0.0 I sometimes feel even ashamed of some of the bad code thats in some classes, but you wont see that in 1.0.0 anymore,but know, all could see what a lousy programmer I may be in some cases, but at least my code is open to the public in a very early stage. Please see the difference between a fully grown & tested game, and my early stage. Alex PS.: the correct name for the book by Terry Pratchett is 'Only you can save Mankind', the first Johnny Maxwell story 'Johnny and the Bomb' is the third in that line, I haven't yet read it. -- Alexander Rawass Email: ale...@us... Project Homepage: http://kobayashimaru.sourceforge.net ...but some day you'll be a STAR in somebody else's SKY... |