General Discussion

[DarkTl]

- Auto-buy can be disabled at higher disposition as well, but that's stupid.

Please no, that's completely illogical. You might freely enable or disable AE and AB systems for slaves (maybe even allow or disallow to have money at all, like in SM3), but forbid free girls to spend honestly earned money is stupid indeed.

I don't know, it's hard to say if a system like that is affordable in an indie game (development time wise). We can implement my system now and build up on it towards percentage (complex calculations) in the future.

Nah, this doesn't require any additional content. We add percents to existing system.
It might be too complicated to use many variables though. I think we could use joy and/or mood.

- Joy and mood are randomly set for every girl during meeting.
- We could add an option to look at girl to define it, with simple short texts like "she seems upset", "she seems happy", etc.
- Joy is that joy stat that we have already. We could add a couple of simple options to increase it (and get disposition points).
- Mood is a stat (maybe one-dimensional array) that describes what a girl currently wants. Every dialogue option has its own mood value. The more the value, the better the chance.
- We don't have to use both variables, I guess. Though we could try.

Note that we can save every interaction if that makes sense as well, that's a lot easier than you may think

AA2 uses it to determine the level of relationships in the long term. You cannot become friends after several very successful dialogues there if you had a lot of bad experience before. Good experience should be > than bad experience for a start.
If you can and want to code it, be my guest 

There is sufficient reason to use filenames instead of json files I guess but that would require yet a new tagger...

We have to deal with this problem sooner or later, there is no way to avoid it. Without our own tagger with purely json or xml based tags list we are screwed up. You might as well code it after AB/AE systems, because we will improve tags in the near future anyway.

I suppose binary is the best here in terms of loading time. It's almost impossible to modify tags without special software anyway (unlike items for example), so we might as well use it if you can code it.

You could try to optimize Rudi's code, but without source code it's a dead end in the long run. You could try to figure out mcmanus's source code (it already is xml based, has more useful functions and seems faster in general). I probably can do it too, but that no doubt will take more time, it's been awhile since I did something useful with coding at my previous job, like 6 years ago or so.
 

[Xela]

Please no, that's completely illogical. You might freely enable or disable AE and AB systems for slaves (maybe even allow or disallow to have money at all, like in SM3), but forbid free girls to spend honestly earned money is stupid indeed.
Nah, this doesn't require any additional content. We add percents to existing system.
It might be too complicated to use many variables though. I think we could use joy and/or mood.

- Joy and mood are randomly set for every girl during meeting.
- We could add an option to look at girl to define it, with simple short texts like "she seems upset", "she seems happy", etc.
- Joy is that joy stat that we have already. We could add a couple of simple options to increase it (and get disposition points).
- Mood is a stat (maybe one-dimensional array) that describes what a girl currently wants. Every dialogue option has its own mood value. The more the value, the better the chance.
- We don't have to use both variables, I guess. Though we could try.
AA2 uses it to determine the level of relationships in the long term. You cannot become friends after several very successful dialogues there if you had a lot of bad experience before. Good experience should be > than bad experience for a start.
If you can and want to code it, be my guest 

Slaves will not auto-buy stuff, I wrote some functions with that in mind. If that doesn't workout, I'll change it back.

Girlsmeets are a difficult topic, I need to see the code, texts and think about what's reasonable there. Also CW didn't respond to my previous message yet.

We have to deal with this problem sooner or later, there is no way to avoid it. Without our own tagger with purely json or xml based tags list we are screwed up. You might as well code it after AB/AE systems, because we will improve tags in the near future anyway.

I suppose binary is the best here in terms of loading time. It's almost impossible to modify tags without special software anyway (unlike items for example), so we might as well use it if you can code it.

You could try to optimize Rudi's code, but without source code it's a dead end in the long run. You could try to figure out mcmanus's source code (it already is xml based, has more useful functions and seems faster in general). I probably can do it too, but that no doubt will take more time, it's been awhile since I did something useful with coding at my previous job, like 6 years ago or so.

If livingforever is willing to code a tagging software or you wanna mess with C#, there is no point for me to do it.

- I cannot optimize Rudi's tagger for the reason you've mentioned.
- It is very likely that it will take me longer to figure out C# code than to write a tagger in Ren'Py.
- If living decides not to write the software, I'll code one inside of PyTFall itself after I am done with AB/AE.

[CherryWood]

You talked about it few times before and now again, but I still don't understand it much. Why do we need a new tagger?
I mean, it's easy to remove/add tags to the both ones we have and how could clicking on boxes with tag names gets any better?

[DarkTl]

If living decides not to write the software, I'll code one inside of PyTFall itself after I am done with AB/AE.

Maybe as a separate project, not inside the game? It should be as light as possible.

You talked about it few times before and now again, but I still don't understand it much. Why do we need a new tagger?
I mean, it's easy to remove/add tags to the ones we have and how could clicking on boxes with tag names gets any better?

Because now we also going to use either names or binaries instead of json/metadata, it's way faster. And there are issues with source code of both taggers.

[Xela]

You talked about it few times before and now again, but I still don't understand it much. Why do we need a new tagger?

No idea... Rudi's original tagger is very moddable and does the job really well. The main disadvantage is loading speed of Pythons build in JSON library...

It's SLOW. I mean like sluggish... In order to load all the tags, player would have to wait at the start of the game for 2.5 seconds (Assuming ALL native packs are loaded, made my Dark or you).

It's difficult to say if it's a big deal or not. Please have reported playing the game for 30+ hours... Who'd give a shit about extra 1.5 seconds at the start, I have no idea... (Saves do not extend to that, PyTom (Ren'Py developer who's a much better coder than me, for some reason able to save ALL of our tags + all girls + all traits + all items + arena + fighters guild in 1.1 MB binary file while when I use the EXACTLY the same library (written in C), when saving JUST the image mapping, get a 2 MB file out of it)).

PS: It's more than possible that the 2MB  file actually loads faster then the 1MB savefile, I don't really understand where the difference in size comes from atm.

Basically, if we use filenames or binary, we'll have the damned game starting a lot faster than it does now! I've already put in request to include any C library for loading JSON into a default Ren'Py build. C, however,  means that sh!t needs to be complied, meaning a storm of cross platform issues + complicated bullsh!t that noone can really anticipate...

Using a C boosted lib for loading JSON is very likely to beat filenames (should still fall behind binary files a bit).

But essentially you are right, we don't require a new tagger... It's more of a luxury than a necessity AND we have two really good once already.

Maybe as a separate project, not inside the game? It should be as light as possible.

I think throwing it in the game would be smart only in case that I write it. It would be light (Completely separate loading labels from the main game). There would be no need to copy-paste/isolate hundreds lines of code. Everything would be in one place and we could read the ingame folder structure and files expecting certain things.

[DarkTl]

I'm sure we'll be able to use mcmanus tagger for everything we could ever want if we'll have a decent, permanent C+ coder. Too bad we don't.
Rudi's tagger is considerably less convenient because he disappeared before he implemented our last requests. Almost all those requests were implemented by mcmanus though.

It's SLOW. I mean like sluggish... In order to load all the tags, player would have to wait at the start of the game for 2.5 seconds (Assuming ALL native packs are loaded, made my Dark or you).

I hope you don't think that I'm done with packs. There will be more when I won't be needed in other systems. So waiting time will increase as well. I think I'll stop when the game will be unable to load all our packs without crashing 

[Xela]

I hope you don't think that I'm done with packs. There will be more when I won't be needed in other systems. So waiting time will increase as well. I think I'll stop when the game will be unable to load all our packs without crashing 

LoL

There is a very good chance that if we use optimized cPickle, C boosted JSON or files-names we'll be able to load every existing Hentai character at reasonable speeds I don't believe even the slow pure python json module will crash btw, it will simply take a while to load

Just for the record: When I wrote that script renaming all files based on tags database, the whole renaming routine took more than 10 minutes, yet it never threw as much as warning, not mentioning any sort of errors... So if coded properly, this sh!t is beyond stable and you should watch what you say 

[DarkTl]

Well, I recall you did some tests in the begining, and at some point the engine just crashed on spot when you emulated too many girls.

I guess we discussed the meeting system enough to have a concept when you'll start to remake it.
Now I'll think about actual options in dialogues that won't require more lines than we already have.

[Xela]

Well, I recall you did some tests in the begining, and at some point the engine just crashed on spot when you emulated too many girls.

I guess we discussed the meeting system enough to have a concept when you'll start to remake it.
Now I'll think about actual options in dialogues that won't require more lines than we already have.

Ok, so what else is new...

1) I managed to solve a problem that came with backbone code from Alkion that bugged the hell out of me. Images kept locking in, meaning that only a single image (of each type) could be used for all interactions, profile pictures and so on. That issue is now fixed and it's a new random image from a respective category each time it is called Smile

2) After a bit of testing I figured this:

For 2 000 000 interactions (around 400 000 girls in game), game crashes on next day.

For 200 000 interactions (around 40 000 girls in game), next day calculations take around 7 - 9 seconds. Saving takes 20 - 25 seconds.

For 20 000 interactions (around 4 000 girls in game), next day calculations take around 1 - 2 seconds. Saving takes 1 - 2 seconds as well.

For 2 000 interactions (a more realistic scenario of 400 girls in game), next day calculations and saving are instantaneous.

So in short, even assuming that next day code will get exponentially more complicated from here on out, neither the programming language nor the framework are likely to crap out on us.

== I am pretty happy right now cause that was my main concern!

cheers sunny cheers

Yeap, that was pure crash, but if you can come up with 400 000 packs, I'll shut the fuck up

Eliont (Alkion developer (I knew next to nothing about Python/Programming in general back then)) "expressed concerns" about Ren'Py being able to handle more than 30 - 40 girls, limiting Alions concept to about that amount. I did those test to prove what I read about Python at that time and that his concerns could not possibly be  true.

While we're adding some ridiculously complicated concepts and sorting to the game (bypassing anything that Alkion has by a considerable margin) that would be almost impossible to code in language like C, C++, C# or even Java at any reasonable amount of time, I believe that we're still well inside of a "green area" and I am figuring out how to move more and more code to Python modules that are executed in pure C with ever day. One of the most important concepts in Python coding is: Refactor relentlessly (try to improve code all the time) and I am trying my best to keep in sync with that narrative.

[DarkTl]

Xela, did you replaced fatigue everywhere? I don't have to do it in items and traits?

[CherryWood]

On my poor laptop, the game takes over 50 seconds to start and show the main menu.
It takes 8 second for my desktop to do the same.
 
=================


I looked at what I can do for the exploration but... it's no fun man, no fun at all!
I mean, to create content for it, it's too random and there are too few options to set now...


My wish list:
- places within explored area. Now you party just randomly gets some mobs to fight and loot or didn't find anything - It's easy but bit boring in my option, I would like to be able to create a settable special places that the team can find. With conditions on how to get there (like % chance, only on 3rd day, only after winning a fight in previous place, flags (for NPC quests and one time only encounters), risk value, etc.), it's own list of mobs and rewards and most importantly a text that will appear on that day report like "party found a forest ruins","was surprised by bandit attack","still climbing towards the top of the mountain"....
- settable items and cash reward lists, like for survival, not just money sum
- customizable mobs! We don't using pictures there, so I don't see a point in using arena monsters for automated exploration. That's unnecessary limitation, it should be allowed to create monsters with any names there. ("Cherryzard", "Woodanator"...)
- time to get there. It's strange to start bashing mobs just outside the city gates on day one - it's ok for forest, but if we added more remote places, it should takes a few days to go there and back. (maintaining advanced outposts or opening magic portals may be an options for the future)
- maybe stat changes? some places may be harden on fatigue to travel through
- collectible item type that you can't use and only sell or bring to NPCs for a quest? (EDIT: I just read your post about crafting - I thing these and materials may not really be "items" codewise and they should appear on some separate lists to not mess the inventory screens if they cannot be directly used anyway)
...




btw. I managed to get my girls killed in almost every run into the current cursed forest. There is no warning that your team is too weak for this exploration, and then, after 3 days, they're just came back dead. Maybe some common sense for the girls and refusal to fight if odds are this bad like arena girls do would be nice there?  It's hard to tell what the "risk" value means from first glance.

[DarkTl]

- customizable mobs! We don't using pictures there, so I don't see a point in using arena monsters for automated exploration. That's unnecessary limitation, it should be allowed to create monsters with any names there. ("Cherryzard", "Woodanator"...)

Good one 
We don't have to use arena jsons indeed, including monsters strength values, since we have difficulty slider there. I wonder if it possible to find a huge list of monsters names somewhere, like we did for teams names...

collectible item type that you can't use and only sell or bring to NPCs for a quest?

Yup, I proposed it too, but Xela didn't want to complicate things.
now there are two of us

[CherryWood]

We don't have to use arena jsons indeed, including monsters strength values, since we have difficulty slider there. I wonder if it possible to find a huge list of monsters names somewhere, like we did for teams names...

Hey, that's right. Because the player sees only a monster name anyway, maybe it could be totally dumbified to just name + individual modifier, and all mobs can be just some base class stat*difficulty modifier*individual modifier. What eyes do not see...
 
About the names list - I prefer less randomization there, so it makes at least some sense to run into that monster at each location...




====
Aaa crap! PV for kancolle anime is out and I need to rework the Shoukaku attack animation to show arrows changing into planes... drawing graphics and mixing sounds is fine, but I sure hate all this confusing anchor geometry positioning stuff 

[Xela]

Xela, did you replaced fatigue everywhere? I don't have to do it in items and traits?

Yeap, I've pushed that already. When you'll be checking the items next time, take a look at it because I've flipped it in couple of items because it was weird (Some items that were described to make you stronger, increased out original fatigue while raising other stats correctly). There is a always a chance that I got something wrong.

[DarkTl]

^Pushed QF. Those capes are supposed to be heavy and relatively cheap.