History: Experiences:LOCV

Source of version: 11 (current)

{IMG(src="img/wiki_up/Locv_title.jpg",thumb="y", stylebox=border, rel="box[g]",width="300",align="right",title="Legend of Crystal Valley by Cateia Games ([http://locv.cateia.com/gallery.htm|screenshots])", button="y")}{IMG}

* __Full game title__: __[http://locv.cateia.com|Legend of Crystal Valley]__
* __Developer__: [http://games.cateia.com|Cateia Games]
* __Year of release__: 2009
* __Type__: Commercial
* __Target Platforms__: Windows, Linux, Mac, Nintendo Wii
* [http://www.adventuregamers.com/article/id,987|Preview @ Adventure Gamers]
__NOTE: This article is work in progress!__
---

{maketoc showhide="y"}

!!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
* __Programming Language__: ((-Python)) 2.5
* __Main library__: [http://www.python-ogre.org|Python-Ogre] (v1.6)
* __Other libraries__: ((OIS)), ((-CEGUI)), [http://connect.creativelabs.com/openal|OpenAL]
* __Ogre plugins__: ((TheoraVideoPlugin|Theora Video Plugin))

You can read about why we chose that software configuration on ((Experiences:Tibor|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
{IMG(src="img/wiki_up/Locv_occlusion_01.jpg",thumb="y",button="y", stylebox=border, alt="Occlusion: OFF", width="100")}{IMG}
{IMG(src="img/wiki_up/Locv_occlusion_02.jpg",thumb="y",button="y", stylebox=border, alt="Occlusion: ON", width="100")}{IMG}

!!!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 ((mesh))es of objects that need to be in front of characters are rendered only in the ((z-buffer|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 ((overlay|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
{IMG(src="img/wiki_up/Locv_hotspots.jpg",thumb="y",button="y", stylebox=border, alt="Hotspots", width="100")}{IMG}
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
{IMG(src="img/wiki_up/Locv_path_01.jpg",thumb="y",button="y", stylebox=border, alt="Pathfinding boundary", width="100")}{IMG}
{IMG(src="img/wiki_up/Locv_path_02.jpg",thumb="y",button="y", stylebox=border, alt="Pathfinding example", width="100")}{IMG}
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 ([http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm|dijkstra's] variant) finds the shortest path to connect the two poins (as seen on the second screenshot
* [http://www.ogre3d.org/docs/api/html/classOgre_1_1SimpleSpline.html|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 ((vertex|vertices))
* A debug key shows a visual representation of the walking boundary as can be seen on the screenshots.

!!Dialogs
...

!!Chapters
...

!!!Data
...

!!!Variables
...
History: Experiences:LOCV

Source of version: 11 (current)

Search by Tags

Latest Changes

Search

Online Users
