Building Tick Tack

ss (2013-05-20 at 08.47.09)

So it’s been a few weeks since Tick Tack has come out now, the game has been doing reasonably well. It might not be obvious to those playing the game (I hope it’s not!), but unlike recent titles we’ve released recently, Tick Tack was actually ported to a new game engine. I wanted to talk a little bit about why this happened, and my experience in porting the game. Also check out the end of the post for the game guide/walkthrough.

There’s a variety of reasons why porting a game to a new game engine may be necessary. The usual culprit are from problems in the original game engine, often resulting from the processing of language. Games written for the Japanese market often use features or functionality that don’t work on systems without Unicode or Asian language support, and our customers expect a working product out of the box. Fixing these issues can be problematic, companies in this market are often very short on manpower and contract out a lot of the required work, so are unable to dedicate resources to fix these issues. It’s possible even that they license the game engine from another company and have no direct control over the code itself. We’ve even encountered instances where licensing fees for the game engine alone are too high to release a product.

Whatever the case, the solution is often to rewrite the game from scratch, porting the game to a new game engine that will meet the needs of English market users. Mangagamer has actually done this several times in the past, with Kara no Shoujo, the Da Capo series, Suika, and the Higurashi games. While I’ve been involved in helping bring several titles to release for Mangagamer, Tick Tack represents a first time where I was required to perform a complete port of the original game.

Building a complete product from the ground up is quite unlike anything I’ve done before. You have all the pieces of a working game laid out in front of you, and a huge stack of sketchy directions on how to fit all the pieces together. The trick is the directions don’t necessarily work on the engine you’re porting to, and require a lot of elbow grease to get it to work the way you’d expect it to.

Sprite sheets were created for animated elements for use in the new game engine. The original game used MNG files for animations, an old animated PNG file type that never caught on.

Sprite sheets were created for animations in the new game engine. The original game used MNG files, an old animated PNG file type that never caught on. The internet had to be scoured for ancient tools to work with those files.

The engine we used is called Kirikiri (or krkr for short), an open source freely available visual novel game engine. The engine is used in a lot of commercial titles, ranging from the softhouse seal titles we release, all the way up to big players like Fate Stay/Night. It’s one of the go-to engines for it’s robust capabilities and flexibility.

Kirikiri utilizes two separate scripting languages to handle the different tasks. The first is TJS, a scripting language that is very similar to Java or Javascript, that directly interfaces with the game engine. The second is KAG script (short for Kirikiri Adventure Game script), a scripting language partially written in TJS, which provides the linear flow that is common in a visual novel through a series of specially formatted script files. By using the two systems together, you can build a fully functional visual novel game.

An excerpt from one of the script files. Complex tasks are simplified through script macros so they're easy to troubleshoot and make changes.

An excerpt from one of the script files. Complex tasks are simplified through script macros so they’re easy to troubleshoot and make changes.

Bringing Tick Tack over to the Kirikiri engine was a fairly complex task. First, the in game interfaces and systems were coded by hand, attempting to keep everything as close as possible to the original game. This means every little thing, to the positioning and ordering of the characters, the behavior and timing of screen transitions, how buttons and the user interface react to the player, etc. Once all the facilities are in place, the original game scripts can be run through a converter that we built to re-write the script into KAG compatible commands. The scripts are then manually touched up to fix small problems that occur. When everything works, the game runs indistinguishably from the original.

Left, the port, with the original on the right. While not all of the on screen effects were completely reproduced in the new engine, a lot of effort was made to ensure the experience was indistinguishable from the original game.

Left, the port, with the original on the right. While not all of the on screen effects were completely reproduced in the new engine, a lot of effort was made to ensure the experience was indistinguishable from the original game.

Porting a game does offer some unique advantages. While the majority of the work is done to ensure the game plays as close to the original as possible, it does let us actually improve on some aspects that felt rough in the original. Of course we didn’t make any changes to the core gameplay, but work was put into making the user interface and menus flow a little nicer, using transitions and fades where elements would normally just instantly pop-in and pop-out. Small tweaks were made all around. The only other somewhat interesting change is I’ve modified the pre-requisites to unlocking the Bust Gallery (a character paper-doll viewer) down from 100% completion to only requiring one complete playthrough, and simply hiding the characters you shouldn’t yet see. Building the screen took some time and it would be a shame if only a few people could mess around with it!

The first screenshot of the port that took. It's come a long way hasn't it?

The first screenshot of the port that took. It’s come a long way hasn’t it?

In the end, I think the final result was good, it looks and feels like a solid product. I hope everyone that’s played it has enjoyed the work we put into bringing it to you guys!


While working on Tick? Tack!, I required a way to verify that I was putting in all the route and scene requirements in the right order, so I created a guide for me and our play-testers to reference. Below is a download link for those that want to take a look at it. If you are only interested in a 100% clear walk-through rather than a guide, I’ve translated one of the Japanese walkthroughs for the game as well.

Tick Tack Game Flow Guide
Tick Tack 100% Walkthrough

Don’t forget to grab the Tick Tack Patch 1.11 if you haven’t already!

Bookmark the permalink.


  1. Thanks for all your hard work, Doddler. Never really knew the extent of an engine port. Nothing is ever simple these days, is it?

    I remember being able to fiddle with a program’s files in DOS as a kid. Even managed things like turning shareware into full version just by fumbling around, often just trying to do the same customization you did for this vn. Now not even the language of computing is the same, it seems like. Oh how time flies.

    Have any other ports you’ve been working on lately?

    • I have a few in progress at the moment actually… three titles planned that need porting. On the plus side, we won’t do a port for any old game, these will be exciting things for you guys to look forward to. 🙂

    • This is extremely interesting.

      Is there an english version of KiriKiri or do you use it in Japanese?

      Anyway, I hope we’ll get to know more about the development process.

  2. Did you port it to the original krkr or krkr2?

  3. Wow, fantastic! Really appreciate all the work that’s gone into this release… just have to scrounge up some money so I can actually buy it!

  4. Awesome work and it was very interesting to read about the porting process as a fellow programmer.

  5. Wow, the kirikiri script language looks rather icky. Unintuitive keywords (wtf is [s]?), and vaguely resembles XML, which seems rather inappropriate for scripting, though I suppose BulletML managed to pull it off…

    • It’s fairly intuitive once you get used to it. A tag is written with [tagname], with any number of properties inside. You don’t close them like you would xml, they’re individual entities. Tags are control entities, anything that’s not in a tag is printed to the text window. As for the [s] tag, that’s a stop tag, meaning it stops execution (In this case, the game would continue once you clicked a location).

  6. Sounds like a lot of work. Didn’t expect that the game had to be almost recreated. I always thought it’s just replacing text and adjusting some images.
    BTW, I really liked the bust gallery. Helped me making lots of Ai avatars ;-). Will we see that in future titles too, or was it an exception?
    Would another Navel title like Really? Really! now be easier to port or is each title an individual work effort?

  7. Nintendo Maniac 64

    Kirikiri? Oooooohh….so THAT’S why certain MG titles don’t properly support swapped left & right mouse buttons! You see, Fate/stay night has the exact same issue. 😛

  8. I enjoy those “Behind the Scenes” posts. I wouldn’t mind if we get to see more of those in the future.

  9. I’m wondering if those scenes where there were 3 characters on the screen. And the sprites were almost on top of each other, were like that in the original version as well. That’s the only thing i found weird.

    And i could have used that walkthrouh two weeks ago :p you should do that for every game.

    • I put out a fix for incorrect ordering of on screen characters in the 1.11 update, if you don’t have that yet, it should fix that issue.

  10. Me and some friends were planinng on making a visual novel, but using ren’py as we’d seen Katawa shoujo was made in it and it looked perfect for our needs.

    Are there many other free-to-use engines out there for visual novels?

    Thanks a lot for the flow guide

  11. The guide links are broken. Please fix?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.