This is the second post in our dev diary. We’re documenting our weekly progress on Mercury Shift 3D with this series. You can find the first post here. Maybe some words on our business model at this point. Mainly, we are making games. As making games takes quite some time and some talented people, it gets expensive. Sadly, we were not able to pull off a great iTunes hit or have a decent game in the Steam Store, but we found a way to make great games: We are using our talents and skills to work on projects that are not directly game related. Those works include interactive displays for exhibitions, visualizations and other things for many different clients. More pictures after the jump.
This week, we’ve been involved in some of those projects, so there won’t be too much process on the actual game. But at least there are quite a few pretty pictures to share with you :)
Rika has been working on bugfixing and improving the performance of the game. Especially tracking down performance issues is quite a hustle. There are a few indicators and the statistics of Unity3D help a lot, but still it sometimes feels like hunting your own shadow.
On the other hand she has been improving the interaction of the players with the environment. A big part of that is dealing with players colliding with other objects. Mainly, we are talking about the crates and boxes in the game. Detecting collisions and moving objects accordingly is a tedious task. Like most games, we’re using colliders for that.
The colliders are pretty basic geometric shapes that approximate the form of the character to avoid complex calculations that are resource draining. Usually boxes and spheres are used, but for one case we are now using a custom mesh. Replacing the box-collider with the new mesh, we are making sure that crates cannot be stacked on a character. They will always fall down, as the collider has a sharp angle.
Beff is building and testing the tutorial levels. This is probably one of the hardest parts of designing the game as the tutorials should be entertaining as well as teaching the mechanics of the game. In the past week, we had several playtests just for the tutorials. We are trying to constantly include player feedback, as this is a part of the game where you could end up losing a lot of players. We’ll see how that turns out.
This is one of the tutorial levels: The monitors we built last week for the tutorial are now in place and working. The gamedesigners filled them with graphics, screenshots for that matter. They work pretty well and I like the idea of them. When the players pass them for the first time, they are triggered. Anytime the players decide to watch the explanation again, they can walk back and trigger it again. See for yourself:
Mic and I have been to one of our customers and showed off our first ideas for their project. They were happy, we were happy, dancing ensued. Still being a coder, Mic worked on the moving platforms and their stability. Not a very visible feature, but they now feel better. Less glitchy. Also he implemented an object which can read some player stats and trigger other things accordingly. Why is this important? Because we’re reading out some of the players actions during the tutorial to make sure the player did actually do the task they were supposed to do. It helps us giving contextual feedback and showing maybe some tooltips.
Another thing he has been working on are sorting algorithms in C# for Unity3D. Sorting becomes important when some situations have to be analyzed to generate the expected results. For example if multiple crates are being pushed, it matters how much traction they create.
Meanwhile Simon, Elena and Niko have been working on the levels they received from the gamedesigners. They look pretty nice now, but have a look yourself:
Elena got together with Mic to create a light changer. It’s a new game object that triggers lights. It can be used to fade between two light settings and works on top of the lightbaked scene. So we both have artistic control and performance optimization. Nice. Bonus: It fades grey between the source and target colors to avoid disco-lights. Such atmosphere. Very glory:
Something we are finally tackling are the feedback visuals for Shifting and Swapping. The mechanisms themselves look pretty much the same, which makes it quite easy to mix up. The shift should feel really different to the swap. Simon is working on a few shaders to avoid the mixing up of the two mechanics. A first try can be seen here:
Alright, that’s it so far.