Hi dudes!

After the Artistic and Design post by William, it’s time for a little tech post!
I’ll try to write a not so boring post by exploring 3 tech points used in Seasons.

> Camera type change (orthogonal to perspective)
The biggest change in the engine is the new possibility of building levels in a real 3D way.
This is what the levels looked like so far, with a 2D construction approach:

Scene organized in 2D layers

We can notice that there is no constraint in the distance between the layers since the camera used ingame uses an orthographic projection. There is no perspective in there and all the stuff is well flattened in one projection plane.

As you can see, the trees got a different scale depending the layer they belong to. This scale was done by hand (by William) and were here to give a kind of perspective to the scene by simulating distance between background and foreground.
Each tree occupies 2 layers : one for the leaf and one for the trunk, allowing us to display the scene in the correct order.

The river was a special textured quad deforming itself depending the camera position to make a parallax between the foreground and background quad vertices.

The new approach consists in thinking the map as a real 3D environment. Now each object position has got an importance because the camera use a perspective projection. With this in mind, two identical objects (like the trees) with a different position in space will have a different visual sizes in the image produced by the perspective camera point of view.

Here is an overview of what such a 3D disposition looks like :

Scene using a 3D positioning

There is no more layer disposition and real 3D objects can be inserted into the map without problem (the river and the cave are real 3d meshes).

Of course, the majority of objects are self contained in one plane (example: the trees have got their trunk and leaf gathered in the same plane).

Here is a view from the game camera point of view, for both 2D and 3D approaches:

2D way

Scene with a 2D layering and ortho camera

3D way

Scene from a perspective game camera

Each approach has got pros and cons.

– With a 2D approach, we can easily build a scene from an artwork. We can also cheat a lot on object positioning since the camera allow this. But it’s really tricky to tweak all the parallax factors and make a scene with a good depth without having some floating objects.

– With a 3D approach, we do not care about parallax factor and layers anymore, but we have to place all the objects carefully. We can insert real 3D objects or objects that can be spread along the Z axis (depth axis).

In the end, our engine is compatible with both kind of map and we can use those methods depending the complexity of the level we want to build.

> Seasons is not a physics game

We love physics games (especially Petri Purho games and World Of Goo), but we don’t want Seasons to be a physics driven game.

Right now, we use a physics engine (Box2D), but we only use it to detect collisions.

The physical objects placed in the physics engine are all kinetics. This means that the physics engine do not apply forces on them until we said what forces should be applied.
Therefore, we script all physical links within our script system (pivot link, gravity, friction, acceleration…).

Let’s take a look at a first behavior of a physics link (a pivot)

In this video, something like a dead tree saw is equilibrium disturbed by a programmer rock and our debugging fox. The lurching speed and power are scripted thanks to the presence of colliders.
Moreover, the rock is not ejected in the air until we script this behavior.

But we can easily change the rules of the physics link by altering the script behavior:

Here the rock has no influence on the physical pivot. This example is maybe too simple, but we are happy to be able to script more complicated gameplay elements involving physics links.

> Post Process

As you know, we do not have much time and money to produce a high amount of textures for Seasons. William came with a clever technique to increase the look of the game: some Photoshop filter.

Here is the scheme to obtain the image shown in the end of the last post:

Photoshop and its magical way of mixing things

The Photoshop Filter had to be reproduced in-game (in real time). To achieve this, we need to make use of shaders and find out the magic formula used by Photoshop to get this color blend. It’s time to get Google and RenderMonkey (my favorite tools to test things out), and here we go:

A shader that takes 1 line and less than 100 characters

Then we can use this blend in game, mixed with other ones.

> The rest
In the end, I’ve done some additional test maps to illustrate some gameplay mechanics that William will integrate in its real level by using his favorite tool: Blender.

I added few features to the tool and some bug fixes to make the William’ experience more peaceful.

Now we have things like a material cache browser or file checker which will take care that the Blender features used in a map are supported in the engine. If not, it will stop the export with some clear log or even try to fix the problems by itself!

The T-shirt I should buy for William

See you soon!