Understandable. Eventually there'll probably be settings to speed up the transitions but we haven't got to that yet. And the reliquary mode is almost done! Should be able to post it next week or the week after.
Yeah... Aspiring + Familiar is definitely the anomaly since it's the only cubic scaling in the game. I'm currently in the process of looking at all the least used followers and see if there can be a similar cubic scaling mechanic, but it's tricky since the while system is reeeaaally not designed to have scale infinitely (as in endless mode). Multiplying dancer's attack could work since charging aspect is the only way to make dancer attack twice and it's already pretty rare, I'll do some testing on that to see if it'll be too op. However, artificer and dragoon will be hard to implement, since the "+1 to all values" effect is not a variable, but a different version of the follower; and what dragoon is doing is change the first aspect into its intrinsic trait instead of actually getting 2 aspects.
I agree that early game need some small adjustments. The current plan is to adjust the spawn rate of initiate and supplicant when the player is on low faith and make the 4-choice recruit events show up 1-2 depth early. Hopefully that'll make the early game feels more fair.
Yes, except that that's not how status works in this game at all. To get into more details, almost all interactions in the game is done through "signals", and each follower will have a bunch of "status" to interact with those signals. Each signal is consisting of a signal type, whatever object reference required from that signal type, and a bunch of float variable. for example, a signal can be something like "deal 3 damage" or "gain +1/+1"; "deal 3 damage" signal will have the signal type of "damage" with variable "damage = 3"; "gain +1/+1" signal will have the signal type of "create status", with a reference to a generic stat status, and variable "AddDamage = 1; AddLife = 1". Each status can be more complicated; some status will passively modify a follower's stats or have interaction with specific signals, like the status "this follower will gain double stats"; How signal and status works in action is: when a follower receive the "gain +1/+1" signal, the signal will inform all status on that follower of the signal's existence, and if the follower has the "this follower will gain double stats" status, the status will then modify the "AddDamage = 1; AddLife = 1" variables of the signal to "AddDamage = 2; AddLife = 2"; after that, the signal will execute its proper function to add a new generic stat status to the follower, and modify the new status base on the AddDamage and AddLife variables; maybe the follower also have a status that says "deal 3 random damage on stats gain" status, in which case, when the status is aware of the "gain +1/+1" signal, it will send another signal "deal 3 random damage" to the same follower, which will then go through this entire process again.
How familiar works is that it'll create a special "adjacent stat status link" status to all followers before the start of combat. This adjacent stat status link is a status that, whenever the source follower receives a "create status" signal, the status will check whether the "create status" signal is creating a stat status, whether the "create status" signal can be interacted by status (whether it has "IgnoreTrigger = 1"), whether the source follower is adjacent to the follower that created the status link (the caster, which, in this case, should be a familiar), and whether the caster is alive. If all conditions are met, the status link will then force another copy of the status are to be created by "create status" signal to the caster. And here's the problem. If the status link then create a new "create status" signal and send it to the caster, then that new signal will also go through the same process. That means that if 2 familiars each have created a status link on each other, then familiar 1 will gain a stat status and send "create status" signal to familiar 2, which will go through the same process and end up sending a copy of the same "create status" signal to familiar 1. To avoid this, the "create status" signal sent from familiar 1 to familiar 2 will need to include the information that "this signal is created by a status link from familiar 1, and therefore should not trigger any other status link that are created by familiar 1", which is really troublesome to implement because signals are coded to only carry float variables and not extra reference to objects. What we end up doing is to just mark the new create status signal with "IgnoreTrigger", making it unable to interact with other status link status.
I guess this is just a really complicated way to say that yes, such a propagation iteration does make sense in a vacuum, but it doesn't really work with the process of how all signals and status are processed in this game. To make familiar being able to trigger other familiar, we'll need to change how signal or status are coded, which is just a bit over-scoped at the moment.
How familiar works is that whenever a status (e.g. a buff that gives +1/+1) is given to an adjacent follower, a hidden status on the said follower will then transfer a copy of that status to familiar. However, the status being transfered can't remember what's going on before the transfer. Therefore, if we let a status being able to be transfered multiple time, it'll result in an infinite loop of 2 familiars transferring to same status to each other (since the status can't remember that the prior incarnation of itself has already being transfered to one of the familiar). So we just make it so that a transfered status can't be transfered again.
These raven interactions are all intended. How it works is that everything that happened simultaneously are considered the same effect. Therefore initiate + emissary will only proc raven once, while Initiate + obelisk will proc raven twice. Huntress and lightkeeper follows the same rule. I made it this way so that trigger effects will be easier to balance and for player to predict, but I guess if this rule turns out to be unintuitive for too many people, the alternative will be to have them based on numeric value (like deal 2 random damage for each point of faith gained)
I agree with the comments on endless mode. My intention is not to just brick some builds completely, but rather that player will need to identify and mitigate the weakness of their build rather than keep using the same strategy. It is probably a good idea to have some endless mode exclusive mobs with weaker version of those hunt mechanics.
Hmmm. I feel like that is probably too complicated as a single trait since it'll need to have a cap. There's probably some design space for summon on friendly death tho...
Yes. Unfortunately dragoon's trait don't work with fracturing due to how traits are coded. Essentially, dragoon will change their intrinsic trait into the first aspect their given, so their original intrinsic trait can't be an additional trait itself.
yes. Unfortunately the original sculptor is just too op and require too little investment. Now sculptor'll always summon 1 sculpture but it'll have more stats with more support; and we added beekeeper for the mass summon archetype.
Appreciate the report! That's a lot of things going wrong and I have no idea why any of them are happening...but also I'm kinda surprised the game didn't just explode at that depth.
Noted; appreciated the reported. Yeah there is possibly a bug related to having too many followers created and destroyed throughout a run, but I have yet to identify it...
Really solid feedback. I'm always very conflicted about reroll, but I think I have found a good way to implement it; and there are also other ways for player to influence their recruit pool in the work.
Supplicant is indeed sort of imbalanced. It theoretically should have 1 less health, but that will make the player lose the second combat if they recruit supplicant and put it at the front (which is the intuitive way to position it). That's the only reason I didn't nerf supplicant, and I've yet to come up a good solution for it.
Oh wow. I looked into my code and found out that after 20 turns of no one dying the game will force player to lose to avoid infinite loop. I must have coded it years ago when this feature made sense, and just forgot about it because it never triggered. Sorry about that...
Appreciate the report, I believe that it's indeed a bug and I'll definitely investigate and fix it.
I was just saying that this bug happens probably because when bees are being summoned, adjudicator has already (secretly) started their turn, at which point the bees are not registered in the follower list yet and their "aggro" value still extremely low. So, when adjudicator is choosing their target, they thought the bees are the back-most followers based on their aggro value, even though the bees are actually in the front. Probably all because I forgot to add a delay on beekeeper's death to stop adjudicator acting to early or something like that.
Oh wow. Failsafe is when the game can't generate enemies that meet all the requirements. I never tested it this far down because I thought it's impossible...
