Survive the Wild Very Very Late March Update

Hello everybody! After many months more blog silence than I originally wanted to create, I’m finally back with a huge update post about Survive the Wild! From what’s been going on behind the scenes over the last few months to the list of tasks required to finish the beta to a frequently asked questions section to an important change to the end of beta plan to a link to an interview I did with the Tony Gebhard show to an update on my personal life and more, this post has it all and should insure that every player who enjoys the game finally feels communicated with again! I am truly sorry for how long it took to finally get this done, I think everyone would have agreed that it was OK for me to miss a post following the release of the beta and maybe even the one 2 weeks after that due to general post-launch hecticness, but certainly I am disappointed in myself for not being able to resume the previous blog schedule at least after a few weeks of the beta being online. There are several reasons for this from the fact that there has always been a lot to do since the beta launch to the fact that much communication has been happening on the running game as well as the discord server making this harder to prioritize in my mind over fixing bugs/brainstorming/etc so that the beta might end as fast as possible to the burnout I’d mentioned in the stw English discord server in January, however I’ve still wanted to post here since a few weeks after the beta launched at this point and am sorry for not doing so before now. Honestly, this post has been in development for months, I mean since like last July or something. I would nearly finish it, then something in my personal life or another issue coming up with the game would distract me and delay it again, this repeated a couple of times. Lately I thought of just rewriting it from scratch since I felt like the post I had been writing was a bit too stuck in the past and a bit too hopeful in the short term, and actually wrote 25kb of a new post which was too negative, before remembering just how hard I’d worked on the one you’re about to read and deciding instead to combine both posts into a giant record containing information all the way back from when the beta launched to the current state of things in late March 2024. Since this post was written over a long period of time, I apologize if while editing it I missed any incongruity with the timeline and/or tone of the writing (I have done my best to insure it flows smoothly). Another consequence of this post being written over time and my resultant wish to fix the communication gap is it’s utterly massive size, I apologize if I overdid it for some! Again I am super sorry for how bad my communication on stw has been lately, and hope that this large post will begin the process of undoing the damage caused by that. Well without further ado buckle up, and lets begin!

What game related tasks must be done before the beta can end?

So what with the beta having lasted so long, I wanted to start by listing the large things that we need to figure out before the end of the beta. I think everyone from me to the staff to the players would like the beta to end as soon as possible, so if we can find a way to end the beta before finishing everything in this section, we’ll gladly do so. However as you’ll see below, some of the items tie together a little bit anyway sometimes making it unreasonable to finish one thing without another. A common theme you’ll observe is that we really are learning as we go here. We found that some systems didn’t work as well as we’d hoped in their first implementation, and are in the process of reworking and/or fixing several things mentioned below.

The biggest thing by far is this situation with the pathfinder. Getting that thing to work as fast as we need is an extraordinary challenge to say the least, so much so that we are likely going to employ more simple forms of movement when we can get away with it. I’m hoping that I am using the thing wrong and will figure out how to properly employ it at any time, however either this may not be the case or I may not soon find the answer, and as such there is a chance that the npc movement system will need a serious overhaul. Most of the lag spikes on the game are due to a single npc somewhere on the game trying to calculate a particularly difficult path. Unfortunately the pathfinder is blocking (E. not much code when run when an npc is pathfinding), and so when an npc does this, the entire server lags. Making the pathfinder nonblocking is of course something that is extremely high on my list to be considered, but there are a bunch of hidden implications here that I need to consider to do this just right. For example the ones that instantly come to mind are that the server handles several packets or other events that cause the modification of map data (such as a user cutting down a tree or opening a dor), or an object could get destroyed while it is actively in the process of pathfinding. This pathfinder absolutely cannot handle a situation where the map changes mid pathfind, so all packets that could modify map data would have to me delayed or something (which means they would then be out of order from other packets). Destroying an object while it is pathfinding is just something I’d still have to look into at the time of writing, it’s possible but a little messy, and there may also be any number of other issues with nonblocking pathfinding that are not as visible yet. Basically making the server able to pathfind while doing most other things is a large potentially messy job especially if I try using actual threads. So I’m considering that, I’m also considering still how to improve how I use the pathfinder myself, and I’m looking into creating an alternative movement system that is used when possible that then sometimes employs the pathfinder in controlled and more necessary conditions. I still have not processed yet what is best.

Regardless of what we do to the pathfinder/npc movement system though, this leads to another problem/mistake that was made when the pathfinder was first implemented, unfortunately it gets a little technical. Basically when a script controlling an npc requests a path, it calls a function that blocks while the path is calculated and then returns true if a path is possible, false otherwise. I had some misgivings about this from the start, but they were silenced by the fact that I didn’t know especially with a map system intended to speed up as much as possible if it would be so slow that I would have to employ a callback strategy instead that would make script writing a bit more complicated or at least unique to stw, perhaps we can add a small dose of overconfidence here in which I convinced myself that I’d be able to fix this issue quickly (lesson learned). Quite simply I accidentally made a wrong choice here and should have listened to the quiet instinct telling me to take a slightly different path. As a result, any sort of different movement system or different usage of the pathfinder will require some reworking of existing npc scripts. However this bridges nicely into the next issue which is that we want to rework the existing npc scripts anyway. We’ve learned loads from what we did previously, most importantly how we can do it better and make the creation of new npcs much easier than it already got during our first attempt at the npc scripts. At the moment we’ve found that when creating a new npc, it is still complicated enough that we are copying the code of an existing npc and modifying a few values, leading to more duplicated code than we’d like. We instead want to write a bunch of general skills used by all npcs, then make it so that the definition of a particular npc is basically a skill tree, a sound selection and a description. If the npc needs to do something special, we can then just add a new skill to the skill library that any npc can then use in the future. We would want to do a rewrite like this after the beta ends, accept that as mentioned above, the pathfinder issues are also a much larger concern that sort of intertwines with this one (E if we do one we may as well do the other), so it makes the priority of this task quite confused. Luckily though a master already did loads of work on the skill tree part of this system, so we aren’t starting from near scratch here at the time of writing this. Perhaps it sounds extremely frustrating to hear that we still didn’t get npcs right and need to redo much of their logic again, to which I can say A, it frustrates me beyond belief as the developer as well, though in my defense B, as I mentioned above the development of stw is very much a learning experience for me and the staff (nobody on the team that I know of has gone to school for game design or programming, I certainly haven’t and have instead been learning as I go along). As long as players stick around though, we’ll try and try until we get this right.

The next thing that is slowing us down is that my knowledge of trigonometry is not nearly as good as it needs to be. Now that objects like tree branches are rotating, we’re running into several issues relating to distance calculation between rotated boxes and the fact that stw was designed from the beginning in grid style meaning that the player is a simple point rather than a full object, and the solution to most of this stuff involves knowing enough math. I’m confident that we’ll figure it out, self learning tends to be one of my strengths and who knows what help or example code will come along, but at this time I am still very much in the learning state of solving some of these problems. Certain examples of these issues can be seen when the premium gift robot doesn’t work correctly or when you can’t collect leaves from some tree branches etc. How much of this stuff do we need to solve before the end of the beta? It’s hard to tell honestly, but put it this way. Elevators, the campground tent flaps, leaf collection, and a certain highly requested object that is mostly functional but which we can’t release because of these bugs would all be working/available if we could fix this stuff.

Though I think I fixed them and as of March 2024 I haven’t seen any evidence of this in the last couple of months, we are still trying to determine whether there are any remaining issues with the account or character database after converting it to SQL as mentioned in previous posts. No doubt some readers will have had bad experiences trying to create accounts especially during the early days of the beta. I think I’ve now resolved the source of these issues, but we are still waiting to make sure. If in recent times anyone has had issues creating accounts or characters, please comment here! Don’t include personal info such as the character names etc, but just an excerpt of what happened (or you can create a bug report in the game). When will I know that they are fixed for sure? Sadly the answer to that is basically once they have stopped appearing for several weeks, which they may have very well done by now (more analysis of bug reports and confirmation from players should give us assurance here).

There is also the pressing issue of object serialization, that is making sure that objects (such as trees and hammocks) maintain their states after the server restarts or crashes. This issue actually goes potentially deeper than stw, causing considerations about more long-term serialization formats I want to consider for the NVGT engine. Or do I want to store the objects in an SQL database/table? A custom format? I’m still considering. It is pretty easy to push aside things that I’m still considering to make room for things that I already know how to do, and there have been plenty of those since the launch of the beta that has pushed this to the background. As I think we can all agree, this is mandatory to get working properly before the end of the beta for several reasons, anything from the elevator losing it’s position to the doors losing their open/closed states to the very obvious falling out of no longer existing trees or hammocks disappearing. Another reason that this hasn’t been worked on yet is because remember all those issues with npc pathfinding and movement? Yeah well we don’t want to accidentally save the state of an npc that is crashing the server, making it much more difficult to restart without manually editing the saved objects database to remove the troublesome npc. This last point about how we can’t save various objects because they may cause lag has actually been quite the deterrent to me working on the object serialization directly. See why fixing the pathfinder/npc stuff is such a priority before the end of the beta?

There is also the timer lag to consider. I’m sure everyone who has played on the beta has seen how the longer the server runs, the slower animals/projectiles/objects move. Recently we discovered the cause of this, which is that some arena based spawners weren’t destroying correctly leaving items to fall forever in nonexistent maps, slowly clogging up the server’s timers more and more. We have already fixed most of this actually, however an annoying difficult to reproduce/track down case of it still remains which can cause hundreds or eventually thousands of items to fall through empty space forever. Why not just slap a temporary measure in place such as a timer that destroys the grenades after a certain amount of time? Quite simply because we have tracked this bug to an issue that is very likely deeper than the destruction of spawners. We’re pretty sure at this point that in some rare cases, some timers are executing on objects that are supposed to be destroyed and in the process of getting garbage collected. It’s rare and the only time we can see the effect is when an arena spawner malfunctions and starts raining grenades into a destroyed map, but we’re worried where else this is happening at this point and would rather fix the bug itself than employ a bandaid fix that may cause us to forget about it until something else possibly more severe makes the bug pop out of the woodwork. As to other reasons that timers are slow sometimes right now and why we can’t entirely gauge the quality of all of our fixes? Hmmm, remember those annoying pathfinding issues slowing things down?

We also have a bit of conversion to sql to complete before we rebuild the January 11th database at the end of public beta. It shouldn’t take that long once I actually get started, but we need to convert trusts, mutes, and group chats to sql as well as the language editor data. Once this is done, character renaming will stop breaking all of these things mentioned.

So those are most of the huge hurdles I can think of right now, at least regarding the development of stw itself, that seriously clog our ability to call it the end of public beta. Of course there are over 500 open bug reports right now (325 as of November 2023), and while we aren’t trying to get that number to 0 before the end of the beta (we’d all be waiting for years), we certainly still need to solve some of the more frustrating ones. Luckily many of the opened ones are described by the list above and will be able to be closed as those items are resolved. As to generally how much of that is essential to complete before the end of the beta, as you can see many of the items above are connected at least a bit by these pathfinder issues, and so I think it’s safe to consider that a must. At the very least, the system needs to be made robust enough for the windywolves to return!

The last several months

So as you can see we certainly still have some work, contemplation and even some learning to do before the end of the beta. However over the last few months, we have made much much more progress than we have things left to do. Since the changelog exists I’m not going to list all of the changes here, but instead will provide a little narrative of the last few months from a behind the scenes prospective so as to make our current situation more clear.

We’ll start right at the launch of public beta. We had prepared well for this bit, so that stress levels among the staff were relatively low. I think all of us were very much anticipating anything going wrong and were all ready to jump in. We certainly had a couple surprises in store, that’s for sure.

I was trying to update the beta server with some final change shortly before the launch. So it was an hour before launch (maybe a bit less), I had just finished compiling that server and ran the updater… the new server didn’t start! Being this close to launch I had to fight pretty hard to stay calm here. Though it was only the private beta server and not the public one, Remember that without the private beta server, no development can happen on the public beta either because it doesn’t include the ability to modify scripts/maps/configuration etc (that all happens on the private server before being pushed to the public one). Every second that server wasn’t running, the other staff members weren’t able to continue making final launch preparations! After a moment to calm down, I remembered that I’d compiled the beta server in release mode, it worked on the public beta server so why not the private beta? Well, I tried in debug mode instead, and thank goodness it worked. I’ve come up with some theories as to why the private beta server won’t run in release mode, but wow that was a sort of unfortunate time to learn that an hour before the launch!

I’d just finished uploading the final version of the game to stw.samtupy.com and we were just continuing our work making sure that the public beta server was totally ready. Luckily a lot of this work involved final secondary testing and a few tweaks. Specifically a couple hurtles that the staff was trying to work on was that we realized that we accidentally neglected to link the foreman’s basement map, so a staff member was scrambling to set up that map connection and test it last minute. Another worldmaker was busy making sure that the script which transports everyone to the mainland was working. Also the lions were so close to being ready to add to the game, another staff member decided to spend the time seeing if they could finish pounding those out before the release, or at least make it so that they could be implemented as soon as possible afterwords. They did this until launch preparations got intense before switching to other more immediately important tasks related to the launch. This is just a small sampling of what some of the staff was doing right before the launch. Imagine our surprise though when in the midst of us just doing our thing, a couple of players started to come online before the countdown timer expired! It seems I should have uploaded the file with a random filename and renamed it exactly when the countdown timer expired, but what with everything going on it just didn’t cross anybody’s mind. I think what happened is that people had seen fragments of the new website at times when the beta server was offline, and someone had the idea of saving the download link so that they could try it before the launch actually took place. In any event the link was soon posted to discord over 30 minutes before the countdown timer expired, and a bunch of people started connecting early! In the end though, this actually turned out to be quite hilarious because rather than stressing for another 30 or 40 minutes about whether everything was functional, a bunch of players started logging in which proved that indeed enough was at least working for everyone to have fun, causing the release of any unneeded tension and the beginning of the first public out of character conversation on stw in 3 months! Of course we were still finishing up a couple things during this time, for example I was making sure that the website would come online 1 minute before the countdown timer expired, but generally things were running at this point. Well, for a few minutes. Then, luckily still before the official launch countdown timer expired, we started getting a massive lag spike every minute or so that would last for like 20 seconds, causing people to disconnect sometimes. C’mon already? It’s only been a few minutes! Luckily though, the easy access to the profiler we’d added in the statistics menu mentioned in previous posts lead us to the answer extremely quickly. There was some really old code from 2017 or something that was trying to perform IP geolocation for the purpose of displaying the antiquated world map on stw’s website for those who had not opted out of that feature. The geolocation was performing a blocking http request to a server that no longer exists! Since then we’ve established methods to perform multithreaded internet requests (used for emailing users about their accounts and more), but as the map was never fixed, that code was never disabled. Since the code only performs geolocation when needed, it never executed on the private beta server! So after the lag had existed for only 10 minutes or so, a simple server update that disabled the geolocation code was released and the brutal lag spikes stopped. Yet another reason that some players ended up joining before the timer expired! Pretty quickly worldmakers started fixing minor things mentioned by the players, but soon after that we ran into a much larger problem.

Someone sent us an interesting report saying that they created their account for the first time, and that account had characters on it! And then another player sent us a similar report, then another, and another, and they just continued. Clearly some people were able to create accounts, but the system was failing miserably in other cases. Months later I would finally figure out the true cause of this, but at that time with everything going on, I had to quickly implement a hacky solution that involved an alternate method of generating account IDs. These issues with the account db were the first instance of a problem that we couldn’t end public beta without fixing. The same day as the launch I also had to allow worldmakers to compile shared scripts in a debug mode that would give more information when errors occurred. There were other minor hiccups, but we made it through the first day, and the game was online! The worldmakers continued responding to bug reports that were coming up.

The next few days were just various random bug fixing, anything from making account dialogs not freeze to trying to fix up some arenas to making online and offline messages not spam the all buffer. It didn’t take very long though for the number of bug reports to get pretty overwhelming, causing us to shut down the beta server for a little over a day while all the staff fixed as many of them as possible. This would happen once more a week or 2 after, but the game became more and more stable each time. The second shutdown period lasted a bit longer, but this time many of the bigger changes got documented in the changelog for 05/28.

The other thing that happened a week or so after the launch of the beta was the return of the stw store. Originally I wasn’t even going to enable the store during public beta at all, but when the realization came to me that I could do so without anybody losing anything and even giving players an opportunity to spend their credits twice (once now and once after the beta), it became clear that I needed to enable the store especially since I didn’t even know how long the beta would last and aside from the fact that stw is currently my financial life support, we need to be able to afford the server! I want to deeply thank everyone who has used the store (supporting me and the game) even while stw is in such a beta state, as both would be in trouble if it wasn’t for your generosity and trust in our ability to transition out of the beta without the loss of your purchases. Genuinely, thank you.

If you want to learn more about what happened in the rest of the month of May, you can read the recent changes topic or changelog.txt where all of the specific changes are mentioned. In my memory, it’s just a flurry of bug fixing and coding and getting things to work that I need to look in commit history logs to remember the details of. Combined with the fact that I needed to travel in early June, I ended up taking a break for a week or 2 after a couple months of intense coding both before and after the launch of the beta. During this break it was becoming quite clear what the next largest issue was, which was our poor keyboard library. It works actually pretty good if you just use a US keyboard layout, mostly anyway? especially with other keyboard layouts though, the quality of the library I had chosen for human input handling was much lower than what would be acceptable for stw. People were having any number of problems from not being able to type accented characters to not being able to open the ooc chat to the numpad not working and more. It became pretty clear that I needed to start looking for alternatives. I finally looked into a library who’s name I’d heard a lot in my life (sdl), and quickly understood why that library was so popular. So after maybe 2 weeks at most of recharging in early June, I began work on completely redoing nvgt’s keyboard/mouse implementation to use SDL2. Also around this time I’d finally learned how UTF8 actually works internally, which meant that I could finally write functions to iterate over UTF8 characters. This meant I could make stw’s chats support UTF8! This went right in hand with SDL2, which already used UTF8 strings. So in late June, a new client update was released which included SDL2! This did 2 or 3 things. First it fixed everyone’s issues with not being able to press certain keys within the game, and everyone could also type accented characters in chat/generall stopped having issues with game input. It also completely destroyed the jaws keyhook and caused it to become pretty much defunct. Yay! I spent the very end of June improving that as well as some other smaller issues. It was also in late June/early July that I began wanting to do a blog post and even started one, however what with the entropy of the beta and everything else going on both in-game and in my personal life, my attempt never got finished and was soon outdated. The same thing happened to an email I started writing to the Angelscript developer, though at least that’s not outdated now.

July opened with me continuing to improve the Jaws keyhook, followed by continuing to fix random bugs and small issues. In particular, converting elements of the game to UTF8 was causing a bunch of problems with everything from the character database to the language translations and we had to start cleaning that up. Mostly though I spent a lot of July cleaning up the NVGT engine after the switch to SDL2, some of those changes can be seen in the changelog for 07/25. They included making NVDA sapi work, updating enet, switching a couple other libraries in NVGT, improvements with exception handling etc. A good portion of this time was spent researching libraries. Some decisions I’m trying to make with NVGT dependencies are tricky and require a lot of reading/learning. At some point though, one of my fixes actually broke the website logins for a bit, at one point a few people were even able to crash the game just by logging into the website! I was fixinng that around the same time I was fixing a bad bug that would cause players to get stuck online after leaving arenas as well as a couple other things. Another huge reason I started cleaning up NVGT was because of a few large issues that were coming up. First, stw’s packet handling. Survive the Wild can handle lots of different messages from game clients (telling your character to walk, pick up an item, send a chat etc). The code that handled these packets was very old, all the way back to 2015 or earlier. It was becoming clear that this code needed a serious revamp as it was now a source of lag, something we are trying to get rid of. I wanted to see if I could add components to NVGT itself to help me with this process (such as binary serialization in c++ needed for object saving anyway), and thus started a lot of research into various serialization libraries, followed by other general libraries that I wanted to consider the use of in place of older or less known components.

So honestly, I can’t call August a particularly productive month. Certainly things got done, but I’d be a lier if I said I wasn’t having issues staying on task by this point. I’ve had several things I’ve wanted to do for months since the old server crash such as bringing back anyaudio/awesometech, rewriting constant motion etc and constantly putting every single one of those projects off this long has started to cause me to get a bit antsy, especially with more and more issues on the beta stacking up that I wasn’t entirely sure yet how to fix from the pathfinder to the account system. In particular, this issue with rewriting the packet handler was still on my mind because of how daunting it appeared to be, especially since it made me not want to add more packets to handle in the mean time since it would mean more code to convert later. Anyway, on August first I added a find dialog to the audio form so that administrators could search through tickets easier as well as any other list/textbox being searchable, but it wasn’t released for quite a while after that on account of some other changes I wanted to finish. I also started trying to fix the issues with the keyboard and the bike at this point, but half way through doing that, I realized that it would be enough work that I may as well rewrite the keyconfig system from scratch anyway and fix loads of issues in the process. So it went from something in progress to something on the todo list, though I’m happy to say that the new key config system has had lots of work put into it since that time. Other work in August included some tweaks to the pathfinder, other small improvements to the audio form and most importantly the resolution of the dreaded “connected from another device” bug.

Where as August wasn’t exactly the month I am the most proud of, September on the other hand was completely the opposite as I was getting tired of my low level of productivity. The fact that I had a mental breakthrough regarding redoing the packet communication logic also helped a great deal. The first couple days of September were just small random fixes, such as removing unneeded slash commands, adding a couple of shared functions for worldmakers etc. But on September 5th, I spent several hours redoing the packet communication on the server, focusing only on improving the speed of it rather than getting lost in ideas of rewriting it from near scratch. This change in mindset brought the task down from a quite depressingly daunting one that I wasn’t sure how I was going to complete to one that could be managed in a day of work. I’m glad to say it was a success! The day after that, I realized that packets on the server had been getting handled out of order for several weeks, causing all sorts of annoying bugs such as people remaining in the air after jumping. Fixing that was a huge relief and caused loads of very random and hard to reproduce bugs to just disappear. This was a very good thing because I think everyone reading this can agree that hope is a basic needed fuel to move forward, and the amount of totally random and completely nonsensical bugs that we had no idea how to fix created by packets being handled out of order was sucking that away quite fast indeed. It was awesome to fix one little defect in a core system that ultimately resolved so many confusing problems! The following couple days, me and another Master just went crazy and managed somehow to resolve over 100 bug reports in a very short time! Though the tiny ones didn’t make it into the changelog, you can see the evidence of this insane bug fix spree in the changelogs for 09/07 and 09/08, with even more throughout all of early September. Then in the middle of the month, I began working on another system we couldn’t finish the beta without completing, and that is the ability to instantly backup and restore characters. Of course a system has existed since April that backs up the entire server to an off-site location, and that works great. However as mentioned in previous posts, admins can’t use that system to restore character backups. Restoring a single file from a point in time using these backups takes at least a few minutes while several compressed and encrypted archives are downloaded, decrypted and evaluated to spit out exactly the file we want from a given date. The system is meant to recover from a complete server failure, not a bugged player death. As the number of tickets regarding inventory restores continued to rise, it became clear that a backup/restore system intended for staff was now a high priority. Much of the work happened on September 15th, causing admins to spend a good portion of the next day helping a queue of players with lost inventories get their items back. This didn’t mark the completion of the character backup system as admins still couldn’t restore characters that had actually been deleted (they could only restore an existing character to a previous point in time), but it was loads of progress leaving not much left to do in that area. To add even more to the heap of accomplishments for September, I also figured out most of the previously mentioned account db issues which were also another massive barrier to ending the beta! During system conversion I accidentally fumbled a very important line of code many months ago which broke email verification, and allowed players to connect to their accounts without verifying their email addresses! Such accounts would then get deleted when the server restarted, breaking the system in several subtle ways. This may seem like a hilariously ridiculous mistake, and I almost agree. The only reason I defend myself at all here is that I was bound to miss at least something in the midst of converting such a large portion of code to use SQLite which is quite certainly when this issue was introduced. So a beating to my pride, a lesson about being extra careful when working on such sensitive code and a little bit of time later, the issues there were resolved and we are now just waiting to make sure there are no further cases where I made some other sort of similar mistake. Fwiw, another huge relief! A large number of bug/lag fixes continued all throughout the rest of September.

I continued fixing bugs into early October, though we’re slowly beginning to enter present territory in regards to the state of the game. A worldmaker finished the Premium gift robot around this time as well. This was about the time that we had another amazing breakthrough regarding grenades that would endlessly fall in destroyed arena maps. To a large extent, we fixed that problem. However as previously noted, some version of it still remains which requires attention. When the premium gift robot got added, it also pushed some of the rotation and math issues we’re currently having to the front again as people kept having to log out and in to use it due to coordinate rounding issues. Since players already log out/in to round their coordinates and fix this issue a worldmaker finally just made the coordinates automatically round upon using the robot, but it’s not the correct long-term solution and just reveals issues in certain distance calculation functions in the core of the object system. More and more people asked about enabling wolves again, pushing the pathfinder concerns forward as well. As mid-October neared, a couple things in my personal life intensified on top of me preparing to travel again, so I didn’t do that much stw stuff during the 2 middle weeks of the month. After traveling though and getting some personal things taken care of, I was back at it by late October, where I finished the character backup system so that staff could now restore deleted characters as well as existing ones from previous points in time. I also started trying to work on new distance calculation functions for rotated boxes, but I still have more to learn here, hopefully I can find a better source than chat gpt. 🙁 I also started working on something more in my element, which was the new key config layer. I’ve now written more code for it than exists in the old system at the time of this post, though there is still more work to do. This keyconfig will be much better, including the ability to change keyboard configurations within the game itself!

In early November I added social antispam and fixed a few other bugs, but generally we’ve now reached the present state of development, finally. I’ll account for December through March in the next section, though sadly it’s not entirely positive and has more to do with my personal life than stw. Regardless, that had been a long few months of development! As of late November 2023, we had 335 opened bug reports, and 1742 closed/duplicate/resolved. My plan then was to finish work on the new key config system, which when complete would finally lead to the resolution of the bike bugs and more. As you can see we had made some amazing progress over the later half of 2023, many of the hurtles that had come up that were delaying the end of the beta got jumped during that time and are now behind us, leaving behind those mentioned in the previous section. Hopefully the previous 2 sections in this post have given you a pretty good idea on where things stand as far as development and what lead up to them! Sadly as the transition into December took place, I unfortunately started dealing with a much more brutal issue, which was some severely bad burnout caused by a year that was much more rough than initially expected, this is a hurtle I am still trying to jump.

My personal life/health/burnout

Several people have messaged me asking how I’m doing personally aside from game development (which is really kind and appreciated), and now especially since my mental state has had a lot to do with why I’ve gone silent starting mid December and why stw development has ground to a halt over the last few months, it seems prudent to just post about it on the blog. In short, everything about stw from the server crash in February to the failing pathfinder/npcs and server crashes started to catch up with me around early December, and it only got worse as December progressed into January. Instead of trying to freshly describe how I was feeling during that time months later, I’ll instead paste a couple of messages I sent during that time for much more authenticity. In mid December a master noted that things had been quiet lately, and my response to the masters at that time, copied verbatim below, sums up many of my feelings back then pretty well:

Yeah they have. I’ve been slowly working on the blog post, it’s over 65k, been working on nvgt as well, but unfortunately I have been struggling lately staying motivated in regards to stw which really sucks because of the time constraint of public beta. Just a burnout phase that I’m waiting for the expiration of I think, came on so suddally I didn’t even detect it as burnout at first but just thought I was overwhelmed or stressed, but then I noticed the contrast of being able to work on literally any other project just fine and then completely exploding if even the tiniest thing goes wrong with stw dev. What sucks is it’s exactly the public beta state causing the burnout, because things ended up mentally aranged at the start of public beta such that I didn’t want to do any other projects until pb was over, that’s turning out to be thoroughly unhealthy. So yeah that’s why I haven’t really been around much, I’m compromising by working on nvgt so that it’s at least a little related to stw, and hope to get my stw drive back soon (probably will happen when we shut the server down next time for bugfixing).

Around the same time, I sent this message to the public English discord chat as people continued to ask about the very same blog post you are finally reading now:

The blog post is still in progress (over 65k). I do apologize that this is taking a while, and, not wanting to be dishonest, will be upfront and say that some of the slowness is certainly being caused by a burnout phase which I am having a difficult time controlling. It’s bad enough that the moment I do something that isn’t stw related I feel ok and more or less normal, even if that is working on nvgt and/or something challenging on it’s own. Yesterday though a small user error with git caused me to lose only like 10 lines of stw code that I then needed to rewrite, and that simple mistake caused me to angraly fly off the handle in childish ways that I shouldn’t admit here. Though I’ve been subconciously aware of it for a while, yesterday’s situation illistrated that this is bad enough that I shouldn’t mind bothering whether I keep it to myself. I am working on the blog post to the extent that I am able without risking my mental health any more thoroughly, and genuinely thank you all for your patients. It’s been a tough and unexpected year regarding stw, and currently it is taking a tol which is making it difficult to work on stw at full efficiency. Again I apologize for the slowness in publishing this post.

By early January the situation had gotten dire enough for me to send the following message in the English discord:

So just to stay at least a little communicative here. The bad news is that I have had to more or less drop focus on Survive the Wild for the last couple weeks completely for mental health reasons, to the point where I next to disconnected from the internet for a few days. In fact at points it seems I am only a hair line away from possibly shutting down the store then in 2 or 3 weeks shutting down the beta so as to properly recharge and get to a place where I can develop stw again without the beta being online as a distraction. I don’t want to do that, it seems that it may be a possibility though. See, I’ve worked myself into an unfortunate mental corner that I’m having a hard time getting out of. I want to communicate in the form of a blog post and I want to open staff application forms, but I also want to fix the game which requires loads of research not to mention coding to do correctly. So I’m stuck in this weird spot where if I want to work on stw, rather than actually fixing the game, I need to use any small amount of restored energy to either work on the blog post or the staff application forms instead of bug reports and large problems, but as for the blog post I have been so burnt out lately that it is rare when I am able to write with confidence or a positive aditude at this point. This doesn’t even touch on the fact that I have other projects I’d like to work on that I’ve abandoned all year for stw such as anyaudio, rewriting constant motion, getting nvgt into a state where I can open source it, properly learning reaper so I can be a better sound designer etc. Due to an unfortunate mental planning error early this year, I convinced myself that it would be a good thing to work on all these projects after stw was out of public beta. This turned out to be a huge mistake because now I’ll get unreasonably frustrated at stw for holding me back from finishing other projects, and/or unreasonably frustrated at other projects for distracting me from finishing the stw beta. This also doesn’t touch on my personal life, where something entirely unrelated to technology has been taking believe it or not maybe even more mental energy than all of this stuff with stw has been draining me of, and I still haven’t figured out how to eat 3 solid meals a day. Also there was a change in the standard for code signing certificates this year, meaning that I’ll likely need to purchase a $250 physical USB key combined with already needing to renew my certificate before I can release signed client updates again. Very much thanks to the players the funding is not a problem, the entire thing is just yet another roadblock. At the beginning of 2023 after the server crashed I was really hopeful for what the end of the year would look like, and that was another mental mistake I made earlier on this year, as of course at the beginning of 2023, I did not expect that the public beta would still be running in 2024! All of this stuff has caused me to at times become quite seriously depressed, and thus I’ve had to step away from most things in life over the last couple weeks simply to let my brain rest from pretty much everything. I am mostly still doing that, but at least wanted to provide this update. One thing that makes me feel really bad is if people have a perception that I am working while I’m resting, and conversely it is quite frustrating when people think that I’m resting or slacking off when I’m actually working harder than I have in a long time. The only way to fix that is communication! So for the last couple weeks, and likely for the next little while, I must continue to rest and slowly sort out the mental mess I’ve managed to get into this time. I think it will be obvious when this period ends for me, such as by the publishing of the blog post / a giant spike in bug fixes / updates etc. I still look forward to the future where lord willing the game will properly flourish the way all of us intend. As always, I thank you all for your pacients.

As far as stw goes, that is more or less where I’ve been stuck since the time of that message. The final thing that allowed me to relax my stw development was a decision regarding item storage and retention that I will talk about in another section further along in this post. Putting it simply, 2023 was quite a different year than I expected. We’d hoped to release an update soon, and then the server’s solid state drive crashed. I hoped to fix that in weeks, and though stw was up in months instead I still haven’t recovered from the crash as far as other projects. I’d over confidently hoped to be out of beta within weeks or a couple of months such that I thought we could do it fast enough for this lack of item storage issue to not matter, and we’re still not out of beta. Days after the public beta launched, some blind people got access to things they shouldn’t have and within months had attained my full social security number which they attempted to open credit cards and bank accounts in my name with since I would not fall to their blackmail and send them the redspot source code or some money, this was obviously not a good backdrop to a good coding mindset (they even tried calling me with an unknown number and overhearing my voiceover read a 6 digit OTP to my bank account which thank god did not work). The amount of shattered hopes, the stw issues that trickled in at just the right rate to keep me down, the realization that I’d still messed up when I thought my plans to be good enough, the fact that those very plans I messed up on stopped me from working on any of my other projects, changes to my physical living situation multiple times in one year, the identity theft, some difficult parts involved in a religious faith development period (which I am still extremely grateful for nevertheless), and more simply not always eating well had left me in a completely crippled mental state by the end of 2023. That year was honestly super rough and I pray this one will continue to be better!

I haven’t been doing nothing since taking a break from stw development, for example I attained the ssl code signing certificate mentioned in that last quote and got that working, I’ve been working hard on the nonvisual gaming toolkit (NVGT) which has already lead to bugfixes in the next stw client update, I have been finally working on some of my other projects again without so much shame about not working on stw instead, and have generally been recovering from this burnout in as many ways as I can so that when I am ready, I can attack the remaining issues in the stw beta with ferocity and finally get us out of this unfortunate mess. I’m happy to say that I’ve experienced some extremely joyful moments during this time. It seems that one of my niches is quickly becoming getting code running on other platforms, and so though it will be a while before these are released (I want to fix the game before sharing it much further), I’m extraordinarily happy to say that I’ve gotten NVGT to compile completely natively on both Linux and on an M2 mac mini, and experienced the joy of pressing command+o on the Survive the Wild.app bundle on MacOS and watching it run great with Voiceover support and everything! I even got stw to run natively on an hp intel netbook a relative gave me years ago which I’d installed Debian Linux onto, which made me just as happy. Again these clients for other platforms won’t release for a while, but it is officially coming as I’ve already gotten stw to run on these operating systems completely natively without a single virtualization layer! This was super fun and even involved me having to learn a bit of arm64 assembly so that I could make Angelscript support calling native functions on arm macs, which ended up becoming my first code contribution outside of the blind community in my life! Someone may be saying “wait Sam you just said you are taking an stw development break and now you’re getting it to run on other platforms, what kind of break is that?” This question is a great transition into the next thing I want to talk about which is NVGT (the engine that supports Survive the Wild in place of BGT).

Yes, I can indeed get Survive the Wild to run on other platforms without actually working on Survive the Wild. This is because the game is being run using my rewrite of BGT called NVGT, and so it is NVGT which I am getting to run on other platforms. The consequence of getting NVGT running on MacOS is that quite simply stw will then run on MacOS as well! The reason I want to talk about NVGT though isn’t because of getting stw to run on other platforms, but because I really, really want to release NVGT open source. There are so many reasons for this from the fact that members of the community who are programmers would actually be able to fix bugs in stw that pertain to the engine and not stw’s direct code, to the fact that games that have been stuck in 32 bit windows only BGT could suddenly run in an improves state and on whatever operating systems their developers are interested in supporting! This presents a problem though, in that there is a lot of work to do before NVGT can open source such as code cleanup, removal of sensitive components such as encryption keys, documentation and branding (also known as creating a webpage for this thing). Trying to figure out how this relates to stw is difficult. On one hand it would be nice to get us out of public beta as soon as possible, and on the other hand releasing nvgt open source first would mean that any number of bugs could be fixed in nvgt and by extension stw while I am working on fixing stw’s npcs. Trying to get stw released first would certainly delay the release of nvgt and by extension any community bugfixing help not to mention the continued withholding of an engine that could be a potential help to anyone wishing to move on from bgt, and releasing nvgt before I fix up stw could potentially cause me to get busier than expected due to initial release feedback/questions which could cause stw’s beta to end even later than it could have. Honestly it’s a tough decision! I can imagine some readers thinking something like “Bro what are you thinking you need to get stw out of beta first we want to play and keep our items again!” That’s more than understandable, and in response to such a question I can only ask you to keep reading, as I will discuss this very thing below.

Tiny beginnings

Wow so that was a lot to read, and we’re still not done! Howabout a short reading (erm I mean potentially pressing the down arrow key) break. I thought you guys might enjoy this little recording that I made on 08/13/2014 demonstrating the progress I’d made on this stw thing that I started like a week ago. There’s not much to it, one subsection of readers may find it quite boring as certainly there is not much that happens in this recording at all, stw had no inventory and you couldn’t even jump yet, I highly doubt the chat was even implemented. But for the curious type who wants to know what stw sounded like after only 5 days of existing (closer to 4 as this recording was saved at 12:12 AM on the 13th), I hope you get some enjoyment out of this relatively ancient audio file. I do apologize, when I was 12 I apparently had some fascination with saving recordings in a low bitrate for no particular reason that I can remember, anyway as a result I do apologize for the low quality of the following recording.

A change to the end of beta plan

Now, lets talk about a decision me and the masters came to in mid January regarding what happens to items at the end of public beta as hinted at above. Both for me as the developer and for the players, I think it’s safe to say that one of the largest issues of contention with stw right now, one of the largest reasons that we all want this beta to end as soon as possible is because of the declaration regarding how all items attained during the beta will be lost at it’s end. Due to the somewhat unexpected nature of my burnout in regards to developing the game, it seems clear that the logical step forward is to very slowly, very carefully and with much thoughtfulness, alter the end of beta plan a bit to work around this problem, and to provide players with the opportunity to save at least some of their progress beyond credits. I do apologize for this partial plan retraction, indeed I’ve noted the failure of overconfidence above which lead to this plan regarding item storage, we didn’t expect the beta to last so long that this would be a problem! As it is though, the situation is what it is and we must react accordingly. As such, the following is what we’ve come up with.

First and most importantly, this will be a choice particularly for anybody who already has a previous inventory. A long time player will be able to choose between their Jan 11 inventories or a filtered version of their current ones, and a new player will get to choose whether to start from scratch or to keep a filtered version of their current inventory. A filtered version you ask? Yes, so basically me and the staff will get together and create what we can call a baseline inventory. The easiest form of explanation is that this inventory will contain the maximum quantity of every in-game item that the admins are OK with restoring. Upon the actual restore, anyone who decides to partake will have their inventory filtered by this baseline inventory. Say we decide that it’s OK for up to 5 swords to be restored per player, if a player has 3 swords they will get 3, if they have no swords they’ll get 0, and if they have 147 swords they will get 5.

Since we still plan to restore raw credits as previously stated, paid items will not be included in this filtered inventory E. a player will still need to repurchase death free cards using restored credits as described in the store disclaimer and the MOTD etc. The theory behind this filtered restore is that people likely care more about item functionality in most cases over quantity, in the sense that most players would rather keep one sword to maintain the functionality of a sword rather than having to go hunting for a sword again, even if that means they lose the rest of their swords. As to the exact nature of this filtered inventory and what items it will contain, you can actually feel free to provide feedback here since we still need to create the inventory! You can feel free to comment here or post elsewhere about how much of a certain item you would consider fair to be restored, and within reason, the staff may try to integrate such feedback into the final filtered inventory. Unless an official situation update says otherwise, quest items will not be included in restored inventories due to potential complications with tracking actually completed quests on top of the items that belong to them as well as remaining stw points, of course if we can confidently figure out the logistics here this could change as mentioned. Please keep in mind that there is not yet an option to subscribe to this restore, and when there becomes one we will make sure to make that clear to every player with announcements, MOTD changes, the blog etc.

Me and the staff register the fact that this decision may lead to a bit of harm to the game economy beyond it’s current crippled state, and that’s why we are choosing to try out this filtered inventory method instead of doing full restores, as we feel that some small and recoverable damage to the game’s economy is worth the much more drastic increase in player satisfaction. In the end, the hope is that the revelation that not all items will be lost will not only provide for a better player experience but will also provide the remaining time needed for me to recover and then for us to get this npc fixing underway. Hopefully this explains why I can even consider the prospect of getting nvgt out there before improving stw, should we go that route. I’d be curious to hear players opinions on the stw vs. nvgt decision as well after hearing the end of beta plan change.

Frequently asked questions

We’re finally nearing the end of this post folks! Since we’re pretty much done with any main announcements, here are the answers to some of our most frequently received questions in no particular order, or at least questions that I know players want answers to. Perhaps you won’t be interested in the answers to some of these as they can get quite technical or specific at times, and as such they are separated by heading for your scrolling convenience.

Why specifically are wolves disabled in the windy wolf forest?

Generally, it’s the pathfinder issues mentioned above. In this case specifically though, a couple things are going wrong. First is just a general lag, basically the wolves aren’t dealing well with the climb in and out of wolf valley. They can manage it, but it’s a heavy load on the server. We need to establish an alternative method of movement for such cases, or I need to learn how to use the pathfinder correctly if I am not currently. Second, the wolves somehow keep ending up in the hidden lake, where they should not go. We’ve attempted placing zones there that should stop this from happening, but apparently these are malfunctioning or not being checked in all possible pathfinding cases. What with everything that’s been going on in the last while, we’ve only been able to dedicate so much time to it.

What’s up with relay servers?

Whether requiring a relay server to connect to the game or just because one may increase connection speed, many people have understandably wondered what happened to these and whether they will return after public beta. The answer to the most important question is that yes, relay servers will of course return. As to why they aren’t ready yet though? To say the least, it’s complicated. For those who are interested in the details, I’ll try to explain.

In the past, a relay server was just a bgt application that ran an enet server and created new connections to the real stw server whenever someone connected to the server the relay application was hosting. The relay would encode and send along the true originating IP address of the person connecting to the relay. This system worked well for a first attempt, but it had several issues. It was a little slow, made voice chat more unreliable for those using the relay, needed to be run under wine for linux servers etc. Generally it just wasn’t ideal.

The result is that I’ve spent quite a bit of time over these last few months trying to answer the question of how do I establish a good relay server application and/or a good relay network. I’ve done plenty of random research as I’ve learned linux, trying to decide whether I should rewrite a new relay application in c and distribute that, whether I should consider raw UDP tunneling solutions which would remove some layers of data parsing from the relay application because enet wouldn’t need to parse then reconstruct the packets, whether I should try to host most relay servers within one vps company or how freely I should distribute any rewritten relay application etc. The biggest problem with a raw UDP tunnel is that there is no easy way to bundle the true source IP address of the connection to the stw server. For administrative reasons, if someone connects to the stw server, we must be able to gather the originating IP address of that connection. If a raw UDP tunnel is used though, everybody connecting to the stw server would always appear with the IP address of the computer hosting the UDP tunnel. I’ve looked into injecting a UDP packet into the communication that would contain the source IP address, but the effort in learning that makes me think it’s best to just rewrite my own application anyway. I’ve looked into vpn solutions on linux where the server at stw.samtupy.com would host a vpn that relay servers would all connect to, which would send the data in an encoded stream that would include the source IP address of any connection. Again though this seems very difficult to learn considering that I already have the experience to write my own app.

Well there’s a weeks worth of time spent researching network tunneling and vpn stuff down the drain I guess, I suppose I’ll write my own relay app that can be compiled on windows or linux. There were 2 reasons I didn’t want to do this. First as mentioned above this tended to make voice chat for those using relays unstable, and second, the relay servers didn’t handle it well if the main server restarted. This is because if the main server went offline, the relay servers would stay online. So the system that is supposed to automatically reconnect you to the game when the server comes online after a restart was very defunct from the context of a relay server. This is because the enet library or for all I know something lower level in the UDP protocol doesn’t allow me to reject a connect request. So if the stw server went off for a restart, the clients who were trying to automatically reconnect would receive a successful reconnect event from the relay but then since the main server wasn’t online yet, the relay couldn’t establish a bridge and the connection would fail. From the relay server’s end, I seemingly had no way to delay the handling of a connect event from a client until the bridge to the main server was fully established. Luckily there are several ways I’ve come up with to get around this issue, so hopefully after quite a lot of not so helpful research and some much more helpful brainstorming, I’ve got a solution to most of the problems.

However, there is another thing to consider for relay applications, and that is the audio bank. This is the streaming of music and sounds from the server to the various clients. I’m not sure at this time whether it’s a good idea to have relays act as direct passthroughs of this audio data. Just as a start the server hardly seems to be able to keep up streaming audio data to clients sometimes, this is why we are getting reports of choppy or broken music on ocasion. As such, I need to establish another method by which this music can be streamed, hopefully one that is good enough to also allow the seemless streaming of ambience. Whatever solution I come up with, of course, needs to work with the relay network. So in that regard, I still have more to consider. However yes, relay servers will eventually return (though almost certainly after public beta ends). Another thing I don’t want to do is to cause confusion by distributing a relay application for public beta and then again for the main game right after. As such both to give me time to finish figuring all this out and so as to only need to distribute one application and/or set of configuration instructions, we’re going to wait until after public beta to bring relays back. They will certainly be back though.

Will there be a full set of strings available for translating the game?

In short, yes. I intend to make several improvements to the translation system, and have only not done so yet because all of the other things being worked on have been taking most of my energy. Still though, I do have a plan for the translation system which I will explain here.

Most of the work regarding fetching the strings that need to be translated has already been done by people who have already created translations. I’ve already asked an official translator if I can use their data for translation strings and they said yes, but that they want to organize it first. Having not heard from that person in many months, I will soon ask a different official translator. Once I have derived a string library from an existing translation, I will then organize it myself a little more, making sure that the engine is being used to it’s best efficiency. After that though, I’d like to do a little more than just publishing a file for download. Instead, I want to actually incorporate the translation strings into the game interface. When a user creates a new translation, they’ll be able to choose if they’d like for it to synchronize with the official strings list. If this is done, new strings that are added to the official list will automatically appear in their translation awaiting a language editor to actually provide the translated text. If we fix a spelling error in a string that already exists in the official strings list, all translations that have chosen to follow it will automatically have that string updated to reflect the official strings list, thus translators will no longer be scrambling to fix spelling errors. As I imagine this post has shown we do have a lot on our plates right now and so I’m not entirely sure when this will happen, but anyway that’s my plan for improving the abilities of translators to keep up with game changes and to allow new translators to start from scratch. The reason that all of this is so hard is because when I first made stw when I was a preteen, I didn’t really know what I was doing as far as an internationalization system. I didn’t understand the significance of formatting strings with numeric or type specifiers, instead I always built up the strings in the code. Furthermore strings ended up everywhere, from the code that only I have access to, to the maps, to the scripts that the worldmakers work on, to the game’s configuration data and more. It would be a massive undertaking to say the least to change these strings such that they could work with a more standardized translation system such as gettext.

What’s going on with say tts?

Originally, say tts (shift+y) was disabled due to instabilities in the sapi system mostly revolving around the NVDA Sapi software, which is apparently a sapi5 voice that causes text spoken through it to be piped to the NVDA screen reader. Many players had set their default sapi voice to one that outputted no sound, and since I’d never heard of this phenomenon in order to patch that edge case in the code, such a player would experience instant game crashes if someone near them used the say tts system. Not knowing the cause of the crashes at the time, we disabled the system. There were a couple of other reasons for this as well, namely that we wanted to replace the system with one that employs cloud tts, and also the code for the say tts system is very old (dating back to 2015 or earlier), and regardless needs some serious reworking. I did end up resolving the NVDA sapi based crash that caused us to disable the system, and now I’m left with a wee bit of indecision. Do I want to reenable the old antiquated system for now and change it later? Do I want to support both SAPI and cloud tts? How high of a priority should this system be? These are the questions that I’m wrestling with regarding say tts.

So what’s so special about this cloud tts idea anyway / what even is it? The idea is to use tts engines such as Azure cognitive speech services and Google cloud tts instead of SAPI for all character generated speech. We are already planning to use this system for human npcs, or in any other situation where in-game speech is needed. Allowing players to use this system has a couple advantages. The cloud tts is available in loads of languages, so in the future we can have automatic translations of say tts for people who aren’t able to speak the language that the text was written in. It would be the system for conversing with an npc easier to implement, as I’d be using only one speech system. Players would also be able to choose among various voices to speak with Vs. the sapi voices that are installed in a users system. However I am still very much on the fense about this because though players will be able to use the system for free, there is still a cost to it. Synthesizing speech in the cloud is not free, and as such beyond a certain threshold of usage (a reasonable one though), I’d have to start charging a tiny bit for the usage of say tts. I can already imagine some raised eyebrows here so let me stop and explain. With Microsoft Azure tts for example, I get 500000 characters of synthesis a month, and after that, 1000000 characters is $16. Now to be clear, a small-medium book would be under 1000000 characters. I want to allocate each player a limit, say 1000 or 2000 characters. As the player uses say tts, this limit goes down based on the number of characters in their messages. Every few minutes, their limit slowly regenerates. The idea is that within reason, a player can still use say tts for completely free, for example a message such as “hi how are you” is only 14 characters, so a user could send that for free over 100 times without expending their free usage limit. If someone finds that they use the system way way more than expected though, that user would then have the ability to purchase extra say tts characters for a very similar price to what I pay for them E. 100000 characters would be 200 credits at very most, probably closer to 160. So that’s my idea for cloud tts anyway, though it’s not final. As I said, I’m still wrestling with options regarding that old system at this point (though I can say for sure that some version of it will function again).

What’s going on with the treasure tree quest?

This quest has been disabled since the beginning of the beta, and naturally many people are curious about it. We have faced/are facing the following issues with the quest. The first was the entrance, I think we have a solid idea for that worked out though we still need to implement it. The more pressing issue though is the cave beast, what with wanting to redo a bunch of npc related code we’ve been hesitating to add it until that is done, especially since the cave beast may use features in the next iteration of the npc scripts. In short we don’t want to code it twice. More specifically though and I’m already just about saying too much by mentioning this, but this quest has larger implications on the upcoming game world than just a small cave under the island. As such, reenabling this quest involves carefully considering a bunch of future world building factors that I cannot mention here so as to not spoil upcoming elements in the game. As of November 2023 We were hoping to at least have a version of this quest running by the end of the beta as well as the others, and of course we still will if possible. As you can imagine though my unfortunate mental flop mentioned above has thrown a bit of a monkey wrench into this plan, causing me to not want to speak to when these will be back at this time until at least a couple of the barriers mentioned throughout these posts are gone.

What about the Samvil Sewer quest?

This is another broken quest that got backburnered because we initially ran into an issue with it during public beta, and have not managed to fix it since the launch because of other things going on. The obstacle is that in the past, the sewer entrances were made up of only a few lines of map code that encompassed the entire map. With shift+enter no longer being a thing, we need to replace these entrances with proper slides. This involves getting coordinate sets for every house in the city to insert a slide, and we haven’t come up with an easy way to do that yet. I’m sure that soon enough we’ll focus on it for more than an hour at a time and will work out a solution before the end of the beta.

Will there be new maps?

In short, certainly yes, likely not until after the beta ends though. Whenever I get asked whether there will be new maps, I always remind people to view the world map and see just how big the ocean is. STW’s world is 250000 by 250000 tiles on the x and y, only a tiny fraction of which is actually filled in with maps. Over the coming months and years, we hope to fill in stw’s ocean with new continents, islands, seafaring vehicles and more. The ocean is far too big and empty to not add new maps, however at this point in the game’s development, we are still in the stage of fixing existing things before we can build many new ones. For example even after the public beta ends, we plan to seriously rework the inventory system that hasn’t been changed much in several years. We want to make it much more realistic in that you could, for example, take a bite out of an apple, put the half eaten apple in a bag with 4 other altered items, and seamlessly give that bag of junk to another player who could then open the bag and find the half eaten apple. Accomplishing this will take a lot of time, effort and testing, meaning that our small team has to decide between building new maps and working on the inventory system. This among other reasons is why we want to open staff forms sooner rather than later once we can gather the time/energy to train new members of the team and figure out the forms themselves. As soon as either A, we get several competent builders or B, the existing staff runs out of things to fix, there will likely be quite a large explosion of new maps and areas to explore in the game.

Will there be any more downtime periods to fix bugs?

A couple of times now we have taken down the server for the purposes of fixing large numbers of bugs at one time. We haven’t done it for a while, however the decision to do this again in the future is not out of the question and is actually very likely unfortunately. Some people may wonder if there is a specific trigger for this decision, there is not. The closest we can come to one is if we consider the general stress level of the staff team. If we find that for any reason we are not able to continue fixing bugs while maintaining a relatively low level of stress due to the entropy of the game, we will consider taking it down so that we can focus specifically on solving problems and fixing bugs rather than trying to support players at the same time. For example, an admin acting as a worldmaker may be in the middle of fixing a complicated bug, and then a support ticket gets created involving a player who can’t access their account after the last server restart. Now even if the admin doesn’t immediately respond to the ticket, they will certainly be distracted by it and will be passively be thinking about how to help the player even as they continue trying to fix the bug, meaning that both the bug fixing and the player needing help now both get less attention since the staff member is trying to balance activities. If this hypothetical scenario comes to pass several times in a row for example, we know it’s time to start considering a temporary server shutdown. Another thing that can cause this to happen is if we need to perform some maintenance on the public user database. This will happen at some point for example when we fix trusts and mutes to use character IDs instead of names thus fixing the bugs involving character renaming. Indeed I think we are nearing this point again as the bug counts are getting quite high, we do need to do the aforementioned maintenance regarding sql, and generally we need some time to just catch our breath a little in order to provide the best game possible. Another period of downtime will certainly be at the end of public beta. What with the decision to allow players to keep some of their beta progress, the amount of work to prepare the final user database just increased by several hundred percent and I predict that I’ll need at least a couple of weeks to get that done while the game is not running not to mention any other end of beta preparations that need to take place.

What’s the plan for the stat and skills system?

So the stats and afflictions menu mostly just shows stats that everyone has known about for years, and the skills and abilities menu is next to empty. Add to that the combos system is all sorts of defunct right now making the tiny boxing arena a ridiculous parity, what on earth is going on?

The best way to answer this I think is to explain our ending goal for this system. The idea is simple enough, the more you do something the more skill points you get in whatever skill allows you to do that thing in turn allowing you to do that thing better. This way a newbie could start with a pretty low butchery skill, and would likely deal with the annoyances of the current system E. swinging your knife too fast misses the animal or hurts you or whatever. When that happens though, the idea is that you would gain a stat point in the cooking/butchery skill. The more stat points you have in it, the more quickly and accurately you could cook, so that when you had 100 skill points in butchery, you pretty much never end up hurting yourself or missing when butchering an animal. Most ideas for gaining skill points revolve around either very repetitive use of a skill, or failures to use that skill properly in the beginning. For example if you hurt yourself with a knife while cooking an animal, that could be made considerably less annoying by sometimes giving the player a skill point in butchery since the character has probably learned something by accidentally getting hurt in that way.

Some of this next bit you may have figured out from the existing infrastructure already in the game, but I’ll write it in detail here for several reasons, one of which is that maybe if it’s good enough we can copypaste parts of it into an stw help article and cut out some work for the scribes lol! There are 2 types of skills, active and passive ones. You have skill points in both types of skills, up to 100. Active skills are things that you could almost consider a function or action that the user can execute at any time, anything from a punch to a pet call to a skill that uses the items you have drawn to sort through your inventory and tell you possible interact combinations and other ways to use those items. The skill points for active skills as you can imagine control how efficient or good your character is at performing a skill. For example with a punch or other simple form of hand to hand combat, the skill points are just the percentage of the normal power of the blow that should be delt. So if someone had 30 skill points in a certain punch, it would hit with 30% of the maximum power of that punch. The amount of skill points in something like a pet call may control the randomness of that pet call having any effect E. if you have 40 skill points in a skill that can call some small type of animal to you which works a maximum of 50% of the time, it would work for you 20% of the time at that skill point level. Active skills can be anything, maybe for example we’ll add one that lets the player run their hands together to raise their temperature by a couple of degrees in some conditions. A way to think of it is this: A player could theoretically do an endless number of things, but we do not have an endless number of keyboard gestures. Say we did want a player to be able to rub their hands together, it’s pointless to do that right now because why would we waste a keyboard gesture on something like that and similar. We could replace clapping with rubbing hands together but I doubt anyone wants clapping to go, and therein lies the point. With active skills, we can add as many actions (that the player needs to learn) to the game as we choose, and since the player can bind their most used skills to hotkeys while still activating other skills in a menu, we will never run out of gestures while at the same time being able to add as many actions as we desire. The only other note about active skills worth mentioning because it’s not yet added to the game is that you will actually be able to add hotkeys for skills at different power levels. For example if you ever have a reason to throw a punch lighter than you are capable of after you’ve gotten a lot of skill points in that punch, you will be able to register a hotkey that executes the punch at for example 50% of the power that you are capable of launching it. You will be able to register such skill favorites at 10% power increments.

On the other hand, passive skills are things that are always in effect on your character in various aspects, and the skill points in such skills determine to what degree. These skills could include things like swimming which for example could make it take less stamina to swim in deep water, a skill called deep sleep could be another method of improving the speed of sleep by making stats generate faster and loud but indirect sounds less likely to cancel a sleep the higher the skill points. If a player has high skill points in ranged fighting, they can then shoot an arrow farther than otherwise (we can imagine they are pulling the bowstring back further or are skillfully aiming a bit higher etc). You know how difficult it can be to complete some of the advanced fishing based quests, a passive fishing skill would likely make it so that, for example, you could real in the line much faster than otherwise, or maybe you’d detect other tugs on the line that you’d have otherwise missed etc. This next one contradicts English language a bit because we’re gonna talk about how your character is somehow skilled in strength lol, that is the character would have a passive skill called strength that controls the damage that their physical weapons do. It would be better linguistically to say that the player could have a high strength stat instead of a high strength skill, but a much deeper difference between stats and passive skills unfortunately trumps linguistics in this case. I’m sure you’re starting to get the idea here, passive skills are things that effect your character in the background in eventually an endless number of ways, you cannot trigger a passive skill. When the system becomes fully integrated, new characters will likely be able to choose certain starting skills upon character creation that will shape a player’s experience on that character.

So then what’s the difference between a passive skill and a stat you may ask? Certainly it’s a good question. Simply, no sort of skill has any chance of instantly killing you or impeding your character where as a stat does and usually in a pretty broad way. You all know most of these stats already, thirst, hunger, health etc. If these stats reach a certain point, your character will die. There are 2 easy ways to differentiate a stat from a passive skill. If the value in question can kill the player just by being too high or too low, or if the value in question is temporal and will soon drop to 0 and vanish such as poison or sickness, then the value is a stat and not a passive skill.

Though this requires more planning, the basic idea is that in the future when the game world is larger and when many skills both active and passive have been added, the character creation screen will be more complicated. Not only do we want the user to be able to select a spawning location among several that will be described based on a new story that will have been added by that time, but then we want them to select a few strengths and a couple of weaknesses in edition to allocating something like 500 points to skills, most strengths and weaknesses would likely revolve around giving lower or higher default values for certain skills. Though it would be to a very slow extent and easily recoverable from, skill points would decay very slowly if a skill is not used for a long time. For example if you have 80 points in the swimming skill and then don’t swim for weeks, you may have 75 later. No matter, just a little bit of swimming will restore the points to your previously earned value, or in other words it’s far easier to learn something the second time around than it is the first time. You could also lose some skill points if you lose a massive amount of health at once, for example if you lose over 900 hp in a fall, you should probably risk at least a chance of losing a couple of skill points in something due to trauma.

So I know this doesn’t answer every possible question about the stats and skills system, but hopefully it at least gives you a pretty good idea of what our general plan is for the system. Keep in mind that some of the things I have mentioned above are not quite set in stone, they are just the plan as it is now, though it may still require improvement. During the system’s planning phase we came up with several possible passive skills, including intelligence, vision, jump height, food benefit, strength, charisma, work speed, cook speed, fire starter, swimming, storm watcher, fishing, aim, economist, mathematician, and possibly tolerances for various substances, such as nicotine or caffeine. There will be many more, these are just some we’ve come up with already. Well, hopefully this gives you all enough to mull over in regards to stats and skills!

What ever happened to the items I donated a couple years ago?

A couple of years ago, in an attempt to reduce the amount of items on the game, we came up with the idea of allowing players to donate items to the good of the games economy for rewards and many people were kind enough to do it. There haven’t been any rewards yet, was that some sort of scam or failed plan or something?

At this point, it is a perfectly valid question what with the amount of time that has passed since the donation runs. The answer is that no these were never forgotten about, but we don’t want to give out temporal rewards that will become somewhat useless after system changes and/or rewards that will just lead to the same problem again.

In short, the plan has always more or less been the same, but we haven’t gotten to the part of it yet that includes these donation rewards other than for a while to increase the effectiveness of food items for those who had donated (which was meant to be temporary). What we didn’t plan on properly in the beginning, as usual, was the time that necessary systems would take to complete considering other factors of development. There are plans for a crazy building system in stw involving the ability to build structures block by block in any way you choose, this is intended to replace shelters. It only took us a month or 2 to realize some idea of how long this would all take, which is why we pretty much went quiet about donation runs. If we should have done them, we should have not done so at that time but instead closer to the release of the building system. See once the building system is complete and well tested, once we get it good enough so that people are spending a significant portion of time in the game willingly building things, then we can begin the long coming process of slowly converting excesses of player items into both building related objects and skill points. People who have donated items will get many more skill points and building objects than everybody else, and that’s just a start. There will be many unique objects that will be difficult or almost impossible to attain without the currency derived from having donated items. Just a random example, I imagine it would be pretty difficult to get an elevator inside of one of your structures and get it working, normally a player likely couldn’t do that anywhere near the mainland for any number of reasons from lack of power to lack of equipment. Though each option would be extremely limited in number, item donators would be able to choose to spend some of their currency on such items, particularly when it fits into a developing world. Say we decide to fill the fishing village with houses, item donators would be able to purchase one of the houses and attach their name to it, then gaining the ability to modify it’s interior and to some extent the land around it. Another example could be any new stores in villages or towns that need an owner to complete a story line or just to make the area look better. Why not have the owner of a shop or a bar in the game be a dedicated player who often goes on holiday to other parts of the stw world instead of some npc that can only understand a limited number of phrases or something!

In the end though, I really do apologize for how the way this item donation plan was handled and, though we still intend to honestly resolve it as soon as we can, at this point I certainly count the rushing of this plan as yet another item in my growing list of time management errors and will use it as yet another building block towards maturity in this area. If worst comes to absolute worst we will simply reverse the donations, however the reasoning behind not doing this is that now years later it would create an even worse item inflation issue than before which is why it is a last resort if, for example we somehow cannot finish the aforementioned building system because of an unforeseen complication.

Are there any details on the broken bones and sickness systems?

After so many things have gone awry with this beta, I’m not honestly sure we can focus on these systems at this time. Though a future post will provide more updates once we’ve fixed at least a few of our larger problems, for now the only safe thing to say is that unless otherwise noted in the future, these systems will still remain disabled likely past the end of the beta due to bad initial implementation when I was 16 to 18 or so and thus their need for a rewrite/major improvement. I can at least provide a couple of details we know for certain, however.

As for the bones system, we don’t intend to enable it again until different broken bones disable specific functions of ones character rather than this static and annoying stunning effect that makes no sense. The plan is that if you break your hand, you may have trouble using that hand or interacting items. If you break a leg, walking will be difficult and if you break your jaw, you may have a hard time eating or drinking. For anyone who joined the game after this system was disabled, probably you should be glad about that lol. Previously you could fall from a tree, break a finger, and walking around would then randomly cause you to get stunned and cause your finger to hurt worse. A player could hit you with a weapon in pk and break your arm, causing the same stunning effect which would trap you in place while you continued getting attacked, breaking more bones and making the situation worse until you were killed. Honestly it wasn’t cool at all, and we need to fix it before we introduce the system back into the game again.

As for the sicknesses, generally this system was written before stw’s first release back in April 2015 and was thus very oversimplified. It was touched a bit when we added one generic antibiotic item that could heal all sicknesses, and aside from maybe making the system less spammy, it was never really the sort of system we wanted and also needs a lot of work such as making sicknesses scriptable for worldmakers. I can’t really speak to what sicknesses will be in the game, but one thing I can say is that the ridiculous spam in regards to sicknesses with the screen reader reporting the same information about your condition over and over will be resolved. We intend to modify how the information provided by pressing the o key works and make it include the current state of your sickness. Then, the screen reader will only speak once when that state changes, not multiple times for the same condition!

I’m sorry I don’t have too many other details here, honestly considering the current stw issues combined with the burnout period has just outright smashed the priority of this sort of thing way lower on the list of things to do and fix than we would like.

Will stw’s audio occlusion ever get better?

For those who don’t know, the audio occlusion is how sounds can disappear or become muffled behind walls. The simple answer to this question is that at some point in the future, I’d like to rely on some people who are much smarter than me to accomplish this, namely by employing the steam audio library properly. This library actually allows you to feed a geometrical map to it consisting of triangle meshes, or in other words we feed stw’s world map to the library consisting of floors, walls etc. Steam audio is actually then smart enough to take this data and figure out the best occlusion of the sound for us based on real physics! Since I know that this solution would always be better than what my trig math lacking brain will be able to come up with, I have held off on touching the game’s occlusion system until such time as I can properly integrate steam audio for this purpose. Trust me, it will be well worth it once we figure it out, the fact that no audio games yet a bunch of video games use this system is super sad and I hope to remedy that problem.

Why does the server lag out and crash for hours at a time?

In general this question has been answered throughout various sections of the post, but for anyone who has skimmed through it (which I wouldn’t blame them for considering it’s ridiculous length), I’ll provide a short answer here.

Most of the lag that I know about is caused by an npc getting stuck, quite simply. An npc can get trapped somewhere which can cause it to lag the entire server as it attempts to get out or the area it got stuck in. Or in a more minor way, if 2 npcs attack each other especially on a hill or slope, many smaller path calculations can happen very quickly as the npcs run towards each other and move around each other while attacking. Though I’m not certain, I think that the times when the server hangs and is down for a few hours is due to a more brutal version of the same problem. If an npc gets stuck, I mean really stuck, it could theoretically spend 5 minutes trying to calculate a path out of an area given current conditions. 5 minutes later the path calculation fails and the npc just starts trying again within the next second, lagging out the server yet again for another 5 minutes, and queuing up even more work for the server to catch up on when it fails. This typically repeats until I see a message indicating that the server is down and manually restart it. People have asked why I don’t write some sort of script to handle this such as a daemon process that tries connecting to stw’s server every few minutes and restarts it if the connection fails, to which burnout is unfortunately my main answer combined with the desire to fix this properly instead of relying on such a solution. Also even if I do want to implement a solution like that, linux already provides one which I’d like to use instead of writing my own once I learn how to use it. Who knows, perhaps I can finally get to it after writing this blog post, which I recognize took far more effort than implementing such a fix would take. Psychologically speaking I think the only other possible reason I’ve hesitated to do this for so long aside from burnout is because in my mind I feel like I have failed to implement this pathfinder properly in time, and implementing a bandage measure feels like utterly submitting to that failure the way one might submit to a bully, even though in reality it’s just supposed to be a temporary measure until I actually fix the pathfinder. I’m sure it comes from the fact that giving up does not typically come easily for me and hurts horribly, and unfortunately I’d convinced myself for too long that I’d be able to fix the pathfinder before a measure like that would be needed, such that finally employing such a measure feels like failing/giving up on that front even if only in my emotions. Logically of course a temporary auto restart measure is the correct solution which does not mean failure but instead means buying time until I figure this out, but I’m not gonna lie it took until writing this FAQ answer on March 22nd for that logic to reach my emotional state for some reason likely because writing stuff down tends to cause one to think about the subject matter far more clearly than they would have otherwise. Due to this epiphany which you guys more or less just saw unfold in my mind as I wrote it, I would expect these crashes to become far less frequent within a couple days of this blog post. The lag, of course, will take longer.

Why do npcs stop attacking mid-combat?

In short, remember that npcs have statistics too! The most likely reason an npc stops moving during an attack is because it gets tired. Now, of course, the logical behavior would be for them to run away from you before deciding to stop right in front of you for a nap so you can easily finish them off, and the reason this has existed so long at least up until my burnout period started can mostly be attributed to having larger fish to fry during the beta combined with wanting to fix up npcs and make them use a proper skill tree as mentioned far above. In the case of an npc getting tired, there just has not yet been code written that makes an npc run away below a certain stamina level though before it gets so tired it can’t run fast. If an npc stops mid-attack with full energy, this can probably be attributed to some sort of bug either in the pathfinder or npc scripts. Regardless neither case is intentional, and this situation will improve as npcs do.

Will there be any events to celebrate the end of the beta?

I simply do not know the answer to this question. Certainly not as I’m writing this, but as stated above there will be some downtime while transitioning from public beta to the main game later. Though I honestly doubt this downtime will be enough to plan for such a thing, perhaps it will go better than we could possibly have imagined and we may have time to plan for at least something small. Being totally honest though? I doubt it. Realistically speaking, the release of the public game is going to be fraught with support tickets regarding things like item restoration, credit restoring that fell through the cracks of any automatic scripts, bugs resulting from what will certainly be an imperfectly done merge between the beta and main databases (I’ve never done that before) etc. I’d love to do some sort of event to celebrate the end of this horrible period in stw’s history, but it’s unfortunately just not realistic, at least not right away. Later though once we know all has calmed down and as many people as possible are happy, when me and the staff have time to plan for something other than how to get ourselves out of our current situation? Who knows!

So uh, will you continue your previous blogging schedule now?

Not starting at the time of this post at least I don’t think, but certainly soon yes I’d love to. I kind of have this fear of putting too much energy into stw before I’m relatively sure I’m ready for whatever is going to come my way. In other words I want to make sure I’m as fully recovered from last year as I can detect before dropping another huge load of energy on the game. Particularly if the decision is made to finish the release of nvgt before getting out of this beta, resuming the normal schedule of stw posts may take a bit longer than otherwise. As such, we’ll timidly start with this: if there are any changes beyond tiny bug fixes or something, I’ll post. Once I really get rolling with stw again, I shall do my utmost to make sure I return to a bimonthly schedule as before so long as large changes or a lot of development continues to take place, and as long as they do, will try my absolute best to not drop the post schedule until I communicate such a thing. Last time I learned that a big enough event such as the release of the public beta was enough to displace me from this schedule, and so now that I know that, I will learn from it and if I detect that I won’t be able to stick to the previous schedule, I will make a short post to say as much rather than going silent. Nevertheless I will post clearly when I wish to start the bimonthly schedule again, which as I’ve said above is not quite yet. I do really apologize though for dropping it so silently, that was not cool at all.

What are the bug report counts at the time of publishing the post?

Since I have not been actively developing the game for a few months as mentioned in this post, the open bug report count is certainly higher than I’d like. Remember though, when me and the staff sit down and attack these bug reports, we hit them hard as shown in the timeline above! There are currently 535 opened bug reports, with 1875 duplicate or closed. Thank you all for your invaluable feedback!

An interview with the Tony Gebhard show

You really want to hear more of my yammering after reading probably a 30 to 60 page blog post depending on font? Wow, 😀 you must be pretty cool, pretty crazy or some combination thereof that I can’t quite pinpoint haha. This post is really long and I thank you for caring enough to read this far! Anyway whether you want to listen to it now or later, in September 2023 I was fortunate enough to be featured on the Tony Gebhard show. This was exciting, as there are many fascinating and talented people Tony interviews on his podcast, and the fact that he considered me to be among the people he wanted to interview is, to say the least, heartwarming. We talk about everything from Survive the Wild to audio editing to AI and more! I must actually publicly apologize to Tony right now for the fact that it took me so many months to share this myself, of course I thought when the podcast took place I would publish a blog post at any time! Combined with the fact that I’m not on any social media anymore where such a link would stick around for anyone who looked at my timeline or something, I wasn’t sure where/how I wanted to share this. I’m really sorry for the delay dude! Anyway I recommend checking out if not this particular episode, then the show itself as it is very inspiring, consoling, and generally just all around cool! If you are a blind person who feels like you’re not sure of your life purpose at this time, then perhaps you can be inspired by one of these amazingly talented people that Tony has interviewed! If you just need an emotional pick me up here and there, you’ll find that on this podcast as well. It’s hard to go wrong with this one! Though you can find it on other services such as apple podcasts, here is a link to The Tony Gebhard Show on Spotify, and below is a direct link to the interview Tony did with me which he called Navigating the Wild: A Deep Dive with Sam Tupy.Thanks again Tony, and sorry again that it took me so long to share this!

Conclusions and thanks

Well you guys, that’s all I’ve got for this one accept for a solemn, sincere and understated THANK YOU. You know, both for players and staff, it occasionally astounds me how many people have stuck with this game despite the fact that I keep making mistake after mistake in the process of trying to make the game better. Even after months more of the public beta running than I could have ever planned on, even with the game being in one of the most broken states it’s ever been in and even after my communication has flat out tanked for several months when I didn’t wish for it to, people are still playing, sharing the game and even purchasing credits. In many ways, I feel like I am in the debt of most of the people reading this, without whom my life would be utterly and completely different. The outpouring of patients and support I have seen from this community in the last many months is genuinely amazing, and I pray that I am able to repay it by making the dream we have for stw a reality, as a stable, fun and healthy game is all many people ask for their support. The fact that we aren’t there yet and that people are still sticking around is a blessing worth more than any amount of words I could ever write or speak, a blessing supported by every staff member and every player, and a blessing that I don’t feel that I deserve. The fact that I am in a position where I can live out this period of burnout and recover at my own pace without needing to find other employment instead is unbelievable to me, and again I genuinely and from the bottom of my heart thank every single person who is a part of that, who still believes that we’re going to get there even after I’ve made so many mistakes during this development process from the beginning to now. Seriously thank you all, and Lord willing I’ll be ready to work shortly and we can be out of this entire beta situation soon!