Very few players get this error, from time to time. For some reason, the memory their browsers are willing to allocate for the game is much smaller than it should be. I'll let you know if I find a solution.I don't know if this is some issue on my end only, but I can't save the game in the latest Free version download.
I get a LocalStorage quota exceeded Error when I try.
I peaked at the source code to figure out how I was supposed to be allocating and prioritizing stats.Thanks for your comments! The AI is still a work in progress, and I'm reworking a few of its areas. Version 0.2.2 brought an important update to the combat AI and it now actively works towards pushing its enemies down, struggling out of unfavorable positions and securing kills,You must be registered to see the links. Let's hope it's not too challenging now. This version will go free in a few weeks.
I'm not entirely sure about how to balance the understandability of the combat system without turning the UI into a spreadsheet, but something that would likely be welcomed would be showing the damage and evasion formulas in the action descriptions.
There are two systems that at a glance seem the same or similar. There's the sex system which is based on a time slice; it ends only when time runs out.I don't understand the sex fight system. Is the loser the first to orgasm? If I am dominant wouldn't using my opponent sexually (cumming first) mean I am the winner? I had sex with the slime lady, and we both reached orgasm, and the fight kept going as I spammed buttons until it ended. I don't know why it ended.
The main effect conversations have is in altering the character's immediate state which makes them more or less likely to accept proposals such as for sex sessions or combat.I don't understand the social/conversation system. I get that if I make the right choice, something positive is supposed to happen, I don't understand what all the variables are or what the ancronyms and changes mean when I choose to talk about training, etc. I am assuming that like in dating games, if you choose the right topics, one can grind stats with a character and then fuck. In a different game, I would expect a setup like the following: the player can 3 conversations per day and depending on girls and topics the player gets stats in those areas and content is unlocked once a threshold is reached.
I was planning on providing more extense explanations of the game mechanics through library scrolls, but I've been pushing that for later because I wanted to polish some things first. However I will add a few provisional explanations in the Readme file until that time comes.I suppose my comments can be summarized as follows: when I click a link to make a choice, I don't feel a strong connection to what follows because I don't understand the gameplay mechanics. This breaks immersion for me as the clicking feels like a chore, not a gameplay choice.
Keep in mind that time is also a resource in this game. Even if a higher cost action isn't as effective to provoke the mood you want, you're saving on time that you could use to train, later. If you found yourself in the situation that you and another character are trying to build dominance on each other (the AI doesn't plan that far ahead yet), choosing more cost-effective actions would give the lead to the other character, which is another aspect to consider.One of the things that is unclear to me from using the interface without peaking at the source code is whether or not a higher resource cost for a conversation option corresponds to a higher effect. Without peaking, I have optimized around minimizing the cost and selecting the lowest cost option in any given turn.
Generic sex scenes do not have consequences yet. In a future update, making another character reach orgasm, leaving them unsatisfied or provoking them to lose willpower will have consequences in your relationships with them.I haven't peaked at the source code yet, so I am not sure what the exact long term consequences of making characters orgasm repeatedly in the session; intuitively my sense is that it alters some aspect of character behavior, but it appears to be a weak effect mostly concerning threshold for acceptance/rejection of offers of sex.
ST and LT are indeed Short Term and Long Term. Each day, a portion of ST values is lost and a portion of that loss is turned into LT. This means that your relationship with a character will deteriorate if you stop talking to them for a few weeks. On X>(Y), X representes the current level, while Y represents the level that aspect of the relationship is increasing or decreasing towards.I am unclear from context what ST and LT are supposed to stand for, but they clearly represent some kind of XP system with the parenthesis values representing what I think is daily changes; Short Term and Long Term changes I think?
I am not sure what the notation, 1>(1), means. The number before the > seems to be my permanent relationship grade with the character but I don't know exactly what the parenthesized number is supposed to be. Maybe the change in grade?
NPCs accepting or rejecting challenges depends on their perception of danger. If you have better stats on average and/or they have empty or half-empty bars (willpower, lust, etc.), they will consider the challenge to be more dangerous and will be more likely to reject. The stakes of the challenge also influence this. Their decisions on forming groups depends on favor, relations, special relations and their perceived general danger: if another character with high infamy has a group stronger than their they will be more likely to form and join groups to not to be as defenseless.Character moods and relations are the main driver it seems for getting a conversation in the first place or getting people to follow you or getting people to accept challenges.
This is an oversight of mine with the algorythm. I have to make sure the NPCs check if kicking a character out of the group will get them at danger levels again.Looking through the AI code, it is clear to me that what is happening is that when I am in no group I have a high danger or threat value. This makes the group consisting of every other character want to have me as a follower. The moment that I join then the threat value drops to nil; this triggers the AI to call the low danger state and get rid of an extraneous character which ends up being me.
I've spent the day reading the source code more carefully rather than just doing a blind play test.Keep in mind that time is also a resource in this game. Even if a higher cost action isn't as effective to provoke the mood you want, you're saving on time that you could use to train, later. If you found yourself in the situation that you and another character are trying to build dominance on each other (the AI doesn't plan that far ahead yet), choosing more cost-effective actions would give the lead to the other character, which is another aspect to consider.
I was planning on providing more extensive explanations of the game mechanics through library scrolls, but I've been pushing that for later because I wanted to polish some things first. However I will add a few provisional explanations in the Readme file until that time comes.
I think that there being a scroll library in game for looking up the in depth information about characters, actions, and items would be really good, and I think that the relative visibility of information available should scale with character perception, intelligence, and empathy. So a character with "max" in those stats would be able to look up like the exact formula representation of the action whereas characters with lower than max in all three would see less information; this could be played with in interesting ways when combined with the bondage system you've started developing with locking body parts, so your perception could be set to 0 with respect to some actions like discerning the mood of the other character(s). Say if you were blindfolded for instance.At the moment, I think the Perception attribute is among the weakest and least utilized attributes. Luck might be lesser than it and Intelligence. Perception and Intelligence are largely defensive attributes; they contribute little to nothing directly to the social interactions and character relationship. I would like to see them linked to mechanics for examining and analyzing the other characters; a high perception character should be able to look at characters interacting and discern information about the relationship, drives, goals, and missions of those characters. Normally, I would think this is asking too much, but you've got a clear handle on the integration of the mechanics.
If you had a 3 or 5 star rating icon next to the stats in the tool tips for the attacks it would help.
Like how Physique is 3x in Thrust calculations where as the other two stats are only 1x. All we really need to know is how the stats are relatively weighted against each other in the calculation for the action. Thrust uses 3 stats for the user; physique is by far the most important of the three and the other two are co-equal.
Doesn't need to tell me the exact numbers and effects. Again just a relative indication of effects compared to other comparable options. The tag icon system you have in place is a good prototype. An icon in a mouse-over tool tip for "effects Observers(mood||relationship)" and an icon for "effects Relationships" would go a long way towards clearing some of that up. Icons for "uses(Attribute(s)) for multiplier(mood||relationship)" would also go a long ways towards clarifying the differences between the conversational options and social interactions.
I think the UI that you've developed for the popup tooltips for mood or the action description button you've developed in the sex and battle scenes would be applicable for the conversation scenes.
I've been investigating this issue. Apparently, Twine games use a space of the browser's memory that is very limited. Since most Twine games have a relatively small amount of variables, it is an uncommon problem and I haven't found anyone discussing solutions that would work for Unholy Arts. I'm going to keep looking into this since not getting a definite solution to the problem may force me to limit the scope of the game, or else it will end up causing problems for a much bigger proportion of players. For the moment, here's a list of things you can do to reduce the likelihood of this issue affecting you:I don't know if this is some issue on my end only, but I can't save the game in the latest Free version download.
I get a LocalStorage quota exceeded Error when I try.
This is actually a well understood problem for a number of Twine games. Small number of variables helps but doesn't mitigate totally; if the game loop goes on for long enough then it will turn into a slideshow especially if you're using the save system in Twine rather than strictly saving to disk; garbage collection is not great with Javascript and dynamic HTML pages. Temporary solution is to save to disk; close out the game, and reload from scratch.Since most Twine games have a relatively small amount of variables, it is an uncommon problem and I haven't found anyone discussing solutions that would work for Unholy Arts.
Combats with uneven characters in each side are possible through assault. Challenges are 1vs1 combats, but assaults involve all characters in the groups of the assaulter and assaulted.Is there any double teaming in the combat? There is a 2v1 scene in a daily scene with you doing mir with val in a spitroast iirc if you choose that option.
But in 2v1 regular combat it seems just regular combat moves. The same kicks and spells etc.
Hmm brings the question is there 2v1 sexing in the consensual encounters when some have teammates?
Thanks. Interesting game btw.
I found Free Cities being mentioned briefly when I was looking for information on this issue, but there wasn't much help in that thread. Any links you can provide where I can keep learning about their solutions would be most helpful.This is actually a well understood problem for a number of Twine games. Small number of variables helps but doesn't mitigate totally; if the game loop goes on for long enough then it will turn into a slideshow especially if you're using the save system in Twine rather than strictly saving to disk; garbage collection is not great with Javascript and dynamic HTML pages. Temporary solution is to save to disk; close out the game, and reload from scratch.
The save system in Twine particularly doesn't handle large save files well. When you have only one save, the file can be relatively large. But when you copy that to each other slot then Twine bogs badly because of restrictions between the browser and its access to the read/write permissions of the system long term storage and the execution permissions of the browser with respect to the operating system.
This is one of the reasons that desktop applications end up being preferred for game development in general, and we haven't seen much in the way of large scale HTML5/WebGL games. Shifting over to WebGL would give you potentially more options, but the change over would be as big as just making a dedicated compiled build for a standalone desktop/smartphone app.
Free Cities is probably the best example of Twine being stress tested. There's quite a bit of discussion around the Pregmod developers about the technical problems of implementing Free Cities in Twine. The Free Cities Pregmod has to be downloaded then compiled on the host system to play it. The compilation process allows certain performance tweaks that make it possible to play the game for a prolonged amount of time.
Causes an error in the battle script by the way. If you setup and detach specific moves it will bug the whole thing out because the script expects a POS and doesn't get one.The spitroast position, however, is set by script, as there are no actions that initiate positions between more than 2 characters yet.
I mean, it's already a slideshow... That's generally how HTML games work.it will turn into a slideshow
Three reasons. The first one is that saving often ends up clogging the memory, and some people would save every single time before they'd pick holding hands or asking for sex, which would provoke lag and memory issues fast. The second one is that not all the data of the game gets saved (such as pathfinding and some short term AI goals), so saving in the wrong screen and loading the game would provoke errors. The third one has more room for debate: if you're free to save and load whenever you wish, you can't make wrong decisions, or wrong decisions that you can't fix in a few seconds, which removes a lot of the significance of choosing. Being successful feels best when you know the taste of failure - and getting Mir to freeze your toes isn't the worst kind of defeat, all things considered.Completely off topic but why lock the save function to start of day? With how interactions work and how oftentimes something you think might help you can end up being negative, why lock the save function? Seems arbitrary to me.
Yeah that makes sense. I wasn't sure if there was a mechanical reason which is why I thought I'd bring it up. I simply liked the idea of being able to save before making choices because as of yet it's not clear what many choices will result in. That said "Trial and Error" isn't a bad thing so I'm not too worried about it. Thanks for your response!Three reasons. The first one is that saving often ends up clogging the memory, and some people would save every single time before they'd pick holding hands or asking for sex, which would provoke lag and memory issues fast. The second one is that not all the data of the game gets saved (such as pathfinding and some short term AI goals), so saving in the wrong screen and loading the game would provoke errors. The third one has more room for debate: if you're free to save and load whenever you wish, you can't make wrong decisions, or wrong decisions that you can't fix in a few seconds, which removes a lot of the significance of choosing. Being successful feels best when you know the taste of failure - and getting Mir to freeze your toes isn't the worst kind of defeat, all things considered.
Get back at her later!