Never Assume, Always Make Sure

17/05/2025 / Fruitbat Factory / Leave a comment

After the popularity of the earlier articles, we’re happy to share another devlog by Rapha, diving deep into a very obscure bug you never saw in the live game, and why it matters!

We hope you enjoy reading it!

Background: We had a phantom message appearing on chat in the testing of a specific update:

> ” turned from player to spectator”

Who was this unnamed person? Where did this come from?

But to make sense of the problem, first we need to dig deep and start from the basics!

*This mostly doesn’t talk about a specific computer architecture, unless specified*

*Code examples are written in a Pascal-esque way for easier understanding*

The ideal computer runs instructions in series

CODE

That’s good and all, but every single program cannot be linear, memory isn’t infinite nor problems can be unwrapped completely at compile time to make it possible. Sometimes you need to go back and redo a calculation. That’s why programs JUMP *ぴょい~ん, JUMP, カンガルーのように!*

So things like, increasing a number can be done by:

CODE

DATA

But what if there’s something after that JUMP 0x0000, that needs to be executed afterwards? What if we could jump to somewhere else and know where to go back? That’s when the stack is useful.

The stack is a structure of data that is normally filled bottom to top (imagine a stack of dishes). Let’s imagine it here, the bottom is, let’s suppose, the last address we can use, in this example 0xFFFF.

One of it’s important functions is keeping track of where you were before. Using more complex “JUMP” instructions that store the next instruction address to them into the stack, and points where the stack ends using the special register known as “stack pointer” we can know where to go back afterwards. Let’s call it “CALL”. And let’s say it currently points to 0xFFFF in our stack above.

As soon as that call executes it would add 0x1008 to our stack, and change the stack pointer register accordingly to 0xFFFB.

That way, once that function ends and executes, let’s call it, a RET[TURN] instruction, it would fetch that value from the stack 0x1008, move execution there and update the stack pointer again, so it goes again to 0xFFFF.

That’s how computers the keep execution flow!

But the stack also have another function, it stores on most architectures… local variables!

> Their counterpart would be global variables, that are stored
> inside the executable memory space or in the heap, a memory space that
> you ask the OS for, and if not properly released when not used, ends
> up as that thing people love to call “memory leak”

Imagine you have a function that’s something like:

function add_two_numbers(a: Integer, b: Integer):Integer;

var

c: Integer;

begin

c := a + b;

Result := c;

end;

That variable c, for convenience will be stored on the stack, that’s why whenever you call that function, it will have a wrapper code, that I won’t explain, but basically expands that stack pointer up, so you can use the space below it. Something like:

As soon as the function exits, it will simply change that modification to the stack pointer, before getting the address to return to:

Observe how c is still there, because is most implementations of languages, it’s too expensive go around zeroing that memory, so the value just lingers.

Now imagine that you have a similar function, that blindly believes that value is zero, and it’s called right afterwards:

procedure prints_value(a: Integer);

var

b: Integer;

begin

b := b + a;

WriteLn(‘The result is ‘+b);

end;

You see were this is going right? It’s value will need a place on the stack:

But that memory still contains the result of the previous operation, so when the operation b + a is executed, its not doing 0 + a, but whatever was there + a, this incurs an undefined behavior, we cannot know what is there, so it could be a totally different value, and our function will never properly execute.

You never want that, unless you are doing something malicious!

The Bug

But why such a long post to explain this concept? Well, during the internal testing of a new build we had a bug.

A message was printing saying:

> ” turned from player to spectator”

without a name.

It only started happening when we change some of our logging code, why???

Well, there’s a function that sends to the player the current information the host knows about the players and spectators it started with;

procedure sends_stuff_to_client;

var

the_data_to_send: SOME_BIG_STRUCTURE;

begin

end;

That the_data_to_send variable was allocated at the stack, and was never properly fully initialized. For *ab immemorabili*, time immemorial, the bits we weren’t initializing afterwards were inheriting the memory of whatever was on the stack before. It always *seemed to work*, until we changed how our log messages were formatted for security reasons.

Now a message to be logged that contained both text and numbers, was formatted more or less like this:

game_log_message(format_message(“This happened with this {} value”, value));

The return of format_message isn’t magically stored away if its big, so the compiler was just adding a new value to the stack, an unnamed one. In a function call that executed before sends_stuff_to_client this made the stack be aligned slightly different, but different enough so when the_data_to_send was allocated, a specific bit of it ended up aligned with data lingering from previous function calls. The data was specifically the SteamID of the host, and it was ending up exactly at the spot on the_data_to_send that contained the SteamID‘s of spectators.

So that stuff was sent to clients, the clients would interpret it and see *”well, this person, with an ID pertaining to a player, was changed to a Spectator”*, then the code to log that was checking *”what is his name really?”* and found nothing, because there was no name associated with that spectator entry. So we got:

*” turned from player to spectator”*

It didn’t affect the game in any way, no state was being changed based on that, but every time that packet was to be sent to the client, it had a specific miss-initialization that caused that message to be displayed.

The coolest thing in this history (but also the most scary one, since it made us run around in circles until the cause was fount out), it only happened on Windows. Only the Microsoft C++ Compiler was generating this specific stack structure and making this happen, our Linux and macOS versions, compiled by GCC and Clang respectively, just didn’t display the bug, because the memory was still uninitialized, but the format didn’t exactly match so that specific SteamID ended up aligned where we were expecting a SteamID.

The fix was easy, and should be there from the start:

FillChar(the_data_to_send, SizeOf(the_data_to_send), 0);

This ensured the thing was always zero, nothing was lingering and so the bug never happened again.

Conclusion

In our case this just caused a message to appear, but it could be a security problem, important data could leak via a similar bug, that’s why an important security feature to be implemented in some compilers is zeroing the stack on function exit, so doesn’t matter what was there, it will turn into zero, so no one will be able to see it by mistake (or on purpose) afterwards.

I know this wasn’t the easiest post to follow around, and that people normally aren’t interested in such specific stuff, but hopefully you liked it!

504403158265497090 Points, or A Day in the Life of a Save File – 100% Orange Juice Devlog

25/06/2024 / Fruitbat Factory / Leave a comment

We’re happy to share with you another devlog by

Rapha, this time about the recently implemented big save rework, why it was necessary and what went into it! Hope you enjoy reading it.

The Perils of Binary
In the realm of video game development, preserving a player’s progress is paramount. This is where game saves come in, capturing the state of a game so it can be resumed later. However, the methods used to store these save games can significantly impact their susceptibility to corruption, be it by external or internal factors.

The problem

100% Orange Juice since time immemorial used binary storage, it used to be the go to for this kind of data when processing power and storage space weren’t plenty available. It’s more efficient to write, to read, and uses less space in disk. But this efficiency comes at a cost, it’s easy to mess up. It’s why we’ve added more and more ways the game backups your saves at various points over time, to make sure players have some backup to return to if their save with years of progress gets corrupted.

Now let’s imagine a theoretical game,

Poppo Saves The World! Let’s imagine it as a beat-em-up, where you go around fighting enemies, one after the other, until you win and save the world. Lets supposed you have the following section of data that needs to be saved:

– Wins

– Points

– Last stage cleared

Lets supposed you have 10 victories, 393939 points and the last stage cleared as stage 7. Let’s imagine you used 64 bit values for everything. So:

|Data | Explanation|

|–|–|

|0A 00 00 00 00 00 00 00 | 10 in hex padded to 64 bits|

|D3 02 06 00 00 00 00 00 | 393939 in hex padded to 64 bits |

|07 00 00 00 00 00 00 00 | 07 in hex padded to 64 bits |

In the file would be:

0A 00 00 00 00 00 00 00 D3 02 06 00 00 00 00 00 07 00 00 00 00 00 00 00

But then you introduce abilities to the game, you decide to store it as a single byte, that will keep if you have each of the 8 abilities available unlocked, one in each bit.

|8|7|6|5|4|3|2|1|

|–|–|–|–|–|–|–|–|

|0|0|0|0|0|0|0|0|

Let’s suppose your player unlocked only the first one so it’s a 1, so in binary:

|8|7|6|5|4|3|2|1|

|–|–|–|–|–|–|–|–|

|0|0|0|0|0|0|0|1|

You inadvertently decided to write it between wins and points, so you would have the new binary:

|Data | Explanation|

|–|–|

|0A 00 00 00 00 00 00 00 | 10 in hex padded to 64 bits|

|01 | 01 in hex, it’s a single byte |

|D3 02 06 00 00 00 00 00 | 393939 in hex padded to 64 bits |

|07 00 00 00 00 00 00 00 | 07 in hex padded to 64 bits |

In the file would be:

0A 00 00 00 00 00 00 00 01 D3 02 06 00 00 00 00 00 07 00 00 00 00 00 00 00

And as logically implied, you would change your reading code to expect that too! But then comes the problem! Your old save doesn’t agree. Let’s see what your game would read from an old save.

0A 00 00 00 00 00 00 00 D3 02 06 00 00 00 00 00 07 00 00 00 00 00 00 00

It expects 8 bytes for the Wins, so it reads 8 bytes:

0A 00 00 00 00 00 00 00

That reads to 10! Seems ok! Up until now everything have gone correctly.

But then it tries to read the byte for abilities…

D3 is byte, your game doesn’t know if it is valid or not, it’s binary, it believes in the binary. Let’s look at it for a bit, in binary:

|8|7|6|5|4|3|2|1|

|–|–|–|–|–|–|–|–|

|1|1|0|1|0|0|1|1|

So not only the first, but the second, fifth, seventh and eighth abilities are unlocked?!? Wow! That’s a problem.

Let’s continue, more 8 bytes:

02 06 00 00 00 00 00 07

That’s 504403158265497090 points… That’s definitely not what was written originally. By reading that byte that wasn’t there, you misaligned the whole thing, and now your player has more points than literally the universe has seconds of life. And then you continue, last 8 bytes:

00 00 00 00 00 00 00

But that’s not 8, you only got 7! If you really try to read that, you will get an unexpected behavior. What happens depends on what system, what processor and what contingencies are in place. In some systems you may read a byte from memory that has nothing to do with your save, in others you may read some leftover on the memory bus, in some you will crash… The ideal behavior would be the crashing.

But lets supposed it didn’t. It loaded.

Now you have:

10 victories

5 abilities unlocked

504403158265497090 points

And never cleared a single stage

If this happens to your user, they won’t understand a single bit of what’s happening, will they?

The conclusion
You must be thinking now, “Well, that’s easy, just don’t mess up”. Yeah, but that’s easier said than done, with less than a dozen of information to save, and total control over it you can’t commit this mistake.

But what about having 200000 different bits of data that need to be read and written correctly, by code written over 15 years, written by different people, with different designs in mind, written by functions in different files, some keeping proper spacing between data, with spare data for future use, some not. That was our situation! Years of updates adding numerous incongruities that we didn’t account for, despite fighting against it all day.

Yeah, that’s a design flaw, and that’s why we are fixing it, starting with this step! 100% Orange Juice is a bigger game than one might imagine, and such huge code base being kept alive by less than 10 people is nothing less than a miracle driven by passion and willpower over the years.

The solution
We won’t enter into detail, because our new save system not only is 100% reliable but has a good number of protection layers against people editing it. But firstly, if your save was changed externally, it won’t load.

This is to avoid the game crashing if your storage is faulty and some bit flipped. That’s why the backups are now more important than ever, if your main save corrupted, it won’t load, no one will be able to restore it, its gone forever. The game won’t even try to read it.

But not only that, now generally speaking, each bit of data inside the save games has a proper name to address them.

Let’s bring the example from before:

Wins
Points
Last stage cleared

Now we build a database in memory, naming each value in a proper structure before writing it to the save. So it would be something like this:

wins: 10, points: 393939, last_stage_cleared: 7

For reading, you simply search for the value name and loads the value attributed to it: wins → 10, points → 393939, and it goes on.

If you add a new value:

wins: 10, abilities: 1, points: 393939, last_stage_cleared: 7

It doesn’t matter, you aren’t reading in sequence, you have a proper system to encode and decode the values and search them by name. If abilities doesn’t exist on the save, you load the default value and go on.

This basically clears the future from unwanted data changes, but nothing in life is a perfect solution. We still need to load the old save, and if that’s corrupted, the new one will be too, as the old save system trusted above everything else what was written, in the exact order it was.

The game also may after some update write something wrong, that’s a bug, it can happen, it doesn’t mean the save is corrupted stricto sensu, but in lato sensu the data was handled wrongly, so that’s still a bug, that’s still a thing that needs to be reported.

So if after the save conversion on the last big update, you got more dice than the universe has seconds of life, the best we can suggest is contacting us! We will do the best in our power to fix your old corrupted save. But be aware there may be some times that it’s impossible (mainly if you didn’t play for the last 7~10 years, the amount of uncounted problems can be beyond any repair), but even in this horrific situation, talk with us, say what you hold dear about your old save, and we might be able to find a path that will make you happy.

Why we’re starting a Patreon

02/02/2024 / Fruitbat Factory / Leave a comment

2023 was in many ways a challenging year for us. Some reasons may be obvious – the post-Covid economy which has been hitting creative industries hard for the past year, as people have less disposable income, others less so, and though I have hinted at some developments in a past livestream, I promised to go into more detail though I find it a heavy subject to write about.

During the early Covid years, we were lucky enough to enjoy a large influx of new players, thanks to both people staying at home more, and us giving away millions of free games in a stay-at-home campaign. We invested the increased sales into hiring more developers so we can put in more work for you – the team currently has 5 developers working on 100% Orange Juice alone, in addition to artists, translators, QA and other support staff.

A specific goal in this recruitment drive was to be able to work on a certain project simultaneously with the ongoing 100% Orange Juice development.

For many years, people have been asking, “when will 100% Orange Juice be ported to Switch? Will it be available on mobile?”

The answer to that question has been that the engine made it rather impossible to port the game to other platforms. But in fact, we’ve been secretly working on a full remake of 100% Orange Juice in a new engine since 2018, with the goal of both modernizing the internal architecture and visuals of the game, and being able to release it on other platforms as well. The project restarted once on the way after staff changes, but the latest version was getting far enough that at the start of 2023 we temporarily assigned most of our developer team on it in the hopes that we could boost it to completion before the lower dev time spent on the live version of 100% Orange Juice becomes an issue (working on a remake of a game that’s also getting constant changes at the same time isn’t the most efficient way to develop something, after all).

It was supposed to be a fun surprise when we can reveal it to everyone (which we were planning to do soon). Then something happened.

You may have noticed I avoided mentioning the name of the engine we were developing the remake in, and some of you might’ve already guessed where this is going from that.

Yes, we were porting 100% Orange Juice to Unity.

From the beginning this came with some caveats, as the development cycle for the Unity engine has always had some issues, but it also had the best terms of use, and was determined to overall make development much easier once the remake is finished.

Then in September 2023, Unity announced their “controversial” new pricing model, which would’ve completely annihilated us as it was originally laid out. Shocked, we instantly froze work on the Unity version while waiting on more news to come out. While Unity eventually walked back the worst details of that decision, all the info that came out as a consequence coupled with the way they rolled out that change out of the blue in the first place had already done the damage. With our port approaching the halfway point to completion, we could either continue working on the Unity port full power for another 2 years, hoping things don’t get worse, or we could cut our losses and kill the project. Given the status of the project and our loss of faith in the engine for the game that’s basically keeping the food on the table, we chose the latter with heavy hearts.

That doesn’t mean we’re giving up on porting the game to other platforms, but we don’t have the resources to start a new full port from the scratch. Instead we’re now looking at steadily replacing the old modules of the live version of 100% Orange Juice to eventually make it compatible with more hardware and other platforms. What it does mean, though, is that all the time and money spent on the Unity version over… 6 years was more or less entirely wasted, apart from the experience gained from it.

Due to the aforementioned dev reallocation, 2023 was a slow year for new content in 100% Orange Juice. At the same time, with the economy at large returning to normal, 2023 saw an overall drop in sales, leaving us with a bigger development team, less sales, and at the same time people understandably complaining about a lack of new content.

Sometimes stars just don’t align the way you want them to.

I want to emphasize that this doesn’t mean we’re going to have layoffs, or that we’re stopping work on our games, or anything like that. This post isn’t about that. While 2023 left us in the red, we’re dealing with it in other ways as best we can. In fact, this Patreon is one of those ways – we’re seeking alternative revenue streams to help support our ongoing development work.

As of late 2023, all of our 100% Orange Juice developers are back working on the live version, and while we had a lot of backlogged content to wrap up (such as the Bounty Hunt rework), you can expect a lot more in 2024 – the 10 year anniversary of 100% Orange Juice on Steam! There are a ton of things we’ve wanted to do but figured out make more sense in the Unity version, which has become almost an internal meme at this point. Now we will be focusing on gradually implementing those in the live version.

If the Patreon doesn’t take off, or ends up being more trouble to maintain than it’s worth, it may end up short lived, but I figured it’s worth a try.

So what will you actually get in return for supporting us on Patreon? Not much, really, and we don’t recommend you do it if your finances are tight. We will be posting random stuff from behind the scenes irregularly relating to whatever we’re working on – some disaster screenshots from things gone wrong in development, ramblings by developers, and possibly teasers for new content. For those curious, I’ve attached a small gameplay video from an earlier Unity build on the page. There might be more stuff like that. The last thing we want is for people feel they need to sign up on Patreon for exclusive in-game content, so that’s not going to happen.

If we get good ideas, we might add more tiers later, but for now there’s just a single $5/month support tier that will give you access to all of our posts.

Thank you for reading this far, and thank you for your support over the years.

– Jakke Elonen
President of Fruitbat Factory

Fruitbat Factory Patreon Page:
https://www.patreon.com/FruitbatFactoryDevelops

The Tale of a Newbie Programmer

22/07/202022/07/2020 / Fruitbat Factory / 1 Comment

Do you know Sora, our newest crew member? Please enjoy this self-introduction. We’re giving the floor to him now!

Hello! You may have not heard about me before, as I quietly slipped into the crew.

I come bearing the mame of my favorite character: Sora as my nickname. I discovered 100% Orange Juice through a friend back in 2016. If I had to quickly give an introduction: I live in France, am 24 years old at the time I’m writing this, and I love heavy metal music. Atreyu’s band is my personal favorite. \m/

My favorite hobbies are pretty much: gaming, creating things, drawing, and hugging my Sora & Suguri plushies.

I joined the Fruitbats on the 10th January 2020. It’s my first professional experience as a programmer, and I was super excited to get started. After setting up the project files and everything, I got assigned my very first task: making the master volume option, which needed both UI modification, and save file changes.

The game engine used, Luna3D, is made in a very specific way which does not use OOP everywhere – I just got out of intense C++ practice before getting hired, so seeing old methods of coding felt a bit threatening at first.

The fun part of working with a brand new environment was first getting my bearings, finding what does what, and putting those two together into a decent code. Thanks to the team, I asked whenever I needed help, and I had my answers quite fast. Something I wasn’t used to though, is that logic and drawing are both handled in two different places, which I was not doing before. That said, a lot of the basic concepts were completely unknown to me as I had no previous experience with them. 7 hours of work were needed before I managed to get a decent result that worked quite well. Later on, I kept on going with other voice options, as well as other tiny changes here and there.

The first big project I had to handle on my own was one of the new Playground mini-games: Poppo Shooting. It went through several prototypes, the one that comes to mind being stationary balloons, and a score based gameplay. It got changed later to moving balloons carrying rewards.

It was also the first time I had to tackle the wonderful network code, and managing the AI behavior. When starting the development, I was unsure of which direction I should go, there wasn’t (from my understanding back then) any hitbox functionality, which was crucial for a balloon & dart based game, which was the base idea. A quick search on google led me to an SDL example, which I could adapt to our code. And miracle of miracles, it worked. Besides that, some of you might remember that the CPU was really bad at this minigame. I came back to it weeks later (I think it was a few days before School Crashers event ended) and improved the AI by a lot, giving them priorities, a (way) better aim, and decision management.

Afterwards came some QoL features, such as saving the lobby name & password between game sessions, and changing those in the lobby directly if you were the host. The previous experience I gathered made that way easier for me to implement. It was the first time I had to bother Tony (Rive, our lead programmer) for some AoS2 code snippet, which I took about 30 minutes (and a lot of re-explanations) to understand. If you read that Tony, please forgive me!

The next “big” feature I made was the integration of the Rich Presence feature of Steam & Discord, as well as fixing steam invites so they would make you join your friend’s lobby directly. It took a lot of effort to debug, but in the end everything worked quite well. The funny part was working with an old framework (discord-rpc) which has no more support at all. I remember having some issue about the game invitations, but trying to email discord would redirect me to a server that gives support to the newer version and not the old, which was not helping me at all. But in the end, I eventually found out the issue myself and corrected it. We had to implement a way to retrieve Steam avatars and convert it into a usable texture, which took me a lot of research in order to know how to do it, as I had little to none knowledge about how DirectX works. With the help of hexun, we managed to get the avatars working together, which were added later in the lobby screen.

Later on, the project I have probably spent the most hours on (a full month and a half!) was handling, along with trackftv (yet another of our programmers), the Bounty Hunters event. While Track was creating the quest & bounty side of the game mode, I was creating the shops as well as thinking of items. It was a lot of ~~suffering~~ fun to debug all of this. (And even if some horrible desyncs got through when it was put live, we managed to fix it quite rapidly.) The one thing I remember the most is all the panel layering issues we had – Basically, the panels had way too many things on them at once, which completely messed up the layers (For example, BH shops going over Arthur’s shops, like competition was a crime!)

Thankfully, Track managed to fix all of it… I think. I’m sure we’ll have to look back at it again once we’ll tackle the remastered version of Bounty Hunt!

You can notice here that we originally planned items to be locked behind your current Norma level.

Lately, you saw me pulling out the official modding support. It was something I really was looking forward to, knowing that I came myself from the modding scene in other games. The whole system took about 20 hours of work. It’s of course not yet finished. A lot more is coming for it, including the much requested Steam Workshop support. I don’t have any big details to share about the system overall, just that it was a second take at it after failing the first time a few weeks back. But I’m glad that today so many people enjoy making custom skins for their favorite units.

I could expand that list of projects even more, but some things have yet to remain private for now. I’m super happy to be a part of this wonderful team, and I can’t wait to see how far we’ll be going together!

Editor’s note: everyone be nice to Sora!

When Jiangshi Met Daoshi

17/07/2020 / Jakke Elonen / 13 Comments

It’s finally out, a visual novel we’ve worked on for some 3 years in one way or another!

Jiangshi x Daoshi is now available on both itch.io (regular version) and Steam (more YouTube friendly version)! Also, both versions are free to play.

Check out the kick-ass trailer for this kick-ass game developed by Dendo-Denkido here:

It’s been an eventful journey to get here, so I wanted to dump some info about it.

The Background

Jiangshi x Daoshi defies explanation. On the other hand, it’s free so just go and play it for yourself.

It’s the product of many years of work by the developer Dendo-Denkido, who are awesome folk and you could always find their booth at Comiket (back in the day when those actually took place). Even if it’s not “long” in traditional terms, you can see their effort on every screen of the game. I don’t think there’s a single screen that passes without some animation. I rather think of it as playing a SHAFT anime. Oh, and it’s also fully voiced, with a very prolific cast of seiyuus!

The game is episodic, and after 8 years of development there are currently 3 complete episodes. Episodes I+II are now available for free at our end, and we will release Episode III – Lady Hexers later this summer, at which point it’s caught up with the current doujin release. The game is still very much in active development, and there should be more coming… eventually. This quality doesn’t come overnight, but good things come to those who wait. If you like the game, you can show your support to the developers on Twitter!

Up to this day, Dendo-Denkido has distributed the game for free in Japan, which we also took into consideration in our decision to release the game free of charge. Of course we still need to cover the translation bills eventually, but you can take it as a sign of how much faith we have in this game. Episode III is planned to be released as a paid DLC on Steam, and with a PWYW model on itch.io so people can still play it for free if they want.

The Translation

Jiangshi x Daoshi is our final full translation into English by the late Conjueror (we still have one secret project that was partially translated by him, but that’s for another day) and edited by Garejei. Drenched as the game is in Chinese lore and the supernatural (as well as bizarre humor), Conjueror mentioned it was the hardest game he’s had the pleasure of translating. I hope you will like the result every bit as much as I have.

As there’s a large Chinese-speaking audience on Steam now as well, and it was something the developers wanted in the first place, we also more recently decided to translate the game into Simplified and Traditional Chinese, which translation should be released alongside Episode III – Lady Hexers later this summer.

The Steam

Okay so this is where things got spicy. Of course we’ve followed the developments with Steam’s approval process with concern for some time, and as such I’m always worried whenever I submit a new visual novel for approval. Still, despite joking about it we didn’t seriously expect the game to get flat-out banned on submission (a rejection wouldn’t have been surprising, it happens more often than not, then you address issues and resubmit). Well, it did. Ticket closed. No resubmission option, no room for dialogue.

This despite the fact that Jiangshi x Daoshi doesn’t feature any adult content.

There’s certainly a lot of offensive content of various sorts (think South Park when it comes to the mature humor of the game), but… yeah, that response was unexpected. Moreover, as a consequence of that game ban, we learned that games that get banned on Steam… leak from the database. So certain sites knew of the ban and thus, of the secret project, as soon as we did.

This wasn’t a very pleasant situation for a release we had high hopes for, and we had to scramble to put together emergency plans with all possibilities considered, including a rapid ninja release the very next day in case that we’d have to release the game to obscurity outside of Steam, and with intense press scrutiny if the story ended getting picked up more (which I’m glad we ultimately didn’t have to do, as we’ve put the time to good use polishing the title, squashing bugs and adding more user friendliness features, such as the option to hide the UI for cool screenshots).

Luckily we received a response from our Steam rep (yeah, we’re fortunate enough to have one, I’m well aware most devs don’t), which gave us some hope for resubmission, and after some back and forth we ultimately were able to resubmit the game. Of course, info regarding what was wrong the first time was rather vague as you might expect (we got one general pointer, but no idea of the scope of what they wanted us to address, and whether that really was all that would be objectionable or if that was just the first thing they ran into), so the resubmission (for which we might only get 1 chance for all we knew) took some thinking. We worked with Dendo-Denkido to alter key graphics under the info we -did- get, while otherwise staying true to the game’s artistic style, and after an initial rejection (fortunately, not a ban this time) with further required adjustments outlined, we ultimately got the game accepted for release!

In good news, the Steam version is probably a lot more YouTube friendly. But if you prefer to play the game as it was originally intended, we have a patch up on our homepage which will restore the Steam version to its original shape.

The End

Make sure to enjoy the craziest game you (probably) never heard of!

Tales from SeaBed

22/11/201723/11/2017 / Jakke Elonen / 3 Comments

With the release date of December 19 fast approaching, we wanted to take a look back on the development process of the Steam version of the upcoming yuri-themed visual novel masterpiece, SeaBed.

SeaBed has been one of our most intensive projects so far, and we absolutely fell in love with the game while working on it. In total, we have worked on the game for roughly a year, from translation to polishing the user interface.

To start with the basics, SeaBed has been translated into English and edited by industry veterans Conjueror and Garejei, respectively, and we’re extremely satisfied with the flavor and life they have brought to the complex story.

While the translation work was ongoing, there was another big project that we undertook: the HD upgrade of the game. Well, HD isn’t technically accurate since the new base resolution is 1440×1080, rather than the 1080p standard, but I think it paints an accurate enough picture of what we did.

SeaBed was originally released in 800×600 resolution, but it features boatloads of stellar art (with around 100 unique CGs and over 1000 character tachies across the game) and we really wanted to make that shine. In a rare fortunate turn of events, the developer Paleontology had the original resources in higher resolution .PSD files, so we proceeded to recreate all the art in the game in the new target resolution. This work alone took months, but after playing the new version we hope you will all agree that it was well worth the effort.

Since not everyone has a 1080p display, we also added support for multiple different resolutions, including an automated resolution selection that by default always uses a resolution your screen can display.

Another visual aspect that we always pay attention to in visual novels especially is the fonts. When done right, you, the player, will never think about them. Especially not in the sense of “wow, this text sure is ugly/hard to read”. We typically evaluate dozens of different fonts before finding one that captures the tone of the game just right – so far, all of our visual novels use different fonts, not by any particular decision to never repeat the fonts we use but simply as the result of this process.

There can be a lot of text on screen in SeaBed, so the main font we chose for the English text has a calm and slightly clinical feel to it, befitting of the narrative tone of the game. It’s first and foremost easy to read.

A secondary font is used when reading through written materials in the game, and we aimed for a compromise between a handwritten feeling and still being easy on the eye.

The font size we ended up using is fairly large, so it’s readable even when playing on a lower resolution screen, but it can accommodate all the text that was meant for one screen and is not obnoxiously huge if playing full-screen on a large display.

SeaBed is our first visual novel that has in-game support for both Japanese and English languages – easily changeable at any time from the settings menu. This compounds all the effort that went toward polishing the text settings, as we had to make sure they would work even if people play around with language options.

Other improvements we have made to the game include improving the text skip mechanics, which will especially help those re-reading the story and looking for particular passages.

Moreover, our programmer Tony and one of our testers, Denis, worked together to loop all of the game’s 60+ music tracks in the game, so they now replay seamlessly while playing. The BGMs have been carefully chosen by the developer and play a crucial part in establishing the mood of each scene, and removing any distracting pauses was a way to further strengthen their effect.

Lastly, the original 800×600 ending video of the game has been recreated in loving detail in the 1440×1080 resolution, with bilingual credits. Look forward to it at the end of your journey!

Finally, the Steam version of SeaBed will come with full Steam features – achievements, Steam Trading Cards, Cloud support. Did you know that Steam overlay doesn’t work in all games automatically? There are various changes we’ve made under the hood in SeaBed – like many of our other games – to get the overlay working smoothly so you’ll never have to think about it.

Soon you’ll get to experience all of these changes live – and if you never have to stop to think about them, they’re working as intended.

SeaBed Coming to Western Shores!

10/02/201710/02/2017 / Fruitbat Factory / 2 Comments

We’re very excited to reveal a new game acquisition: SeaBed, Paleontology’s highly anticipated psychological yuri visual novel is getting an English language release by us!

SeaBed was released in Japan in 2016 and quickly drew the attention of visual novel enthusiasts in both Japan and abroad.

Text-wise, SeaBed is one of our largest translation projects, in addition to being known for its unique, high level writing style. We expect translation to take longer than usual, since we want to bring it out in the highest quality possible to meet the fans’ expectations. The English PC version is currently expected to release in late 2017.

Who is SeaBed for? Well, if you like yuri games, or just like a really well written story regardless of genre, this is a game you shouldn’t miss. SeaBed’s story is deeply psychological and beggars description, but here’s the official synopsis:

SeaBed is a critically acclaimed yuri-themed mystery visual novel told through the perspectives of three separate characters: Mizuno Sachiko, a designer plagued by hallucinations of her past lover; Narasaki Hibiki, Sachiko’s friend and a psychiatrist researching the workings of human memories; and Takako, Sachiko’s former lover who has been rapidly forgetting her past, including how or why the two women drifted apart despite being together since childhood.

All three live in different worlds, but seek the same goal. To separate truth from illusion. To make sense of their own lives.

The Steam version of SeaBed is being updated to natively support 1440×1080 resolution. It will also include Steam achievements, Cloud support and Steam Trading Cards.

You can see a full set of high resolution screenshots on SeaBed’s homepage and Steam page. The game is available for pre-order for the price of $19.99 from the Fruitbat Factory store with a -25% pre-order discount.

About Paleontology
Developer of original Japanese version (Twitter, Homepage)
Paleontology is an independent Japanese game circle creating yuri-themed games. SeaBed is their first game release. It was developed based on the characters of a 4-koma manga series created by their illustrator, hide38.

We have even more exciting announcements coming out, so stay tuned!

100% Orange Juice – Popularity Games

21/01/201721/01/2017 / Fruitbat Factory / 1 Comment

We just recently made an internal summary of 2016 player stats in 100% Orange Juice, and I figured it’d be fun to do a breakdown of some popularity stats for the year.

It’s a long post, so prepare to scroll down!

Before writing this post, I also made some polls on Twitter for some of the categories, to see if people can guess which character was most popular. The community answers will be included where relevant.

Starting with the big one:

Most popular starter character – the winner is… Suguri! (Community guessed correctly!)

Least popular starter character – the winner(?) is Kai!

Most popular non-starter character – the winner is Star Breaker! (Community guessed Sora)

Most popular non-starter FRB character – the winner is Sherry (who gets a bottle of wine)! (Community guessed correctly!)

Most popular non-starter male character – the winner is Peat!

Most popular campaign unlock character – the winner is Yuki!

Most popular bonus character – the winner is Mixed Poppo! (community overwhelmingly guessed Sora (Military))

Most popular bunny – the winner is… Aru! Congratulations!

Most popular NPC character – the happy winner is Chicken!

And last, the answer (at least for 2016) to the question, which one is more popular – Saki or Sham? The numbers don’t lie, the winner this time around was… Sham! (Community guessed Saki)

We have a lot of cool stuff planned for 2017 too, so stay tuned!

Status Update

29/09/201629/09/2016 / Jakke Elonen / 2 Comments

Hey everyone! It’s been a while since our last post where we talk about the status of our various projects. Since we have an extraordinary amount of games in the works at the moment, I figured it’d be good to give a bit of an update on them all.
So if that interests you, buckle up and read on.

100% Orange Juice

I’ll start with a game that’s not coming out any time soon. In fact, it’s been out for 3 years now. Still, it’s our best-selling title, and we’re constantly working to keep improving it, so it feels natural to talk about it first.

We employ a full-time programmer, and most of his time goes to developing 100% Orange Juice, it being the most technically demanding of our games. Over the months and years we’ve kept improving the infrastructure of the game to the point that if you watch the Steam trailer for it now, you’d be hard pressed to find a single detail that hasn’t changed in some way since making the trailer (and yes, we have a new trailer in the works!).

The latest major undertaking was changing the rendering of the game so that almost every text in the game is now stored as plain text instead of graphics, allowing us to support multiple languages in a rapidly changing game. It was the wish of Orange Juice to add support for Japanese, and with the most recent update, we can now also support any number of custom languages. It’s cool to see many people working to translate 100% Orange Juice into their native language!

On our recent trip to Japan, we sat down for a good chat with Orange Juice about the game’s current development, and the things we’d like to do with it in the future. It was heartening how they were completely on board with all of them, so we have a ton of exciting news in store for 100% Orange Juice in the coming winter. A keen observer may have observed some spoilers for some of them on the Internet already, but we also have some ideas that we’re confident will surprise everyone.
*****
Moving onto our upcoming releases…

ENIGMA:

Although our background in the industry comes strongly from visual novel translation, Magical Eyes – Red is for Anguish was the first pure visual novel we released as a company (putting aside the two 99 Spirits fan disc stories). However, it won’t be the only one. With all likelihood the next one will be Uzumeya’s mysterious fantasy ENIGMA:, which has an interesting narration style and tons of endings.

The translation, courtesy of Conjueror, is now at 100%, and the game is moving into editing. The project’s slated for release this winter, either late this year or early next year.

Lionheart

This cool new RPG comes from Shiisanmei, and is packed full of cute character art and tongue-in-cheek humor. As a fairly massive RPG, there’s a lot to QA in Lionheart, and I can foresee that process taking a while.

Translation itself is at 95%, and same for editing. What remains is mostly combat data. Although it’s possible we’ll be able to release the game this year, it’s more likely to happen early next year, since playtesting is expected to take some time.

Miniature Garden

Translation is now beginning on Muzintou’s dark mystery visual novel Miniature Garden. Not much else to say about it yet, but look forward to the finished game! The production values (including Korie Riko‘s art and the top of the line anime voice actors) are pretty amazing. We’re aiming for a release around Spring 2017.

Dungeon Girl

Inu to Neko is a hard-line developer who’s been making gameplay-heavy games for well over ten years, a major feat in itself. Dungeon Girl is our first release from them, and we’re looking forward to bringing many new fans to the game universe. Did you know that all Inu to Neko games share the same world and many characters? Working on Dungeon Girl has been fun so far, and there’s a ton of depth to the gameplay mechanics.

Translation of Dungeon Girl is currently at 78%, and editing at 72%.

Acceleration of SUGURI 2

We had a slightly unusual reveal for Acceleration of SUGURI 2 this summer, and one that was a ton of fun for us. Since then, we’ve received countless requests for status updates. Well, I’m happy to say that the translation and editing of AoS2 is 100% complete. However, the biggest challenge we’re tackling for its release is programming, since we want to handle its multiplayer right. As with 100% Orange Juice and 200% Mixed Juice, we plan to support Steam lobbies and possibly add some extra multiplayer features.

We will start the Steam programming shortly, but it will likely take several months, so I can almost guarantee it’s not coming out in 2016.

Seven Days

While not really an ongoing project on our part, those who follow our social media, or visited our booth at Tokyo Game Show, saw us promoting LIFE0‘s upcoming visual novel, Seven Days, and made the correct assumption that we have the rights to an English release.

Seven Days is currently raising funding on CAMPFIRE, a Japanese crowdfunding platform, and has so far raised a hefty 4.2 million yen out of its 2 million goal. There’s still a few days left if you want to support it, though please note that CAMPFIRE is for Japanese users only. We are also co-funding the game’s production, so naturally our expectations are high.

Seven Days is coming out in late 2017 and we’ll have more updates and an official reveal closer to that time.

***
…And more?
***

That’s the end of this status update. You should take any release estimates with a grain of salt, as you may note that we don’t list an actual release date for any of them yet. There’s always a chance that some aspect of a game takes longer than expected, or that we run into an unforeseen issue somewhere along the way. Or conversely, we may finish our work on a game a month earlier than initially estimated. That’s why we avoid committing to any dates until a game is virtually ready to release, and the estimates you see here are just that, rough estimates.

Tokyo Game Show 2016 Guest Schedule

08/09/201608/09/2016 / Fruitbat Factory / Leave a comment

Hello everyone!
With Tokyo Game Show 2016 (September 15-18.) rapidly approaching, we’re happy to announce the final list of guest appearances at our booth. The full list of guests includes Yakiniku Banzai, Orange Juice, LIFE0, Tazigen Clock, Inu to Neko, Muzintou and Shiisanmei!

You can meet representatives of the circles at our booth, 7-N01 at the above times. Our star guest, Poppo, will also be giving signatures whenever she’s not out and about.