Jump to content
Skull132

Regarding Development and the Dev Team

Recommended Posts

Hooookay. Before replying, please read the ENTIRETY of this post. There are multiple things I wish to address with my post and they're all sort of related. I will also be using links to specific places to illustrate some of the points I raise. So you can evaluate some of the material with your own eyes, instead of just taking my word for, "We do stuff, trust me."


The intent of this post is to shed light and to address sources of frustration that I've heard from the playerbase, and from the development team. To outline some actions we plan to take to alleviate this frustration. To request that certain actions be taken by the playerbase to alleviate this frustration. And to shed some light onto some processes which may otherwise remain abstract.


First, let's have a talk about the community interactions with developers. There are two notes that I want to concern myself with here, the first of them being the reporting of bugs via Discord/OOC/whatever mode of communication other than Github you may prefer. Please do not do this. Understand: there are 500 or so players that visit this server regularly. That is a lot of people to listen to. And if you're all poking the small team of 5 individuals with gripes which they choose to be important, then, well. The devs get burned out to hell and back. Github should be used to report bugs, and we, the developers, will run regular patches chipping away at the every growing issue count. Now, there have been high key bugs which persist and which people have probably grown disgruntled over. A short list:

  • Space wind
  • AI crashing
  • Server crashing
  • Anesthesia not working reliably

 

Since these four are high profile and have gone unfixed 5ever, I will be illustrating various difficulties with fixing them. But I assure you, every high priority bug that is reported to us gets evaluated within a few days. This involves security breaches (tickets recently; being able to crash the server with the ore summoner or character creation window from the past), and items which have a high impact on gameplay. But there is a list of things we cannot fix. AI crashes and server crashes are clearly in that category: we have investigated both. I've filed a bug report to Lummox regarding the AI crashing, and backed up MSO's report on the server crashes. Unfortunately, Lummox has yet to resolve the issues. It did look like AI crashing was remedied in a patch to BYOND, but later patches caused it to grow worse. Also, specifically regarding the AI crashing: people have called me and my team out on our updates increasing the frequency of crashes [1] [2] [3] [4]. Yes, this is possible. However. At present it looks like the crashes are caused by images being loaded by the client. The AI system relies heavily on images to create the static which stops them from wallhacking. Due to the size of our map, there's a lot of those images. So the frequency of crashing is quite high. There is also a theory of certain objects causing it under specific conditions, however, dicerning this is a practical impossibility as well. Figuring out what causes the crash, if it is a visible object, would involve days of brute force testing to potentially come to the conclusion that the object in question is no different from anything else, which plants us back to square one. Ultimately: the key principle of BYOND is that the client and server should never EVER crash. We lack the proper tools to humanely handle them. We have done all we can, the rest is up to Lummox.


Regarding the other two, those are within our power to fix. And effort has been expended into fixing both. For space wind, the easy fix was known to us forever, effectively. And a form if it was eventually implemented by Lohikar in the PR I linked above. However. This fix is not ideal. The present state of Aurora code, specifically the speed and reliability at work, was achieved through a long list of really specific optimizations and fixes. It was and is meticulous work. The fix, as implemented, goes completely against it, implementing a very costly procedure into an already costly subsystem. And the unfortunate matter with code is, once something is implemented, it'll probably remain as is until it outright breaks. Which is why there was initial push back against implementing this fix, and the hopes of a better alternative being figured out. As for anesthesia, I already told Xander about this, but I personally put half a working day into figuring out this issue. And wasn't able to reproduce it on a local server. I was then called in a few times on the live server when it was happening, and was unable to notice anything out of the ordinary on the mobs and setup that would reveal the issue. This is all to say, I personally cannot fathom what the issue and it is by no means trivial to spot. Which is why that specific report is sitting with little motion.


To summarize the discussion around bugs. I assure you, we are not ignoring the community. I assure you, we pay attention and actively handle them as we can and are able. We are also aware of the annoyance and pure frustration it causes to players; some of them also cause a great deal of annoyance and headache to us as well. But please keep reporting them on Github explicitly, unless they're a major security risk, at which point PM me over Discord. And please have patience, because after all of the major ones are done, the rest, to us, are all equal in severity and it's literally a random draw what we fix and when. (Though bugs centered around newer features are usually prioritized higher, specially right after an update.)



Now, moving on to another source of frustration that I've heard from the playerbase. This would be some recent gameplay changes alongside some controversial PRs that have gone up. First, allow me to address some of the recent gameplay changes, map changes, etcetera. This includes things like junk food and firing pins. First, much like with bugs, please do not moan at the developers directly for implementing these changes. While I don't wish this entire thread to read as, "The devs are made of glass please hold them dearly," I do wish to bring to light the fact that this kind of conduct is absoloutely draining and makes the developers not really interested in paying attention to you and your wishes. Or just makes them want to leave. Communication is a two-way road. Now, first, where to moan? Suggestions forums, those two threads are a good example. We do heed feedback and have adjusted multiple features to accommodate feedback post-launch. Mice buffs, K'ois, devouring, Alb's overdose changes (which were killed) etcetera. The list is long, extremely long, and the PRs are unfortunately kinda hard to find on this. But if you've played enough, you should be aware. However, note that said balancing is done with some consideration given and we rarely revert things. We'd prefer to adjust new features to fit feedback and see if they can be salvaged. This is why reverting something sour might take up to two months: one month to save it, another to kill it if required.


On top of this. Lately there's been an uptick in merging controversial changes. This is not really surprising, considering there's been outside contributors to the code. Their gameplay views do not necessarily match one-to-one with what's been done before, but aren't necessarily out of line either. So essentially these could be classed as growing pains. Once water's been tested, and we know the result, we know to follow that line in the future. It should also be noted that it isn't necessarily possible to evaluate the performance of a PR ingame without actually putting it out there. For example, the discomfort caused by junk food might look fine on paper, but ayy, turns out, it's horrible in practice. This is most notable for any PR that involves probability or continuous processes. Probability is really easy to get wrong, and evaluating the discomfort caused by continuous processes and their evolution is also really easy to get wrong. But as long as there's a suggestion thread up regarding feedback on a feature that's implemented, we will do our best to re-evaluate and balance. (And yes, re: Janitor, I apologize for missing out on that one. It was actually posted in #developers whenever the last update was being finalized, but I was too ill to actually pay attention to it. We'll making a decision on that this coming update.)


A related matter is feedback given about pull requests by the playerbase. First, there's been violent reaction to PRs which propose more outlandish changes and then violent reaction to those PRs not being immediately being denied/changed/whatever. Allow me to clarify the entire process of a pull request:

  • A coder drafts up initial code and puts up a pull request.
  • That code will then, at some point, be reviewed by Aurora developers. If it's funky, it gets tagged as "Feedback required" and I usually drop it to admins or head admins for opinions. Alongside discussing it with the development team at large. Sometimes also a suggestion topic is created.
  • Once feedback is consolidated and provided, it is then up to the developer to consider his actions. NOTE! Changing PRs TAKES TIME. At some point, an absurd amount of time. Do not expect immediate,

    visible actions to make amendments to a PR, this is unrealistic. Pestering a developer continuously about it may also end badly. Your best bets are to either post on the PR itself, to have a civil discussion with the developer and hope he takes your views into consideration, or to leave a note on the related suggestions thread.



    But note that once a developer or a maintainer has left a notice on a PR requiring some sort of changes. The PR will not be merged without those changes being implemented.
  • PR gets updated and reviewed again. This cycle repeats until we're happy with the end result.
  • PR gets merged.

 

The third point cannot be overemphasized enough. PRs are usually not closed if the specifics of implementation are deemed bad. Official word from staff may take time to get to a PR, so again, no changes on a PR which has no official review from a developer is also not something to get frustrated at. The gathering of information, or even getting around to reviewing PRs, takes time. But the process I outlined above is completed at one point or another. I assure you this. And there are plans to help with feedback aggregation, but those are for later note.



Now. That was a lot of discussion around how to interact with developers. Again, I cannot over emphasize the reason why I wrote all of that. It is ultimately not to force or to even ask of all of you to hug the developers close as if they were some glass cannons. No, we get as annoyed and as frustrated as you all do at times; we fire back and meme back. But in order to maximize the effectiveness of having your wishes go through, you should be doing the things I noted above. We usually forget bug reports given verbally after 30 minutes, none of us are going to up and fix them immediately as you say. The specifics of verbal feedback are hard to remember after a day, when it comes to new features. And when it comes down to it, we can just ignore you on Discord, as it's a scrolling medium and no one's going to take you seriously if you say, "Well I told you on a fast-moving channel on Discord!" So please, use the forums, use the Github. And don't spam the devs with things that belong in either of those two places. Talk code and features when we're up for it and actively talking them ourselves. I hope that makes sense. And note that similar principles are in place for all other staff already: the devs really shouldn't be any different.


Somewhere down in those paragraphs I also mentioned that communication is a two way road. Well, that's true, and the developer-to-community communication hasn't been the best. Specifically, aggregating feedback for PRs and features has been a mixed bag. Both in terms of where and how you folks get to provide it, and in how we can gauge it. So, we have a few ideas to improve that process in the works. Specifically, introducing feedback provided from within the game around issues marked as requiring it and via a direct link to Github. Ideally, it'd involve with you either filling out a short questionnaire about the feature, or providing written feedback and whatever; and eventually, it'd get aggregated for the coders to view on the WI and a link to said panel posted on the relevant PR. It'd allow the coders to remain Github centric in their actions, while the players get to provide feedback from the comfort of their most favourite 2d farting simulator. Hopefully this'll bring the two settings closer and allow for better synergy.


Another thing we took a look at was incentivising bug fixes and suggestion implementations. Specifically with perhaps something similar to gud koder points. Hopefully this will allow us to get a more balanced diet of bug fixes, random features, suggested features, and major reworks. But, due to the fact that this would have to be more thoroughly planned out and discussed with both developers and community coders alike, the only thing I can say about this at the moment is that, "We're considering it a bit more than we were in the past."



SO. Hopefully. In these 2 330+ words, I was able to answer a few concerns. Bring some light onto development related issues. Explain some things. And provide reasonable solutions and discussion to some of them. If you have any questions or concerns or whatever the dicks relating to development, feel free to leave a reply.

Share this post


Link to post

Despite a forum existing for reporting suggestions, and a forum for reporting bugs, the number one way to report a bug is to complain in ooc about it. A contributor will not take you seriously while they're busy playing games; use the forums or github so we can look at them and work on them on our own time. If it feels like I'm ignoring you in OOC when you complain about junkfood, it's because I am. Use the forums. I'm also noticing a trend where people over exaggerate the issues or act silly on purpose to prove a point. I've seen people buy bread tubes in vending machines early in the round, and I say to myself "That person fully knows that bread tubes are bad for them, and they're going to eat 3 of them just to bitch in OOC." and that's exactly what happens. The less truthful you are, the less seriously I take complaints.

Share this post


Link to post

I'm wondering if the anaesthesia has anything to do with the character gasping or not breathing properly. I've noticed the issue when dealing organ damage though I will need to test this further. If it is the case however, you can maybe, if time was free, you could implement something from actual surgery which use endotracheal tubes and laryngeal mask airways. They could function like a mask but must be applied by someone else for safety, and if removed aggressively could cause damage. Not a suggestion thread, but seeing as it's relevant to your issue, eh.

Share this post


Link to post

Have I made a longer post than this? I don't think such a thing exists, Skull. I am beaten and humiliated.


Appreciate the clarification on the Big Four Bugs, though. Is it possible to use a temporary measure such as a non-animated image placeholder to to substitute for the static and designate what cannot be seen by the AI? Would that help things?


And in response to the bemoaning, such as in the junk food thread. I really don't think it was an excellent idea to be pushing through, even with the standard premise of it. I can't speak too much of the firing pins but it was obviously a contentious subject in the first place, as 50% of a vocal minority was like, "Yeah!" and the other 50% were like, "OK, no, this is too far". So moaning, debate and whining was seemingly inevitable in that case, which understandably gives everyone involved a headache.

But in regards to the junk food thing? Contextually, I feel the addition was really unnecessary. I do take responsibility for not more avidly checking the github to post my own thoughts as to why I felt it wasn't needed, but I really didn't expect that sort of change would be suggested and implemented in a PR in the first place. The change seemed very silly, arbitrary and contrived. There are ethical limits to where you can change mechanics to force ideal in-character-centric behavior.


Obviously the major takeaway from 'moaning' would be to only moan constructively and not be too annoying, and that much I'd be willing to perform concessions for.

Share this post


Link to post



Have I made a longer post than this? I don't think such a thing exists, Skull. I am beaten and humiliated.

 

Appreciate the clarification on the Big Four Bugs, though. Is it possible to use a temporary measure such as a non-animated image placeholder to to substitute for the static and designate what cannot be seen by the AI? Would that help things?

 


No, because the icons are sent only once into your cache. Anyways, newer versions of BYOND fix the issue. (Until Lummox breaks it fucking again.)

 

But in regards to the junk food thing? Contextually, I feel the addition was really unnecessary. I do take responsibility for not more avidly checking the github to post my own thoughts as to why I felt it wasn't needed, but I really didn't expect that sort of change would be suggested and implemented in a PR in the first place. The change seemed very silly, arbitrary and contrived. There are ethical limits to where you can change mechanics to force ideal in-character-centric behavior.

 


To be quite frank. No amount of individuals observing the github will stop cases like the junkfood PR popping up and getting merged. Even if junkfoods was a bit more overtly stupid, there have been a dozen and more PRs which appear quite innocuous, but have a profound and negative effect on gameplay. And spotting and calling out all of those is an impossibility. Which is why there must be, and is, a feedback system in place. If a feature that gets merged is detrimental to gameplay, post a suggestion to improve or revert. As long as we, the developers and contributors, take that feedback and roll with it, all will be fine.

Share this post


Link to post

I have noticed that some people complain about developers/contributors not listen to the feedback thread, or resisting community. I would like to point out that in every single case the creator of feature is a single person who does this as a hobby. Development is not an easy thing:

  • you need to get idea
  • present it
  • ask if it is okay to make
  • Implement idea
  • find spriter(optional)
  • Test idea
  • Go through code review process

These are not easy steps. Remember again that people have to spend their free time to do all this, on top of still playing game and doing real life things. For example it took me 3 months to do something as simple as oxygen candles - it is very small in code. But I had to research how mechanics of it works, test something, finish code and refine it into clean product. I personally actively develop on computer science team of a club in my university, and these two take time of their own.


I found myself to not have enough time replying to every single post on feedback thread explaining how it works. Mostly because I would write in details my idea, and answer questions of people to only see other people posting same questions as previous people. I would really appreciate if people would take time to read entire post of thread and Q&A posts before they make duplicated questions that are paragraph long. That is my key point of this post. And please again keep in mind that contributor/developer is a one person, it is easy to try and make hoard of people to crash someone.

Share this post


Link to post
Guest
This topic is now closed to further replies.

×