|
 |
The_Field: a square of <0,0,0> to <10,0,10> on the y=0 plane.
The_Ball: an object that has these properties:
i) #declare The_Ball= box{<0,0,0>,<0.5,0.5,0.5>}
ii) it's randomly placed in a manner such that its volume is entirely
contained within a box{0,<10,1,10>}, and rotated, i.e.,
rotate 360*rand(R)*y translate <0.25+9.5*rand(R),0,0.25+9.5*rand(R)>
iii) considered dense and rigid with "really high" kinetic coefficient of
friction with the ground.
The_Goal: a box{0,1} centered at <0,0,-10>
The_Actor: your SDL programming genius, technical and artistic. Its "base"
if any has to start at a position of Z>0 and outside The_Field.
Object of game: write a file such that it renders your Actor starting
outside The_Field, figuring out where The_Ball is, and transporting its
center of mass (any rotation) to the x, z coordinates of The_Goal in an
intelligent and reasonable fashion. You should reasonably account for the
physics on a cube of whatever you do to it. Fair play would involve not
making access to the actual position of The_Ball as a variable, but fair
play wouldn't frown upon a gazillion trace calls against The_Ball. (If
you're making a gazillion trace calls, try to animate something that
visually represents this information-gathering process-- is it a dwarf
walking around with a laser, or what?)
Examples of Actors:
a) One of the simplest ways to move The_Ball might be with a big,
boring-looking wedge made out of two rectangular boxes that come along and
push the cube into the goal. But you gotta be able to program a realistic
view of what happens when your wedge bumps into the box-- it's probably at
least going to rotate.
b) A hundred photorealistic basset hounds, modelled in Blender, walk
sniffing through the field and when they bump into it, bark until a flying
eagle swoops over, picks it up, and takes it to The_Goal.
c) An extended robot arm with multiple elbows gropes around the field until
it finds the box, picks it up, and carries to The_Goal.
Just an idea.
Post a reply to this message
|
|
