Demo dev diary - Week 2 news

Hi there! Here we go for the 2nd weekly dev diary of the making of our Seasons demo that we will show next September in Paris.

PROGRAMMING

> Path
The week began by implementing Blender path support in the game engine. A Blender path is made of a tridimensional curve parametrized by a 2D curve (called speed curve). Here is a Blender screenshot of such curves:

A 3D cube is set in the 3D View (on the left) and follows the path. On the right, the 2D curve is our parametric speed curve that indicates how the objects will follow the path. In this specific case, the speed curve indicates that the object starts moving from the beginning of the path (frame 0 of the animation) then goes through the whole path and reaches its end at frame 99. Then the object will go backward from the end of the path to the middle of it, between frames 100 and 150. Eventually, the object will return to the end of the path from frame 150 to 250.

The speed curve drives the position of objects along the path, but it also drives their acceleration. Paths are going to be useful for us because we can attach anything to them: visual objects, effects or even camera (to make cutscenes).

> Particle emitters
Until now, there were no particle effects in our engine. This week was the opportunity to begin a very simple and funky particle code.So far, we need only 2 kinds of particle emitters:

- Trails
Trails use paths (see the above paragraph) to produce some rangy effects. Here is a simple example in a test map (sorry, no time to make video right now, but soon…):

- Spawners
Spawners create particles with different sizes, velocities, lifetimes and initial positions (by using some randomness and constraints bounds) and we use them to generate effects like rain or snow.

Each effect needs specific parameters to be defined. Snow particles will be quite big and have a low velocity while rain particles will be narrow and have a high velocity speed.

Here are the first early tests:

To have a snow or rain particle effect on the entire screen, we need the spawner to follow the camera and create particles in a rectangle that fits the screen size. As a consequence, we have 2 kinds of emitters: local and fullscreen.

If we simply move a local particle emitter with the camera, we will notice some holes where there are no particles. This is because the particles are spawned randomly in a rectangle region and there is no special reason for the new particles to fill the holes created by a camera movement (the holes are situated in new areas discovered when the camera moves).

To fix this issue, we move living particles that are leaving the camera frustum to put them on the opposite side of the camera frustum. So we are doing some repeat particle wrapping. This wrapping is done only for fullscreen emitters.

Here is an example:

Particles are colored depending on their spawn position to allow us to see the phenomenon. As you can see, the left and right screen borders got particles of the same colors. This is because the particles on the right have been moved to the left border thanks to wrapping process.

Here is what the snow particles emitter looks like in the scene shown last week:

There is still some tweaks to be done, but the result is fine for now. We will increase the quality later, when all gameplay features will be implemented.

LD/GD/ART

> Art
After a first time working on the early game screens, my non-graphist brain wasn’t able to picture perfectly how atmosphere, colors and settings elements should be represented, I felt like it was better going back to good old paper works. This is why I printed all collisions maps and use them as a base to scribble on it.

Some of the draws were scanned back to my computer and colorized just to figure out the amount of work to do, and to reassure myself a little. Once my doubts were dispelled enough, I’ve done some asset creation again, including a waterfall that now exposes its dancing vertices on screen.

First in game waterfall integration

> Level Design
After printing collision maps, I figured out that some parts should be added and others (a lot of them) should be moved. The screens numbered 10 and 11 were the most reworked ones. The aim of the modifications is that the obstacles’ succession should become more smooth and natural, and requires more seasons’ changes to get through difficulties. More over, such changes help the learning of gameplay elements.

LD modifications