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

[Bram S. <br...@sa...>]

steve wrote:

> Wow!  That's a really neat idea...fun to play too.

Thanks, Steve.... a good review coming from you means a lot.
=20
> I presume other game levels are planned - may I suggest a couple of
> things:
>=20
> 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.

>     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=20
avoid building against shared objects, for all the good reasons you
so eloquently put on this mailing list.
=20
> 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).

> 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.
>=20
>     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.

>     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.

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

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

> 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.

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 :-)

>=20
> 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?

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

It even worked on a twin-view setup with 2 monitors for me.

> 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.

> 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.

> Is there any level design information out there?

Tricky stuff....
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.

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.

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.

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.

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.

  Bram