Jump to content


Head Admins / Devs
  • Content Count

  • Joined

  • Last visited


About Skull132

  • Rank
    Head Developer
  • Birthday 14/12/1995

Personal Information

Linked Accounts

  • Byond CKey

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Okay lads and ladderinos. Let's take a step back and a moment to think about this. First, allow me to establish what it is that we're trying to achieve here and why. A lot of these changes are aimed at outright reducing the amount of effective control the security department is able to exert over the station. This is a necessary since, as has been proven time and time again with events, gameplay additions, etcetera. Any outside entity that is introduced into the round will be put under immediate scrutiny by security, and will effectively be restrained or otherwise controlled by security. While yes, "Realistically" this is fine. From a gameplay development perspective, this is absolutely limiting. We are rendered with the choice of either accepting that, "Yup, sec will keep these guys on a short leash, so anything interesting is gonna get shut out," or making the outside force large enough to be able to outplay sec (which, at present, is at most a 10 man team and that's asking for a lot of trouble). There is something to be said about not making these matters "security centric". However, special events in the past have demonstrated that security has a knack for butting in on matters which should primarily involve science, medical, etcetera. Which sorta makes sense, since security's job is to control whatever is underway on the station. But again, this is troubling from a gameplay perspective. Granted, security isn't the only actor here responsible for the balance upset here, and we have Other Things:tm: planned for the other actors, like the AI. But, this is about security; just don't come running to me with the argument of "BUT WHAT ABOUT X!" as some of you have been doing on Discord. With this said, let us gauge what effect DepSec, as previously tested, had on security. We got security officers with extended access in all departments, still adherent to the Head of Security and thus a part of the cohesive security team. The practical effects of this was the reduction response time for security to departments. Which meant less need for them to adhere to warrants, and an easier time all around getting to places. (This also nullified our maintenance access changes! Which were positively received by a majority crowd.) If we compare this to the goals established above, then it should be clear that we did not move towards the established goals at all. If anything, we simply extended security's reach. So, the foot goes down on the fact that DepSec, as tested, will not be merged. Due to the fact that it does not satisfy the requirements set out for it. The matter of the changes as previously tested not satisfying our goals is backed up by the questionnaire and its output. This is where the proposed tweaks come in. Removal of the departmental officers from the cohesive security department until code blue (at which point the threat the station poses to its opponents should increase anyways) was deemed as the acceptable path to walk down. As already noted multiple times, the most effective way to do this is to make the departmental officers primarily subordinate to their head of staff, and to remove the security radio from them. While yes, as I've stated both on Discord and here, this is a "severe" measure, it is also the one that's most likely to get us to where we want to be. The proposed changes would remove the departmental officers from the easy-to-deploy security response force on code green, and would effectively force them to focus on securing their own department. This reduces security's tactical presence in the round and thus helps us move towards the goals outlined in the beginning. The alternative to these specific alterations is to implement DepSec with severe access restrictions. Basically just give them main departmental hallway access and drop the other changes. However, again, if we look at the "What and why" portion of this post, you'll quickly see that this alternative doesn't really further any of those goals. All it does is give security access to departmental hallways. That is it. While less egregious than the previous test merge, it is still not a solution good enough to accomplish what is required. There exist other ways to skin this cat as well, obviously. And something from this hat is being considered for NBT. However, without completely uplifting Aurora's current command structure, implementing those changes is difficult. The only other alternative solution that I'm currently aware of is to directly nerf the number of security team members that are on the station. Remove 2 officers and 1 cadet, say. This should lower the effectiveness of the security team enough to serve our goals. We are open to further suggestions, but in proposing them, you must keep in the overarching goals. Some of the proposals that I've heard thus far sorely miss the point, and they mainly do so out of ignorance.
  2. We likely won't go for another test merge. Purely because long-haul test merges are assenine in terms of keeping the server up to date during them. As said, the decision is to be re-evaluated following launch, so we'll see. Well, you see. The stats say otherwise. As does enough anecdotal evidence which has reached me and the rest. And if we want to discuss representation of the numbers, this is 10% of the monthly unique player base that has spoken. Which is a pretty good representation as far as our polls go.
  3. The ultimate goal is to ensure that departmental officers serve the departmental head of staff first and foremost; and that the enforcement of warrants and other matters does not fail as epicly as it did during the test merge. We deem that the most effective way we can make this point clear is to separate them from the general security information space. If this ends up being too much, for one reason or another, then we shall alter our approach. But for now, and because the only other alternative currently visible was deemed more counterproductive to the goal of departmental security, we're gonna try this first.
  4. Funnily enough, this was actually discussed! We expect the laws of physics to apply here, though. Specifically ones around entropy, conservation of energy, and human laziness. Good luck!
  5. Well fuck I need to write this shit up a second time because I decided to hit an unknown combination of buttons and Windows's response to that was, "WELL I GUESS YOU DON'T WANT TO SEE THIS WINDOW OR ITS CONTENTS EVER AGAIN THEN! BYE!" I am saying this to vex my frustration, I hope this is clear. So the Player Feedback We got over 100 99 responses on the questionnaire that we released. Which is I think a solid 10+% of our monthly unique player count? Something like that. And hey, that's good! 54.5% of the respondents had played security during the test merge; 32.3% of the respondents had played antag during the test merge. Here's a short rundown of key results: 62.6% of the respondents rated departmental security a 4-5 / 5 in gameplay. 74.7% of the respondents said that departmental security made it easier for security to exercise authority over them and their department. 74.1% of the responding security players said that this had a positive effect on their game play. 50% of the responding antag players reported that this change made their setup period more difficult. 56.3% of the responding antag players reported that this change made it more difficult for them to avoid being captured. In contrast to the above numbers, 72.2% of the responding security players said that these changes did not make spotting antags easier. 42.6% of the responding security players said that these changes did make it easier to spot other criminal or suspicious activity. So, what can we take away from this? Well, the majority of the player base appears to like the change. For one reason or another. So hey, that's good! Sec players also seemed to like the change! But this comes at a cost. The rest of the numbers aren't all that positive, with regards to what we, the leadership and development team, were trying to achieve. To use the touting of a loud mouthed security player on Discord to illustrate the matter, "Hah, you just gave us easier access into departments!" Discussions with other players and members of staff pretty much confirms this, that the largest change here was increasing the effectiveness of the centralized security team, by virtue of giving them more access. Which is, completely and utterly counter to what we were trying to achieve. The Changes & What's Next The player base wants dep sec merged. Alrighty. But this comes with 3 changes that are to be done. The first two are aimed to directly tackle the point we missed above. The idea of departmental security is that they are departmental security. Officers who are subject to the departmental chain of command they are stationed in. So to reinforce this, the following two changes will be done: SOP will be introduced to clearly state the departmental officers as having to listen to the departmental head of staff first and foremost. (At least on green.) Simple enough, will clarify the CoC. There will likely be other edge cases and matters to be tackled by @The lancer and his SOP team as well. Departmental officers will lose security channel access on code green. While I do wholly understand the importance of communication, I do also understand that undermining this point is the most effective way to get at what we want to get at. Removing the departmental officers from security net will make them more reliant on their own departmental chain of command. The alternative to this one, thus far, has been to nerf access of the departmental officers to just departmental hallways. But I believe that to actually run counter to what we're trying to achieve. The final change is to do with basic arithmetic and numbers. 1 cadet slot will be removed. The reasoning is simple: security as a whole gained 1 officer slot in dep sec. Thus, instead of fielding 10 bodies that can be armed as needed, we're now at 11. Removing the cadet puts us back down to 10, and life will be fine again. Is This All? Well, yes and no. SS13 is not a very static nor persistent game. Things will change, and the setup of security will likely change as well, again, in the future. So none of these changes will be Permanent:tm:. And specifically with this, we'll be re-evaluating the new implementation a short while after it's gone live. If shit suffers too much, there's always the :ree:vert button to be pushed. Or changes to be made, comms to be removed, access to be tweaked, etcetera. But on a bit of a longer game picture. Security has an immense role and presence on the station. (This is followed by the AI and a few other things.) And this is limiting, from the perspective of gameplay development. Any obstacle we present to the station, anything remotely foreign or dangerous, security is going to be there, in force, to deal with it. And this is not necessarily a positive thing to work around. So I want to put forth the idea that this will not be the end of us touching security. NBT has a different suite of changes slated for security to undergo, ones that are not even remotely enabled by the current command structure, setting, etcetera. More details on this whenever NBT has actually passed pre-production entered production (otherwise I could be saying the same story over again for 5 times). But, smoll steps at a time.
  6. The long standing idea is to introduce more powerful random events. Specifically player driven ones, like random Vox appearing on station or whatever. For both extended and non-extended rounds. I don't think increasing extendo chance in secret is a good idea, extended is already the most played singular game mode, taking up 40 - 55% of the play time per year.
  7. On the flip side. It is debatable whether "You need a good gimmick" to be a good antag. IMO gimmick culture is cancerous and needs to die in a fucking fire. Just play antag, create a bit of a story, and voila. You're good. People being disorganized is fine, this is the norm for new antag players. Another fun thing to point out is the idea that bad antag players get "punished for being bad at antag play". Arguably, the more players play antag and the more familiar they become with the role, the more welcoming (hopefully) the whole playerbase becomes towards the matter.
  8. This is likely a bug with how restricted jobs was implemented. The novel code that I introduced is effectively a copy of how the original draftee list was composed, ergo, it does the exact same thing. So the code implementing the job restrictions is the code to look at to figure out why it's broken.
  9. Age restrictions still apply. So new players won't get antags we consider to be "too complex".
  10. So a bit of history. Last year, we decided to start messing around with code which handles antagonist selection. Specifically, a piece of code which forcefully drafted people who voted for the winning roundtype was removed, and some other changes were made. Following this, we saw a marked flux in the status quo of what round types go through and what fail. The spread of round types played started to suffer, according to our observations. The other changes mentioned were reverted in early December, late November. And the situation did not get better. So, now we've reverted the last change and are about to find out what's gonna happen! With this said, to make the barn big and red, here is what has happened: We reintroduced a mechanic which, on the condition that the currently winning round type does not have enough antagonists to start up, will forcibly draft into antag roles everyone who voted for the winning round type. This mechanic was reintroduced with the primary goal of having the played round types be more varied, by virtue of more round types getting passed their voting requirements. This mechanic was reintroduced under the premise that it did not prove an issue before. This will mean that you are likely to be chosen for antagonists that you would rather not play, specially when voting for secret. We understand that this may appear inconvenient, but we trust that most of you are able to see the necessity of antagonists in the grand scheme of the game, and are willing to play a less-than-desireable role some of the time. We will, of course, monitor this change. Primarily seeing how the round type spread is gonna work out from now on. Along with the disgruntlement of the playerbase, of course. Administrative policy on this matter (and how easy or hard it is to get out of forced antag status) will be clarified by Alb and Garn.
  11. To be clear, he isn't saying that you did bypass. He's saying that you tried. Did you?
  12. Just to shove my 2c in here. I still do not necessarily understand nor see the need for warp drives to exist. Just another under-explored muguffin to escape away from Bluespace because "Bluespace bad and silly" or some shit, in my opinion. Similar comments exist about bluespace gates, though less so.
  13. @UnknownMurder Well, time to put that mystery to bed. Skull, revealed for the soulless entity that he is:
  14. Test merge is over for the time being. Time to gather feedback. Go here and fill this out: https://forms.gle/hvkEtSpk9S6PL36C9
  15. I once had code for this. I remember my initial drive fizzled after people were unable to provide me with fonts to do shit with when I asked.
  • Create New...