I really should have added this one a long time ago.  There’s been a few times where I lost some content due to bugs and had to rewrite it. -_- Here it is, though. At least, here’s an early version of it.

Many sites have something like this. Wikipedia does, and so does github. They store the older modified versions of content and highlight the differences between them. I’m not aware of any actual game engines, or game making tools like this using it, but things like Subversion typically handle that. This is extremely helpful when multiple people are working on the same content, and simply to have a way to go back when something doesn’t work as expected and it gets broken.

Here, in the picture, I’ve added “beep boop” in another line in the content, and hit “Compare to current scenario”. This compares what is currently in the content, compared to the old one, and marks the differences. New lines are green, removed lines are red, and changed lines show the old line in red then the new one in green one after another.
Oh, and they’re al 833 words because I was just repeatedly saving it to test the system without changing the content, is all. :3

Old versions can also be loaded back in to revert content to it.  That can also be used to compare two older versions, instead of simply the newest to an old.

Another thing that this is useful for is storing alternate versions of content, and to be able to switch between them in an instant. As I’ve mentioned before, with the way I programmed this engine, content is updated live without requiring a client or server restart. So this revision control makes it easier to write alternate versions of content to switch on/off for, say, events like for holidays or other things.

The content it’s comparing is the JSON that the tool makes and sends to the server.  JSON is a form of serializing data, which can be sent cross program easily. The server takes that JSON and turns it into actual game logic. I suppose I could point out the version differences right in the content authoring area of the tool, but it’d be extremely difficult to write that with how many different things it handles besides simply writing. For now, looking at the JSON comparison and ctrl+f’ing is a fine way to figure it out. :p  It’s good to understand the JSON the tool forms, anyway!

This is an important update I needed to get out of the way before having others using the tool to make content, to help make sure they don’t accidentally change something in a negative way. It also makes sure that if two people miscommunicate and save something for the same scenario at around the same time, the first person’s isn’t lost.

Updates notes:

There haven’t been significant updates lately, yeah. Now though, I’m getting back into the groove of things. Oh, I also have a twitter too. Enjoy my first tweet. Feel free to follow me~

Huge floppy dongs make just as good of pillows as boobs and butts.

— Sadtaco (@followSadtaco) April 7, 2014

First I was watching so much GDC stuff. I also wanted to take a break to catch up on a few shows, since I hadn’t had time to watch anything or play any games.
Then there was looking for artists. -_- I didn’t realize that’d take so long. I knew what to expect with the normal art industry, or games industry, but I was really naive to how difficult it’d be to find a good, experienced artist for an adult/hentai game. Looking back, I suppose it should be obvious because this is a really small niche that many people distance themselves from. :<
I spent two weeks looking, and it wasn’t very fruitful. It’s made me rethink my plans a little, and figure that I should just sort of wait and look for opportunities as I continue to work on LEWD. It’s changed a bit of my plans on how to handle producing LEWD, but I’ll get into that on the next post I make after I make some calls around to merchant services.

Game:
-Changed how dialog responses are formatted so it’s easier to read, while still clear that it’s a chosen response.
-Fixed a new bug with dialog options that created an infinite recursive loop if the option had a requirement and was selected. This would also cause content to not show if it was the first option.

-Added a Libido system, which is basic for now. (described below)

Content:
-Minor fixes and editing.
-Changed the finding the jar and figma scenarios so they won’t appear instead of more important content.

-Added a revision system for content, similar to a wiki or github. (described above)

Time-difference based functions

I started on a system for libido. Someone had posted a good idea about that, pointing out how it’s a little silly how you can repeatedly screw everything and never get low on cum.
That was a good point, and a great idea, I thought. It’d add some more realism, more game-y-ness, without detracting from fun if the numbers are right for it. It’s also another stat that a player can adjust via aphrodesiacs, transformations, chargen, etc.

I thought I’d go into detail about this because “time-difference based functions” are an interesting thing to talk about when it comes to a client-server model.
In a time-difference based function, you are figuring out what a number SHOULD be based on a current time(usually in seconds or milliseconds since unix epoch), a last changed time, a formula, and what a number was the last time it was changed.

In a single player game, if you want a number to change over time, you can just adjust the number every few seconds or milliseconds on the client. But because you don’t want to keep doing that for every player on the server, as it’s a massive waste of resources, you make a time-difference based function to figure out what the number should be each time another function wants to know it.
I suppose this could be one of those things that makes game servers really inefficient for less experienced programmers.

yourChar.__defineGetter__('libido', function(){
return Math.max(libidoMin, Math.min(libidoMax,
Math.round(unixtime() - libidoLastTime) / 25 * libidoMod ) + libidoLast
));
});

“(unixtime() – libidoLastTime) / 25 * libidoMod ) + libidoLast” is the meat of it.  It’s seeing how many seconds have passed since the last update to Libido, and doing some math to it to figure out how much should be added to what it last was. In this case, it’s seconds/25*libidoMod, where libidoMod would be a number from 1-10.  So at “libidoMod” being 1, you only gain 1 libido every 25 seconds. At 10, it’s every 2.5 seconds. This rate will likely be adjusted. This number is added to what libido was last changed to.
The other part is the min() and max() which are keeping that number within a min and max libido range.
Right now I have these numbers at libidoMod*10 for max, so min libido would be 10-60, and libidoMin+50 for max, so 60-160.
Base libido I have set at 3, so you gain 1 libido every 8.5 seconds.
That also means the range is 30-80 at the default 3, and it’d take 7 minutes to go from 30 to 80. The game is supposed to be 12x real time, so 1 real life hour = 12 game hours. That’s about 1.5 “game-hours” to recover from a fully drained libido at the default stats.
I figure 100 libido would be huge face covering orgasms, or squirting all over the place.

I want to sort of keep drive for sex tied in with potency. Not really for simplifying code at all, but to simplify things to the player.  If there were to be an extra potency thing, i’d just be a single trait and have something to min-max. This is also a “hidden” stat that just the game uses, and not something you use stat points on.
Of course I could also add something that adjusts your variance between min and max libido higher or lower than 50, or how much libido each orgasm drains, but this is the basic math I’m going with.

Finally, on the client where I’m updating the libido shown on the UI, I’m calling that time-difference based function in a slow loop over time. The reason for that is because doing something like upping it by 25/libidoMod seconds would not be accurate due to the inaccuracies of setInterval() in Javascript.  If you tell it to do something every 8500 milliseconds, it may do it after 8101, then 8853, etc, instead.

In programming, there are often many many ways to end up with the desired end result. Not all these methods are equal, and one may be more or less efficient, or create problems with one thing or another. For what’s needed here, this is the best way to implement a stat that changes with time with a closely matching sync between client and server, and very very low resources used on the server.

There is also an update to the writing parser that tries to detect that the PC orgasmed, and automatically drains their libido. Larger orgasms than normal can be triggered manually. This is experimental; let me know if any writing about orgasms/cum looks weird! English is hard for computers, etc.