After a long pause, here comes the awaited blogpost of it all. It is a megapost, so we devided into a few chew-able bits. We have to catch up a bit with the devblog of Mercury Shift and we haven’t been posting much recently.
A lot of other things have been happening, I can assure you that. As a small teaser, here are some recent screenshots of the game:
But now here is what happened in the last few months in the gamedesign department:
Gamedesign work bees Oli, Beff and Matt did their best to make sweet honey. Occasionally they worked on Leveldesign and such.
We are not the biggest fans of hints in games. A poorly placed hint can destroy your game experience, as a lot of players do enjoy experimenting and trying. It is basically the core of any puzzle platformer.
But on the other hand you have a lot of people who get frustrated easily.
To make everyone happy, we thought of something we call a skill-based hinting system. It will display hints based on your current actions and on settings you can change.
So the gamedesigners implemented this system for skill-based hinting. Basically we are detecting the player interaction with objects and measure how long things take. As a lot of the riddles consist of combined actions, we were able to do this in multiple steps, so the puzzle won’t be unmasked instantly. We are thinking about implementing something like this:
Players should be able to play spoiler-free, so we should at least give them the option to adjust and even disable it.
Jochen and Anticipation
One of the game objects got named “Jochen”. It is a moving object, which can be used as a platform or as meat tenderizer for small players. The Jochen is famous for smashing a lot of playtesters into oblivion.
A known principle of animation is the concept of anticipation. Jittering preceeds the movement of the object, signaling its upcoming movement.
Now with this anticipation the Jochen is way easier to deal with, as the frequency of its movement is easy to predict. With that in mind, the gamedesigners were able to use it in a lot more contraptions. Good Jochen.
Chain Coins are a new feature which replaces one of the higher tier coins. Apart from being just more worth and harder to reach, they demand cooperation and quick reflexes to collect.
This gif gives an impression of the basic principle of the chain coin:
The coins can be collected only in a specific sequence, which makes it a skill and communication-based element. We feel that adding sense to most of the objects helps making the game a better experience.
Speaking of meaningful elements: The Bonus Object has always been a cool feature, but weren’t quite satisfied with it.
Before we reworked the object, it worked like a rubber band between the players. A coin was in the middle of the two players and they had to get close to each other to receive it. If one of them died, the coin snapped back into its original place and had to be collected again.
In the current version, the object is still hovering between the two players and it will snap back to its original position as soon as one of them dies. But to make it more interesting, the players don’t just have to get close to one another, they have to deliver the coin to a receiver. This means coordinating and maneuvering the hovering coin between them over a collection area. There it will snap to the station and both will get a bonus.
To create even more meaning, bonus coins will make it possible to unlock new bonus levels. At least that’s the current state of things.
Oh the barriers. Oh sweet barriers. Since their introduction they have been a much discussed topic. Barriers are a energy field like object, which can – depending on its settings – let pass and block different objects, such as players and crates. They can be switched on and off by either player interaction or scripted events.
They are a pretty easy to handle object, but their implementation and visual representation were not always easy. What would happen if a barrier is switched on while a player or a crate is in its target location? How do players realize that this barrier only lets players pass and that a very similar looking barrier blocks them?
The current solution looks like this:
Let’s hope that’ll work.
The camera is a difficult topic. Mic wrote a pretty elaborate system, that takes various things into account. Player position, distance between players, deadzones and points of interest all influence the movement of the camera.
But the camera is more than that: It allows players to leave the active screen for only a few brief moments, so it’s also an active game element.
A new addition to the level editor is the minimum and maximum setting for the camera. It overrides most of the other rules and forms a fixed area in which the camera can act freely and influenced by the other camera nodes. It IS complicated, but it works. And a dynamic camera makes the game feel better by a whole mile. That’s 1,609.344 meters of improved gameplay.
Part of the problematics arising from camera movement are specific request by the artists and the general limits of level boundaries. The levels aren’t suited for a full camera movement, as we do not have a designed world outside of camera bounds. Now everything should be just fine.
The joy of stepping on to a bounce platform is known to those who own a trampoline. Or those who watch Community (http://www.youtube.com/watch?v=orcT0Vk1A3s).
Both characters are now able to jump equally high on the platforms. We discovered whilst playing multiplayer that this would be necessary for a smooth gameplay.
The fetch is an ability both players have. Before the updates, a player could “fetch” lost coins, i.e. he could attract dropped coins and absorb them. The ability did not affect active coins which hadn’t been previously collected. Now with the new fetch in place, players can even catch the juicy fresh coins.
We added this mostly for consistency, but it actually makes the whole function way more fun. Look at them!
Alright, that’s it for Gamedesign. Next up is the code department :)