Over the course of the last weeks a lot of things were implemented and tweaked in order to get our project to a point where the core gameplay is finished. So we thought it would be nice to create a small video that shows the progress we made over time and share it with the rest of the world.

Enjoy watching and happy holidays!

Core Team:

• Christoph
  • Lead Programmer, Scripting,  Physics, Gamedesign
• Dominik
  • Leveldesign, Maya Production Pipeline, Models, Gamedesign
• Sebastian
  • Projectmanagment, Scripting, Sound, UI, Gamedesign

3^rd party:

• Christopher
  • 2D-Artist
• Karl
  • Music

And that’s how “TheBall Game” looks at the moment:

The Block Editor

The block editor is use two create so call blocks for the track editor.

The picture shows the shelf for the block editor. The left two buttons will be explained in another post. The other buttons are to insert platforms in different sizes into the scene. The shelf is automatically filled with buttons by scanning a define folder for maya files with this different sized platforms in it.

global proc TheBallBlock() {
 global string $gBuffStr;
 global string $gBuffStr0;
 global string $gBuffStr1;

 string $tempDir = "D:/WS09_The_Ball/Production/Model/Element/Boxes//";
 string $blocks[] = `getFileList -folder $tempDir -filespec "*.mb"`;

 for ($i in $blocks)
  {
  string $block = `substitute ".mb" $i ""`;
  string $short[];
  $numTokens = `tokenize $block "_" $short`;

  if($short[0] == "Box")
   {
   shelfButton
    -enableCommandRepeat 1
    -enable 1
    -width 34
    -height 34
    -manage 1
    -visible 1
    -preventOverride 0
    -align "center"
    -label $block
    -labelOffset 0
    -font "smallFixedWidthFont"
    -imageOverlayLabel $short[1]
    -image "commandButton.xpm"
    -image1 "commandButton.xpm"
    -style "iconOnly"
    -marginWidth 1
    -marginHeight 1
    -command [Here has to be the command to import maya files]
    -sourceType "mel"
    -actionIsSubstitute 0;
  }
 }
}

This is a part of the script to fill the shelfs with buttons. The next picture shows a “turn block”.

The Track Editor

The track editor uses the blocks out of the block editor to create a track.

The picture shows the shelf for the track editor. The three buttons on the right show block elements that can be inserted currently. This shelf is also automatically filled with buttons by scanning a folder for the blocks created before. It also loads a picture of the block into the button, but this pictures have to be made by hand. In difference to the block editor the elements of the track editor are imported by reference ad instance. This makes it possible to make slight changes in the blocks without having to build all the tracks new to update the block elements. The next pictures shows a simple track created with our current block elements.

An in-game movie coming soon, with a new texture design.

Last week we had many many meetings, but there was time to develop

We are proud to show you the actual version of the game in the video added to this post. The controls are now implemented and tested and we can control the avatar with a gamepad, thanks to pygame! Our Avatar changed a little bit, because of feedback we got. We also decided our Art&Style which is going to be very dark with glow-effects and transparency.

Last but not least we solved our problem with the missing artist part in our team. We  found a 2D artist who is going to produce fancy textures for TheBallGame.

Best regards

TheBallGame Team

camvec = self.ball.getPos() - base.camera.getPos()
camheight = camvec.getZ()
camvec.setZ(0)
camdist = camvec.length()
camvec.normalize()

if (camdist > 20.0):
    base.camera.setPos(base.camera.getPos() + camvec * (camdist - 20))
elif (camdist < 15.0):
    base.camera.setPos(base.camera.getPos() - camvec * (15 - camdist))

if (camheight > 0):
    base.camera.setPos(base.camera.getPos() + Vec3(0, 0, camheight - 0))
elif (camheight < -3):
    base.camera.setPos(base.camera.getPos() + Vec3(0, 0, camheight + 3))

self.ballPosHprDummy.setPos(self.ball.getPos())
self.ballPosHprDummy.setH(self.ball.getH())
dirVec = self.desiredCamPosDummy.getPos(render) - base.camera.getPos()
dirVec.setZ(0)
turnRate = 0.1
base.camera.setPos(base.camera.getPos() + dirVec * turnRate)
base.camera.lookAt(self.ball)

So what’s this mumbo-jumbo all about?

Let’s have a look at it step by step:

• First we get the vector pointing from the camera to the ball and store the difference in height between those two in camheight and camdist.
• The next part of the posted code is responsible for the camera following the player with a distance of at least 15 and 20 units at max (first if…elif statement). The second part makes the camera follow the ball on the z axis (which is up and down in Panda3D). What’s important here is that the camera is not directly set to the player’s height, which would give it an unnatural feeling – instead it starts matching the height when the given threshholds are surpassed.
• In the last part, we are using the ballPosHprDummy and desiredCamPosDummy NodePath objects to adjust the camera rotation with a slight delay. The desiredCamPosDummy is parented to ballPosHprDummy and (in our case) always 15 units behind ballPosHprDummy (the code to setup this hierarchy is not shown here). This can be used to get a vector from the camera’s current position to its desired position, which is then used to bump it a small part along this vector (influenced by turnRate) to get closer to the desired position. You may need to tweak the turnRate variable to adjust it to the turning speed of your game character!

Closing thoughts and notes:

This way to handle the camera may be a little hacky and will most definitely see some changes (just think of problems like the camera intersecting / getting occluded by objects) on our journey to the final version of the game, but as a drop-in solution for quickly testing our basic gameplay, it worked like a charm!

Also note that there may no need for something like the ballPosHprDummy in other kinds of games. We just were not able to parent desiredCamPosDummy directly to the ball, because it is spinning most of the time (Well, there was a short moment where we didn’t mind this that got us a little dizzy when starting the game…).

Another fly over movie rendered in maya.

The picture does not show this very well. That’s why we created a little movie with a flight around the map. Another point we tested was the exporting of this camera motion path to use it for map intros and overviews.

This video is showing the latest version of TheBallPrototype. The prototype was created with a custom engine and used game mechanics which are going to be replaced in the final version.

This is the actual game version. It’s using the PhysX integration and pygame for gamepad support.