Last year, in May, we announced that we had received new funding from the Norwegian Film Institute to help us develop our next game. For an independent studio like us, this means not only an economic boost, but also peace of mind: we can keep working on the kind of games we like, and giving more life to our worldbuilding as we wish.
Category Archives: Game development
Summer Sales and Made With Unity
Reply
Your shipment of Rain news has arrived!
If you’ve been waiting for the Steam Summer Sale like a godsend, then you know for sure that it’s live since the 23rd of June, until the 4th of July. And yep, Teslagrad is part of it: our game is 75% off, so you can add it to your library for barely a couple of bucks. Just click here and let Steam do the magic.
An update on Teslagrad’s vita port!
Fredrik and Eduardo explains:
More than a year ago we announced the PS Vita version for Teslagrad, and sadly we haven’t been able to deliver it yet. But this time has definitely not been wasted; apart from the Wii U version, both PS3 and PS4 owners can download and play our game now in Europe, North America and Japan. Furthermore, during this period we’ve got to know the PlayStation platforms fairly well; we’ve solved a couple of issues (or a hundred), and considering Vita’s popularity among indie developers (and how much indie game fans appreciate that console) we’re glad to share our experience, hopefully saving other developer’s time. We wish someone had told us what we are about to tell!
What is like to port a heavy physics-based game to several consoles?
As you can read in these lines written by our past selves, we were more than confident in being able to complete the task, that was to bring Teslagrad to PlayStation 3, PlayStation 4, and PlayStation Vita in a relatively quick and easy manner. We were mostly worrying about having to “shrink” and optimize the game to make it fit on Vita, and with everything more or less working out of the box, optimization looked like the major beast we had to face. Improving loading times proved essential, and we thought that threading optimization would counteract the incredibly high demands of our custom physics system. And that’s precisely the underestimation that costed us the most.
Let us add a small disclaimer here: even though we’re now far more experienced in this porting subject, we’ve also learned that we’re as likely to point out the wrong things this time as we were the last time. We’re smarter, but still can’t look into the future. However, we can look into the present and recent past, a past in which we realized that magnetism calculations stood as a total resource drain in a physics-dependant game as Teslagrad certainly is. Trying to take advantage of multicore architectures, our lead programmer had to write his own framework, mainly to see it overwhelmed by calculations. All the math behind magnetism behavior in Teslagrad is customized, or hand-made if you prefer, with a physicist and a mathematician ultimately involved in it. Take a look at the screenshot below to get a grip on the importance of physics in Teslagrad’s performance.
Working on PlayStation
The screenshot belongs to an actually optimized build using our custom physics system at 120hz refresh rate in Unity 4, showing how physics calculations themselves (orange segment) can bring the game from the smooth 30 frames per second to choppy 15 FPS. As stated, optimization has been the biggest development time consumer, and indeed we have seen Teslagrad builds that could run 15-30 frames per second for a long time by just taking our PS3/PS4 projects and converting them to Vita. A year ago, about the time on which the aforementioned interview with our past selves was published, we were optimistic. Every week we kept trying new thing… just to get those last 15 frames per second back. And oh, weeks went by. At a certain point, we had been optimizing for a long time already, and no more low hanging fruit would available, you could say. With one programmer devoting himself to Wii U and another to all PlayStation 3, 4 and Vita versions, we got the feeling that we were under some time pressure. So we decided to focus. PlayStation 3 version was chosen to be delivered first.
Fortunately the PlayStation 3 builds were very much more doable. In those we only needed to handle the 256MB memory issues, and PlayStation 4 handled anything the PS3 could do… so it almost didn’t require any changes to the game at all but a few controller changes. Two birds with one stone! Later in 2014 we actually arrived at the point where the PS3 build was shippable, and we shipped in Europe on our own. This is the first time we delivered anything on any Sony platform ever, so we used a long time familiarizing ourselves with the process, and also a long time trying again and again to get Sony QA to accept our builds. We went through several attempts before we got the PS3 build accepted in Europe, and it’s interesting to note that each attempt implies 1~2 weeks of waiting.
This process we have went through ~8-10 times counting physical and downloadable builds in Europe, America and Japan. Sometime in February this year, Teslagrad was released in Japan, and for our Playstation programmer, that meant he could finally dedicate himself to working with the Vita again. By that time, he finally spotted the next step that would allow him to push optimization a bit further, and it was scene loading. It wasn’t minor changes, though: Fredrik already managed to change the whole scene loading model for it (our idea was to have no loading screens on any platform) so that it worked on Vita.
The new system features explicit loading of scenes, taking a few seconds for loading purpuses every 3-4 scenes. The player will actually walk beyond the screen edge, and the next couple of scenes will load before he can continue, taking no more than a few seconds. With this model (and only if necessary) we can take a demanding boss scene, and make sure that nothing else is loaded or running while the you’re there. Most other games do this kind of loading, and for us it suddenly became a very attractive option considering current, and unknown future problems with memory and frame rate challenges. It’s a hard earned conclusion that seamless loading is very challenging on certain consoles with Unity while others (such as PS4) doesn’t seem to twitch.
Moving on to a different aspect, we’ve rebuilt our own area detection system from the ground up so that we could bypass the internal physics in Unity, which is still there for the stuff that you can see, but it is not detecting that the player went to a certain place for example. That system is helping us reach stable framerate… but represents a tremendous amount of work so far, and also a lot going forward. As a result, Teslagrad actually feels smooth most of the time, in contrast with the old builds that we had a year ago.
Unity 5, a light at the end of the Vita tunnel
With Unity 5 came a better and faster physics engine, which helped us reach the desired framerate stability, but as usual it also required a lot of extra work. For instance, In Unity 4 we could put two colliders (floor pieces in this case) right next to each other, and they would seem like a smooth surface; but in Unity 5 those pieces will have to become one piece entirely, or the player would stumble on the edge between them. That’s weeks worth of work, just finding those piecing and merging them together so that players won’t experience weird collisions or falls through the floor. The new physics system indirectly pointed out another issue with the refresh rates that were making things more difficult than expected. Since the launch of the game, the physics engine refresh rate had been 150hz, but it really should have been something divisible with the screen framerate. We chose it as suggested by the old documentation, which lead us in the wrong direction. When later tested on PS3 and PS4 it became evident to us that we needed to go with 120hz physics, and even more importantly, that working on Vita we could benefit from going way down to just 30hz, providing we work on finding and fixing all the colliders. By the way, Unity default value for physics is 50hz, and as far as we know many don’t ever change that. Be warned!
And that’s how we’ve come to this point. After slating the game for release, being perhaps too optimistic and re-scheduling once again, we’ve learned that there’s a lot of things which could and will go wrong even when everything seems nice and easy on a first step of the port. There were major problems and changes that we couldn’t anticipate, and a little million tasks in the many-other-thing box that can be anticipated but are often underestimated. Teslagrad is being rebuilt scene by scene, and performance- wise, rebuilt scenes are working on PC-like solid 30 FPS. In any event we’ve learned to stay conservative about future announcements, in line with our under-promise policy as a studio (and believe us when we say that we have had tough times telling our fans about delays and problems).
The Vita version is resulting the most demanding version so far, but all this chaos offer a bright side too: this version benefits from optimizations made for the PS3 and PS4 platforms, and Vita’s release will at last bring cross-buy for all the three platforms.This ordeal has been a product of a mixture of our own mistakes and bad luck, but there’s something for sure: if we decided to keep fighting it has been so that we made Teslagrad equally playable and enjoyable in every platform. That’s the whole reason we do it, and the model (with several improvements) will be kept in our next game yet to be officially announced, World to the West.
this article also appears on gamasutra. !
Ancient history!
During the move we recovered a couple folders of notes and scribbles from very early in Teslagrad’s development, here’s a look at a couple of nuggets:
an excerpt from the initial script outline for Teslagrad’s story! This changed a lot as we decided to do completely nonverbal storytelling, so in the end a lot of nuance was cut in favour of more instinctively understandable/ archetype based story beats. A lot of the story work in teslagrad was “how much can we cut/streamline this to make it more understandable without losing the flavour” rather than “how much of the story can we cram in before people get impatient”.
In the end, the amount of behind the scenes, not explicitly stated stuff probably made the ingame world feel richer and more expansive than it would have otherwise!
Early sketches of the king, complete with a list of design inspirations. his outfit was a lot more flash gordon-esque here!
The Teslagrad approach to puzzle platformer level design
I got a question online the other day about level design that i gave a long and rambling answer to, but i figure it might be useful for some of you who might be starting out making games yourself:
“So I’m interested in getting into game development. I’d also like to make a platformer puzzle type game. I have 0 experience outside of being the consumer of games. I’m a developer and I’m sure with enough time and research (and tools like Unity) I can handle the programming side. For me what I think seems most daunting is level design. What was your team’s process for designing the levels?”
-Best laid plans, trial and error, killing your darlings and iteration! No one is born a perfect level designer and things rarely work just as you intended when you play the first iteration you build of a level- and that’s ok. The important thing is being able to identify what you are trying to achieve with the level and change it to fit that vision if something doesn’t work as intended. Or alternately, seeng when something unintended works outbetter than the original idea. Most of teslagrad’s levels changed a lot from first to final version! one thing to keep in mind is that level design that seems easy on paper can be very hard to play, almost all the initial designs had to be simplified and made easier-and teslagrad is still considered a fairly hard game!
Also, never start out trying to make levels with a high degree of graphical fidelity-always stary out just building them from grey boxes or basic tilesets, and decorate them when you’ve nailed the gameplay aspect. This makes it far easier to iterate. make sure you think of what parts of the level are visible to the player in-camera from any point in the level, if you keep that in mind you can imagine the experience of playing it for the first time from another person’s perspective, and try to make it an enjoyable experience for them.
Get people to play your WIP levels (anyone, but keep in mind how their skill level relates to your intended audience). Don’t talk to them while they’re playing, even if they get stuck. Never try to help them along, just observe and see what seems like it works for them and what doesn’t. This can be very hard to do. Afterwards you’re free to ask them anything about their ecperience, what they enjoyed and what they didn’t, what they found too hard, too easy, too obtuse or what confused them. Results may be surprising.Sometimes the part where they looked like they were struggling was their favourite part, sometimes it can be the opposite. Try to adjust your levels if it’s obvious that spesific parts aren’t fun for the majority of players. Listen to suggestions, but keep in mind that not everyone is great at problem solving and what they suggest may not actually be the solution to the problem they were having in the game. Never dismiss people outright if they are struggling in some way, even though something seems like it should work for you, it might still be a bad design choice. That’s not to say you should compromise your vision or make a dull design by comittee game, but try to find a balance!
Lastly there’s a Shigeru Miyamoto quote that applies to almost every aspect of game design-paraphrasing here, but it’s something along the lines of “A good idea is not an idea that solves a single problem, but an idea that solves multiple problems”.