Re: [Plib-devel] OT: new linux game

[steve <sjb...@ai...>]

Bram Stolk wrote:

>> 1) The RPM didn't work for me because it demanded a version of glibc
> 
> RPM support is pretty minimal.
> I simply create a deb archive, and convert with alien.
> I've uploaded the rpm without testing.

Yeah - I found it hard to support enough different RPM's to keep
everyone happy - in the end I just gave up and gave people the source
and concentrated on getting good enough './configure ; make install'
support.

>>     Makefile it demands /usr/lib/libode.a - but the default installation
>>     of ODE if you just download it and do a 'make install' is
>>     /usr/local/lib/libode.a - why don't you just link like this:
> 
> I'll change the default prefix in the Makefile from /usr to /usr/local
> 
> I intentionally use libode.a instead of -lode, because I want to 
> avoid building against shared objects, for all the good reasons you
> so eloquently put on this mailing list.

Ah - good point.

The problem with changing it from /usr/lib  to /usr/local/lib is that
on Linux distro's that ship with ODE installed by default (evidently
this doesn't include SuSE 9.3), you'll probably find ODE in /usr/lib.

So whichever path you look for it on, you won't find it 100% of the
time.  (This is why PLIB installs in /usr/lib no matter what!)

>> 2) The level you have working now is way too hard for a first level
>>     (even assuming you do the training level).
> 
> Yeah... last time I checked, out of 50 downloads, only 5 people or
> so made it onto the leaderboard (meaning a complete run below 100 secs).

I didn't even realise we were doing it against the clock!  *OUCH!*

>> 3) The problem with this level is that it has three hard problems
>>     and if you fail the second or third one, you have to 'die' and
>>     then go all the way back to the beginning.   That makes it a lot
>>     harder - but not in a good way - it's just really frustrating.
>>
>>     One thing that would help would be if there was a 'floor' under the
>>     basic level that allowed you to drive back around to the start so
>>     you didn't feel like you were 'dying and restarting' - it's a
>>     psychological thing in a game like that.
> 
> Interesting idea, however, it would really mess up your time without
> the restart, so after 10 attempts or so, your time is already so large,
> you don't make a chance on the leaderboard when you do make the complete
> run. Maybe a start-gate to accompany the finish-gate would fix that.

I hadn't appreciated that speed was a factor.  If you can do it at all,
you can probably do it pretty fast.

When there are multiple levels, maybe you should have two play modes -
one in which getting through a level (no matter how slowly) unlocks
the next level - and another mode that's against the clock.

While you are still working out how to do a level, the ability to go
round and round retrying it would be very useful - once you can do
it reasonably well, doing it faster and faster means that if you
fail even once then your time will be crap - so the restart issue
is less important.

>>     By dividing the 'floor' up with big vertical walls, you could arrange
>>     it so that passing the first problem level would get you past the
>>     first wall - thereby giving you access to a ramp that would let you
>>     retry the second problem without repeatedly having to retry the first
>>     one.   (This is hard to explain in words!)
> 
> I understand it. You want to preserve the progress you already made.

Yeah - somehow.  On longer stages maybe you can do automatic restart
points so once you've gotten through a couple of obstacles, you pass a
gate - when you fall off the track, you get restarted at the last gate
you passed through.

> Then again.... doing a complete run of all the stages on a string, is
> kinda rewarding when you do get there in the end.

Doubtless - but for a lot of people, they'll try that level five or ten
times - then give up in disgust.  There is no better way to put people
off a game by making them go back and redo the same thing over and over.

> But for a new and a much bigger level, your idea makes a lot of sense 
> to me.

I was assuming more/bigger levels would be coming in the future.

>> 4) It's annoying that you can get fatally 'stuck' and that the only way
>>     to proceed is to commit suicide.  That's a HUGE 'no-no' in game
>>     design.  There must ALWAYS be a way to finish the game if you are
>>     still alive.   In a game with real physics, this is a bit of a
>>     challenge since there are ways for the player to get stuck that the
>>     game designer couldn't possibly anticipate.
> 
> Yes.. I agree... I've been thinking about it as well.
> The 'upside down car' is pretty easy to detect, and is already handled
> by the game.

Yeah - but with a physics engine in control, there can be some amazingly
'creative' ways to get stuck.

I'm not sure what you should do about it - maybe there is a key you can
hit that causes a giant crane to swing over, pick you up and put you
back at the last reset point.  It would be FUNCTIONALLY the same as a
'suicide/restart' thing - but without taking you out of the 'game
world'.  It's a subtle distinction - but one that your players will
appreciate.

Like I say - having to 'commit suicide' in order to restart is a
real 'no-no' in game design because it's not something that would
EVER happen in the real world - in game design parlance, it's
"MetaGaming" - and metagaming is to be avoided at all costs.

> Getting your wheels off-ground, without being turned over causes the
> main problem. A possible approach is to detect fast-moving wheels,
> without any motion of the car-body itself, but then again... you could
> be doing a burn-out instead :-)

Yeah - but if you were just gradually making progress (like once I 
managed to use the steering to nudge me just far enough back onto the
track to get going again) - it would be REALLY annoying for the system
to kill you off.

If you had the giant crane (or something) then the user could ASK for
assistance when he needs it - because he knows better than your software
does when he considers himself 'stuck'.

>> 5) On startup, the game opened a large window that was mostly off the
>>     top-left corner of the screen?!?  I had to drag the window so that
>>     more of it was on-screen - then resize it and drag is some more
>>     before I could see all of it.  I've never seen another program with
>>     this problem?!?
> 
> I don't understand this.
> With 'a large window' you mean the main (and only window) of the game,
> right? The one that plays the revving engine animation, the menu, and
> the game itself?

Yes.

> I put glut in fullscreen mode, so it should exactly fit your screen.

It looked like maybe it was the size of my screen - but it was centered
at (0,0) - so I could only see the bottom-left quarter or so of the
screen.  I've never seen that happen before.

Which 'GLUT' are you using?  GLUT?  freeglut?  OpenGLUT?

>> 6) Use 'pw' instead of GLUT - it'll make life easier on your end-users
>>     because that's one less dependancy to worry about.
> 
> I'll take a look at pw, to see if it fits my needs.

It should - all you seem to be doing is opening a window and fetching
key up/down events.

>> My son says he's interested in making some more levels for you if
>> you are interested.  He has to finish an animation he's trying to get
>> into the 'blender' SigGraph show reel - and then he owes me some
>> work on my current game project (The Lemur of Lima) - but if you'd
>> like some help, he would be able to help out in a couple of weeks.
> 
> Yeah... that would be great. I was hoping on level design
> from the community.

I've always hoped for that in my games too - but never, ever got a
single usable level!

However, my kid is pretty amazingly good at 3D modelling work...and
he's on school vacations right now.

>> Is there any level design information out there?
> 
> Tricky stuff....

Yeah - I can understand that.

> modeling is very hard to do properly, using the Wings3d tool helps
> a lot, because the method of construction pretty much avoids
> problems with backfaces, wrong polygon orientation, non matching
> normals/orientation, z-fighting, etc. In fact, with wings, you can
> only create solid models, not e.g. a single triangle.
> With blender models, I've seen all the problems I mentioned above.

Well, not if the person who is doing the modelling knows what they
are doing.  For the game I'm working on, I designed a version of the
PLIB scene graph that was expressed in XML - with an XML writer in
blender and an XML reader for PLIB (although it's not a part of
PLIB for reasons too complicated to explain).

> The other complicating factor is that you need to be aware of
> OpenDE limitations to design levels for sturmbahnfahrer.
> 
> For the static scenery (e.g. the spikes) which is stuff that
> does not move, has no mass, and no velocity, etc, you can pretty
> much do every thing you want.

Right - but there are lots of interesting things you could model
like ramps and jumps and curving track sections - loops maybe.  But
yeah - we'd need to get to the dynamic stuff too.

> For the dynamic parts in the world (ferris wheel cart, magic carpet,
> jump board) you need to approximate these with very simple geometry
> (boxes). The car is approximated by a single box and 4 cylinders.

So would you want to see two versions of the geometry?  One for
rendering and one for ODE's benefit?

Seems reasonable enough.

> An object in the game has three properties:
> -OpenDE body (dynamic properties)
> -OpenDE geometry (used for collision testing only)
> -Plib geometry (used for OpenGL rendering)
> 
> Unfortunately, the opende geom and plib geom are very loosely coupled:
> The first is specified in C++ code, and the latter simply modeled.
> It is the responsibility of the C++ coder to make those two match
> by hand.

Ah - so you have to hard-code the dynamics stuff?  That's not so nice!

Could it be abstracted in some way that could be read from a file?
My recollection is that ODE uses a heirarchy not entirely unlike
a scene graph - but with masses, moments of inertia, etc.

> Due to all this required hand-work, level design is best approached
> by brainstorming on possible obstacles for the course, and then
> consult the opende mailinglist on how to model such an obstacle in
> OpenDE terms. After that, it is simply a matter of modeling a matching
> faceset to go with it, but basically, it starts with the dynamical
> model, and derive a visible model from that.

Right.

Do you have a mailing list for the game where we can take this
discussion?