Experiences:LOCV         The experiences of the creators of LOCV

NOTE: This article is work in progress!



About

Legend of Crystal Valley is a classic 2.5D adventure game. 2.5D means 2D backgrounds and 3D characters/objects.
The game was being developed by a former Croatian developer company: Razbor Studios, but the project failed and was held in a drawer for years since that.
In 2006, Cateia Games purchased the IP from Razbor and started development from scratch in PythonOgre.

Software and tools


You can read about why we chose that software configuration on Tibor's page as they are the same.

Theora Video Plugin

The game's design required the use of video. We tried all options and finally settled with Theora Video Plugin for Ogre, originally developed by pjcast. The plugin worked okay, but it left something to be desired in the performance department. So I took over leadership of the project and have at the time of writing this been able to boost performance up to several hundred percent. Most notably using frame precaching and shaders to decode YUV->RGB wherever possible.

Occlusion

Hidden geometry

Often, in an adventure game, you need to place 3D objects behind and above some objects in the scene. Since the scene is 2D, and the world 3D, some magic is required :-)

So we've decided to use a method called "Hidden Geometry" : Simplified meshes of objects that need to be in front of characters are rendered only in the Depth Buffer.
So, when characters are rendered, their pixels that are further away from the camera then those of the hidden geometry are not rendered, and thus, appear correctly in the scene.

Another useful side-effect of this method is to provide shadow receivers for stencil shadows.

Overlays & Underlays

When we need some graphical elements to always be above characters and are not shadow receivers, we use Overlays pasted on top of everything. This is usually an image with an Alpha channel.

Underlays are usually used to show objects that can be removed from the scene.

Hot spots

Hot spots are regions of an image that can have an action assigned to them. On the right you can see one such example in our game.

We've implemented it in a way that each colour represents a different action which is then bound with a -Python function in runtime.
A hotspot image is painted in Corel PhotoPaint, exported as PNG and coverted to a quad-tree representation to reduce memory footprint. (The simplest way would be to load the image as an Ogre::Image, but that would take 3MB of RAM per scene.)

Movement

Pathfinding in LoCV has been done in a somewhat unusual way, an algorithm I thought of by accident which proved to be a perfect choice for an adventure game:

  • walking is limited by an enclosed volume of bounding planes
  • each plane has a center point, a direction vector and a radius (as can be seen on the screenshot). This radius is a distance from the center of the plane, and determines the area which the plane bounds.
  • additionally, we've extracted edge points which are extruded from the edges to simplify the intersection algorithm

Algorithm

  • if two points can be connected directly, then a character walks in a straight line
  • if not, then pathfinding (dijkstra's variant) finds the shortest path to connect the two poins (as seen on the second screenshot
  • Ogre::SimpleSpline is used to smooth the path line.

Toolchain

  • Our artists draw a simple silhouette of the boundary in a 3D modeling program and export it to ogre mesh format
  • The -Python script parses that data and creates appropriate bounding planes and edge vertices
  • A debug key shows a visual representation of the walking boundary as can be seen on the screenshots.

Dialogs

...

Chapters

...

Data

...

Variables

...