ROBLOX in 2016 and beyond

We are creating a platform where, each month, over 15 million people come to play games, create, learn, and imagine with their friends. At peak times, there are over 500,000 concurrent users playing ROBLOX across all platforms, including mobile, computers, Xbox One, and now VR. On ROBLOX, users can share experiences together in family-friendly immersive 3D worlds where they can imagine what it’s like to work in a restaurant, be a fashion model, survive a natural disaster, and much more. All of these experiences are created by our community, where over 500,000 builders each month are continually providing an infinite variety of things for people to explore and do with their friends.

This year alone, we launched ROBLOX on the Xbox One, which continues to be the top free downloaded Xbox One game. We also launched on Oculus Rift with cross-platform capability. As we continue to add more and more platforms to our portfolio, the growth of ROBLOX continues to exceed all expectations. Everything that we do today and in the future will adhere to our vision of driving social immersion and co-experience, powered by user-generated content.

VR gaming scene in 2016

Virtual reality is a relatively new frontier for many traditional games businesses, but there’s an even bigger opportunity that’s still burgeoning. As virtual reality matures, a new category known as “social co-experience” will emerge and will ultimately surpass video games. Typically, platforms like Minecraft, ROBLOX, and Second Life have been associated with video games. However, what separates these platforms from conventional video games is that they are powered by user-generated content. Today’s AAA video games don’t always provide the variety or the social graph one might find on these platforms because big budget titles are limited by certain market factors.

In the past 10 years, we’ve learned what inspires our users and we’re constantly learning about their changing behaviors and patterns. We found that our developers are creating experiences that go beyond traditional games. They are creating experiences that mimic what kids will play in the real world, such as hide and seek or tag. We are also finding that our developers are also creating immersive role-playing experiences; they can build a world where users can imagine what it’s like to be a high school student or what it’s like to manage your own supermarket. Being able to co-experience and imagine with friends in an immersive social environment is what keeps people coming back to ROBLOX. The future of VR is social.

Indie gaming scene in 2016

Today’s technology allows anyone to create content and share it with the world. Platforms like ROBLOX give young independent developers the opportunity to monetize their creations through a shared economy and ultimately create successful endeavors from the comfort of their own home or anywhere around the world.

ROBLOX is fostering the growth of many budding game developers, some as young as 13. These developers are creating new and emergent games and experiences you wouldn’t necessarily find on other app stores. Many of them are also utilizing our Developer Exchange Program to take virtual currency they earned from their ROBLOX games and convert it into cash. To date, we have paid out more than $6 million to our developers, and they’re using these funds to pay for their college tuition or to advance their careers in game development.

This summer, we have also invited 14 ROBLOX community members to work in-house on their games together with our R&D teams as part of our Accelerator Program. We enjoy working hand-in-hand with our community to support their aspirations as game developers. We take great pride in watching how these talented developers find their passions as artists, creators, and coders.

Mobile gaming scene in 2016

The mobile gaming scene today is brimming with gimmicky, limited, and two-dimensional experiences that don’t always operate on the social graph. ROBLOX and other platforms like it are looking to spearhead the development of cross-platform, 3D mobile multiplayer gaming. Many of our user-generated mobile experiences can also be played cross-platform with other devices, including PC, tablets, and Oculus Rift.

AAA games development scene

AAA game studios produce enormous, beautiful games. But because of their huge budgets and long development cycles, they cannot deliver the volume or the infinite variety of experiences you can find on ROBLOX. As a result, AAA game studios, like blockbuster movie companies, tend to invest a lot of money to develop titles they know will be a hit, rather than cater to the niche interests of consumers. This is where ROBLOX and other user-generated content platforms like YouTube succeed. We appeal to the user who wants to create and play anything they imagine.

ROBLOX’s plan for the future

ROBLOX is focused on the future of play. Our vision is to empower the imagination of kids and teens so that they are encouraged to create and think outside of the box without boundaries or limits. As new platforms like VR emerge, you’re going to see ROBLOX become more and more immersive as environments continue to look increasingly real over time and co-experience play becomes more robust. It will be easier to find your friends and have a rewarding social experience in VR. In terms of content creation, we will continue to offer accessible, easy-to-use tools to create amazing VR experiences. Our developers will have the power to make their VR games more transformative and immersive than ever before.

Everything that we do today and in the future will adhere to our vision of driving social immersion and co-experience, powered by user-generated content. We want to satisfy a core human need that not only incorporates communication and storytelling, but doing things together.

In the next ten years, ROBLOX will continue to provide the foundation for immersive 3D gameplay, while simultaneously elevating the graphical fidelity to that of today’s CGI films. On the social spectrum, more and more users and their friends will immerse themselves in the world of ROBLOX using their virtual reality headsets. As our top developers begin forming their own game studios, ROBLOX will branch out into more and more entertainment mediums and platforms. All the way from connected smart toys to potential licensing deals based on the biggest ROBLOX properties, we are excited to forge the future of play.

Steam Early Access could be described as the Wild West of the gaming industry: The rules have yet to be written, authority has yet to establish any kind of firm grip, and great fortunes seem to await everyone who goes there. However, with Valve’s recent move to establish more rules and guidelines for Early Access, that may be changing. It certainly gave our whole team at Skara, The Blade Remains much to ponder, as developers for one of the last Early Access titles to be released prior to the new guidelines.

So here are my thoughts on the Early Access topic in general, what the program is good for and whether the new guidelines help make those aspects better.

"When it came to Skara’s Early Access, we thought it would be important to offer something back to these players willing to invest, so we have pledged that all Early Access members will get their money back as in-game currency and several limited edition in-game items once Skara is fully released."

Firstly, Early Access is a key way for indie developers to get their product out to the people as quickly as possible, bugs and all. And the play time Early Access purchasers put in is useful to most indie developers in showing them how to improve their projects. In Skara’s case, this is certainly true.

So why are first adopters paying for the privilege to play Early Access games? Why isn’t it the other way around?

Indie titles run a huge risk by putting themselves on Early Access. Nothing could be easier for players than to rip the experience around the incomplete game apart, and with it the morale and confidence of the game’s developers.  Making players pay for the privilege of playing acts as a kind of barrier to bad reviews and ensures that those taking part are invested in the process.

When it came to Skara’s Early Access, we thought it would be important to offer something back to these players willing to invest, so we have pledged that all Early Access members will get their money back as in-game currency and  several limited edition in-game items once Skara is fully released.

In that sense, the new guidelines are really good. It is in both the developer’s and the purchaser’s best interest that they know what they are signing up for. And although the onus is on the developer to make sure that communication is clear, it is not altogether in their power whether secondary sales sites use that communication. One clever way around this, which is mentioned in the guidelines, is to include the words ‘Early Access’ in the title of the game.

Secondly, Early Access is a good way for new titles to test their concepts on a real audience. Making even a simple game requires thousands upon thousands of small decisions, things that are often difficult to alter after the fact. Having even a small group of dedicated players helps designers and developers make those decisions.

"Early Access purchasers also take a risk by buying the game, that the game won’t get finished. It is completely normal that some users are starting to mistrust these projects. They are right. For the last two years a few studios tried Early Access as the last attempt to save their games, but because the sales were below their expectations they were forced to close the studio, unable to deliver what they promised."

With a game as complex as Skara, this is doubly true. Our community was helping with ideas from the beginning, in forum discussions about combat mechanics, etc. Turning our targeting system into a manual one was a crazy three months task, but we did it because our players asked. And they were right, the game is much better after this unexpected change. And I could continue for days describing how helpful our players have been since we released our game on Steam.

So for the developers, Early Access is a huge win, and for the players it is also a win—they end up getting to have input into a game—hopefully turning the relationship with it from ‘like’ to ‘love.’

Of course, making a game is a huge, and hugely expensive risk. Lots of developers can only afford to make games in their spare time, while holding down full time jobs. For the ones that go full time, failure has very serious consequences attached. They are heroes to me: for each new version of Call of Duty, there are thousands of small developers working their tails off to amaze and entertain you. Because THAT is the only reason they do what they do: passion, and a job that is a hobby to them.

Early Access purchasers also take a risk by buying the game, that the game won’t get finished. It is completely normal that some users are starting to mistrust these projects. They are right. For the last two years a few studios tried Early Access as the last attempt to save their games, but because the sales were below their expectations they were forced to close the studio, unable to deliver what they promised.

"After all, arguably any kind of entertainment investment is a risk. A movie may be lousy, a comedian might not be funny, the food at a restaurant may not be to one’s taste. Why should games promise anything more?"

As a user, it would be completely normal to be bummed out and even angry if this happens. But really, that kind of risk pales in comparison to the risks the developers make.

After all, arguably any kind of entertainment investment is a risk. A movie may be lousy, a comedian might not be funny, the food at a restaurant may not be to one’s taste. Why should games promise anything more?

In that sense, the new guidelines telling developers to launch only if they can afford to without sales and “to set expectations properly” do seem a bit harsh on developers, especially indie developers. Customers should be warned, but at the same time developers should be given some recognition for trying to create, even if they fail.

All in all, the new Early Access guidelines are a really helpful way for developers to think about their Early Access plans and establish their Early Access communications. We hope to see many more games go the way we have by opting for an Early Access and we hope many more gamers will see the benefits of playing Early Access games.

Note: The views expressed in this journal are those of the developer and do not necessarily represent the views of, and should not be attributed to, GamingBolt as an organization.

As it turns, a lot. Resogun became the highest rated PS4 launch title and even gave competition to the Xbox One’s launch lineup. Despite its relative length, the game was beautiful, addictive and still an incredibly engrossing experience for shooter fans.

Housemarque is now busy on DLC for Resogun that is reportedly awesome. But how did it all begin? Did Housemarque wake up one day and decide to make an awesome game? Community manager Tommaso De Benetti penned an exclusive dev journal for GamingBolt in which he discusses the inspiration and development of Resogun from the concept stage, along with how the developer went about using the PS4’s power to bring it to life.

Overall development from the concept stage to code:

In the beginning there were voxels. Everything started from the technology. At the time, our Creative Director Harri Tikkanen and the tech team came up with an idea: “Wouldn’t it be cool to build a game entirely out of voxels?”. So we started working on that concept, and from that three games emerged, all based on the idea of being built with voxels. One became Resogun (interestingly enough, that has been the name for the project since the start), one became the iOS project we are currently working on (with rather drastic changes, as voxels are not the main thing anymore), and one didn’t make it out of the prototype stage.

The name “Resogun” was chosen because we wanted to make a game that would bring to mind the 2D shooters of yesteryear. Those games had such an impact on everybody’s imagination because of their bitmap graphics, and since voxels are 3D pixels, we crafted the “Reso” prefix thinking about “resolution”. The “Gun” was more about attitude, as we knew it was a game about blowing stuff up.

Resogun started as platform agnostic. While in the prototype stage, we were running some code on PC and targeting different Sony platforms. As we proceeded, it became more and more clear that to fully express what we had in mind we would need a lot of raw power. Building all levels and enemies out of voxels turned out to be really expensive in terms of computational power, especially when you consider that there are no “fake physics” in Resogun.

Early mesh concept. Open the images in a new tab to see it in full screen.

Every cube behaves according to a specific set of physics rules, and each one of them enjoys its own lighting. When I talk about a “specific set” of physics rules I mean that we had to decide what was good for gameplay and readability and what was not. For example, it’s possible to blow up the entirety of a level, but that wouldn’t be very fun, since after a few explosions there would be very little standing up to work as a background. For the same reason we decided that if you destroy the bottom of a building, the rest of it doesn’t immediately collapse on itself.

"In the beginning there were voxels. Everything started from the technology. At the time, our Creative Director Harri Tikkanen and the tech team came up with an idea: “Wouldn’t it be cool to build a game entirely out of voxels?”. So we started working on that concept, and from that three games emerged, all based on the idea of being built with voxels."

For quite a long time the game didn’t feature the graphics you see in the final product. We went through several concepts: some were more retro, some much more colorful. The original prototype we used to pitch the game to Sony relied a lot on red and blue hues. Nailing the visual style was a long process, and we had several meetings with Sony XDev Europe, the publisher, before we hit the sweet spot of what Resogun is nowadays. There were some concerns regarding the “retro” aspect of it: we wanted it to bring to mind old games, but we didn’t want it to look old and unappealing, especially when we had this really amazing voxel technology that worked so well with lighting effects.

So, while hard at work on the way the game looks, the team was also down to the nitty gritty iterations of gameplay. Over the months things have changed quite a bit in all the key areas of the game. There have been builds featuring “options” (like Gradius or R-type), meaning some small drones circling around the ship and adding firepower to your ship. For a long time we only had one central tower where the player had to deposit both humans and green energy cubes to generate power ups.

In this version the humans run around a treadmill and build the weapons for you – that idea was abandoned because it made the gameplay gravitate too much around the same spot. Experiments with a weapon shop worked great, but the idea was abandoned because it slowed gameplay too much between phases. We were also planning a World Map to track players’ progresses – that was axed because it felt like an unnecessary layer between the player and the action.

The gameplay elements associated with humans have evolved over time as well: for instance we used to have “normal” humans, “special” humans, and even “expiring humans” – all that is pretty much gone now, with the possible exception of the Throwing Human button, born as part of a “refill-human-energy” mechanic and kept because it was just fun to use.

One of the most crucial choices we had to make involved the “twin-stickness” of Resogun: we experimented with the possibility to shoot at 360°, but it didn’t feel right because it turned the player into some sort of “moving turret” – move a bit, shoot in every direction, move again – so in the end we settled for left and right. If we had made the opposite choice back then, you’d be playing a very different game now.

The more the development advanced, the more we started to feel the need for a powerful hardware: to realize our vision any other platform wouldn’t cut it. The concept itself – a cylindrical world around which the player has to pick up humans and fend off aliens – can work pretty much on any hardware, but not when you throw into the mix voxels, physics, lighting, 1080p and 60fps. So the more we talked with Sony, the more we agreed that Resogun needed to be on PS4.

Creation of high definition assets optimized for 1080p:

Despite the similar appearances, the levels and enemies in Resogun are built in different ways. Levels appear to be aligned to a rigid grid – that fits with the architecture style of the game; enemies are built following another logic entirely: first of all they tend to show organic shapes such as curves, plus we needed to make sure that they appear as clearly as possible as elements of the gameplay – avoiding the possibility of them being confused with the background.

"The more the development advanced, the more we started to feel the need for a powerful hardware: to realize our vision any other platform wouldn’t cut it. The concept itself – a cylindrical world around which the player has to pick up humans and fend off aliens – can work pretty much on any hardware, but not when you throw into the mix voxels, physics, lighting, 1080p and 60fps. So the more we talked with Sony, the more we agreed that Resogun needed to be on PS4."

Talking about 1080p, the lack of SD limitations means that we were allowed to design enemies, humans and pick ups in a specific way, using maximum contrast between blocks, shadows, etc. To make a long story short, if the game was working at a lower resolution, all these elements would literally look different in shape. The same is true for texts and particle effects: at 1080p we were able to communicate effectively abstract concepts without stealing estate from the gameplay.

Because of their importance in the game, we couldn’t use pre-exsisting photographic skyboxes. So we started to do them by hand, trying to convey that feeling you have when you look at an open sky through your eyes rather than through a camera – a wide, baroque stretch of clouds.

The level backgrounds were created using first simple meshes, then converted to hollow cube geometries. The final touches were done by hand, so we could make things look the way we wanted.

Physics and particle engine Insights and GPU usage:

All of Resogun physics is directly offloaded to the PS4 GPU using compute shaders. As mentioned earlier, for gameplay and readability purposes we didn’t opt for a 100% realistic physic model, but we clearly needed something powerful enough to calculate all voxel collisions.

Regarding particles, there’s not many of them in the game. Examples are the effect used for the Overdrive – which is a mix of compute shaders and point sprites – and some of the things flying in the background. For the explosions we opted for a legacy particle system used in previous games, one that doesn’t involve the GPU at all.

Use of unified memory and how it helped offloading the tasks:

Using Unified Memory means that the CPU and the GPU share the same memory. The main advantage of this setup is making the game code communicate with the compute shaders much faster, like we did in the case of particles and voxels. Another way we used it was for the enemies’ code: that was written in the Unified Memory, so the GPU could read it directly.

Challenges faced due to PS4’s slower CPU speed/Core Speed and targeting 60fps

One of the main advantage of consoles over PC is that, independently from the CPU speed, the console-specific libraries are usually much faster than comparable libraries on PC. Reaching 60fps was our goal from the beginning, because it makes the gameplay so much more fluid. It wasn’t a terribly hard result to achieve: all game code is heavily multithreaded, so all available PS4 CPU cores were put to good use.

Audio Creation

The goal of the original Resogun soundtrack – composed and played by our friend and collaborator Ari Pulkkinen – was to reflect the arcade history of gaming, combining modern electronic genres and styles. The main references include Daft Punk’s Tron Legacy OST, M83′s score for Oblivion, and the Transformers score by Steve Jablonsky. The Super Stardust HD soundtrack was also used as a reference, even though we knew Resogun was darker in tone and needed something a bit different from its “spiritual prequel”.

We started from a couple of concepts: it had to sound like a tribute to “old school” games (namely, those from the C64/Amiga era) and we wanted it to sound chiptune. Over time, the songs changed to reflect the changes in art style: the darker the game became, the less we relied on chiptune as an inspiration, moving progressively into more modern electronic soundscapes.

"One of the main advantage of consoles over PC is that, independently from the CPU speed, the console-specific libraries are usually much faster than comparable libraries on PC. Reaching 60fps was our goal from the beginning, because it makes the gameplay so much more fluid. It wasn’t a terribly hard result to achieve: all game code is heavily multithreaded, so all available PS4 CPU cores were put to good use."

No real instruments were used. It took Ari about 3 months to make it sound just right – some things made it just in time, for example the boss themes were completed just before release, together with the final visuals for the bosses themselves. When all was ready, we mastered it at the famous Finnish studio “Chartmakers”, which among their clients features artists such as Rammstein, Amorphis, Sonata Arctica, The Rasmus and a bunch of other bands. A lot of fans expressed their desire to purchase the OST: we should finally be able to make it available this year – more info about that in the next few weeks.

When it comes to sound design, Ari and his collaborator Alexander Dmitriev created over 1000 unique sounds effects. On average, the game mixes about 100 different sounds at any moment. The approach was what they call “oldskool chip-board sound design”, and it was heavily influenced by what old school games have done in that regard. The final mix for the sounds took almost two weeks: obtaining the perfect result required heavy iteration.

A lot of effort was put into the LFE channel. We wanted the bass to kick ass – and hopefully you can hear that! One final note on the female voice giving hints: she seems to have a lot of supporters, and yes, she’s the same “voice” you can hear in both Super Stardust HD and Dead Nation. Unfortunately, no further details on her origin are available, – for now, that will have to remain a mystery.

Resogun was awarded Best PS4 Sound Design by IGN last year, so all in all I think our efforts paid some dividends.

Adjusting and fine-tuning the gameplay, and controller input for the console:

The last few months of development were mostly dedicated to fine-tuning the gameplay, finalizing the UI and wrapping up the bosses. We knew the main game mechanics were in place, we just needed to take some decisions regarding the scoring systems, multiplier, amount of humans per level, etc.

"As a developer, there’s never enough time, and there’s always something you can do better. And indeed, the months since the launch of Resogun have shown that we could still do a lot to improve the overall gaming experience. Most likely you’ll see the results of the extra development time very soon."

When you make intense games with a high replay value, the most important thing is iteration. Test an idea, judge the result, then try to change it up and see how that works. Rinse and repeat. That’s what we usually do in the final stages of development, until we can’t find any room for improvement or, most likely, time runs out. When it comes to Resogun, even now that we are working on additional content, we have a new build each day, each one slightly different from the previous one. The team compiles an iteration, then gathers with Internal QA to play it, and then everybody goes back to their desks to work on a better, improved build.

Just before its GamesCom debut, the guys were literally banging on the keyboards minutes before the taxi that was supposed to take us to the airport arrived, and the same scenario pretty much repeated itself when we sent Resogun for final QA.

When it comes to the PS4 controller, we realized that the embedded speaker was to be used to communicate important events to the player when distraction was out of question. If you have played Resogun at the hardest difficulty levels, you know there are some parts you have to face while being “in the zone”: hesitate for half a second and the score is ruined. In retrospect we feel that the announcer speaks a bit too much, often prioritizing things out of context. So, one thing you’ll notice in future updates will be less speaking and more focused audio feedback.

Closing Words:

As a developer, there’s never enough time, and there’s always something you can do better. And indeed, the months since the launch of Resogun have shown that we could still do a lot to improve the overall gaming experience. Most likely you’ll see the results of the extra development time very soon. As the saying goes, the devil is in the details: getting a shippable product is not the hard part, being happy with the fine-tuning… that’s another matter entirely. Luckily for us, players seems to like what we shipped, and I have no doubt they will love what’s coming next.

Frozenbyte Studios’ marketing manager Kai Tuovinen offered his thoughts on PlayStation 4 version, documenting the changes from the game’s initial inception to the final stretch, how the new content fundamentally changes the game overall and the process behind the level design.

Overall development from the concept stage to code:

The concept process for Trine 2 started already during the development of the original Trine; We had learned from our experiences on the aftermath of our first game, Shadowgrounds, that we should immediately have a follow-up project after a game was complete. So the decision to make Trine 2 was made quickly, and from early on we began planning the improvements and new features – many which were left out from the original Trine (sometimes due to time constraints and sometimes because they would have clashed with other existing features/design).

Since Trine 2 was a sequel and the gameplay was very similar, we didn’t use any grand design documents to cover the entire game. Instead, the design team focused on doing documentation for different core elements of the game: The new skills and abilities, enemies, interactable objects and puzzles – basically everything gameplay related was thought out.

"A lot of the things you see in Trine 2 are custom animated and the famous frog scene is a good example. It was originally modeled and animated for use with our Trine 1 engine back in 2009/2010, but broke completely when transferred over to the new engine. It took over two weeks to get it working and that seemed like time wasted – but the frog became one of the most iconical scenes in the game, so it was definitely worth it!"

There were a lot of things to consider, since all the puzzles in Trine 2 are pretty open ended and can be solved in a number of ways. Adding a new skill can drastically change how certain things interact with each other, and with physics involved a lot can happen with very minor changes, so balancing was important!

For example, it was important to limit the amount of wood used, so the Thief character couldn’t grapple onto everything (her grappling hook attaches only to wooden surfaces, and can easily become overpowered).

Once designs for different features had been finalized, our programmers began work on them, and in the meantime they had done a lot of work on rewriting our game engine. In fact, the programmers spent more or less the entire year from summer 2009 to summer 2010 and even beyond to rewrite the whole game engine, aiming for a modern engine with multiplayer features and other improvements over the original (including ”save anywhere” save system and a million other things that had bugged us throughout the early years).

We had a concept artist who painted a lot of environments and enemies to help with envisioning the different levels and the story created by our writer.

Also a lot of the concept art was used in the game itself as assets in the background, some could be found in secret chests and they were also used in the storytelling screens in between maps.

Here the Dwarven Caverns concept art comes to life in the actual game: 

The different levels in Trine 2 were first mapped out by our level designers, who place and design all the gameplay assets to begin with. They start with a basic pathing for the map and add collision detection to limit where the players can move around and interact. Different types of puzzles are then built into the levels, and physics-based properties are defined to make the different parts work as intended. We use a lot of different elements to the puzzles such as fire, water, weights, ropes and levers, and creating puzzles with good variety for 20 levels takes some time.

Enemies and their AI are added next, often scene by scene. The main recurring enemies in the game are goblins of different varieties, but we also have environment specific enemies such as flesh-eating plants or wyverns, and the boss fights vary more: They’re often puzzles of some sort.

The grey and brown-colored areas are collision indicators – usually placed early on during level development.

Different components of a lighting / electricity related puzzle at the end of the Cloudy Isles level. You need to redirect the lightning to hit the water, and balance something on the device to connect it to the electric current.

When the levels are completed from a gameplay perspective, one of our senior artists starts adding art assets (modeled and textured by other artists) that really make the scenes come to life. A lot of the things you see in Trine 2 are custom animated and the famous frog scene is a good example. It was originally modeled and animated for use with our Trine 1 engine back in 2009/2010, but broke completely when transferred over to the new engine. It took over two weeks to get it working and that seemed like time wasted – but the frog became one of the most iconical scenes in the game, so it was definitely worth it!

We were quite happy with Trine 2 when it was released during the end of 2011, but at the same time we again knew that we had left a lot of cool ideas on the drawing board and it would be cool to implement some of those into the game. At the time of Trine 2’s release we were toying with a couple of interesting game concepts, but we decided that those weren’t yet ready for full-blown production, and set to work on the Goblin Menace DLC for Trine 2.

We really felt that this would be the definitive version of Trine 2, and the team was very happy with the quality and detail of the 6 new levels and the new skills for the characters. We combined the original campaign and the Goblin Menace campaign, along with the new level Dwarven Caverns, for the Director’s Cut version (2012, Wii U) and also to the game Complete Story version (2013, PC, PS4) – both versions are basically the same in content.

Decision to bring Trine 2: Complete Story to PS4

"For the PS4, prior to the launch much of the documentation was incomplete and some times not translated to English. But in the future these should get filtered out when more development is done for the console, and there's not such a rush as there was during launch time."

The decision to bring Trine 2: Complete Story for the PS4 was made fairly early on after the console’s announcement. The success we had on the Wii U with Director’s Cut made us work hard on getting the game ready for the PS4’s launch, since being available from the get go of a new console taught us the benefits, and we really wanted to be there for the PS4 launch. We didn’t actually get the devkits for the PS4 until around half a year ago, so the porting process was started very quickly and we wanted to make it to launch.

Another reason to bring Trine 2: Complete Story to the PS4, was that finally another console (besides the Wii U) was powerful enough to run the new levels from the Goblin Menace expansion without optimizations, and those were integrated into the game for Complete Story. For the PS4 we quickly learned that we could even increase the resolution and framerate and run the game steadily, and even add 3D support (which had been working magnificently on PC already).

Engine development and how the engine was ported over to PS4

Our game engine has been running on the same tech (although constantly modified and improved) ever since it was rewritten after Trine 1 – so it was made with Trine 2 in mind specifically. After Trine was finished, our programmers re-wrote the entire engine from scratch, which took over a year, but that allowed us to bring many wanted features such as online multiplayer to the game.

Generally speaking the PS4 port was easy and required little work. The Wii U port was somewhat harder, but that was mainly due to the required work on a lot of input support, as there were many different controllers and of course the touch controls of the Wii U GamePad. Our engine has typically behaved well when ported to different platforms, and we have quite a bit of experience of ports now (Trine 2 is on PC/Windows, Mac, Linux, Xbox 360, PS3, Wii U and PS4), so that has certainly helped with new platforms.

In the past three years, there’s been tremendous development on our engine, and one of the big new features we are aiming for now after multiple ports is to further streamline our code to be transferrable to all the relevant future platforms that we decide to bring our games to.

Each port has typically the same things that need to be done specifically for each platform: input support, multiplayer game support, profile & save file support, achievements, getting SDK’s for physics (e.g. PhysX), audio (e.g. Wwise) and videos (e.g. Bink). Also every console platform has their own set of requirements (PS4 TRC, Xbox TCR, Wii U Guidelines) that need to be adhered to as well. In theory they are quite similar on each platform, but all of them do have some specific ones as well. These were a bit of extra work (implementation + testing + fixing). For PC and Steam we can pretty much publish anything we want without requirements.

Also the game’s menus always need some customization, and tool tips that match the platform’s controller.
For the PS4, prior to the launch much of the documentation was incomplete and some times not translated to English. But in the future these should get filtered out when more development is done for the console, and there’s not such a rush as there was during launch time.

The PS3 port was a lot of help for the PS4 porting process, a great deal of miscellaneous code was ported almost directly through that one. Probably the biggest job was the renderer, where we had to remake some things slightly, such as shaders.

Of course when we aimed for launch we knew that we were making a port/game for a device that wasn’t on the market yet, and the consoles we had at our office were practically prototypes, so some unexpected problems were natural. Sony was helpful throughout the development process and we got all the problems (which were very minor things) sorted out quickly, even though many of the issues we experienced were entirely new to them as well. So being a launch title for PS4 did require a bit of extra work, but it was nevertheless the easiest of our ports so far.

Controller input for the console

On the PS4, input was straightforward to work with and we had no special issues. The touchpad is similar to a touch screen, so making the controls work based on our Wii U touch screen controls was fairly easy.

There was little to no new things needed, only some adjustments and applying those to previous controls which we took from our Wii U port. On a low level, the API on the PS4 is very simple (even easier than PS3, but nothing majorly different from most platforms) and there was enough documentation to help us through.

Even up to the launch, we did not have any final version of the new PS4 controller (DualShock 4) which had some impact on the touchpad support, although this did not necessarily change anything. The protytype controller had slightly different material, which felt a bit weird, but on the final released controller the material felt much better and nice.

Asset creation along with optimization for 1080p resolution

The art assets that you see in Trine 2: Complete Story are all 3D-rendered objects, even everything in the background. We have several 3D-modelers who create those objects, some animators, and one very busy texture artist.

The famous frog scene – a normal screenshot and the another from our editor, with wireframes and a different angle, that show the 3D objects that make up the scene.

We haven’t done anything specific for the PS4 to optimize the assets for 1080p, because the console was able to run the game without any problems at a solid 60fps. The only difference is that the PS4 version had a rewritten renderer which does some very minor visual changes almost unspottable to the naked eye.

Sound development

We worked together with AriTunes for the sound design in Trine 2. Most of the sound effects came from AriTunes, but their implementation was handled in-house. For the sound engine, we used Wwise by Audiokinetic, which enabled us to do many audio design tasks without requiring code.

"We haven't done anything specific for the PS4 to optimize the assets for 1080p, because the console was able to run the game without any problems at a solid 60fps."

In the Trine 2 editor, we made general components for the most typical situations such as point audio, collisions and movement sounds. If making a general component for a situation is not possible or reasonable, sound playback can be controlled with communication between different game object components inside our editor – sound components send events and parameters to Wwise, and Wwise plays back the sounds based on those determined properties.

The workflow for sound design inside the level editor was roughly as follows: First we add the areas controlling the playback of background ambience sounds and non-interactive point audio. Then we set up interactive sounds that can be made with single components, such as sounds for different types of rotating and moving objects. At last we add sounds to the more complex puzzles, where the conditions for sound playback are determined by the state of components in the game objects.

A few examples:

Rotating and moving objects are very common. For those, we have designed a sound component that sends data to Wwise about linear and rotating movement speed in parameters. For example, a platform made out of wood and metal that rotates gets this component added to it in the editor; we determine it to play a certain sound event and to send the rotating speed as parameters to Wwise. In Wwise, for the rotating sound we set curves with a samplerate and we set the sound volume, and determine them to use the rotating speed receieved from our game engine.

A sound event call from our game engine can also do more complex things in Wwise. For example the damage sound from the Mummy Goblins is a set of multiple sounds combined – mostly different hits and vocal incoherent rumblings. When the event is called, the hits and incoherent rumblings are played, in such a way that sounds from both sets are played in a random order, and we avoid playing the same sound effect consecutively.

Adjusting and fine-tuning the gameplay

In the past two years, there’s been a number of changes to Trine 2. Most notable ones came to fruition when we released the Goblin Menace DLC, where a number of new skills were added to the characters. For example we added magnetism-related skills to the Wizard and Knight characters, and all the 13 original levels had to be reworked to include new properties for metal surfaces, so the skills would be useful in all the levels and not just the 6 new ones.

We’ve also done an extensive number of bug fixes over the few years. Porting the game to different consoles has the benefit of revealing issues that might not have otherwise been found. QA teams from different companies tend to find different types of bugs, but most often though they are console-specific. Our own internal QA has done a good job of ironing out the majority of gameplay bugs, and there’s a notable difference between the 2011-released Trine 2 and Complete Story.

Adjustments and changes to extra content such as Dwarven Caverns and Goblin Menace

For the Goblin Menace, our artists had a more lenient schedule for completing the assets and levels, and they produced some of their best work. The Goblin Menace and Dwarven Caverns levels had entirely new and different looking environments and we also added more frequent cutscenes, which helped a lot with the story – we think the Goblin Menace campaign is our best storytelling work so far.

Content-wise Trine 2: Complete Story is nearly identical to the Director’s Cut that we have for the Wii U, with the exception of one secret Nintendo-themed room in the Dwarven Caverns level, which can only be found on the Wii U version – a small tribute to Nintendo who we loved working with! The Complete Story on PC and on the PS4 are identical in their content.

During our Computer Science study we started to build a 3D game engine in our spare time. Along the way we created some game prototypes. Of course, with us being new game design enthusiasts, our first game ideas were far too complex ( we even did some Motion Capture!) and with a group of only technical people most prototypes didn’t look very appealing. Luckily, at the Global Game Jam in 2009 we met our experienced graphics artist.

For our first earnest game attempt we wanted to keep things simple. Also because we decided to only work one day a week and keep our regular day jobs. Soon we decided to create a game inspired by the brick-breaking game Breakout, which is a fairly straightforward game with simple mechanics. We decided to breath new live into the concept by converting it into 3D, use real-time physics, and juicing it up with modern graphics.

Our vision changed a lot during development. The first prototype of Caromble! focused on destroying cities and a growing ball (Katamari Damacy style). When showing it publicly people were already pretty positive about that version, but we wanted Caromble! to be more than just another Breakout. So we thought of more features to create a unique game, like bringing the 3D world into the gameplay, adding pinball mechanics, introducing puzzle elements and creating a distinctive atmosphere and tone for the game.

For us, working on Caromble! is a great journey. Brick-breaker and pinball games have a very fixed set of gameplay mechanics, but there is still so much you can do with a  few extra things. We are still discovering new ways of combining  our current feature set to create interesting gameplay and that’s very exciting. We can’t wait to share it with you!

Stay tuned for the next entry in this developer’s journal and please vote for Caromble! on Steam Greenlight.

Written by Pascal van Beek, Developer of Caromble!

Developer journals is an ongoing series at GamingBolt which aims to give our readers an inside look into the development process of video games. These journals are written by game developers  who share their experiences/difficulties etc while developing the game/engine/middleware. You can find and read more Developer Journals here.

Hello Gaming Bolt readers! I am Laurent Ancessi, a game developer at Mojaro, a small indie studio that makes 3D games for mobile. Previously I was the A.I. lead on ‘Uncharted’ and ‘Medal of Honor European Assault’.  The very first game that we released was ‘KnightScape’. It is a runner that mixes parkour and sword fighting. The fighting game-play of ‘KnightScape’ was really cool so we thought that it would be great to make another game involving sword fighting.

We all agreed that fighting against an NPC is not as fun as fighting another player over the internet so we decided to develop an online multiplayer game where you could fight your friends online in epic battles.

The last problem we had to solve was the user interface. In ‘KnightScape’, the controls are not easy for everyone. Jon, our technical director, proposed that we let the player decide in advance which strategy of fight moves to adopt. Perfect!

We implemented the core game in just a few months and it was immediately so much fun to play. However, we were still missing that special ingredient that would make this game addictive. Chris, our designer came up with the great idea of adding a puzzle game that would boost your stamina for your fights.It was at this time ‘Puzzle Knights’ took shape. We then added on the Facebook feature that allows you to challenge and play with your friends online.

The whole Mojaro team is very proud and excited to launch ‘Puzzle Knights’.

Hello readers of GamingBolt! My name is Nick Padgett, and I am the sole developer of Irritum. I am 22 years old, and live in Woodstock, Georgia (Close to Atlanta). Irritum is the first game I have finished, and will be the first one that I will release.

For those of you who are not familiar with Irritum, it is a game that deals with the topics of suicide and depression. The game takes place after the player has attempted suicide, and while they are stuck in a coma in reality, they are trapped in limbo elsewhere. Throughout the game, you must choose whether to try and remember why you committed suicide or not. The gameplay is that of a 3d platformer, but with a twist. You need to activate platforms with mouse-clicks to be able to land on them.

Early in development, I decided that I wanted to make an emotional game that dealt with topics such as suicide and depression. I decided this because I wanted to make a game that would stand out from the competition, and address topics not many games have talked about before.

"The Wonderful 101 sports a unique visual style that combines elements of Viewtiful Joe, Hideki Kamiya’s earlier game, with a colourful overlay of Rayman Origins."

For that reason, I have decided this Journal entry will also be about emotions, specifically the emotional toll the game had on me while I was making the game. Many people think working on a game is fun and exciting, and while it is, it is also very stressful and depressing. In this journal, I will share how creating the game affected me emotionally and mentally, and how it challenged the design of the game.

To get a better idea of how this all ties together, let be give you some context on my history. I do have a history of depression and some suicidal thoughts. I did not seek or get treatment. I still occasionally get these feelings, and this game may have inhibited or exaggerated these emotions. I used this to my advantage, and I was able to have a lot of insight with the topics of the game, but it also hindered the development of the game.

Nervousness. During development, I was plagued by constant nervousness. Why? My biggest fear is the fear that I will be a failure. I don’t want to be known as the developer who makes bad games. Who does? I wanted my game to be as good as possible, while still maintaining the message I want the game to carry. But I always was (and still am) nervous that people just won’t get it, or maybe the game is just uninterpretable, and the game is bad.

"Depression. This goes hand in hand with nervousness. I consider myself depressed for a majority of development. I was worried my game would suck, and would be hated by everybody. I was worried I would drop the game and give up. I was worried my girlfriend would leave me."

Normally, people would hire play-testers to find out what is bad about the game. I didn’t have that luxury (for the most part). I opened the alpha and beta for people to play as a web-player, but nearly no one actually played it.

I promoted the game as much as I could (in an alpha stage) where people could play for free and offer their feedback, but it was incredibly limited. When the game actually started getting attention (recently), it was too late for me to put it out there for people to play because it was almost already done.

Why would people pay for something that is out there for free, and is supported by the developer? I had a constant knot in my stomach that thought the game will fail because the art will turn people away, people won’t get it, there are too many bugs, etc. and I could do nothing about it but wait.

This isn’t the kind of “butterflies in the stomach” nervous, but a “raging bear in the stomach” nervousness. The kind of thing that keeps you up at night because you can’t stop thinking about how much could go wrong.

Depression. This goes hand in hand with nervousness. I consider myself depressed for a majority of development. I was worried my game would suck, and would be hated by everybody. I was worried I would drop the game and give up. I was worried my girlfriend would leave me. I was worried that if this game failed to even be minimally successful, I would have wasted three and as half months of my life.

"Not just “day-time” three and a half months, but literally every hour of every day would be wasted. Knowing that I could be this close to failure scared me more than I can describe. The worst feeling I could imagine would be knowing I suck at doing the one thing I want to do with my life. "

Not just “day-time” three and a half months, but literally every hour of every day would be wasted. Knowing that I could be this close to failure scared me more than I can describe. The worst feeling I could imagine would be knowing I suck at doing the one thing I want to do with my life. Now with release only a week away(at the time of this writing) , I feel much better. I hope the game will be an immense commercial success, but I am glad if it seems to get mild traction. As long as it isn’t lost miles under the sea of other indie games, I will happy.

Stress. Daily Routine: Wake up in a rush, worrying that you slept in until after noon. Read emails. Work a bit. Get ready for the day. Work some more. Get food (maybe, depending on the schedule). Work. Sleep. That schedule sounds normal for many game developers, and it was normal for me.

However, every day for me, I woke up knowing I had to get as much as I could every day. I did everything alone, from art, to (most) music, and code. In addition to doing all of this, I only had the time frame of three months to finish the game (Summer break).

That means that, for me, every day was a rush to get done as much as I possibly could. I had to work on everything simultaneously to have it all come together in time. Knowing how far behind you are in one area is stressful, because you don’t know if you have the time to take a step back for a day or so. It would be as if your boss told you that you have a deadline to do something, and your job depended on it, and you didn’t know if you would be able to make it. Every day you would work as hard as you could, but you would always be behind schedule because the boss continues to add more work to the project.

"Frustration. My computer almost put me into a rage-induced coma numerous times. The biggest obstacle in finishing the game, besides myself, was probably getting the software and my Macbook Pro to stop messing up."

Frustration. My computer almost put me into a rage-induced coma numerous times. The biggest obstacle in finishing the game, besides myself, was probably getting the software and my Macbook Pro to stop messing up. An example is the character model. The final model in the game is actually the alpha model. I was designing and modeling a new character, but Blender suddenly decided to mess everything up.

When rigging the character, Blender seemed to randomly apply different rotations to the character model, making it look like the monster from “The Thing”. It was beyond salvageable. Two entire days I could have polished mechanics, other art, done music, advertised, made levels, tested, all wasted.

This was not the only instance of issues either. I was literally a ticking time bomb due to the high amount of stress and frustration that I was going through, and I normally erupted in fits of rage.

Attention. The last thing I noticed about myself being different was my point of view and attentiveness. Towards the end of development, or mid-late July, the only thing I could think of was the game. Breaks no longer had any effect on me, besides increasing my frustration in myself for being lazy.

"In conclusion, making the game was awful. I suffered from many emotional traumas, but finishing the game is incredibly rewarding. It is definitely worth the emotional costs to create something that other people support and love."

They didn’t help me relax and take a step back. I was too involved in the game to stop thinking about it. I found myself daydreaming about bug-fixes, new mechanics, level ideas and such while watching television or films, sleeping, or even driving. I couldn’t escape the game I was trying to make, and my ability to give my attention to other matters suffered.

In conclusion, making the game was awful. I suffered from many emotional traumas, but finishing the game is incredibly rewarding. It is definitely worth the emotional costs to create something that other people support and love.

The feelings you get after finally finishing the game outweighs the negative feelings you get while working on the game.

A big thank you to Ryan Noble from BeefJack  for setting this developer journal up.

While we wait for the Beta to be ready (announcement on this to come soon!), here’s a bit of a development update on City of Steam.

A lot of new things coming up for the Beta… a lot. One of the big ones? Why, a little thing we’ve been mulling over for a while now: Wilderness instances.

“But Mechanist,” we hear you say. “Don’t we already have ‘wilderness’ instances in places like the Dustyard and Scraphills?”

To which we chuckle condescendingly, replying: “Oh, no no no. Those are just aboveground dungeons, which just have a ‘wilderness’ aesthetic to them. The Wilderness is a public combat level, an open instance where monsters respawn.”

Yes. Public instances. A place, with mobs, that won’t just be yourself or up to 5 players in a group. Everyone can jump into the fray.

If you’ve been following City of Steam up to now, you probably know how big this is. So far, we only had single player or group instances, making the game more of a dungeon crawler MMO. We had been toying with the idea of an open, public instance, for a while now. We wanted it, players wanted it, but it was a matter of making it work within the game’s limitations. Well, after months of trial and error, we found a way, and now City of Steam is starting to look like an actual MMORPG!

Now, if you’re only finding out about City of Steam now, this feature is probably not as exciting to hear about… so um… How about this? We also have jetpacks!

They (both Wilderness instances and jetpacks of course) will be awesome. That is all…(for now)

I do have a special love for our empire building series Europa Universalis and the team, we are all major fans of this series. We are a group who love playing Europa Universalis, both in singleplayer and in multiplayer together, so you could definitely say it is the favorite series for the people working on Europa Universalis IV.

For you unfamiliar with the series, Europa Universalis IV is a grand strategy game where you take on the role as the guiding hand behind a nation struggling for supremacy during 400 years of history.

My personal history with the Europa Universalis series franchise started many years ago, namely when I was in university and found this game called Europa Universalis.

This game was not like anything I’ve ever played before, I had played Civilization and Imperialism, but a game that actually had a historical world map and where even the smallest AI state played to win was something that fascinated me.
Then I learned that a sequel was coming out I managed to sneak my way into the beta. Not sure if I reported that many bugs, but I was pestering the devs about my pet peeves and even managed to write an historical event that was actually taken into the game, I was very proud.

Then later when I was looking for a job paradox was looking for a programmer and I started to work at a very cramped office in central Stockholm. After some other projects and moving office three times I got to work the sequel to my old favorite game, Europa Universalis III. Now several years later I get to stand here as the project lead for Europa Universalis IV, it’s been quite a ride.

Originally Europa Universalis I started development in 1997, Europa Universalis II in 2001, Europa Universalis III started in 2005, so we were overdue a new take on the game series.

During those years we’ve accumulated quite a lot of ideas, and discarded far more. We’ve come to understand what Europa Universalis is about for a lot of people, and what it means for ourselves.

During 2010 we spent a lot of time working on the design concepts, and late in 2011, the core team for Europa Universalis IV was assembled, and actual development started. We wanted to reconquer Europa Universalis, because the most exciting thing about a sequel is for us truly the ability to go back and do more with a game with the goal of taking it to the next level.

Creating a sequel for this game is of course a great challenge. It’s not only what the original game was but a huge part is also what Europa Universalis III grew into with all the expansions, from the first release to the fourth expansion. For every office multiplayer game and every time we went to the pub over the years, we came up with new ideas that generated yet another expansion. With the new expansions the game really morphed into something that a lot of us came to see as the ultimate strategy game.

The challenge in creating a sequel comes in keeping true to previous game and what it became, while giving all our fans enough that is new to make it feel that it is worth calling it a new game.

One important thing though, is that while we had lots of cool and interesting ideas for Europa Universalis we simply couldn’t just add them all in, as the game would become an unwieldy mass. Europa Universalis has a complexity level that we do not want to dramatically increase. We are happy with the level of complexity and want to keep it at this level. And while improving the interface can reduce it a fair bit, it is a very fine balance when it comes to designing a game.

So we took a step back and looked at what Europa Universalis was and what we wanted to do, and since it’s a new game, we had quite a large amount of flexibility. We could rewrite entire systems from scratch, and do some paradigm shifts.  One such example is the complete removal of the old trade system with centers of trade, which was replaced with a new trade system with dynamic flow of trade. This flexibility has been a great benefit when it comes to designing the game.

What we have done is that we have done a complete overhaul of the trade system, added a new monarch power system and a done a major rework of the diplomacy system. We have also taken a good look at most of the features, big and small. How well do they work with each other, which parts makes the game fun and which are more tedious.

In all our games we aim to have believable mechanics. When playing a Grand Strategy game it should be about immersion and suspension of disbelief. You should feel like you are playing a country in the time period. This is something all our Europa Universalis games have managed to achieve, and it is very important that Europa Universalis IV will have that same feeling.

And the first step was also the most painful for us on the team – the purge. Purging is when we remove features that simply are not good enough, or not as fun and exciting as we had hoped them to be when we thought of them, or that we feel stand in the way of a completely new system.  Sometimes you remove features because they are not good enough, and sometimes because you feel that they simply are not fun enough.

For example spies were present in Europa Universalis III, features that will not be around in Europa Universalis IV. Spies were removed along with the entire system for sending them to do covert actions. We felt that the mechanic wasn´t enjoyable enough. First, it came down to ‘click for random effect’, and, second, it had a negative effect on the game balance. At the same time we kept and developed the best bits of it, if you want to support rebels in your neighbor’s realm you send a diplomat to do it, only now you can choose exactly which type of rebel to support and how much money to give them.

Trust me when I say that it is hard for us to kill our darlings and let features go altogether. We have all lived and breathed the Europa Universalis series and we’ve invested time in creating the features we are now tossing aside. But sometimes you have to let go of features people have come to know and understand in order to make the overall game experience greater. No matter how hard it feels and no matter how your heart (or head) hurts… 😉

Greetings, dear readers of Gaming Bolt!

We are Daedalic Entertainment, an indie-games developer and publisher from Hamburg, Germany. We not only publish renowned games of international partners here on the German market, we also develop our own games.

And that we do pretty successfully.

Our passion are good old point & click adventures with sophisticated characters and a good chunk of humor.

But all generic talk and self-adulation aside: We simply love to create games offside the mainstream, setting great value on unusual settings and an awesome storyline.

We just recently announced the release date for the grand finale of our ‘Deponia’-series, ‘Goodbye Deponia’.

What is that? You never heard of this series?

Well, then take some time and check out our unbelievably exciting developer’s diary, so you’ll learn everything worthwhile about these games.

The ‘Deponia’-series’ first installment hit the shelves no later than spring 2012. Why we already upped the ante with the second part, ‘Chaos on Deponia’,  6 months later, is probably best explained by the man and creative genius himself, Jan Müller-Michaelis aka Poki:

„In the beginning Deponia was planned as only one game. Therefore the idea for the second part already came up while working on the main idea. Actually there were even two different sparks that preceded the idea around the world Deponia:

First, I wanted to make an adventure, settled in a so far unused scenario, which is at least as funny as more obvious settings.  A planet made of trash seemed to me an ideal adventure playground for  point & click friends.

The second thought was to make a game, dealing with the untidiness of life. Every one of us has goals which are so far away that they appear unrealistic at first glance. The more fantastic and unreachable these goals are the more one has to step out of the old sphere of action. But this can only happen at the expense of current living conditions. From the outside one seems egocentric when refusing to settle down in the here and now over a long period of time. Occasionally the whole world appears like a giant building lot, improvisationally patched together of things that actually should have been disposed.  This is the theme of Deponia. Rufus’ flirt with pipe dreams, namely the city in the sky “Elysium”, is reflected in his feelings for the character “Goal”.”

This should give you a fairly good impression what the ‘Deponia’-series is all about.

Love. Scheming. Chaos.

The stuff Hollywood tearjerkers are made of…at least, that’s what one would think!

‘Cause who would have the brilliant idea of throwing in a rag tag anti-hero on a trash-planet?

Yeah, alright…we obviously would.

Rufus , as you might reckon, grows weary of all the junk and yearns for a better place: Elysium. The hovering city and the only way out of the stench and trash.

As a literally gift of heaven, the beautiful Goal falls from exactly this hovering city onto a nearby scrap heap.

Rufus, as the selfish bastard he is, seizes this chance to reach Elysium through Goal. But it would be way too nice if both of them just ride hand in hand into the sunset…or rather, up to Elysium.

Since Rufus falls head over feet in love with Goal. However, Goal is betrothed to Cletus, who bears a striking resemblance to Rufus.

All this is just asking for chaos. And thus, quite fittingly, the second installment has been named ‘Chaos on Deponia’.

Regarding the plot, I could give you another nice summary or I just throw in some keywords like: flaming saw blades, torpedo dolphins and platypuses…Or you just take a look for yourself, how Rufus not only tries to win Goals heart an finally leave Deponia, but also tries to save his home world he seems to despise so much from certain destruction.

But of course you need all kinds of people to weave such a complex story with all its puzzles. Apart from all the illustrators animators, our scripters are also really important, since they manage to tie everything together nicely in the end.

Who knows what we have in store for the grand finale ‘Goodbye Deponia’?

Getting curious already? Then take a look at our games.