'Space Station 13': Behind One of the Largest Open Source Games

[Music] has anyone here actually heard of space station 13 heck yeah okay so i'm a maintainer for space station 13. more specifically the tg station flavor of space station 13. we boast thousands of stars forks contributors we get tens of thousands of commits making us one of the largest open source games on github we get tens of community contributions per day in the form of pull requests meaning people bringing in their own features bug fixes whatever else they have in mind our code is 100 agpl licensed open source but the influence of space station 13 expands far past just this one repository in order to explain that i'll need to go into the history of space station 13 i'll talk about how our open source model works how we accept contributions and how we interact with our player base

i'll talk about the benefits we get from doing our way of open source as well as some of the bads but also how we live with them and i hope i hope by the end of this talk we will have a good understanding about how open source games work at a large enough scale and maybe give you some thoughts on open sourcing pieces of your own games so how do we get here space station 13 originally was not even a game it was a tech demo built on an engine that at the time was made up of primarily anime fighting games eventually they start building a game around that and just adding whatever comes to their mind peak concurrent users at this time was about 10. the source code is shared between some forum users until eventually it gets published under cc by sa basically the code is free to use but you have to upload your own changes to it ever since then several communities decided to take space station 13's code into their own hands and build their own versions of it there's hundreds of unique forks out there these are just the ones that i could fit on one slide and they don't even include every active server there is now the longer these

forks stay in development the more radically they differ from one another they're all driven by vastly different communities with vastly different ideas about what makes the game fun so if you ask what is space station 13 it depends who you ask if you ask the tg station player they might tell you it's a steadily paced sandbox game with a focus on high action and unique complex mechanics however if you ask a goon station player the very original version they might tell you it's an arcade style game with a heavy focus on individual player knowledge and stories if you ask a base station player from a community of dwarf fortress fans they might tell you it's a slow paced game with a heavy emphasis on role play between players and if you ask a tgmc player they'll tell you it's a pvp team deathmatch game because they took the code of space station 13 and flipped it completely on its head they're basically just using it as a game engine at this point and these aren't niche communities either space station 13's popularity comes not from any one version but in the hundreds of forks with huge

communities building games that might only barely resemble one another and while our game engine beyond might not be open source there's countless projects that intend to move us to a freer platform projects like open dream work to recreate the current game engine into an open source alternative allowing us to port our existing code while projects like space station 14 and unity station are taking traction as full-fledged remakes in other game engines space station 14 is championing its own open source game engine but while we're on beyond we make huge use of open source tooling to replace the engine specific proprietary software we have a few open source map editors such as strong dmm which are all vastly superior to the built-in map editor we have aux tools which reverse engineers the game engine itself in order to let us do things that would otherwise not be possible and we have support for external editors whereas the game engine would normally have us use a basic text editor with colors but just being open source can mean a lot of things maybe parts of your game

are open source and others are closed source or maybe your code is open source but only a subset of paid workers can actually contribute there's a lot of different ways to do open source and so it's important to know the way that we do it on tg station we let anyone make pull requests and we have fairly loose guidelines on what can actually be added in practice this means we frequently get both fun niche stuff like high fives or blowing kisses but we also get large content expansions such as new maps planets or game modes due to our fairly lacks restrictions in our extremely high output of contributions space station 13 boasts a huge amount of content what you're looking at is our wiki all of those are separate full-fledged guides to every nook and cranny of the game and when i say extremely high output i mean at a rate that traditional game development has trouble competing with we get hundreds of commits merged per week we do squash commits so in practice that's hundreds of pull requests per week remember a pull request is a community contribution like a bug fix or a new feature

and we get this from over a hundred unique contributors per month while contributors might come and go we're always getting fresh funds ready to work on the next big thing our team is still fairly small we have little over 70 members in our organization around 25 are considered maintainers and are tasked with reviewing the code and the design for pull requests as well as having the final decision on if they're merged we have about 40 issue managers who are tasked with helping triage and label our nearly 2000 issues as much as they'd like to see that number go down despite hundreds of pull requests per week we managed to make a decision on most within seven days and we're always talking to contributors about what types of changes we'd like to see on both github and discord we regularly help new and old contributors learn the proprietary language our own code base as well as walking them through our general game design process so sort of by necessity in order to keep the game alive our open source model turns players into designers if someone has an idea on how to make the game

better they can easily hop onto our support channels and learn how to get their id into the game players are very active throughout the entire design process from ideation to production both in terms of those that originally came up with the idea and those who want to help flesh it out with their own perspectives in fact even before the pull request is merged our open source model provides content to players at an unmatchable rate a day in which several bug fixes and quality of life improvements are not added to the game is an abnormality and a month without some large part of the game being changed or added is almost unheard of to the point where when we do instate things like feature freezes there's always a tiny bit of uproar the bits about community involvement are really important and very unique to open source game development so i want to go deeper into that so in larger traditional game development you have dedicated members in fields like design programming art and so on of course the more indie you are the more of these roles are going to be filled by the same people but my point here is that the developers are separate from the players developers

play their games of course but pure players and developers can have vastly different ways to view the resulting game so for example if we have a class shooter maybe as a designer my focus is on things like team compositions win rates pick rates but as a player my focus might instead be more on what i actually choose to do my class what i would have fun with and what i find frustrating to play against in space station 13 our development is nearly entirely from this category and i'm not saying one cell thinking is better or makes better games but i'm saying it creates a substantially different design that i think is pretty interesting as said before basically all of our pull requests come from players while across maintainers we do have a broader vision for where we want to see the game go we don't write much code ourselves compared to players much less features and we can't force anyone to work on anything that they don't want to do players know this and they know that if there's anything they want to see to the game usually the only thing stopping them is themselves so let's think back to the class shooter example

in space station 13 players are split up into departments which are split up into jobs similar ish to classes as maintainers we do have a rough idea of how we want departments to interact on the macro scale but nobody knows how the micro interactions play out better than the players themselves so as maintainers we know that we want engineers to build things but some players know that they want to build couches so they send that as a pull request there's nothing harmful about it so it goes in it might not have been something we thought of or would have made the art for but it's definitely not something we're going to deny as maintainers we know that we want people who are security officers to be responsible for handling crew that commit crimes some players think why not let people choose to be a prisoner if they want to give security something else to do it aligns with the way that we see the game and so it gets in this style of thinking of just adding what you think would be fun within reason is something that you'll only see from player driven development and open source can make it super easy

and inviting people who enjoy a department who play it for hundreds of hours are invited to add content that they think other people in their department will enjoy maintainers still have the final call of course we're not going to let security players give themselves machine guns anytime soon but players are able to provide ideas from a super unique point of view this helps the game either at large or job specific or math specific or whatever else feels super vast there's always something to do made by people who have fun doing what you do and new or experienced players are always giving you more to have fun with and even if you're a game developer who does listen to even the nichest of player suggestions your time is still limited you can only add so much in open source player driven game development time often isn't being diverted at all a player who enjoys character customization adding the ability to customize glasses is someone who might not have contributed anything at all otherwise the presence of these contributors is way more often than not a net positive for us

so in order to show our processes at work let's walk through one good example let's look at circuits circuits look like this they're like unreal blueprints or like wiremod and gary's mod they're little contraptions to automate some work but most importantly they're a feature built upon by several separate contributors for context they used to look like this and i kind of still don't know how you were actually meant to use them that version of circuits got merged in late 2017 it was a collaboration between five separate contributors that being for design sprites code support or any mix of those but it has some problems one is that it's really easy to make circuits that just kill people and really fast death in space station 13 can be impossible to come back from and you might be out of the game for upwards of a few hours circuits can be saved and then sent to others meaning basically everyone who wanted to could have one of these really powerful weapons every round and to top

it all off these weapon circuits could then just be hidden away in your hand nearly impossible for other people to see until you used it and they died and also you saw how they look only a handful of people could actually make anything with these because of how clunky they were so over the next year countless contributions are made for circuits some add new features some fixed bugs and others try to rebalance them so that people weren't just using them to kill everyone but eventually as these problems seemingly got worse not better the decision was made to scrap the feature entirely though with the hope of going back to it later with a little bit more thought so what went wrong well one of the downsides of our open source model is that with lots of contributions coming in it's very hard for us to thoroughly investigate the design of every feature that gets made features getting made and not working out and then necessitating full removal is not uncommon we have lots of contributors but we have very few chances to onboard them while larger features like circuits do get more attention from maintainers more often not stuff is just dropped on us and we now have to figure out how to deal with

it sometimes we'll ask for a design dock but most of the time we're just figuring out amongst ourselves if it seems like a good idea because of this we struggle to keep a consistent model in our head about how everything interacts with each other especially once this new proposed feature is added we don't have a clear road map or anything due to our contributions being from motivated players and not people paid to push the design of the game and even when we do notice problems huge pull requests like circuits often don't get denied people pour a lot of work and not uncommonly money into these and on a human level it just kind of feels bad to be the one person responsible for letting all of that go to waste we've done our best to resolve these problems over the years maintainers are very easy to contact if you're working on a feature and we are starting to amass a large amount of design documents though presently they're only really for very large features and they're not required this lets us discuss and iron out our thoughts more into a better feature but my goal is not to scare you off from open source game development because we did go back to circuits there

were these so circuits we're gonna get it right this time in early 2021 i wrote this crew design document on the second iteration of circuits it's rough our design dock process is as informal as it gets but i wrote it it's based very much around the failings of the first iteration and clearly documents what won't be added but here's where open source gets interesting because i made the document but i didn't make the code someone else saw the design doc posted and decided to write the 7 000 lines of code it took to get it into the game this itself is not uncommon either not all players can or will code but ideas getting passed around to other interested people happens all the time remember one of the best parts about our open source model is that players are working on the features while designers are the ones to approve them so from there just like most features we make pull requests come in from tens of different contributors all adding new stuff fixing bugs and changing what's already there we've got nearly 100 pull requests for just this version of

circuit specifically and now that we have a design document even a rough one maintainers know what features should and shouldn't be added helping us to protect them from removal again all in all this feature is what it is today thanks to the work of maybe about a hundred motivated contributors so as you've seen open source and open contribution development helps us to amass a large amount of contributions but at a large enough scale it comes at the cost of it being fairly difficult to maintain a consistent path for the game but it also carries the additional cost of the work required to maintain those features such as code or balancing along with requesting design documents for larger features we also have other ways to keep quality control one problem we get is that a lot of people are excited to make features for the game but not so keen on maintaining them features having bugs being pushed to production isn't a new problem they need to get in eventually after all but it's a worse problem the longer these bugs stick around especially since we're 100 volunteer work and not uncommonly

the only person who understands the code is the one who wrote it in worst case scenarios this leads to features just getting outright removed that's what you see on the screenshot right now both of those had some fairly big big problems to them that just nobody was fixing so our solution to this is pr balances and here's how it works the core of it is that every contributor has a score the score goes up for contributors that help maintain the code base and you spend your points on prs that will require more maintenance such as adding new features so let's say that i'm a new contributor and i made this brand new feature right now i start at zero points when my feature gets merged i spend 10 and now i'm at negative 10 points from there if i make another feature maintainers will be notified of that it doesn't close the pr and it doesn't mean that it will get closed but it acts as a warning to us or if i instead submit a coder factor then i'll gain back that 10 points when it gets merged now i can make features again without the warning the system works quite well we reward positive

changes like bug fixes quality of life improvements improved accessibility etc while still being able to gain consistent features from those who we can trust to maintain them in fact if you're interested i turn it into a github action it's a bit strange to set up but you can look at our repository to see how it works or file an issue requesting documentation so one of the obvious downsides of open source is your source is open the fact that anyone can read the code and know every single bit of information there is limits our design a fair bit things like damage numbers spawn chances all of that are easily searchable we recognize this in features we make such as this one which lets you examine an item to see how much damage it does rather than just try it and see because pull requests represent individual changes it's also not terribly difficult to keep up with them as a player who wants to be able to gain an advantage some players will try to form strategies around changes before they're even merged and of course we can't really do truly mysterious designs such as say destiny 2 rays being intentionally fairly esoteric

at times if it's puzzles you might be thinking we can just put the secret stuff somewhere else in fact goon station does exactly that and we have the basis for a system like that but because the rest of the code is open to contribution it's possible to cause bugs in the secret stuff that at best only a small handful of people even have the ability to fix and at worst won't show up in unit testing since that only has the public source code but i'm not even really talking about the obvious stuff like this when i refer to mysterious design i'm also referring to the fact that if we send you a message saying you don't feel well a good chunk of players will in that moment literally just search that text in the source code and find out exactly what's wrong with them but just because we have this limitation doesn't mean good doesn't come out of it so because players have have access to every little detail about the game our wiki is really in depth pages have all the stats you'd want to know if you're digging deep into the game what you're looking at is our page for chemical reactions all of what you

see should be automatically generated from the recipe code itself but there's one downside that i think is intrinsic to open contribution that you won't find in traditional game development at least not truly independent ones and i like to call it the every change as a username problem it's about how people react to controversial changes in our open contribution environment so for the sake of example let's pretend that space station 13 isn't run in broad daylight but instead is a product of a game studio a closed source product we're calling the studio toolbox games and the developers at toolbox games have a change they want to make they want to remove nanites they know that this is going to be really controversial a lot of people really like nanites and apart from them removing a big piece of content from any game doesn't often draw applause but they've gone through the rigmarole of ensuring that there isn't any other choice this controversial change has to unfortunately get made eventually this change gets announced and people aren't happy i mean we expected that but the important bit here is that while they're angry their complaints are directed at toolbox games or maybe even just space station 13. the

actual people the humans behind the change don't have the hostilities directed at them personally they're directed at the game at large and sure developers read forums and reddits and all types of social media religiously and it sucks seeing a lot of people really upset about the work that you know is going to be good for the long term even if everyone's mad about it now but this changes in the context of open pull requests because in open pull requests they show who made it they showed the individual who felt motivated enough to make that controversial change meaning the abuse is a lot more directed and mind you there can still be a lot of people behind the change but eventually someone has to open the pull request and idly reading players aren't going to know the full context behind a change or even be expected to read the motivations behind them what you're seeing on the screen is all chat logs directly from the game and even though this change was made like a year ago i still get a ton of direct harassment over this i like the one the bottom left that guy came up to me in the middle of the game like roleplaying and asked me

why i removed nanites i don't think he's malicious at all i just thought it was funny but this can be a huge problem depending on your community it's especially a problem for us in specific where we make a big deal about separating the concerns of the game servers from the concerns of the code base so people like this don't often end up getting banned in game and we don't control the game subreddit or anything like that but we do take this problem really seriously and we do take some steps to mitigate it our lead maintainers along with their usual duties of trying to manage the project at large also take the role of public relations they're often on the forefront advertising and defending controversial changes which means that a lot of the blame shifts to them rather than the contributors this helps shield both ordinary contributors and maintainers whose names are often forgotten in the hostile discourse we make huge use of github moderation to block people who are just being toxic or otherwise provocative on pull requests github seems to take ban evasion pretty seriously and we haven't had a problem with people doing it to try to disrupt the code base this only affects github

though as i said before our moderation of the code base is separate from the game but we also don't control any third-party social media and it also thought i'd throw this one in here that being a maintainer can kind of suck sometimes if you're part of any open source project make sure your maintainers get the appreciation they deserve for the usually stressful and thankless work that they put in so while open source game development has its flaws it still creates massively interesting design by virtue of the fact that players play such an important role in its future open source game development also is the best way to support derivatives or mods i only briefly touched on them but all the different forks just the fact that they exist help constantly push the bounds on what we think space station 13 can be and space station 13 is also only what it is today thanks to open source game development and i would be super excited to see this space develop outside of our little corner that's that

there's a microphone there if there's any questions hey so i'd like to hear more about pretty much everything about uh assets so you mentioned they're all creative commons licensed as well uh attracting non-code con contributors is kind of the worst part of every open source project so uh about that about what you're using for a library because all the open source asset libraries suck like everything about assets would be great a whole new talk oh so is your question in regards to how we get spriters and such to contribute or just non-code in general all of it sure okay whatever you're gonna talk about so um for sound effects specifically this is kind of the only part where we actually do use um like third-party assets uh we often use like public domain free sounds or we use things that are available with attribution for sprites really hard um we can't use anything we

see online we have this you know 32 by 32 icons we have a specific art cell we're trying to maintain um the best i can say for that is we got really lucky by having a ton of really talented people contributing art um the only method that i would say is slightly interesting to open source specifically is that um sometimes when writing a feature if you can't make sprites will kind of let you in if they're good enough and then eventually someone sees that and it ticks them off enough to replace it with a good sprite uh and also sometimes we have like bounties on making sprites that replace old ones what are you using for an asset library uh what do you mean by that where are you storing all that oh um this is kind of a game engine specific thing for us it's just like a clumped icons folder like we don't get access to like you know like texture unpacker or like third-party tools it's kind of just all built into our engine kind of okay lee um it sends the

like a resource file with all the sprites when you actually connect i don't know if that answers your question no that's cool yeah uh we have an open source sig meetup on thursday so hope to see you there cool hi i had a question about um secrets as in like say maintaining the database the logs running servers and stuff like that um one of my concerns with open source is that i mean everybody can see everything about say my data my prod database keys and all of this kind of security issues that i find concerning how does the game handle that are you asking about in terms of like stopping cheaters or you're asking in terms of like storing passwords and stuff basically who is running these servers who is maintaining and paying for them and when basically if people are deving them using on local environments there's all sorts of just

um they would have to see the nooks and crannies of this in a way that yes it could lead to hacking it could lead to all sorts of problems with just all the shared servers and who's maintaining this how exactly does that ecosystem work if it's all open contributors so in terms of the code base itself um we have like configuration files that are not we have configuration files that are on the repository as like templates but with different information on the actual servers so passwords and stuff aren't stored um in terms of who's running the servers right now it's one guy um who is just really really good at sysadmin and stuff and has been pretty good about like stopping ddos attacks that kind of thing um as for cheating uh i'm assuming that is in regards to how it's a lot easier to find out like exploits and things by reading source code um our answer for that is when we do see like a new exploit um it happened

this week actually of like there was like a server crashing bug that was actually related to our code itself because we have so many eyes on this code base at any given point the problem was identified in like 15 seconds and a pull request was made in like a minute um of course that doesn't extend to everything and of course some cheats are kind of just like problematic with the game engine itself or like um if you're a game that has a lot stronger control of the client than we do then client-side cheats are kind of more or less unsolvable without like you know vanguard and that type of like overlapping stuff um finding exploits definitely happens but uh we're pretty good about fixing them does that help answer the question cool [Music] you