Hello there fellow Witch Trainer enthusiasts, LoafyLemon here! I’ve got some bits and bobs to share with you all today, so buckle up!

First off, I want to give a massive shout-out to everyone who chimed in on the recent polls and voted resoundingly in favour of spicing up our Patreon with exclusive behind-the-scenes content. Creating these posts is not just fun, it also serves as a good creative outlet to vent our frustrations and accomplishments. I truly appreciate the love and support you’re showing us. You’re the reason we put so much effort into making this project special! ❤️

Now, onto business! As some astute observers already deduced from previous hints scattered across our social channels and git repository, we’re currently knee-deep in polishing the final touches of the Luna Lovegood update. And lemme tell ya, it’s been quite the roller-coaster ride! 

One scene in particular, has been keeping me awake at night with its relentless demands. I’m talking about the grand finale of our intimate conversation system – the infamous ‘Talk to Me’ interaction. You know, the one where you, the dashing Genie, coax sexy responses from your loyal witch, Miss Luna Lovegood, depending on how naughty you choose to be. Well, this time, we have decided to spice things up, breaking the boring formula and add some visuals and reactions to it!

If you recall correctly, the last time we dropped some tantalizing teasers, we gave you a glimpse of Luna posing provocatively, splayed on the desk with legs and feet held up high in the air. Quite the image, isn’t it?

However, as always, behind every mesmerizing facade, there lies a sweaty, grubby artist, toiling away ceaselessly in his dark lair, struggling to translate those fleeting visions into tangible form.

I won’t bore you with tedious details about selecting suitable colours, tweaking minute details, or trying to get the feet right until my eyes bleed tears of blood (I already did that before! Although if you’re genuinely curious, feel free to drop a comment below, and I might indulge you later).

Fortunately, after countless failed attempts and plenty of cursing under my breath (maybe not so quietly sometimes), I think I finally cracked the foot-drawing code! Well, sort of. It’s not perfect, but hey, nobody said it has to be.

Of course, the previously showed images in the last dev-dump post are merely a rough draft, just a tiny fraction of the bigger picture. There’s still plenty of polishing left to do before it reaches its full potential. But rest assured, my dedicated team and I are pouring our hearts and souls into this project, ensuring it lives up to the lofty standards you’ve come to expect from us. This scene is the last big part of the update that we need to finish. Currently I’m working on the line art.

Line art is basically the skeleton of your drawing – it establishes the basic shapes, forms, and lines that define each element’s silhouette, volume, and proportion. Think of it as tracing the essential outline of the object you want to render, except with lines instead of pencil strokes.

This phase is arguably one of the most critical parts of the process since it determines whether the final product will look cohesive, balanced, and pleasing to the eye. A solid foundation makes it much easier to refine and polish later on.

For this specific project, I’m using *Paintool SAI 2* vector-based ‘Pen Tool,’ which allows me to draw precise, smooth curves and straight lines with various weight and colour settings. Using vectors instead of pixels has two significant advantages: first, they scale infinitely without losing quality, meaning you can zoom in or out as close as you want, and it will still appear crisp and sharp. Secondly, you can easily manipulate and adjust elements later without causing any distortions or artifacts.

In this case, I start by defining the main silhouettes (such as Luna’s body or the desk) using thick, heavy lines with darker colours, making sure they intersect correctly where necessary. Then I move onto secondary elements like hands, hair, clothes, etc., using thinner, lighter lines with brighter hues. Finally, I refine everything even further by tweaking angles, curves, and points, experimenting with line weights, line widths, line caps, line joins, and various other parameters until I achieve the desired effect. On top of the usual typical line art work, and because the scenes are supposed to be dynamically rendered in the game engine, I also must slice and split layers accordingly to fit within the engine’s scope for posing purposes. Once the line art is done, I will move onto shading, but more on that later.

And finally, before I wrap things up for today, I’d like to address one burning question that’s probably been nagging at the back of your mind like an annoying mosquito: “When can I finally play it?!”

Well, sadly, I can’t reveal our exact timeline publicly (gotta maintain some mystery, don’t I?) But I promise you this – we’re working hard as humanly possible to finish this monster ASAP so that you can feast your hungry eyes on all the steamy, sexy delights Luna and company have prepared for you!

Until next time, take care, stay tuned, and don’t forget – your support means everything to us! Thanks for sticking by us this far; here’s to many more exciting adventures together ahead!

Hey there, Patrons and WTS fans! It’s LoafyLemon here, your friendly neighbourhood adult-game dev. Today, I’m going to give you a sneak peek into the process of implementing CG scenes (hand-drawn smut) in Witch Trainer Silver.

The process starts with sourcing the perfect CG images. We’re quite picky about this *cough* as are most of our users *cough*, as the quality and style need to match the overall aesthetic of the game as closely as possible, which I must emphasise, it’s not easy! Once we’ve conceptualised and drawn the scenes, it’s time to prepare them for integration. This involves splitting layers, resizing, cropping, and optimising the images to ensure they load smoothly within the game.

Next up, we need to decide where and when these CG scenes will appear in the scene they were planned for. It’s all about finding the right balance between storytelling and visual pleasure. We want to make sure that these scenes enhance the (s)experience without disrupting the flow of the game.

Once we’ve figured out the placement, it’s time for the programming part. I use SublimeText as my code editor of choice because it’s blazing fast, versatile, and has all the features I need. To integrate the CG scenes, I write scripts that trigger the scenes at specific points in the story. These scripts also handle the transition between regular gameplay and the CG scenes, ensuring a (usually) seamless experience for you lads and gals.

Of course, I wouldn’t be myself if I didn’t dive a little bit deeper into the technical side. Historically, I used my own python implementation for CG scenes, which turned out to be less than ideal because I was going against the current, fighting with the engine quirks, instead of following its workflow. Ren’py’s layeredimage feature plays a crucial role in this new process. For those unfamiliar, layeredimage is a built-in Ren’py feature that allows us to create complex and dynamic scenes by layering multiple images on top of each other. This is particularly useful for CG scenes, where we often need to combine backgrounds, characters, and various other elements to create a cohesive and visually appealing image, while maintaining the ability to switch parts of the image dynamically.

Promptly after the image definitions are implemented, it’s time to pose the scenes and see how things fit together. This is a time consuming process and has a huge impact on the overall quality of the scene, involving posing facial expressions, adding visual effects, and setting up animation timers. At times we also draw additional bits and bobs as we go through the implementation to fully flesh out the scene.

After the programming is done, we move on to testing. This is where we make sure everything works as intended and that the scenes are triggered correctly. It’s also a chance to fine-tune the timing and presentation of the CG scenes to ensure maximum impact.

Finally, once everything is working as it should, and we’re happy with the final piece, we upload everything to our git repository.

By the way, we really appreciate your support and feedback, as it helps us continue to improve and expand the game.

That’s a quick overview of how we implement CG scenes in WTS. I personally hope you enjoyed this behind-the-scenes look, and we can’t wait to share more updates with you in the future.

Stay naughty,
LoafyLemon.

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!