[2023] Pitchforks for Fairy Rings

Hey all! I want to jump in and quickly say there is a genuine technical reason why we went with a graphical change as we can’t just increase the size of the click boxes without a lot of technical work, so the easiest and most feasible solution for helping mobile users was to add a graphical element.

We don’t take graphical changes lightly so we are looking open to feedback on it. But in this case it is really important for us to make improvements which benefit accessibility for players.

I realise there’s a lot of misconceptions about this topic because it seems on surface value very simple to solve. I haven’t been able to explain the issue well enough and so perhaps need to give more information about how complex this actually is. From what I understand it’s a very complicated technical limitation we have and explaining the reasons why we are not able to increase their clickbox is really hard! Some of the devs can sometimes even find it difficult to decide how best to explain it to CM haha. The TLDR is we are technically limited in our solutions but I’ll ask again tomorrow for more info to share on this!

Thank you! I will make sure to ask - I don’t know the technical reason well enough to comment on whether a transparent* beam would work but I’ll try to find out.

I just wanted to chime in just now because I noticed a lot of people think we aren’t being truthful with our explanation. It just seems that the technical blocker hasn’t really been explained well enough by me.

So I will make sure to get a better understanding and feedback to you if possible after speaking with the team. :)

I’ll try to get more context on this tomorrow. The thing that I have learned with these types of technical issues is that nothing is ever “impossible” if you have the time but something can be so annoying to fix and take so many hours worth of dev or engine time that it becomes way too expensive to justify the time cost vs the added benefit. I believe this is that type of situation. And then when you compare it to what that time could have been spent on like updates etc that is where we prioritise the “bigger” things.

I think the problem is with the Fairy Rings themselves, as I’m aware about the Agility click boxes being OK. I will ask for a more detailed explanation tomorrow on this. I think the thing that I really want to explain is we are not trying to create more work for ourselves with this change or make things more complicated than it needs to be. if the solution was as simple as just making the clickbox bigger we likely would’ve preferred doing that without making any graphical changes.

Also Will pass your feedback on. Thank you for engaging with me on this. :)

Hi, back here with a a quick update! Positive news is that we've worked out a more player-friendly solution where we think we can change it so that the is transparent until it's highlighted. In CM we've recommended this as the best compromise and we have passed that feedback on. In next week's game update newspost we hope to update you officially on it.

Okay so going into the "technical" reasons a bit more:

Each part of the fairy ring is a different "ground location" (9 in total) then there is an extra location in the middle which is what you click on. If all of those had "ops", the ops from various ring parts would stack up in the minimenu. During the game-jam we tried solutions and they didn't look nice when highlighted - so the number of ops in the minimenu was definitely an issue!

Fairy Rings are also "multi-location" with as many possible states as there are fairy ring destinations! The same click location is used for every fairy ring, as it has no ring-specific graphics. If we were to use ops on the ground location, we would need the number of location per ring (3, corner, edge and center) x number of multi-location states (64) x number of different colours of fairy rings different locations. That's 192 locations for every colour of fairy ring (And there are at least 40 of those!). That would mean 7,680+ new locations (that is insane), although we would be able to reuse 120 of those which already exist.

Having said the above, we discussed it again today with more people, who brought more ideas to the table and think we can work around these obstacles too.

But agility clickboxes work fine!
Agility click boxes are on agility courses, where all you want to click on is the agility obstacle. Our main concern with the Fairy rings ais that they are everywhere in the world, where what you want to click on might not, in fact, be the fairy ring. We were conscious that fairy rings may be close to activities that you would want to do and didn't want to make the clickboxes too large.

Can we have a toggle?

We asked about the ability to toggle the effects on and off when you're holding a Dramen Staff for example. But this is not possible. Each fairy ring is a multi-location with as many possible states as there are fairy ring destinations. That's to show you the code of the last destination. When we allow things to be turned on and off, like with a setting, we usually turn a normal location into a multi-location with each state corresponding with each setting. We cannot have a multi-location of a multi-location. We could pretend that we do, in some cases, by reading the setting and the other multi-location variable, combining them into one, then setting a variable that sets the location to the right state when you approach the location. There are a couple of locations in the world that work this way, but it is very fiddly and we try to avoid it.

We could lose the functionality of it telling you the code of your last destination. For the few fairy-rings that are multi-locations for other reasons, (like the ones that you have to unlock), they just don't have that functionality. The trade-off the ability to see the code of the last destination for a toggle on the Fairy Ring isn't worth it.

So in summary then, we've taken on board your feedback. I personally probably could've explained the tech issues much better. A good compromise might be a transparent beam as you suggested, however, I can't promise anything yet. I expect you'll hear official word on this next week :)