The current state of affairs

by Max

The summer is nearing an end and schools begins yet again. This means that both my and Lukas’ focus will shift quite heavily towards the subjects we’re being taught, and the amount of time spent on Semest will diminish to the level of the occasional evening and or weekend.

As one of the last “heavy tempo posts” i’d like to show the current state of the project.

On my part, the past couple of weeks have been spent on a number of things including

* Improved ball and chain behavior, making it more “physical” and heavier.
* Added initial game-pad support.
* Created two kinds of levers and a gate that can be bound to one.
* Initial work on a “heavy drag” state for the animation and player orientation
* General improvements of sound functionality.

You may notice the occasional “relaxed pose” moments when Semest is moving around, this is the current placeholder for what later will become an animation where he is slightly bent forward, expressing a general sense of strain. This is activated when his movement is in some way restricted. Like when the ball goes the opposite direction, there being a slanted hill. Or when pulling a lever.

Near the end i intended to show of Semest being pulled of the ledge due to the balls state changing when of ground, but due to the nature of the resulting force being straight down, he instead gets stuck on top of the platform. Something that will have to be polished away to give a better behavior.

Lukas has diligently been continuing his work on the rest of the map, but i should leave the details to him.

Our current goal is to someday in the future complete the first level and then release that freely as a proof-of-concept. What we do from then on is not decided as of yet.

That’s it for now. Feel free to share any form of criticism.

Early sound functionality

by Max

Last week i spent most of my time getting some functional spatial sound into the game using OpenAL and stb_vorbis.

The current state is somewhat limited as we’re currently only able to play simple looped sounds that are placed around in the world.

In the future we intend to extend functionality, be able to bind events, soundgorups etc.

 

Creating the Lava Stream level

by Lukas Orsvärn

I recently finished the second pass on the Lava Stream level, and other than a few small things here and there that need to be fixed, it’s all looking pretty good!

After I had decided what part of our world I wanted to create first, I tried coming up with a layout for the level that would provide some interesting gameplay. Then I started the first pass where I created a very simple layout for the entire level just to make sure everything actually fit and worked together like I had imagined it.

During the second pass I have been working in stages. From the first pass all the walls and the ground is flat, so I start by increasing the amount of geometry that I have to work with by subdividing the walls and ground.

Then I craft the geometry into the shapes I want, like cliff faces or rocks and so on, and once that is done I add seams to the mesh that designate where the seams will be in the UV map when I UV unwrap the model.

Then I apply textures, unwrap it, scale the UVs to an appropriate scale and make sure there are no places where the textures are too big or too small.

The last thing I do is vertex coloring, I use this to give some depth to the geometry, without it the levels look very flat as you can see above. I tried using automated methods at first, but I couldn’t find any that would produce good enough results.

The next step would be to add more detail to the level like smaller rocks, particle effects and so on.

This entire process is very time consuming, and for the future I’ll be looking into ways of speeding it up. I’ve been considering creating several separate objects that I place to create a level instead of making each part unique (like Aubrey does for Overgrowth). I’m not sure that approach would suit our kind of game though, so I’ll have to do some experiments.

What do you think about my level creation process? Do you have any ideas for ways it could be improved?

Improving the chain behaviour using splines

by Max

I ended up getting rather tired of the look and feel for our chain. So a couple of days ago i started working on improving it.


A slightly older version

Early on the setup was rather simple and straight forward, What i did was that i had a series of physics objects attached to one another using joints. Each representing one link in the chain. Each end of the chain was then attached to the player and ball respectively.

This worked, kinda, but not in a satisfactory way. It was quickly quite apparent that the instability of such a contraption would be quite severe, especially when there are object with wildly differing mass joined together.

What we had was something that easily teared apart and jittered like crazy, it was ugly, and worse, it wouldn’t pull the ball when the player moved unless the mass of individual links where in the same magnitude as the ball and player. This with a link count of around five to seven, increse this number and the result would blow up by itself.

The current state of the chain is somewhat different.

First of all, most of the dragging and other motion control is performed manually and not handled by the physics engine, thus the purpose of the chain has become cosmetic.

Secondly the way the chain is rendered has changed.

While we still create the chain physically in a similar way, each virtual link encompasses multiple “visual link” making each physical link longer.

I them employ a catmull rom spline along the bodies of the links in the chain on which i then render the links along.

The result is shown in this clip.

There’s still some issues with how the links are placed along the chain. It becomes evident as the chain “piles up” and is shortened. It ends up separating and sticking out in different places in a way that isn’t very pretty. Not at all actually.

There’s also some ugly clipping in the player and “dragging” of the attachment points. But overall, i was quite pleased with the improvement. It just feels better.

Progress on Lava Stream area

by Lukas Orsvärn

Most of my time the past few weeks has gone into creating the Lava Stream area. There are a few new textures and a lot of the terrain has been completed.

Only a small part of the level is left for the current pass, then we need to add some puzzles, more detail, optimization etc. There’s still quite a bit to do, but we’re getting there!

We recently went out and took some reference images of cliff walls and rocks, so hopefully I’ll be able to make a good rock texture for the walls to replace the current one soon.

Some notes about tweaking variables

by Max

Working in a language that needs to be compiled into binary code have several drawbacks. There’s always some time required to compile and link a program before even a minor change can be ready for testing. This can really slow things down when tweaking things like running and jumping.

Often it’s interesting to only adjust a float to have something move slightly faster or rise somewhat higher in order to achieve that feeling of “just right”. And in a situation like this, having to wait for as much as a 20 seconds can really mess with the flow of the work.

One way to quickly get around this limitation is to use a decent debugger which allows you to adjust variables during runtime. This works great, especially for variables you never intend to touch ever again. However this is not always the case. The nature of arbitrary values is that they tend to stop feeling right as other things change in the world, and this happes more as a game grows and becomes increasingly complex.

Another approach is to have the program read an external configuration file at startup that is easily modified with a texteditor. This way the tweaking isn’t only limited to a developer, but is also accessible to others, like artists (who are usually better at these things in the first place).

We like this approach, so i took some time to put together something that saves all of the static configuration parameters into an xml file during shutdown and then loads it back up into memory at start. Using xml for things like this seems like a rather good idea as it allows for human readability, categorisation and the use of third party software (for loading and management).

There’s still a drawback though, as the user have to restart the game everytime she makes a change. So, to make it easier for us we even took it a step further and added an ingame console, with it we can list, view and modify different parameters during runtime. Which makes the tweaking even easier.

The console is easily extendable to allow for other commands which might prove to be useful for the duration of the development.

Early look at lava stream area

by Lukas Orsvärn

Since I’m now finished with the animations for the main character, I’ve moved on to creating a first area for the game.

Much of the time spent on this has been experimenting with what I can do with Ogre, testing how the materials work and so on. There’s still a lot to learn, but it’s nice to have something in engine and working!

As you can also see in the video, Max has been working on a console, level loading, saving and loading settings and more, he might go into more detail on those subjects at some point in the future.

Ingame movement and ball-motion

by Max

For a couple of weeks now i’ve been working on the core function of the game engine. Using ODE and Ogre i’ve been trying to create and render a chain with a ball attached to it. Sadly there are some severe restrictions and instabilities that  plague modern physics-engines and our planned usage, where we would like to have a system consisting of multiple joints interacting, doesn’t make that problem any less apparent.

It will require some work to get the system more stable, and we have to consider alternate solutions to the particular problem of dragging around a large object that is attached to the character via a bendy/jointed contraption.


So far I’ve managed to reach some kind of stability where the chain doesn’t explode into an iterative mess, but to get the gameplay the way we dream will require a lot more work.

I’ve also been working on a controllable main character. This is something that we feel is necessary to perform early testing of the assets being created by Lukas.

 

Semest Initial Animations

by Lukas Orsvärn

We’ve all been away for a while now since we have been helping Max move to a new place, but now we’re back in business.  I showed some concept art of our main character Semest in my last post, and lately I’ve been working on the model and animations for him.

This video shows some early work in progress animations for Semest. We’ve got him in the engine already, but his code is not ready to be shown in action yet.

Since these animations are still a work in progress, they’re probably going to change a bit before they’re done, do you have any suggestions for what could be changed?

Creating an efficient toolset

by Max

The goal for the past week has been to get some early physics running in the game. So far I’ve been developing everything on Windows, but it wanted to try to set up and compile the project on Linux to see how well our current methods would work and how easy it’d be to get it running.

Earlier I chose to use Code::Blocks as the IDE of choice for our project. But as I started looking into it more, and reading up on how to compile Ogre I came across CMake.

CMake is a cross-platform, open-source build system with support for most major platforms. The really neat thing about it is that it can export the project into any number of different IDE’s and environments, thus unlocking us from using any specific tool beyond CMake itself.

I’ve seen and heard of CMake before, but I never really took the time to read up on it in detail. But thanks to how well Ogre is prepared for it and even offers examples on how to create basic projects, I started feeling heavily inclined to do so and now we have our project set up use CMake, thus far i’m quite pleased with it.

After putting down some time into the build system and getting everything to run on Linux i started working on getting a quick ODE test running, and thanks to the really helpful demos and the in-depth manual i now have some simple physics running and rendering, next up is playing with joints to see what we can and cannot do for the main game mechanic, and see how well a “realistic” physics representation of it might function.