Hey there chaps,

It’s been a busy few months for us, and a lengthy wait time for you, but we’re excited to announce that the conversion of the game from Ren’py 7 (Python 2) to Ren’py 8 (Python 3) is finally complete! We’re now in the final testing phase, and we can’t wait to share the new version of the game with you.

Before I get to the juicy stuff, I’d like to unleash my inner nerd 🤓 and talk a little about the process we went through, and how it affected the game and our workflow. I’ll try to keep it concise, but no promises.

One of the most challenging aspects of the conversion process was redesigning the internal systems without hurting performance or losing functionality. I have made some questionable design decisions before, that in retrospection I’m not proud of. Some were made due to time constraints and others due to my limited knowledge of the Ren’py engine. During the conversion process, I took the opportunity to address some of the aforementioned design and performance problems that had been plaguing the game ever since its creation.

For example, whenever the character call was made in the script, it would compute the clothing colours, layer structure, animation constructs, and only after that was done it would finally render the character image using a custom displayable. While the design was logical, unfortunately it was flawed at its base because I designed it as if it were being implemented in an entirely different game engine. The implementation was computationally expensive, the calculations had to be made every single statement for every single displayed character. Moreover, due to the nature of the engine and my misunderstanding of certain key features such as rollback, the performance degraded each time a rollback was performed. Uh-Oh. That doesn’t sound efficient, does it?

So, here’s what went wrong. Rollback is a great feature that other engines besides Ren’py implement, but the Ren’py implementation is pretty unique. Since Ren’py is based on Python, I assumed everything would work just like in good ol’ Python because why wouldn’t it, right. That’s the first mistake I made.

It is true that Ren’py supports the majority of Python functions, but it also implements its own subset of instructions and changes that modify how Python itself behaves inside the engine. To be able to showcase what went wrong, first I need to explain how memory is handled in Python.

Whenever you spawn a python object, the object reference and its attributes are being stored in memory until the program ends, or you delete the object, in which case it will be garbage collected (removed from memory) after python detects it is no longer in use. Sounds simple enough.

However, in Ren’py, each object reference and its attributes are being stored in memory twice. This is because rollback makes a copy of each object’s attributes and stores it in a log. This allows Ren’py to roll back the game and its code seamlessly, however, not without side effects. To reduce the number of side effects, each time you roll back the game, the statement you are rolling back to is being re-run, recreating the objects and their data. Some of you may already see the issue I’m trying to portray here.

The code responsible for generating character images was not intended to be run so frequently, so the faster you rolled back, or moved forward, it would not only waste CPU cycles, creating hitches and lags, but also bloat memory out of proportions in certain situations.

This brings us to another issue that I have been trying to fix for forever — Android devices crashing. For the longest time, I have been attempting to pinpoint the cause for crashes on certain devices, but for the life of me, I could not figure it out. The game worked absolutely fine on all my android devices, it was frustrating, I have been looking over the log files some of you were kind enough to send, and wondering… the numbers, Mason, what do they mean?

In the past few months, I was finally able to piece everything together. It turns out, the implementation of the rendering engine on certain phones is completely different compared to the implementation on my test devices. So, basically, this memory handling thing was a big headache, especially on Samsung devices. There were two main culprits: my code wasn’t quite up to snuff, and to make matters worse, Ren’py had a few bugs in the features I was using that were causing the same issue.

Initially, we have tried keeping the engine development apart from the main game development, unfortunately, during the implementation of some of the new content and features we had planned, we discovered game breaking bugs that stalled the process, and it put us in a conundrum.

We had two choices; We could either redesign the content plan and cut the problematic parts, risking encountering them again in the future, or, spend more time and resolve those issues once and for all, at a cost of a longer development cycle.

After lengthy discussions, we came to the conclusion that our only option is the option number two, and here are some of our reasons;

• Performance issues:
  • Adding content would exacerbate the issue
  • Under memory-constrained situations, switching to full-screen would crash the game
  • Replay mode would take literal seconds to activate and switch contexts
  • The rollback performance was bad
  • The focus mechanism was causing stutters and slowdowns
  • Memory bloat
• Python 2 deprecated in 2020:
  • Last update in June 2016
  • Issues with modern implementations and hardware
  • The Python 2 version of Ren’py will be discontinued eventually
  • Memory limitations
  • Suboptimal functions and syntax
  • Long list of known issues with no fixes
  • Lacking optimizations
  • Lack of support
  • Ever-increasing number of vulnerabilities
  • … and more
• Android issues:
  • High memory footprint
  • Segmentation faults
  • Performance regressions
  • Memory and texture leaks
  • Lack of hardware acceleration in certain cases
• Ren’py 8 and Python 3 offer numerous features that:
  • Enhance game development
  • Reduce downtime
  • Improve quality
  • Improve performance
  • Add modularity
  • Enable creation of user-defined statements
  • … and more

There are many factors to take into account, but the above list only scratches the surface. Unfortunately, we had to overhaul everything, which I was hesitant about, but I kept going because I knew it would stop you guys from complaining about performance. I’m joking. Or am I? 😗

Putting jokes aside, tackling this task has been a true behemoth, especially since I’m the only programmer on the team. But luckily, I’m surrounded by the most helpful and passionate group of people you could imagine making a porn game with. Whenever I hit a roadblock, I can just hit up Johnny or the others and talk it out, whether it’s coding problems, design issues, or just something as simple as waking up on the wrong side of the bed. Being able to discuss things or vent helps me gain new perspectives and ideas. Although, I should probably look into rubber duck development, as I’m already taking up too much of their time. 😆

Wrapping up. I’m pleased to report that all the aforementioned issues have been addressed, and we’ve noticed major performance improvements across all range of devices (that’s at least 3 computers and 2 phones 😉). I understand that not everyone has access to top-of-the-line hardware, so I’ve also included certain optional features that should enhance performance on the more capable hardware, such as an image cache slider that aims to improve performance at a cost of higher memory consumption. There are also numerous tweaks and enhancements that apply across all platforms. To address the performance issues within character image constructors, I implemented a solution where the results of the calculations are stored and cached. This allows for the efficient retrieval of previously generated valid combinations of character statements, saving both memory and cycles.

Of course, it’s not just about performance and bug fixing. We have also implemented a vast range of features that we hope you will enjoy in the upcoming weeks.

One of such features that wasn’t mentioned before is the expanded modding support that allows you to expand the game with ease and to the extent that was not possible before. You can add new characters, events, modify storylines and dialogues without limitations or increased complexity. I’m also working on adding documentation and modders resources.

I’d like to mention another feature we’re working on: the improved integration of wardrobe within the game. We noticed that gameplay and wardrobe elements were a bit disconnected, so we’re actively trying to address that by adjusting events and adding more checks where needed. But that’s not all.

We’re also working on revamping and adding clothing support to chibis. We plan to cover all quest-related outfits and clothing pieces, but we’ll need to discuss the rest further before I can give you a more detailed answer.

But enough about technicalities. Now, if you are still awake reading this post, it’s time to share the juicy part you all have been waiting for — the release date.

If everything goes as planned, the next update should be released… queue the drumroll, sometime next week. Yep, you heard it, the wait time is about to be over boys and girls!

Given the extensive nature of the changes and the use of an unreleased version of the Ren’py engine, we will label this update as an alpha version until both our codebase and the Ren’py codebase are stable enough. We’ll likely keep the older update live alongside the alpha update until that point, but we will need your help with testing if you’re willing.

The plan is to release updates in quick succession, fixing reported bugs and adding some new content we haven’t included yet, alongside some other changes we hope to reveal publicly later. We will make an announcement as soon as we have further information to share.

Once the bugs are squashed and the update becomes feature-complete, only then we will move onto working the next update, which should take much less time to develop now that we’ve addressed all the issues we’ve had with the project and our workflow. No worries, we don’t plan doing any more maintenance. 😛

If you’re reading this, congrats – you’ve made it to the end of the post! Before I go, I just wanted to thank you all for your support and patience. We wouldn’t be here without you, and there’s no better feeling than seeing others enjoy your hard work.

LoafyLemon out.

P.S. We will be posting some teasers in the upcoming days, stay tuned!

Hey everyone! We have some updates on the progress of our game development process. To begin with, we’ve decided to start making development blog posts to make up for the radio silence, which we apologize for. Progress reports aren’t always possible to make when we’re in the middle of the development, and they don’t always contain information about what we’re struggling with or the actual immediate changes we’re making.

Another reason why we’ve decided to start making these development blog posts is because we understand that not everyone has the expertise to read and understand the code changes we’re making, even if we use Git and everyone can view our progress. By writing these posts, we hope to make our development process more accessible and transparent for everyone interested in the game, so you can get a behind-the-scenes look at our work. We’re excited to share our journey with you and hope you find these updates helpful and informative.

We also want to inform you that we plan on making these development blog posts bi-monthly, so you can expect to hear from us more regularly. We want to keep you all in the loop and share the progress we’re making in the development process.

Moving on to the game development progress, Johnny has been working hard on the writing, while I’ve been focusing on porting the game to the newest version of Ren’py and Python. This has been a long and challenging task, involving testing, fixing bugs, converting CGs, and refactoring the code. However, we’re finally starting to see the light at the end of the tunnel, and all the hard work has been worth it.

During the playtesting phase, Johnny has been able to elevate the writing even further. We’re making adjustments to Hermione’s public events to match her personal events and adding more event checks. For instance, during early Hermione favours, you can ask her to dance for you. However, when you ask her to do more than dancing, the event will fail. Once you’ve progressed further, and you’re finally at a point where she accepts, she will still act surprised by the request, which didn’t make sense. So, we’re adding more checks like this to make the writing less generalized and the reactions more genuine.

We want to make sure the game feels authentic and immersive, so we’re asking for your help. If you notice something that feels off, even if it has already been established, please let Johnny or me know.

In other news, I’ve made a Discord bot to automatically post embeds on our Discord server whenever we create a new post on the website. This way, we don’t have to repeat the same thing on every website we manage.

We appreciate all the support we’ve received so far and are excited to continue working on this project. Thank you for your patience, and stay tuned for more updates!

P.S. Johnny had a chicken for lunch today.
P.P.S Johnny says it was a joke and to not include it in the post, well, it’s too late for that now!