Hi! Today's post is about what's currently in development for "Life with the Tribe", as well as what unfortunately had to be dropped.

The new build isn't ready yet, but work continues while Frazunk is helping with animations for Demonnete Playtime. Here's an example of something he made:

So what's changing in Life with the Tribe?

First, the thing everyone's been asking for for ages — you can now properly close the game and adjust settings during gameplay (settings menu, return to title, and quit game):

This is a simple part, but it was needed for a long time. You may also notice two new settings options that weren't there before — these are for the full version of the game (or the patched version). The first option switches all characters from the West version to the original ones, while the second removes censorship from the Asian version.

But as I mentioned, the new changes aren't just to the game's backend code. I've also improved the look of the main character a bit:

I'm also going through all the animations I have and making small fixes to each one. Some, like the sex scene with the shopkeeper girl, might be changed entirely, since it's very hard to carry that animation over to the West version.

Why bother with all this? There's a reason — I want to bring the look of the base game closer to the look of the content I'm planning to add as DLC. Some changes are fairly easy to add, so this won't be like with Demonnete, where the animations and game details are much more complex.

Alongside these changes, I'm also working on improving some of the mini-games, fishing in particular. Fishing is a pretty weak part of my game, so even for the base game I'll be improving both the quest tied to getting the fishing rod and the mini-game itself. Right now I'm planning to lock getting the rod behind a purchase, and also raise the price of fish.

Since I brought up prices and purchasing, let me talk about that too. Honestly, the whole buying/selling part of the game isn't balanced at all — once you buy the important items (like the shears for cutting sheep wool, and the robot girl's limbs), the whole point of the economy basically disappears. That's obviously due to the current amount of content in the game, so for the base game I won't change anything except making prices more balanced. But in the DLC I'm planning to add more situations where you need to buy and sell things. For example, I'm planning to add gifts/consumables for the tribe's women. You might've noticed there's a heart icon in the settings menu — that will show the women's affection toward the main character, because even if you've fuck them, that doesn't mean they instantly fall in love with you. What exactly unlocks affection you'll find out once I finish updating the base game.

That's what's currently in development — but what got dropped? There's a lot here, and unfortunately some of it was interesting as a concept, but too hard to pull off within the game's limits.

The most interesting one was a tribe life simulation. I genuinely tried to develop this — making the tribe feel more alive, adding walking/movement animations for every NPC, giving them tasks, daily schedules, and so on. It would've made the game more interesting, but the problem was that implementing this on top of an already-built game was way too difficult and would've drastically changed how the game plays. Right now the game is simple: you talk — get a quest — complete it — get a reward, that's it. But once everyone starts walking around doing their own things, it looks cool, but the core of the game stays exactly the same. Aside from immersion, it wouldn't have added anything, so this idea got dropped and reworked into something that fits the game better — more on that later.

Another one was shared poses. I thought about adapting every pose in the game to fit each NPC. It's a cool idea, but it would require a huge number of animations, since every NPC differs from the others in height and body size. Honestly this just balloons the amount of animation work, and maybe once the DLC is ready I'll consider it — but only as final content for this game, since adding new poses down the line would be way too much work (it's not 3D where you can just rotate the model however you want).

I also dropped the idea of changing the dialogue. Right now the dialogue is often unclear to a lot of people, since the dialogue bubble itself is pretty small, and so are the icons shown in it. I sketched a couple of examples with a bigger dialogue bubble, but honestly it didn't really solve the problem. Overall, how quest information is presented could be a real issue in the DLC, so I want to add notes to the player menu that show a mini-portrait of whoever gave the quest along with its objective. It won't have text, of course, but I think it'll help players understand what they need to do.

Development is continuing, and I know it's been a while since the last build. That's on me, and I'm sorry for that, but I'll keep working until I'm satisfied with the result. Because if I don't like what I made myself, how could you like it, right?

Hey! Today's devlog is about programming languages for the Godot engine. It's text-only this time, but I'll add art as compensation :

For those who don't know, let me quickly explain. Godot has two programming languages, and accordingly two versions of the engine:
- The regular version — which only supports GDScript and works exclusively with it.
- The Mono version — which supports both GDScript and C#.

It might seem like if the Mono version supports two languages, it's better to use it — but that's not entirely true. If you only program in GDScript, the regular version will be much more optimized and better.

So why did I bring up the topic of programming languages? Well... there's a whole bunch of things I ran into during development, so let me walk you through how it went.

After releasing "Life with the Tribe" (which was made in GDScript), my job at CriticalBliss asked me to brush up my C# skills (which were zero at the time) to join development on a bigger project. I agreed, and with the help of reference code from other programmers, I started learning C#. This led to a situation where, during learning and work, it became hard for me to develop projects in GDScript — for the simple reason that switching between two languages for two different projects is difficult. So I decided to switch entirely to C# for my own projects.

That led to my current situation. I know two programming languages: C# and GDScript. So when I started working on optimizing "Life with the Tribe" for DLC content and a global update, a thought hit me: "Why am I even porting this project to C# in the first place?"

That thought stopped my work completely, because I had never really thought, after switching to C#, that I'd ever need to go back to GDScript. Why is that? Well, most programmers I know who develop games on Godot work exclusively in C#. If they all use that language, doesn't that mean it's better, right? That kind of thinking seemed logical, but it had no real basis. So I decided to check it for myself.

Thanks to forums and — yes, with some help from AI (we all ask AI when we don't know the answer, right?) — I came to the conclusion that there is a difference between them, but it comes down to convenience rather than anything else.

Let's start with C#: it's a language that's been around for a long time and is used in a lot of places. That's its biggest advantage — you don't limit your career options and can work on all sorts of things. But honestly, that's the only advantage it has over GDScript. Just that one advantage!

C# has a huge existing ecosystem and is very convenient, but at the same time, if we're working in Godot, we're forced to use only the Mono version and constantly rebuild the project. The Mono version itself is bigger, so even the project ends up bigger than the same project in the regular version (in file count and size). Mono builds also have export issues specific to this language (for example, you can't build a web version of a project in C#, and there are problems with Android builds).

Although that might seem like a small issue compared to the advantage, you do open the door to working at bigger companies — but that prospect doesn't interest me. Having worked on a big team before, I realized it's pretty demanding work, and the whole approach to development on a big team is fundamentally different from what I enjoy.

Now for GDScript: first and foremost, it's the native language of Godot. Most things inside the engine are built around it. Even though C# might seem to work well with Godot too, GDScript still works noticeably better. The build itself is smaller, most features available in C# also work in GDScript, there's no constant project rebuilding just to check for errors, no limits on different export targets (web, Android) — and overall, this language doesn't fall short of C# except for a few specific things that are rarely used anyway.

As for downsides, the only real one is that this language is used only in Godot. So if you learn it, you won't easily be able to start some other project outside of a game or product built on the Godot engine. For some, that might be a big drawback, but I don't see it that way — everyone has their own priorities, after all.

Which brings us to the conclusion — it all depends on your goal:
- If you want to work as a developer beyond just Godot games, you should pick C#.
- If you only plan to make games on this engine, GDScript is the better choice.

After this analysis, I realized I fall into the second category. I'm not interested in working on big teams on big projects — I'm much more drawn to indie games. Even looking at the games I buy on Steam, I almost always go for indie projects; games from big companies almost never interest me (except for FromSoftware — I'm a fan of theirs). So I concluded I'd been heading in the wrong direction.

As for "Life with the Tribe", I've stopped porting it to C# and am now focused only on optimizing the existing project (version 1.0). Right now I'm porting some of my addons (which were written in C#) into the project to replace some old, broken code. And honestly, it's going a lot faster than I expected. Maybe the experience of learning another language made me a more skilled developer overall — either way, the project's progress right now is much better than it was before. So expect updates and news!

Hey Today's devlog will be about something a bit more specific regarding game development.

Every game is, in essence, a huge collection of variables and data. We all know this, but very few people have actually tried developing a game themselves. No matter how you look at it, game development is not just visuals and sounds — it's also about internal calculations and data flow.

For those unfamiliar with these concepts, let me explain:

Variables are named values that can change. For example, here's a simple health variable:

And here's the same variable, but with a bit more logic behind it:

Both examples are variables. The first is a simple variable with no logic attached to it beyond its name. The second, however, is a variable specifically responsible for health: it never exceeds its defined limits, and when it reaches 0, it triggers the character's death method.

Data is all the information that describes a game's content, rules, logic, and resources, while not being program code itself. In most cases, this includes all the assets and scenes you see in the game, as well as all tracked player and world states. For example:

Here we can see NPC scene data,  sprites,  animations — all of these are data. And so is this:

This is a game save file. Data is also something that gets passed between objects and scripts within the game. For example, when you pick up an item in almost any game, you're manipulating data by updating your inventory with a new item.

Of course, this is only a brief explanation. Going into every detail would quickly turn this devlog into a dictionary reading session.

So why am I even making a devlog about this topic?

Because every aspect of game development is deeply connected to data, and surprisingly few people ever talk about it.

Every system, every mechanic, even something as simple as pressing a button is tied to variables and data. While adding something like a health value may seem straightforward, properly using even a single stat requires a clear understanding of how it functions within your game.

And even if you've created a health variable and are saving it in a save file, you'll immediately encounter another challenge: data transfer.

Passing data — such as dealing damage to a character's health — is something present in countless games, but there are endless ways to implement it. You could directly modify a variable in an object upon collision to deal damage. But if your attack hits an object that doesn't have a health variable, you'll get an error. You could use a global signal that only affects the player's health, but that works only until you want enemies to take damage too.

You can keep solving these issues one by one for a long time, either patching every possible edge case or eventually finding an architectural solution that fits your specific project.

Developers have invented countless approaches to solving these kinds of problems, and it's always worth learning from them. However, even the best architecture can't solve every development challenge. Sometimes your game may not need a complex architecture at all because the underlying concept is much simpler.

This devlog may seem a bit chaotic, but even a single health variable can be handled in countless ways depending on the type of game you're making.

For example, in my game Life with the Tribe, I had a health system. However, conceptually it only mattered during battles. There is no active gameplay outside of those encounters, and the battles themselves aren't particularly complex.

In a sense, I could remove health entirely from the game and only keep a battle-specific life system. It wouldn't even really be health anymore — just a number of lives. Every hit would remove one life, and when all lives are gone, the battle is lost. At the start of every new battle, the player's lives would simply reset.

That approach would actually be much simpler.

And surprisingly, this is still all about variables and data — because I effectively removed data transfer from the equation altogether.

This small shift in how I viewed the game's design changed many things behind the scenes. Suddenly, I no longer care how much health the player has. I don't need to save that information. I don't need to display it in the UI. I don't need to create loss conditions based on save-file data or variables stored in other objects.

It seems like a tiny conceptual change — simply asking whether a variable is needed in the first place — but the results can be significant.

This idea applies to any variable or piece of data in a game.

Some things may seem standard and necessary. You can create variables, save them, manage them, and build systems around them. But eventually you may end up with so many variables and interconnected pieces of data that maintaining them becomes difficult.

That's why it's sometimes important to step back and ask whether your game actually needs them in the first place.

That's the main point of this devlog.

Understanding the purpose of variables and data is incredibly important. Just like with the health example, something that seems insignificant at first can become much simpler once you rethink it and remove unnecessary data from the equation.

Hi! Today's devlog is about animations! Probably one of the most important things in R18 game development.

As you know very well, animations are the most necessary thing for R18 games. I won't explain the reason, since you yourself can understand that an animated scene is much better than a non-animated one.

But why doesn't everyone animate then? Well... because it's hard. Instead of one art, you need to draw 4, 6 or more arts/frames and make them consistent! And even drawn frames can look terrible if you combine them into an animation!

Why is that? Animation is the process of "reviving" art and sometimes even the simplest action can be implemented differently! Today I will touch on the topic of basic animation and how it is created.

As always, it is best to talk about the topic by showing an example, so here it is:

This is the basic art from which animation starts! But how to animate it? If you are thinking about starting to create frames or something like that, you have already fallen into the trap of "simplicity" of animation.
Here is the same art but without color:

Why is it important and what is the trap? That animating by color is more of a problem than a animation. Any animation must be designed from the beginning whether the art will be animated or not! And this is very important and applies to ANY animation! And as you can see, I saved the lines of the art to animate it later, and simplify my work.
But if you pay attention to the art, you will notice one problem. Is it planned to animate sex or just the entrance into the girl? Because if you animate sex, then there will be a problem, the dick is too far from the entrance and this art is not a keyframe!
What is a keyframe? This is a frame that is the main position in the animation. All animations have keyframes and will always consist of them. Thus, to animate sex through this art, we must change the position of the dick!

This doesn't seem like a big change, but now we have a full-fledged keyframe. What to do next is to create the next keyframe. Since we're animating sex, it would logically be in this position:

And with two keyframes, we ALREADY have a simple animation:

But what to do next? Well, some animators stop there! Yes, I've seen some animators who didn't improve their animations much after adding keyframes. But it doesn't look very good, does it? So next we start adding intermediate frame! A intermediate frame is a frame that is created between keyframes to improve the look of the animation.

And how many intermediate frame are needed? It depends entirely on the animator and the target animation. For example, I'll create a dynamic sex animation where the movement is fast and strong, it only needs 2 frames around the keyframes:

As you can see, the animation looks much better! Of course, this is far from a perfect animation and to bring it to the final form you need to work for quite a long time. For example, you need to change the head animation, add variations like slow sex, etc. But for devlog I'll leave it like this, just adding a simple color on top:

Thus we created a simple loop animation with 6 frames, where 2 are keyframes, and 4 are intermediate frames that are around the key frames. 
And this is just a simple animation with a fairly clear movement, since the dick moves from left to right, and the girl only reacts to this in a very light and clear pose. Of course, there are always more complicated cases when to convey the movement you need to change the base art several times, and sometimes even change the concept of the animation, due to the limits of pixel art (for example, very small pixel art does not allow you to draw a blowjob correctly!). But I will write about these limits in another devlog.

Hi. Today's devlog is about "Life with the Tribe".

It may seem a bit strange that I want to write about this game, since I should be more focused on "Demonette's Playtime", but I can't help myself. I've been overdoing it with animations a bit and recently switched to "Life with a Tribe" to relax.

And what can be interesting about a project that has already been released? This is an expansion of the project through DLC! But there is a problem here - it is a rework of the base game. Why is this necessary? Well ... have you ever heard of the term "technical debt"?

In short, technical debt is a concept in programming/project development that reflects the additional work that appears due to the easy and quick implementation of mechanics without thinking about expanding the project in the future. The larger the project becomes, the harder it is to create something new and add new features. Unfortunately, I encountered this and even when I was finishing "Life with the Tribe" I had a lot of problems with adding content.

I touched on this topic in previous devlogs, so today I will bring some clarity. This is a necessary measure, since for the DLC there is a plan to expand almost all the existing systems that are in the game, which in essence affects the entire game as a whole. You may think that "Life with the Tribe" is a fairly easy game in terms of mechanics, and this will be true if you look at it from the prism of separately selected things. But if you combine all the little things in the game, you will understand that there are a lot of problems here.

Let me take the quest system that exists in this game as an example. Yes, you read that correctly, in this game there are quests that were not shown in your UI:

These quests were the driving force of the story, but their execution through the code was as simple as possible. I simply created a list of events that are checked directly from each player action:
 

And although it worked, all my tasks were as simple as possible, here is a diagram of all the tasks in the game (although it is in Ukrainian, but this diagram was created for development, so I did not think to translate it):

Don't be afraid, in fact, this is all a simple reflection of only one system in the game. I created this diagram when I started reworking the project to understand why it was so difficult for me to add new obstacles. And looking at this diagram, I realized that all the actions for completing quests can be broken down into only a few global actions: conversation, mini-game, sex. But what if new actions are needed? This is where the technical debt arose, which greatly hindered the addition of new types of tasks and actions for completing tasks.

And this technical debt, unfortunately, is present in almost all parts of the game. And so a vicious circle arose:

This problem arose because I did not think ahead when developing the project. This is entirely my fault as a developer. That is why I am now rewriting this project. Will it be better for the planned expansion through DLC? Yes. Will there be technical debt again? It is unknown, sometimes mechanics are invented that may seem simple, but in fact can be very difficult to add.

But what kind of DLC is this that I am talking about? Well, there are a lot of things that I have written in the plan, and some of them are so degenerative that they cannot be described in a post (something about increasing the population of the tribe). If you are interested, I can talk about it in more detail in the Discord channel.

Of course, there are some points that are basic (and some will be made for the base version as well):

These are global goals that are facing DLC ​​and the porting of the base game. Right now, I have ported about 40% of the game with system updates. As soon as the base porting of the game is completed, I will update the product on all platforms. Also, after the porting of the game, some additional animations and a newer interface will be added to the game. Next will be the development of DLC which will be a separate pack to the base game. Of course this plan is only about this game. Demonette's Playtime is still a priority, although I got a little burned out drawing all those animations. Apparently I overdid it a bit...

Hi! Today I will write about localization.

Let's start with something simple. Now, thanks to translators and other tools, localization has become a fairly simple thing. You might think that if developers just throw all the text into a translator, at least readable text will come out. But if you are not a native English speaker, then you know very well how bad the text from the translator sometimes is.

The latest tools allow you to simplify the translation and this is very cool. But without proofreading the translation, you can screw up the translation quite a lot, and this is a problem. In fact, you can always hire a translator so that they can translate the text for your game, but nowadays many translators use AI or translators, and they give it to you without proofreading. Unfortunately, I know projects where this happened, and the developers had to redo the entire translation.

So what to do? In fact, it's a game of roulette and if you are lucky, you will find good translators who can translate correctly. Otherwise ... well, no luck.

But is localization necessary? I believe that localization is necessary. You may think that it is more work for the developer, or that it is expensive and there is no point in investing in it, but the more languages ​​the project is translated into, the better the sales and overall rating will be. Of course, there are cases when you cannot afford to pay for a translator, but in this case, at least you need to do an auto-translation into English (unless of course you are a native speaker).

Why is this important? First of all, English is a global language and the simplest possible language. And almost all AI translation is trained primarily in English. Even if you translate a game through AI into English, in most cases, proofreading will not be necessary. That is why it is important, it is quite easy to achieve and you will almost not lose quality in the translation.

Of course, I am not saying that this translation will be 100% correct. Like any other language, it needs proofreading. But having even a not-so-correct translation is very important for your project.

And what to do next? Well, prepare the game for the maximum number of translations! And for this, first of all, you need to understand how any translation in games works. Of course, this may vary from engine to engine, but I will describe how it works in Godot.

First and foremost, you need to create a .cvs file in which you will record each line of text. This file is divided into columns and the first of the columns is keys, it is the main one and these keys are what you use to display the text:

As you can see, I have a key and its value . And in fact, you can use this CVS file for any localization by adding a new column with the correct language key in the first line (like en for English). By puting it into the engine, you will get localization files, and simply by adding them to the project settings you can have different languages ​​in your game!

Of course, this changes the code writing a bit, as you need to set that you are looking for a key and not text, so you should always use your keys that are in the CVS file :

That's it. You have added a new localization and now your game will have several of them!
But this only works for the developer, players will never be able to make their own translation for your game!
That's why Godot has another cool feature - .PO files :

These are files that work as a single column of translation, and if the file name matches the localization key you can safely load it into the game during the first launch and add a new localization!

I learned about this when I was studying how to create DLC and Mod support in my game. This feature will allow anyone who is interested in translating my game to translate it into the language they speak. In my opinion, this is enough to satisfy all players and honestly I think that any developers should do this. Even if you don't have money for translation, you can give players a way to do the translation themselves.

For a Ukrainian like me, this is a very important topic, as the russians have been trying to destroy my language for more than 300 years. There were many bans on writing and speaking. Military and civilians who were captured by the russians are tortured just because of their language. And it warms my soul when I see how developers of even the smallest games add my language to the official release. And even without an official release, Ukrainians have many enthusiasts who translate games for free, I even translated three different R18 games on Steam for free. Therefore, localization must be there, and if your games have support for easily adding languages ​​to the game, I am sure that many translations will appear for your game.