Marriage, Lineage Tracking, and SQL

[chronos]

So, I found this rather entertaining game of yours 2 months ago or thereabouts. After playing it for a while and seeing that the source was available I decided to have a go at moderately customizing a build for my own play style. What I've done so far is pretty mild, added a custom trait, added a few effects for existing traits and changed the inheritance for a few traits. Having done so, I can see why the request for custom traits usually gets the response "yes, that would be lovely". Traits can potentially touch so many different area's that it's dang tricky to provide a mechanism for adding custom traits at will.


Anyway, some of the other changes I'd like to make I think would make good additions to the trunk. Unfortunately, some of the idea's I have would require some significant changes to some core methods and I don't want to break compatibility between my custom build and the trunk.


So, suggestion 1. Four traits having to do with various married states. Married (not to the player), Divorced, Widowed, Your Wife (Married to the player)


First, it has always seemed strange to me that when you kidnap the wife and daughters of some poor schmuck who couldn't pay that the only difference between the wife and the daughters is their age. The wife should have the trait Married (and also MILF, we know she has daughters after all), and it should have an effect on her willingness to do certain kinds of tasks (primarily sex related jobs) and also her willingness to sleep with the player (ie, she should outright refuse unless you have drugged her up so high on aphrodisiac's that she'll take any dick she can get). Of course, you can still 'force' the issue. Unless of course you convince her that you're the better man and her husband was a loser (ie, make her fall in love with you) and convince her to get Divorced. Alternately, you can hunt down and 'deal' with her husband, in which case she becomes Widowed (which will make her weepy and depressive, ie, loses happiness faster). Once she no longer has the Married trait, if you feel so inclined, you can ask her to become Your Wife.


For normal girls on the other hand you just convince them that you are their True Love and ask them to become Your Wife.
And, this being Crossgate, no one is going to give a crap if you have more than one wife, nor for that matter are they going to care if you marry Your Daughter.


As for the effects, some jobs the girl should be more willing to do, and others less so. Non sex-related jobs she should be more willing to do to make you happy. Sex related jobs on the other hand, well, she's married to YOU, not this random guy on the street who wants to get laid (although, perhaps an exception could be made for Lesbian sex). Anyway, you wouldn't want to marry all of your girls, because most of them would refuse to work in the brothel. Possibly there should also be some sort of limit on how many wives you can handle (after all, theres only so much time in the week for making sure your wives are satisfied, and an unsatisfied wife is more likely to disobey).


Moving on, lineage tracking. We have the Your Daughter trait, and when a girl grows up the mom gets flagged as "has daughter", but there's no record of the relationship between the two. It would be fun to be able to look at a girl and see that her mom is X, or see that she has 2 daughters Y and Z, or possibly both.


So, now lets talk about the architectural changes need to make these ideas work. The first thing that would be needed is some way of adding required traits to a random girl when we create one. The first option would be that when you call the CreateRandomGirl method, instead of directly returning it to another function would be to return the object then call AddTrait a couple of times based on some if statements. The other option would be to have the CreateRandomGirl method take as an optional parameter an array which is a list of required traits.


The next part is figuring out how to store the mom<->daughter relationship in the save file and also how to create it in the first place. You've got two potential cases here. The easy one is when one of your girls gives birth. You just add a few lines into the child_is_grown method to add whatever bit of data to both the mom and daughter to track the relationship.
The more complicated case is when you kidnap a mother/wife and/or her daughters. Arguably, if your goons tell you that the deadbeat has a wife and three daughters, and you choose to only kidnap the daughters, the wife should still be created and tracked somehow. Likewise the opposite, if you kidnap the wife but not the daughters the daughters should still be created. Perhaps later the deadbeat will pay a visit to your brothel again and this time you'll kidnap whoever you didn't last time (which probably means we should be tracking the deadbeat as well). Or maybe the deadbeat shows up to buy his wife/daughters back from you (whether they're willing to go back is another question).


Anyway, the whole structure and interaction between these two elements can get pretty complicated pretty quick, but I think it would also add an entertaining element to the game. The one major major problem with the idea of lineage tracking is this, the save file format is pretty darn fixed as near as I can tell and I have no idea how to add this to the save file without breaking backwards compatibility.


Which brings me to my last thing. It's been over 10 years since I last did any real C/C++ programming. I am however a Perl and SQL programmer (and a windows sysadmin). To my mind this whole game is screaming for a database backend, both for the core game data and most especially for the save file. I saw in another thread, I think it was for one of the spinoff games that one of the devs is working on, that they were considering using sqlite for some portion of their game. So my question for devs is this, what would be your thoughts on ripping out the save system and replacing it with an sqlite driven save file?

[Flowersteel]

I like what you are suggesting, and I think to top it off, you should maybe be able to go to 110 in value on girls you have bred.

Im not sure about the relationship, and the links, if it would add anything to the game. Unless of course you add some synergy like two related girls being able to comfort (+happiness) or heal one another. The behavioural patterns you describe I like, and the fact that bred girls should take on attributes and traits of the mother +/- up to 25% would be cool.

[Sigfried666]

I like chronos ideas and agree with Flowersteel points.

Also, would be interesting if their reactions to the player's moves changed with the trait change.
And I mentioned waiting to see some lesbian sister/sister or mother/daughter action a long time ago. XD

[crazy]

Like the ideals here.  Just so u know they do accept new devs to the team, just put out a patch and they will decide if they want u on the team or I think thats how it works.  Awhile back they talked about changing the save format cause they need to change it for docs daughter code but they never got around to doing it.  So i dont think they would mind having the save format changed they needed to do it anyway.

[DocClox]

Which brings me to my last thing. It's been over 10 years since I last did any real C/C++ programming. I am however a Perl and SQL programmer (and a windows sysadmin). To my mind this whole game is screaming for a database backend, both for the core game data and most especially for the save file. I saw in another thread, I think it was for one of the spinoff games that one of the devs is working on, that they were considering using sqlite for some portion of their game. So my question for devs is this, what would be your thoughts on ripping out the save system and replacing it with an sqlite driven save file?

We talked about that a while back, and the general consensus was that it was probably a good idea. It also opens the door for things like keeping a history for a given girl, or saving financial breakdowns over time. I think the main reason it never got done was that there were other things ahead of it in the queue.

[chronos]

Ok, so I've had a first go at designing a database schema for a game save. It's not entirely complete yet, there's a few values that I'm not entirely sure where or how the best way to store them is. There's also quite a few tables that will go unused initially but would allow for future expansion of gameplay elements. I've also put one logging table in so far, I'm not sure yet whether or not I like the design of the table though. The way it works is this.


The table is girl_id (int), day(int), key1_id(text), key1_value(text), key2_id(text), key2_value(text), and so on. How many key/value pairs would be needed is a bit of a question. The basic idea though is that at each key level you start with a more generic descriptor and at each level you get more detailed about what the even is you are recording. For example, to record a girl servicing a customer you would need a couple of entries in the table somthing like this:


girl_id  day  timeperiod  key1_id     key1_value  key2_id               key2_value  key3_id  key3_value
1          1      1                action        normal sex  pay                       75
1          1      1                action        normal sex  cust_enjoy           yes
1          1      1                action        normal sex  skill norm sex up  2
1          1      2                rest                               health                  20
1          1      0                interaction  pc sex         enjoyment           10
1          1      0                interaction  pc sex         pregnant              yes


And so on... You can basically record anything you want and reconstruct what happened. So here the girl performed an action on day 1 in the morning. That action was normal sex and the customer payed her 75 for it. The customer enjoyed it, and her sex skill went up by 2. On day one at night she rested. On day 2 during the 0 time period (that would be while the player is wandering around the management screens) she interacted with the player, the player requested sex, she enjoyed it, and she got pregnant as a result. You could easily extend this same logging method to record the gang actions, actions the player takes such as buying slaves, changing the bribery rate, basically whatever you feel like recording.


As far as handling the actual save/load process, sqlite can create both in-memory databases and actual files. The best thing to do is probably to load the whole database into an in-memory database from file and then manipulate the in-memory database while the game is being played. When the player saves you write the database out to a file with a random filename, delete the old save game, then rename the random file to be the save name. This would drastically reduce the possibility of accidentally corrupting the save file while writing to it. Of course, if you wanted to create a "hardcore" mode ala Diablo II you could also save every event to the save file as it occurs which would eliminate save/load abuse. Probably the best thing to do if someone wanted to do this would be to make it on option when creating a new game.


Anyway, I'm attaching two files to the post. One is an empty version of the database and the other is just the SQL schema file for creating the database. I've been using a combination of two programs to design the database. sqliteman which is an opensource program which can be found at http://sqliteman.com/ and DBManager which has a free lite version of their app which can be found here. http://www.dbtools.com.br/EN/downloads/.

[HoganKlink]

So like an erotic version of Crusader Kings? CK has a lot of similarity to what your describing.

See first attachment

As you can see it's pretty extensive in the showing various relationships. Even though it's not shown multiple wives are possible and it tracks progeny to specific parents, including bastards!

Second attachment

The bridefinder, to show how some of the data is collated. It can be sorted by any of the column headers.

Everything is logged: events, diplomatic actions, combat, trait gain/loss for every character.

Here's an event from CK

Code: [Select]

###########################################
# Intense Stress causes Severe Depression
###########################################
character_event = {
    id = 4906

    picture = "event_sickness"

    trigger = {
        condition = { type = trait value = stress_symptom }
        condition = { type = not value = { type = trait value = depression  } }
        condition = { type = age value = 5 }
    }

    mean_time_to_happen = {
        months = 120

        modifier = {
            condition = { type = trait value = honest }
            factor = 0.8
        }
        modifier = {
            condition = { type = trait value = generous }
            factor = 0.8
        }
        modifier = {
            condition = { type = trait value = suspicious }
            factor = 1.2
        }
        modifier = {
            condition = { type = not value = { type = age value = 10 } }
            factor = 5
        }
        modifier = {
            condition = { type = age value = 10 }
            condition = { type = not value = { type = age value = 13 } }
            factor = 2.5
        }
        modifier = {
            condition = { type = age value = 13 }
            condition = { type = not value = { type = age value = 16 } }
            factor = 1.75
        }
        modifier = {
            condition = { type = or
                condition = { type = and
                    condition = { type = gender value = male }
                    condition = { type = any_friend condition = { type = gender value = female } }
                }
                condition = { type = and
                    condition = { type = gender value = female }
                    condition = { type = any_friend condition = { type = gender value = male } }
                }
            }
            factor = 2.0
        }
    }

    #The Sun will never rise again!
    immidiate = {
        effect = { type = remove_trait value = stress_symptom }
        effect = { type = add_trait value = depression }
    }

}
Though I'm no programmer, it seems similar in structure to some of the xml and scripting stuff we have around here. One of the cool things here is the mean_time_to_happen, which sets a time for the event to occur after the initial conditions are met and then multiplies it  by the factors that follow. The effects usually exclude other similar events (by removing and initial condition) so as to create a branching type results i.e. in this case depression instead of syphilis or worms. These events and other data structures are externalized. Just like WM!

I highly recommend checking out CK or any Paradox game as they handle large database structures well.   

[DocClox]

girl_id  day  timeperiod  key1_id     key1_value  key2_id               key2_value  key3_id  key3_value
1          1      1                action        normal sex  pay                       75
1          1      1                action        normal sex  cust_enjoy           yes
1          1      1                action        normal sex  skill norm sex up  2
1          1      2                rest                               health                  20
1          1      0                interaction  pc sex         enjoyment           10
1          1      0                interaction  pc sex         pregnant              yes

Pretty cool. That's the sort of thing I had in mind for an audit trail. I'm not sure for a save format however, purely because loading the game would mean replaying the events from scratch. With the same random results (although we could handle that by saving the seed values, though we'd need to track load actions as well). Anyway, the concern is that it would take longer and longer to load as time progressed.

I'd keep that, but have a set of tables that more or less reflect the data structures in the game. So instead of recording the actions the girls took, record their stats at the time of the save,

So like an erotic version of Crusader Kings? CK has a lot of similarity to what your describing.

Some interesting UI there, certainly.

Though I'm no programmer, it seems similar in structure to some of the xml and scripting stuff we have around here. One of the cool things here is the mean_time_to_happen, which sets a time for the event to occur after the initial conditions are met and then multiplies it  by the factors that follow. The effects usually exclude other similar events (by removing and initial condition) so as to create a branching type results i.e. in this case depression instead of syphilis or worms. These events and other data structures are externalized. Just like WM!

Interesting. I'll have a think about that.

[Zero_Profile]

Man now that would be one killer MOD,  , wonder if that could be applied to the robozou game extension i'm working on. 

[DocClox]

Man now that would be one killer MOD,  , wonder if that could be applied to the robozou game extension i'm working on. 

Well, the SQLite probably not - I did a bit of googling and it looks like you'd need Adobe AIR or a PHP server to make it work. Still, only a quick search, so I may be wrong.

I'm glad to hear the Robozou project is still active. I'd formed the impression from Hongfire that it had folded - nice to hear otherwise

[Zero_Profile]

Oh no not folded, just been having problems with the computer. Plus i had to redo most of the project from scratch

[chronos]

Pretty cool. That's the sort of thing I had in mind for an audit trail. I'm not sure for a save format however, purely because loading the game would mean replaying the events from scratch. With the same random results (although we could handle that by saving the seed values, though we'd need to track load actions as well). Anyway, the concern is that it would take longer and longer to load as time progressed.

I'd keep that, but have a set of tables that more or less reflect the data structures in the game. So instead of recording the actions the girls took, record their stats at the time of the save,

Hmm... I guess I wasn't entirely clear. That bit of table layout is purely for an audit trail. The rest of the database is exactly what you suggest, a reflection of the data structures in the game. I just commented on the audit trail specifically because it's rather more complicated than the rest of the database. I'm also not entirely sure I like it yet. It might be better to have multiple audit trail tables for different event types rather than trying to cram every single girl action into a single table. Obviously the point ultimately is that you need enough levels of key/value pairs to uniquely and completely describe an event and the result of the event. I think the major question is whether or not to use the first k/v pair as a descriptor of the event or whether or not to use a unique table for each possible event.


There's advantages and disadvantages to both methods. By using unique tables for each job you reduce the overall size of the database because you don't have a k/v pair that describes what job was performed. On the other hand, it increases the complexity of the SQL a fair bit and will technically increase query time because you now have to run through multiple tables looking for what happened. Of course, you could also have a simple table that stores, girl_id, day, portion of day, and job id. This would reduce you to three queries, one to find out the jobs performed on any given day and what period of the day they were performed on and one each for each of those jobs to the appropriate table.


By using a single table however you just need a single query to a single table. The table would be larger however due to that extra k/v pair. The SQL is a fair bit simpler for this design as well. The major point in favor of this is that as the not yet implemented jobs are added to the game you don't have to have code that checks the database version, creates new tables if needed, and no need for new sql queries for the new tables. It's all just data in a hash table. Add the new key/values to the lookup hash and it just works.


The rest of the database is incredibly simple by comparison. I think the only I forgot to put in that schema is a version table to store the database version. If you keep track of the save game database version then it becomes very easy to run a set of queries to add tables/columns/indexes/etc to bring it up to the correct schema when changes are made to the schema.

[trex]

Idea dead? I actually do track some of this in a .txt file, I used to put a lot of data in, but now keep it to a minimum, like who is whose daughter, if they were slave/street/born by a girl when they started at the brothel ect. Anyone else track their girls?


A bit of pointless micromanagement thrown in to keep the gameplay fresh, one of my alternatives from collecting oodles of girls anyway. What other ways do you guys like to play?

[chronos]

I don't know if I'd really call it dead since it isn't precisely alive yet in the first place.


For my part, I'd be happy to write the SQL queries required to convert, but for the moment I can't even figure out how to link the sqlite.h files and compiled dll's into the project. Like I mentioned in my OP, I'm a Perl and SQL guy, I can muddle my way through C++ code, but I'm far from being even competent, let alone proficient in C++.


What's funny to me is, if I wanted to I could very nearly have rewritten the engine code in Perl by now. The trouble is, I've never worked with GTK so reimplementing the display code would probably take me a rather long time. The real problem though, is that nobody would play the game if they had to download and install perl, and then make sure they had the SQLite perl module installed, and then make sure they had GTK installed. Compiled languages really are better for distributing software of this sort. Perl is a powerful language, but this kind of thing isn't really what it's designed to do, although it can.


Anyway, thats a bit of a tangent. The problem with the idea of lineage tracking is that it relies on either changing the structure of the existing save game format, thus breaking backwards compatibility with older saves (unless you create a save conversion tool), or creating a whole new less rigid save game structure (aka, a database like SQLite).


I guess what I should do to start would be to inventory the code and document every function that would need an SQL based replacement. From there I could work out which functions could use dynamically generated SQL vs which ones are static statements and then just start writing the SQL. Writing the C calls to run the SQL can come later with the help of someone who knows C++ better than I do.

[DocClox]

For my part, I'd be happy to write the SQL queries required to convert, but for the moment I can't even figure out how to link the sqlite.h files and compiled dll's into the project. Like I mentioned in my OP, I'm a Perl and SQL guy, I can muddle my way through C++ code, but I'm far from being even competent, let alone proficient in C++.

Probably easier to add the sqlite source files to the project and static link them in - as with lua or tinyxml