“Your game is shipping in 3 days. What has to be added to make it work?”
Although this is not the actual situation for us, the statement (or question for that matter) helped us quite a bit in this week.
So there is this opportunity to show the game to somebody in the industry, who possibly will be able to propel it much further. That’ s pretty awesome, but at this point the game is not ready for shipping. We are working on a vertical slice and are not even halfway through this vertical slice. So the project is not in a perfect state for deployment to an external reviewer, to be honest.
Thus we had a meeting in which we discussed, what the most important things to include in the version to ship would be. A bunch of things were mentioned, to get the game “feel” right. The game should work and feel at least close to that what we will be shipping in the end.
Maybe some hours on the weekends will be spent to further improve the build, but it seems like we will get it done tonight.
It’s interesting to see what kind of things pop up as soon as you actually have to send it. Usually you’re always part of the playtest. There is always the possibility for us to say “oh that’s not ready yet. We will be adding XYZ to improve.” and so on. But now, with an upload and download, there is no one explaining the game and maybe helping someone who is stuck at some point. No chance. So what should we do?
Another week, another update. This week in development has been pretty exhausting, as we are encountering a few difficulties and some tasks became tedious to work with.
Lightmapping is still a big challenge, to be honest. When coming from software like 3ds Max, Beast for Unity offers good results, but behaves a bit like a black box. There are a lot of settings to change, but it takes a lot of time to see the effect of that.
On top of that, Beast seams to crash when baking selected objects for no visible reason. Quite possibly the fault is on our side, but at the moment we cannot reproduce it reliably and file a bug report. We’d really like to contribute to the fixing of this stuff…
But enough of the bad news! On to the gifs and stories.
Mic has been working on the so called “wires”. Wires connect objects and show the relation of those objects. For example a pressure plate is connected with the associated door.This helps player to orient within the game and understand the puzzles. The riddles should be readable and easy to understand. So when creating the art for the levels, we are mostly working within Unity3D, instantiating the already imported assets and placing them. So most of these assets are used multiple times to reduce drawcalls and overall performance. As the riddles tend not to be the same over and over again, wires themselves are similar, but each single wire is unique. Creating them and importing them would take some time and make the process very inflexible.
So Mic created a node-based tool in which the end points of those wires can be set and chamfered. A process we know from most 3D software. The wires can now be refined within Unity. Mesh is generated with UVs already applied and so Simons great shader can do its magic on the wires.
Simon has added some shader magic, and boom: it looks cool. More images after the jump.
These devdiary posts are being crafted on the content the Klonk Games team works on a daily basis. The team is not very big, but nevertheless we do lose sight of some parts of the project. When you are working on your own things for the game, you tend to miss the work of other people.
So these weekly posts are not only to keep up a public track record of our, it serves also as a very personal documentation and information for the other team members. Every week I am surprised, how many things made it into the prototype and how much work has been done.
This week is another rather big update, at least visually. But have a look for yourself!
Usually it is my job to write all those posts, go to local events and keep contact with the general public and keep an eye on our media presence. This week and the week before I took a bit of time off those tasks and was able to work on some assets that are going to be part of a laboratory stage.
These are objects that we plan on using in the first tutorial levels. They should be part of a research lab kind of stage. The so called “game design objects” i.e. buttons, levers, death-zones and those kind of things will all be in this kind of visual style. They are the same throughout the whole game and they do net get adjusted to the stage.
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.