![titleimage]()
Doddler here, Mangagamer’s resident programmer. Really? Really! has just released, and it’s been a really exciting project for me for a variety of reasons. It’s the second game that I’ve had to port, the first one being Tick Tack, but this time I chose to do something different. Rather than rely on an existing visual novel system like before, I made one from scratch using the Unity Game Engine. Why did I go to such extremes, and did it pay off? Well, lets take a look.
Why port the game?
Like Tick Tack before it, Really? Really! ran on a game engine developed by Navel which, while solid, had a pretty serious flaw–it doesn’t run properly on systems that don’t support Japanese text. That doesn’t impact them in their Japanese market, but it’s a serious problem for us. Sadly, Navel has already long since moved on to new releases and no longer have any of the source code we’d require to modify the engine for our needs. So how do you cope? Well, pretty much your only real option is to pack up everything and move it all over to a different, better suited engine.
So why start from scratch?
When porting a game, your primary goal is to make the game look and function as close to the original as possible. To do that, you need the right tools. For Tick Tack, I ported the game to the Kirikiri game engine, a commonly used Japanese visual novel system (you can read about that port endeavor here). But the more I looked at it, the more I figured Kirikiri may not be well suited for the job.
To understand why, you’d have to know a bit more about how most normal visual novel engine’s work. Most all visual novel games are controlled by a script, a series of text commands that control and direct what happens on screen. They are filled with commands that say when and where to display images, what text to write, basically directing everything you see on screen. The game engine reads through these scripts, and plays it back for the user as they step through the game.
But it can quickly get a little out of hand, transitioning between scenes with different backgrounds and characters is tricky business. What most games do to make this easier is implement a two-scene system. One scene is designated as the foreground (what you see when you look at the screen), and the other becomes the background (which is normally not visible). Then, through the script, you place, change, and move characters and layers on the background scene, out of view of the user. Once everything is set up correctly, the foreground scene fades away to reveal the new background scene you’ve set up. Once the transition is over, the background scene becomes the new foreground, and the sequence starts over again.
![An excerpt from the Really Really script.]()
An excerpt from the Really Really script.
Kirikiri and Navel’s engine both use this approach, and it worked pretty well for Tick Tack. Really? Really! however expands on the functionality that was used in Tick Tack– characters move about, they bounce around, come and go from off screen, change and swap positions, and all other kinds of fun. All that happens while text types away. And here’s the issue, in Kirikiri, you can’t make any changes to the background or foreground during transitions, which includes text typing. For some effects, animations, and transitions, this is a serious issue.
Now Kirikiri is open source, so these are surmountable issues. Other companies have built onto the base functionality of Kirikiri to have it do all of these things and more. But I took a look at the future, with the D2b vs Deardrops port, which is considerably more complicated from a technical perspective, and came to the conclusion: rather than spend a lot of time rewriting parts of Kirikiri to do what I need to, I’ll do it the way I need it to work from scratch.
![Unlike in Shuffle and Tick Tack, characters don't have fixed positions anymore, and they can move about on screen.]()
Unlike in Shuffle and Tick Tack, characters don’t have fixed positions anymore, and they can move about on screen.
How does one go about making a Visual Novel engine?
While I chose to go with the Unity engine for making my port, I’m sure there’s any number of viable options though. Most commonly I get asked why I didn’t use Ren’Py, a popular engine used in English for making visual novels. The main reason is, I don’t know Ren’Py. I do know Unity though. I’d be starting from the start, but that just means I can make each piece as I need it. This is where the fun begins.
For those unfamiliar, the Unity Engine is a modern game engine that’s really caught on among indie developers over the last couple years. It’s main draw is accessibility, speed of development, and multi-platform support. While multi-platform wasn’t our primary concern, getting something off the ground without taking a huge amount of development time was. Unity allowed me to focus almost entirely on building game relevant code, and very little time on laying groundwork systems. Even though Unity is commonly seen as a 3d game engine, any modern visual novel will use textured objects to render to the screen, it’s just cleverly done and you don’t see it when playing. Our game is no exception.
So how does one actually build the engine? Well, it’s pretty much what was said above; at the core of the game engine, you have the script interpreter. The scripts are interpreted into commands, which then communicate to specific parts of the game system. The display controller handles moving and drawing scenes and sprites. Sound commands go to a sound controller to handle audio playback. A data controller handles in game variables and save data. A UI controller handles interaction with on screen elements. And everything is tied together with a Game Controller, which handles when the script should advance, handle different waits, game states, and user input.
![clip (2013-07-14 at 10.17.23)]()
The above image shows a relatively early version of the game being run in the unity editor. The bottom half is the game as the user sees it, but the top half gives you a behind-the-scenes look at what’s going on. The top is broken into three sections: the two scenes, the foreground and background are to the left and right sides, and the composite ‘final’ image is shown in the center. Internally, each scene is being rendered by a separate camera, and then those are being combined using a custom written shader to blend the two together. In this screenshot, the foreground is the left side, with the scene transition revealing the background on the right side using a pixelated transition mask.
Actually pretty much everything follows the foreground/background scene design, not just characters and backgrounds. Even many of the interactive elements in the game, such as the world map, the location and memory picking, they’re treated the same as any other character or background layer. I designed them as unity prefabs, collections of objects that are saved and can be instantiated at runtime, and then when you pull up the map or other similar action they’re placed into the background and a transition occurs just like any other. It’s actually pretty neat how everything works together.
![Sakura, shown using the evening, nighttime, normal, *sparkling*, and monochrome filters.]()
Sakura, shown using the evening, nighttime, normal, *sparkling*, and monochrome filters. All use the same original sprite.
Everything in the game is built strictly to emulate the game as close as possible. Custom written pixel shaders were made to properly perform transitions and render sprites on screen properly. In Tick Tack for example, each sprite had different variations based on time of day and lighting. In Really? Really!, sprites are adjusted in real time, and so in my port I performed these effects as part of the pixel shader.
One part where I did actually take some liberty was the shattering effect that occurs when you correct one of Kaede’s memories. In the original, a shattering sound played and the screen dropped away piece by piece, but I found it very difficult to pull off that effect in Unity as I would need to do pixel-by-pixel manipulation of a texture (something that’s really slow to do). So instead, I came up with my own effect. I used a unity asset store script “Ultimate Fracturing and Destruction” to create an object that I could apply a snapshot of the screen to, and then used the built in Unity physics to handle it falling away. That’s right, I managed to use Unity physics in a visual novel. The end result is really convincing, and runs quite well even on under-powered devices.
![The screen shattering effect is actually simulated and rendered in 3D, something I can get away with only in an engine like Unity.]()
The screen shattering effect is actually simulated and rendered in 3D, something I can get away with only in an engine like Unity.
Some Learning Pains
Not everything went super smoothly though. I’ve you’ve paid attention to the launch, you’ll notice that it’s been patched a few times already to address various issues. That’s mostly my fault, for a bunch of reasons. The main issue is though, is that a lot of work went into making things work, and work right, that not a lot was put into what happens when things don’t work. The most glaring issue was the game not working at all on Intel integrated graphics adapters- there were no fallback shaders present, or any real testing to see if the video adapter meets the capabilities required of the game (that has since been fixed). The game testing also didn’t uncover a lot of relatively minor bugs that I think probably should have been caught before release because the testing team usually only has to worry about quality of text and similar script related issues, rather than game engine problems.
It’s in a stable shape now though, and I still think it was successful experiment in spite of a few problems. These things I can apply going forward to make sure other releases go smoothly, starting with D2b vs Deardrops, which I’m sure will land before too long.
Conclusion
So that’s how I did it, the whole port done in C#/Unity, over the course of about 4-5 months. It’s been really a crazy experience, and I’m really happy to see it finally get released. It’s not without it’s own ups and downs, and I’m sure there’ll be some minor issues and pains with it, but I’m proud to have finished it, and I hope you enjoy playing it as much as I have helping to make it happen. ![:)]()
Update (6/12/2014)
I’ve gotten some comments about the possibility of doing multiplatform releases. The answer is, it could be possible, as the game can be made to run on different platforms. In fact, there’s secret mac and linux versions of the Really? Really! demo that were made, but never went public. There are several reasons why we elected at the moment not to do a multi-platform release.
First, we’re not as easily able to support issues on other platforms if they come up, and it also greatly increases the complexity of patching different versions of the game. I’m pretty much the only staff member that would be able to troubleshoot or support those problems, which is a bit of an issue because I’m not a confident mac or ubuntu user. Second, we couldn’t find a way to meet our contractual obligations with our clients to provide DRM on multi-platform versions of the game. That sounds a bit silly, I’m somewhat anti-DRM myself, but we have an obligation to our client in our contracts to put some form of protection in place. And thirdly, a fairly minor thing, but our website doesn’t at the moment support different downloads for the same product, so distribution became a problem. This game is also a sequel of sorts to a windows only game, so it doesn’t make a lot of sense to go multi-platform here. It’s perhaps not much solace, but I’ve heard reports that the full game runs well in VirtualBox and VMWare, and possibly even on Wine as well. It is something we’re keeping open to, and in the future may do multiplatform releases if it’s possible.
If you did want to try the cross-platform demos that were made, you can grab the mac and linux versions below. They’re older versions of the game, so they could contain bugs that were fixed by release, but if you want you can give it a shot!
Really Really Mac Demo / Really Really Linux Demo
Today we’re proud to introduce our second Tester’s Corner for Milles Knight of Anal Tyranny! (This post contains minor spoilers.)
