Future (Patreon)

Yiffalicious has come a long way, and I'm proud of what we've managed to accomplish. We've bumped into many obstacles on our path, but we've always managed to overcome. Despite major changes throughout development, we've managed to maintain compatibility between different versions of interactions. As far as I know, not once have we abandoned previous interactions and said "Yep, these won't work anymore. Deal with it!", and I'm happy of this achievement. However, it seems like this is something we'll have to break for the first time in the near future...

Throughout the development of this project, flaws in the engine itself have become more and more apparent. It seems that the design philosophy we went with works great for some things, but not others. While we could continue to work on this incarnation of the engine for a great while yet without these issues becoming unmanageable, we feel it would be far better to tackle them right now rather than later.

So what are these issues? And what is the design philosophy we've used so far? Well, to start it all off, let's dive a little bit into how Unity works (the engine we're using). In Unity, everything revolves around components, that are added to objects and configured. Because of how prevalent this concept is throughout the whole Unity community, I was influenced to go with something similar to this when it came to the implementation of Yiffalicious.

At first, I really liked this way of working. The components themselves are short, simple and easy to manage. So I used this methodology extensively. Basically everything made in Yiffalicious is a component that can be added, configured and removed. Each component is responsible for its own UI, editor interaction and influence of the sex animation.

But as time went on, things have gotten increasingly hard to work with. It's not necessarily complex because the components themselves are, but because of how they all interact together. The complexity is emergent. The code that defines a certain concept or behavior is sometimes spread out across multiple modules, which means that if we want to change that behavior, or add more, it's troublesome to do.

To give you a grossly simplified picture of what the current design looks like, it would be something like this:

https://i.gyazo.com/e03fa4c66ca4d1761aeddc4b81f85819.png

(This does not mean that code is repeated, but rather that certain concepts are defined across several modules.)

So, on to the big question... What are we going to do about all this?

Well, I recently read a very interesting article about how a certain programmer structured his projects in Unity, and I was very inspired by this. Basically, instead of organizing the project through components (which is the standard way in Unity), a more traditional approach was made, where each concept had its own definition outside of Unity and with relations to the rest of the project. This is the way I was taught at the University how to design projects, and I instantly felt at home when I read the article and saw all the opportunities such an approach would offer. The more I thought about it, the more I realized this was the way I wanted to go.

Here's a (yet again grossly simplified) picture describing the difference:

https://i.gyazo.com/c7347d1cbe99ecb91ccec27613b9a8e7.png

(NOTE! This is not a promise that all these behaviors will be created, but we will try for sure. One thing is for certain - doing it in the current engine would be extremely cumbersome, but in the new incarnation there's a much greater possibility.)

(As a side note - a neat consequence of this design philosophy is that the engine itself would basically be a completely separate unit, that can exist without the need of Unity specifically. In theory, the yiff engine could be ported between different game engines if we wanted to, with very few code changes required. But that's not the reason we're doing this, although it may be of use in the future.)

To give an overview of all the tangible benefits this design philosophy would mean for you as a user, here's a list:

More sex behaviors

Rather than just thrust-hump, we want to create a lot more behaviors that drive the sex in this game. By realizing and defining each concept as its own thing, complexity is far more manageable than it would be in the current engine implementation. What's really cool is that we want to make these behaviors stackable (to some extent). So you could for example have two characters kissing while being stroked and fucked, all at the same time!

As a start, we will first just try to get the standard thrust-hump going, but as time goes on, the idea is to define more and more behaviors.

Better posing

By changing the way sex behaviors affect poses and by making it stateless, we can make the posing easier as a result. Currently you can't pose two characters independently and then have them have sex, but rather you have to add the penetratee first and then the penetrator. This wouldn't be necessary in the new incarnation of the engine. Rather, connections would exist as tangible concepts that can be instanced, altered or removed during the design of the interaction. Each character could be posed individually and attachments defined afterwards.

Scenes and keyframes

Each interaction will be able to contain several different scenes, and each scene can have different keyframes. Keyframes will work like snapshots in essence, but also make it possible to blend between different poses.

Performance increases

Not only will we be eliminating a lot of interop invocations by separating the engine from Unity, but just generally structuring our code in this traditional manner and by not using components it will be easier to write and maintain efficient code.

Multi-selection

Adding multi-selection to the current engine would be hard because of the way it was structured. By taking this into account from the start, we can get multi-selection going.

UI redesign to make it faster and less confusing

The way properties are organized right now is a bit confusing and quite cumbersome to use. With the new engine, we want to make a filterable context sensitive inspector, that changes what properties are shown depending on what you have selected. Furthermore, we want to pool all UI elements, meaning less performance cost and less memory usage.

Faster load times

Object pooling was something I always wanted to implement, but adding such a feature afterwards is hard in the current implementation. This time around, we will keep this in mind from scratch to make loading characters a lot faster. So switching between interactions and scenes will be super fast.

Better undo-redo

I never liked the way it was implemented in the current engine. Instead of tracking properties, we will try to track actions. This should mean we can offer undo-redo for a larger amount of events, and not just node manipulation.

Dialogue

We'll make sure that any type of property [inside the engine] can be keyframed (unlike how it is today, where only floats can be), which means we'll be able to keyframe strings of text. This offers some interesting prospects, especially considering that each interaction can contain several scenes, and each keyframe can link different poses.

Character editor

We've had "custom characters" on our roadmap for a long time, and we felt it's about time we do something about this. Our original plan to implement an importer turned out to be too much of a headache to pull off (for many practical reasons, which you can read about here). So now we're switching focus to a character editor instead. With the redesign of the new engine, it's a prefect moment to make the necessary adaptations so implementation of this will be smooth once we get to it.

(NOTE! The editor is probably pretty far off still, since we need to get the engine core up and running first. This is more of a pledge to you that we're making the necessary preparations to get this going in the future.)

So yeah, that's pretty much it!

We're very excited about all the possibilities this path offers, and we hope you are too!

FAQ / tl;dr

What's happening?

We're adopting a new development philosophy in our project, where we will need to restructure core parts of the engine.

Why is this happening?

The current structure of the project makes it increasingly cumbersome and complex to add certain kinds of functionality to it. We think it's better to take this step now rather than later.

What are the benefits?

Better performance, better posing, scenes and keyframes (with different poses in each keyframe, if desired), more sex options (with more and more being added as time goes on), faster load times, dialogues, multi-selection, character editor (eventually), less confusing/cumbersome interface, smaller memory footprint and better undo-redo.

Does this mean development has been halted?

On the contrary! Development is happening more intensively now than ever. It'll just take a while before these changes are ready to be shared with the community.

When will the redesign be complete?

Updated: 

We originally intended to add the character editor later on, but now we're developing it to be included in the first release of YL2. This first release won't have anything else but the character editor.

We don't know when this will be. All we can say is that we have an internal date we're working towards, and we'll be writing updates as often as possible to show the progress.

When will we see a new update?

We will continue to push out new updates with new content as we normally do for Yiffalicious, containing new characters, environments and bug fixes. But they won't be published as often as before during this YL2 development period, nor will there be any large new features implemented.

What about the old app?

The old app will still continue to be available, and new content will be added to it as usual [until the new engine is launched].

Will all the old code be ditched?

No, a lot can be reused, but core parts of the actual engine itself will have to be rewritten, and the remaining will have to be adapted to the new design.

How far have you come?

We've just begun to implement parts of the new design and we're very excited. :)

What other consequences are there to this development?

As we're completely rewriting the editor part, it means that the current interaction file system (.yiff, .yiffc) won't work in the new version of the engine. We'll also exclude certain content that we feel isn't appropriate to keep (from a technical standpoint). Maya (Giraffe), Horse and Bunny are three characters that will have to go (there may be more), and the Ocean house (the first one) is going away as well (there may be more). Any character removed will get a new incarnation with updated mechanics to work with the new engine (if not sooner then later).