Howdy! The name's Perseverant Determination. You can call me PerseverantDT or Perse, but anything is fine as long as it's not offensive and I can tell that it refers to me.
I'm a hobbyist programmer with experience in C#, Java, C/C++, etc. I aim to be a game developer, though software development seems to be what's calling me right now.
Past Projects
I used to run a small project where I create various timelapses of r/place 2022. I'm looking into getting back into it, as well as including the 2017 and 2023 iterations of the event, but time is not my friend.
I also used to create datapacks for the Origins Minecraft mod. The datapacks are still available, but they are severely outdated. I also intend to re-continue it, but again, time is not my friend.
What to Expect
Things that spark my interest. Mostly, it's delving into the functionalities of how games work, especially Sky: Children of the Light. If I'm working on a game, I might post some development logs.
Other than those, expect radio silence aside from the occasional reblog.
My theory is that TGC changed something with how player interactions persist through area loads and servers. Could be related to how lighting players now persist through areas and even servers sometimes.
Specifically for this bug, the game doesn't appear to remove the piggyback state from you when a server split happens. What this allows is, if the player who was carrying you joined you fast enough, you will be carried immediately again without requiring the other player to restart the prompt.
My guess is that the bug happens because, when you go to a new area (e.g.: by going home), the game tries to find the player who was carrying you. If it fails, it uses a fallback entity and attaches you to it. I've seen two fallback entities when going to Home: the spirit selling near the spell boat and a non-existent entity way up high.
Unfortunately, something in the game's handling of piggyback doesn't recognize that you are on piggyback when you try to move. Because of that, the prompt to get off does not appear. As far as I know, the only way to get rid of this bug is to either close the game or have the player carrying you earlier join you.
It also happens with princess carry, but some mechanics of the bug seem to differ with it. I've seen princess carry just stick you to a spirit immediately when a server split happens. Strangely, I have not seen it happen with hand hold.
Was playing Sky when a barrage of server errors hit me.
I know everyone else also probably got hit by this so I feel like I should say that these server errors are likely not caused by a bug in the game. Instead, these are likely due to Sky becoming too big for TGC's current server capacities.
Why do I say that? Take note of the timings of when the server errors hit. The server error I experienced, it happened during geyser, a day after the third quest of the season got unlocked. They also commonly happen during grandma, and especially during the start of a season or an event. First time I recall this happening was back in Days of Sunlight last year. Ever since, the start of events and seasons are always plagued with these server errors. And they always seem to happen around the same time as the first buns in grandma spawn.
What's common with all these timings? They happen at a time where server load is at its peak around the same time when the game experiences a spike in player count.
Both geyser and grandma give all nearby players with light. When a player collects light, the game sends data about the collected light to the server, and the server needs to process that data in order to register that collected light. What that means is that every time either the geyser pops out darkness balls or buns spawn during grandma, there's a spike in server load when players burn those items to collect light.
This is especially worse for grandma, because players have shared memories which burn the buns the moment they spawn. This means that, instead of having the light collection be staggered across tens of seconds, the server gets hit with data for (potentially) thousands of players all within two seconds.
The timing around the start of events and seasons is also important. Live service games often experience a spike in player count around new updates and events. I believe this is also true for Sky, though admittedly, I don't have concrete evidence to back that up. However, if we proceed under this assumption, then we can say that there's a surge in Sky's player count at the start of a new season or event. This means that Sky's servers received an increased amount of data during these times.
I'll disclaim that I don't have access to Sky's architecture, which means that what I say here could be completely wrong. Without going too deep into the technical explanations, when a server takes a long time to process the data, the game assumes that it got disconnected from the server and attempts to reconnect. Because the server is still under heavy load, this reconnection will also take time and, if it takes too long, the game assumes that it failed to connect, causing the server error.
One thing to note is that the server performing the processing for collected light and the server connecting you with other players are not the same. Even when you encounter server errors, you still see what the other players are doing. You can see them run, perform emotes, and even chat with one another. However, because the game thinks that it lost connection with a server, it says that it is experiencing server errors.
I don't call this a bug because all of this is intended behavior. It is an issue, but it is not an issue caused by some error in Sky's programming. Everything that happens on the game's side when server errors occur happens precisely as TGC intended. No amount of game updates can resolve the core issue of the servers slowing down due to high player count.
So, while frustrating, these server errors are the result of Sky being successful. Unfortunately, these signs of success could also bring Sky down because, again, it's frustrating to deal with these server errors. I'm sure TGC is doing what they can to scale Sky's architecture, but hopefully, they do it fast enough. Especially with the coming AURORA encore, Sky is bound to see even larger player spikes in the future.
"Don't you just love the sound of gunshots while coding?" -@perseverantdt [perse]
"Don't you scream for help in asmr?" -@orthogonal-slut [elliot]
"Giving all the AIs mad cows disease" -@moose-mousse [moose]
"that's not hard because its supposed to be hard. It's hard because windows hates me." -Moose
"It's like when people are afraid of the console like oh my god what if I kill everything" -Moose
Elliot: "You should try suicide linux"
Moose: ELLIOT NO WE ARE NOT TRYING TO TRAUMATIZE THE NEWBIES GODDAMNIT
"The good bad thing about linux is that it does what you tell it to do. So if you tell it to scoop out your own brain it goes OKAY!" -Moose
Elliot: "If you upload a repo with an empty readme the ghost of Linus Torvalds will come to haunt you at christmas."
Moose: "You do realise Linus is not dead?"
Elliot: "You kill him in spirit."
Moose: He astrally projects anger at you.
Sky using all your CPU? It's more likely than you think.
I wrote this in a comment on a Reddit post of someone complaining that Sky isn't using their GPU properly and that it's stuttering for them. However, it's detailed enough that I feel like it deserves its own post in this blog. As always, this is a very technical post. But if you like seeing how games work behind the scenes, then this might be for you.
There are many reasons why Sky doesn't use your GPU as much compared to other games. It's actually a common issue in many games, and while the general reasoning is the same, the details of it can vary. The short version is that it uses the CPU a whole lot more than your GPU. Hence, it's not using a lot of power because increasing it won't have much of an effect. The bottleneck isn't on GPU speed, and that's what higher power draw tries to address. It also does most of its work on one thread, which means that it won't display a high CPU usage, as that counts work done on all logical processors. The long version is a technical explanation of how Sky was designed and the resulting implementation decisions that were done because of it.
Disclaimer: I cannot confirm these because I do not have access to Sky's source code. All of these are hypotheses based on the game's visible behavior and general development decision making.
Long version below the cut. (This isn't in the actual comment, but this is a blog post. Come on now.)
A lot of things that Sky does is CPU-bound. As an example, unless it's been updated along with the AURORA concert which used GPU-bound procedural animations, the animations of the butterflies are done on the CPU. They created the butterfly animation system long before the AURORA concert, and with only around 80 butterflies at any given time instead of 100 thousand, it doesn't make sense to go through the trouble of making their animations run on the GPU. Stuff that requires network requests to do (e.g.: forging candles, buying spirit items, etc.) are also done on the CPU because there's no way for it to be done on the GPU. This means that unless you have a weak GPU, your CPU usually dictates the frame rate of Sky.
As an additional point, Sky does not have a lot of advanced rendering features which will use the GPU more. Remember that Sky was first designed for iOS as a casual, social game. While the option for adding advanced rendering techniques like raytracing and HDR rendering are available, doing so used more power, which isn't good for a mobile game that you play with friends. Sure, you can play it with the phone plugged and have no issues with it running out of power, but that's not as fun as playing it with your friends around you. As such, there's not a lot of tasks for the GPU to run, reducing its power usage.
Sky also does not run some things asynchronously, even if it could. What this means is that, instead of performing some tasks in a separate thread, it does them in a single thread. This means that what really matters most for Sky is single-core performance rather than multi-core performance. It's not completely single-threaded; you can see that it uses more than one logical processor when you open Task Manager. However, it's not using multithreading to its maximum capability. In particular, it does not load resources asynchronously.
Asynchronous resource loading just means that resources (e.g.: models, terrain data, textures, etc.) are loaded in a background thread, allowing the main thread to continue updating the game and continuing rendering. You can tell this behavior is happening because, when you switch areas, the game becomes unresponsive for a moment while it's loading the next area. The main thread is occupied with loading the resources, which means that it's not responding to window events and it's not rendering anything. This could actually be the reason for some stuttering that happens. When the game tries to load something, it will freeze because the game stops doing any updates and renders. I don't think this happens a lot — Sky seems to always load all resources it will need for an area when you enter it — but it's a possibility.
Because the GPU isn't being used as much, it's also not drawing as much power as other games. Doing so would just be wasteful since it'll still do just as much work for higher power usage, lowering its utilization. Better to have lower power draw but higher utilization since that gives you more power efficiency, which is beneficial for a laptop.
There's not much you can do to improve Sky's performance in this case. A lot of the bottlenecks here are on Sky's implementation rather than its settings. Most you can do is lower the game's target frame rate down to 30 FPS, but that's not going to help much. Frame rate limiting is generally done to reduce GPU load, not CPU. Plus, gaming in 30 FPS nowadays generally isn't desirable. It's still in the realm of "playable", but I wouldn't recommend playing in 30 FPS unless there's a specific reason to.
Small rant post about the intelligence in artificial intelligence.
Every time I see someone say there's nothing intelligent about AI, then give a reasoning coming along the lines of "it's just following a set of instructions" or something, I get a little bit irked. Do people not know that we pretty much modelled AI systems after ourselves?
Would you not consider scientists intelligent because they're just "following a set of instructions"? Are chefs not intelligent because they're just "following a set of instructions"? Mathematicians? Engineers? Artists? Are they not intelligent because they're just "following a set of instructions"?
There's undoubtedly some threshold that a system needs to cross before we can call it intelligent but making such a general threshold for that is not the way to go. If we apply a threshold for intelligence for computer systems, it should also be applicable to humans. After all...
We pretty much modelled them after ourselves. Why else do you think AI systems are always getting compared to humans?
Sorry performer. I guess you can't be called intelligent. After all, aren't you a colossal database of knowledge that your mind can consult extremely quickly?
Disclaimer: I am not affiliated in any way to TGC. Barring confirmation from the developers, everything below is a hypothesis based on observed game behavior.
From January 16, 04:02 GMT (the release of update 0.28.0) up until January 20, 04:03 GMT, Sky players experienced a bug where players rarely encountered other players, resulting in a rather lonely experience playing the game. At the same time, gates and other objects which required lighting an interactable element to activate didn't activate even after lighting said element. Most players attributed this bug to server merging (i.e.: a function where two servers have their players and state combined into one) not working as intended.
This wasn't the case, however, as it was still entirely possible to encounter other players at times. It was just happening a lot rarer than it used to. Instead, a related function — server splitting — was not working as intended which, in turn, caused server merging to happen extremely rarely.
Potential explanation of what happened below the cut.
TLDR: The 0.28.0 update to the game likely accidentally disabled server splitting in all areas of the game, causing server merging to rarely happen and for some gates to stop working.
Keeping Players Close: Server Splits and Server Merges
Have you ever had an experience where you were with your friends when all of a sudden, they all disappear in front of you? And when you teleport back to them, they apparently were still in the same place as they were? Congratulations, you just encountered a server split. A server split is where a player or group of players get disconnected from a server they're currently in and pushed into their own server. Sometimes, the server will separate everyone out of it in what will be called here a "full server split". In that case, everyone gets pushed into a server where they're the only player. The scenario mentioned above is a very noticeable example of a full server split happening. Most of the time, however, server splits don't happen to every player in the server. Instead, it only happens to one player or group of players in that server. This kind of separation is what this blog will refer to when mentioning the term "server split".
The exact criteria needed for a server to split a player or group of players isn't known. However, one criterion that can be easily observed is that the server will split a player or group of players when there are no other players within close proximity to them. "Close proximity" is not defined in strict terms here as it is currently not known how far this distance needs to be. However, to observe this behavior, you can do the following steps:
Stand on one of the floating islands in Sanctuary Island.
Have a friend fly towards the main island.
Keep honking in order to see your friend's name.
As they fly down to the main island, eventually, your friend's name will stop appearing when you honk. A server split just happened. Because you are far from your friend, the server thinks that it is alright to split the two of you in order for a server merge to bring either of you to a server where players are close to you or your friend.
This is necessary behavior because there's a limit of 8 players per server. In order for a server merge to be successful, there must be at most 8 players in both servers combined. By splitting players from the server they're in, it increases the chances that the game will find a server that they can be merged in by reducing the number of players in their server. This is why waiting inside the 8-player puzzle room when there's already 7 players there usually takes a long time. By having 7 players in the server, only a server with one player can be merged into it. However, the two-player door before the room means that most servers with players in that room will have at least two players. Those servers cannot be merged into your 7-player server.
Determining the Absence of Server Splits
To say that server splitting isn't working as intended, we can establish the existence of players that should have been split away from us within the server. Normally, it would be hard to determine such a case, as that entails having to search for the presence of players in areas we cannot see. Additionally, if we do spot a player, we cannot know if that's a player who was already there, or one who was just merged into the server. Thankfully, there is a way to determine the presence of players without seeing them: the chat history.
When you send a chat message in Sky, it is sent to all players in the server you are in, including yourself. This prompts the game to display that chat message on top of the player who said it as well as in the chat history. However, if you don't have chat unlocked with the player, or if either of you aren't in a chat bench (doesn't have to be the same one), the game will replace the text of the message with a bunch of asterisks when displaying it to you. Additionally, if you have a player muted, the game will not display the messages they are sending, but it will still store them. This can be verified by muting a player, having them say something, then unmuting them. The game will then show the messages they sent while you have them muted, which means that it stores their messages even when they're muted.
Because player messages are sent to the entire server, you can see the messages of players in other locations, provided that they are in the same server as you. You can verify this by joining a friend (chat can be locked or unlocked), going into a level transition, then having them chat something. Their messages will still appear in the chat history until the server splits you off from them.
We know that this happened during the period of the bug because there are numerous bug reports in the Sky Discord mentioning the appearance of messages from players who are nowhere near the reporter. These messages can only appear if a player had sent them, which means that there's a player somewhere in that server sending these messages. This player is far from the reporter, which means that they should have been split off from them. However, that is not the case, which shows that server splitting is not working as intended.
Gates and Their Dependencies on Server Merging
Another part of the bug is that none of the gates and other places which require lighting some sort of pedestal or key to open work. While the reason for this cannot be definitively determined, it is possible that these required a check that involved a server merge for it to start working properly. Given that a server merge usually happens often and sometimes unnoticeable, it is likely that a server merge was made as a requirement to ensure that some gates only work when there's multiple players in a given area. The presence of this requirement doesn't make much sense, as two-player and four-player doors already require multiple players on their own, and requiring multiple players for one-player doors is not intuitive and sometimes even harmful for user experience. However, this is the most likely explanation as to why this bug is related to the server splits bug.
Reworking Maps and Inadvertent Changes
To give a possible explanation as to how this bug happened, we need to look at a handful of places and scenarios, namely:
Homespace and Aviary Village
Eye of Eden and Orbit
Valley of Triumph Races and Red Shard Memory Collections
Homespace and Aviary Village serve as central hubs for players to go through. As such, it is important that players be capable of gathering in these areas. Server splits would require players to not explore the central hub while waiting for others, which can make for a boring experience for some. Additionally, full server splits may also happen, which will force the players to repeat the process of gathering, which can be annoying to deal with. As such, server splitting is disabled in these areas.
Past the first area of Eye of Eden, server merging is disabled. While the game's tip for Eye of Eden is to stick together, keeping server splitting enabled is too punishing, as it prevents a player straying too far ahead or too far behind from receiving help from other players. Additionally for Orbit, keeping server splitting enabled can prevent players from hanging around with the people they shared the experience of the end with, which can reduce player satisfaction. As such, server splitting is disabled in these areas.
Races in Valley of Triumph as well as memory collection in Red Shard events sum up all the light/memories that all players in a server receive. If a player within a race or within the memory collection activity were to get split off from the server, it could make the light calculation inconsistent. To prevent these, server splitting is disabled while a race or any other activity is active.
What this all shows is that server splitting is something that can be enabled or disabled when needed. In preparation for the new season, nearly all areas of the map have been updated for the new dye light mechanic. It is possible that, while updating the maps, server splitting was accidentally disabled in these areas, causing server splitting to be disabled in all areas of the game.
A Quick Hotfix
An update was released on January 20, 04:03 GMT which fixed this issue completely. Server splitting now works as intended again. This didn't require a manual update of the game, which meant that this was a fix that involved only editing the assets of the game and not the actual code. Either way, players can now continue playing the game, finding others who are also playing near their character.
This was supposed to be out a few hours ago, but I fell asleep while thinking of what to write here.
The first week is done, and I'm pretty satisfied with progress so far. I've got a still-unfinished design document for the game, and an unfinished layout for the first level. This week's goal would be to finish the design document and complete the first level, though only with placeholder assets. Hopefully, I get to finish it with spare time to include making some sprites within this week.
Additional stuff below the cut. Not gonna anything important besides what's already shown, though.
Some snippets of the design document as a teaser of what's coming to the game.
This is probably going to change a bit as development goes on, but this is the general idea of what the game is going to be.
Also, here's the unfinished layout of the first level. I won't be providing much context as to what room is what, but I think people would be capable of inferring them based on their sizes. The white parts show the walls, while the parts in pink show what is inbounds.
After a few more days of prototyping the idea I have for this jam, I finally managed to make something that I think would work well for the game. It's currently out now on itch.io, but don't expect anything great. It's just a prototype of an idea.
Now that the idea prototype is out, I'll be moving to the design document. I like to think of myself as a good game designer, and I guess I'll see if that's true.
I've always wanted to build a game, but back when I first started joining game jams, I had no clue what I was doing. I had some experience with programming, but not enough to make a game just yet, much less under a time constraint. However, now that I have more years of experience, some formal education, and a schedule that gives me more time to work (for now), I think I have what it takes to create a game within the month. Because of that, I decided to join...
Boss Rush Jam 2025: Day 1
Note: I don't intend to maintain daily devlogs for this. Instead, I'll only make one if I think that something is going to be interesting.
I decided to join this one mainly because the submission period is quite long. It gives me a lot of time to work on assets, which I don't have much experience with. The cash prize is secondary; I don't expect to win anything at all, but it would be cool if I managed to.
The theme is quite interesting, to say the least.
There's a lot of ways that it could be interpreted, and the announcement video provides some ideas on how the theme could be used. First things first, some brainstorming. After a 635-word document on what could be done with the theme, I ended up with something that could be good but needs some tuning to not be tedious.
Still very early to tell how this concept will go, but I think this has the potential to be very engaging. All it needs is a proper execution.
