Making Night in the Woods Better with Open Source

[Music] hi everyone oh right this is going to be fun um hi uh my name is John Manning and this is May um let's talk about how to get other people to fix your bugs for you um I am 50% of a Game Dev studio called secret lab we're based in Tasmania Australia uh and I'm working on a small game called lean's moonship which is an adventure game with a really pretty handdrawn look we're really excited about it awesome I'm also an author uh we recently wrote a book on kbal Space Program this is a Shameless plug please go buy it uh and also more importantly I'm helping on Night in the Woods which shipped last [Applause] week and uh it did pretty well in fact one of the ways that we know that it did pretty well is because aby's tweeted about it and we don't know why um so yeah that was really really fun um so n in the woods was developed by infinite fall and published by Fini who were some

rad people and um massive massive thanks to everyone involved and particular thanks to aelle in the pit who did all the amazing sound um so Night in the Woods if you don't know is a adventury platformy type emotion game um it's a game about this cat and today we'll be talking about how open uh how Night in the Woods work with the Open Source process why you should do it how to do it well and also how to maximize the benefit that you get out of it so Night in the Woods hit a problem and that is dialogue is really big and really tough to manage uh the word count in night the woods is ridiculous and to manage it a tool called yarn spinner was written and open sourced which I'll talk about that first and then I'll talk more broadly about open sourcing and then ways uh you as an independent developer can take advantage of that so we have about 130 unique characters lots of dialogue um we have about 13979 words in the game not counting any code or character names um dialogue in

these kinds of games is either typically node driven or scripted so by node driven I mean each line or choice is created in some kind of visual editor and each node is connected up uh chat mapper uh is a really good example of that uh the other the other alternative is scripting where you basically write code that describes how the dialogue Works node driven is really intuitive but can be quite clunky but there's a lot of dialogue it's difficult to manage in a very graphical way uh by contrast scripting is it requires you to learn a whole other language and depending on the complexity Scott Benson and Bethy hackenberry who were the writers of the game didn't have time to learn a new complex system on top of what they were doing already cuz uh Scott was doing all the art as well so writing I believe should require the least amount of coding as possible you don't want to have to additionally burden your team so we noticed that one of the most popular game tools currently available is

designed for non-programmers and that is twine um who loves twine by the way yay twine's awesome so twine is increasingly being used by people who don't know programming but do want to tell a story and Twine syntax is really really sparse and focuses on letting you write so this approach was perfect for managing night thewoods content Yan is the editor that we built uh on based on the ideas deel in twine it lets you create text files that get loaded into the unit based game engine and in the game we wrote a library called Yan spinner that does the passing and the compilation and execution and we'll come back to Yan spinner in a moment here's an example of some of the Yar code we did in the game so you can see how the amount of syntax required for a conversation is really really sparse and minimal so Yan became the scripting language that ran the entire plot of the game um we have a lot of additional small commands that just make acting happen that set some game State and

things like that most of the game I would say is written in Yan the the US visible stuff anyway some very cool features that were specific to dialogue heavy games like Night in the Woods got added to the syntax of the language halfway through that was really powerful and really great so like this really really simple Choice syntax which helped the writers create lots and lots of branching dialogue very easily so we can just pop up a dialog box and select uh an option and then easily write with a lot of player choice so basically the entire game is written in Yan all the dialogue all the cut scenes all the high level game logic and in fact the game save files are mainly a dump of all the variables that Yan knows about the Yan tool was put up on GitHub uh with no license which is not great for reasons I'll talk about um so it was on GitHub at that point me I discovered it and went okay this is really cool um maybe I can improve it and I did and it

turned into Yan spinner which is a totally separate and independent Library which had a more robust passer some better tools better error handling W localization and other good stuff and others started contributing to Jan spinner as well uh so we got things like multiple type variables where previously there were all integers and Bug fixes and all of these changes were able to emerge Straight Into Night in the Woods so if you go to this page you can find more information it also has a link to the GitHub it's kind of great basically Yar spin is awesome and I think everyone should go and use it right right now so yeah so it worked for Night in the Woods why should you do it though on your game and how are you going to make it more likely to get a good outcome so first of all big thanks to Paul Fenwick who created the C Canon project for cob Space Program uh a lot of this information is from a conversation that I had with him when a project is open- sourced it's guaranteed that if the author vanishes that won't kill the project I happen to think that this is the most important reason to open source

anything aside from the personal benefits to the core devs additionally when you open source code you make it more likely that others are going to use it critically for you it means that you let other people fix your bugs that's less work that you have to do now a lot of people are only aware of Open Source because they grab the stuff from GitHub and with good reason because it's free so you don't have to pay for anything and it's often quite good and it's free so you don't have to pay for anything um but GitHub isn't where open source starts and ends so I've given given you some reasons why open sourcing is good in principle let's talk about some practical things you can do to get the most out of doing it first of all let's define what we're trying to get out of this you're busy working on your game and that means your primary goal for releasing code during your production is to get contributions which translates to community done features and Bug fixes that you didn't have to do yourself so's let's look at how we can do this the critical thing

for building any kind of community of people who want to fix your bugs for you is to make it as easy as possible for them to make those contributions so talk about two main categories for this technical things you can do and things you can do to improve the emotional and social experience of those contributors so that people come back after all your goal here is to attract help so a great way to start is to put your code somewhere where people are familiar so GitHub has kind of won this kind of battle but it isn't the only one bitbucket is also great as is gitlab the reason why you want to do this is the popular code hosting sites not only are a great place to just dump your code but also they have built-in social features which can really help your community so GitHub has the biggest thing because of the network effect but bit buuck and gitlab are competing quite well on technical features at the moment this is the slide that I want you to pay most attention to you need to have a license if you release code AS open source it's the most most important

thing to take away from this you you need to let people know whether they can make changes additionally if there's no license it's unclear if they can even use your code in their games there are basically two types of licenses available for you to choose from copy left and permissive a copy left license is designed to make the idea and the philosophy of Open Source spread so the idea behind copy left is if I use copy left license code in my game then I must release my game under the same license as open source so the GPL the general public license is a really good and famous example of this usually games tend not to use copy left licenses because of this and additionally some engines especially the Unreal Engine specifically says you cannot use code that under GPL in your project because doing so would require you to release the entire game Source including unreal under GPL and epic say no thank you so by contrast permissive licenses say that you're allowed to release derived closed Source versions

in other words use it in your game without having to release your game as open source so these are generally more commonly used in games usually the only thing that they need is attribution and just you know uh acknowledgement that you are not going to try and sue them for warranty stuff but you're busy you're working on your own game you don't want to have to think about which license to pick in which case people generally go with MIT or the Apache 2 license so I'll talk a little bit about those in a bit more detail detail uh MIT is the simplest one you have probably seen it around all it says is you can do whatever you like as long as you give attribution and are aware that the author offers no warranty support um I'm paraphrasing please read the license itself for the details Apache 2 is more complex but it's also more thorough uh it gives a more complete job of explaining the user's rights and it also grants the recipients of the code a patent grant for anything in the code that is patented that's very useful to have because you can up in situations

where you have the source code to something but you can't use it because you don't hold the patent license to do it so um yeah Apache 2 includes a specific Grant saying also you get to use whatever patterns apply to this code if you don't care at all a lot of people default to going with Apache 2 because it's fairly straightforward and offers the most Clarity to your users so that's often what I go with but make your own decisions next up have a contributor's guide you need one of these this is second on my list of things you should know about a contributor's guide offers guidance on how someone can make a contribution both technically as well as socially so interacting with other people on the project it tells them what is expected in their contributions who to talk to for help and also how to get started it really reduces the daunting of a person's first contribution critically it should also direct people to your code of conduct which I'll come to in a bit if you're using GitHub then if you

have your contributor's guide in a file called contributing.md then GitHub will actually link to that file whenever you go to post an issue which is a really great way to get people you know directed to that uh to that document a really another really good reason for putting a code on a servers like GitHub and bitbucket is it keeps your code and your bug tracker in the same place that's really awesome so it's much easier to deal with both the code and the issues when you don't have to jump between them uh reduces the friction and again reducing reducing the friction means fewer people get discouraged which means more contributions have a central place where people can go to talk about your project a slack an IRC anything that lets people chat what's really important about this one is you should be present there that doesn't mean be on call or reply to every single question instantly but it's really really reassuring to see that the creator of the project is invested enough to want to be reachable make a list of very very lwh

hanging fruit easy bugs simple things that a person who's brand new can get started doing right away um make this very visible put it in your contributor guide maybe even put it in your readme and E and direct people who come to you who say I want to help out say well then here's our list of things you can do right now so easy bugs um is one part of it you can also direct people to look at your existing bug list and ask them to Mark the bugs as easy sounding or hard sounding that's a thing that doesn't really require a huge amount of knowledge of the project um but it you know it gets people going gets people ready and finally documentation updates uh are also a great source of non-technical contributions on the flip side to this it means that you as the developer should focus on the stuff that requires the knowledge of the code and to resist the temptation to work on the easy stuff yourself get other people to take care of the easy stuff for you and free yourself up if someone comes to you saying hey could

you add this cool feature I'd really appreciate it and you don't want to do it yourself you should immediately reply no but we'd love that then refer to them refer them to your contributor's guide or to an open ticket in the bug tracker or even make a new ticket for them and then aim them at it so this helps to bring people in because if they're able to they're more likely to add the feature themselves one thing that a lot of Open Source projects have discovered is even just noting that a a feature is desired can be enough to bring people in now it's important to realize that and remember that contributions to your open source project aren't always source code bugs documentations and feature ideas are all just as valid as the code anytime anyone adds anything to your project you should notice them you should thank them you should promote them and you should make them feel wanted and welcome they'll stick around for best results you should prepare yourself for when someone comes in so that you know what steps to take so let's talk about what those steps are you should have a pre-prepared induction

process this is not a big complicated thing just have a list of steps that you follow for when someone else comes along when someone comes along and makes any kind of contribution even just a post on your Forum saying this is awesome welcome them immediately and thank them for whatever their contribution was if it's their first contribution you really really want to accept it if this is their first chunk of code or pull request accept it even if it's bad people will feel accepted and and will get them excited to do more Additionally you can modify their contribution before you merge it into the main branch people don't mind when that happens in fact they love feeling like they're being given you know more information on how things work it feels like they're bring being brought into the fold so yeah this is kind of non obvious but I hope that you do it third on the list of things that you really should know have a code of conduct I I hope that this is not like an amazing news flash but you really should have a code of conduct conduct

because if you have a successful project then at some point there will be some sort of incident that will be considered inappropriate uh if you have a code of conduct then you have a clear document to point to on how these things are to be dealt with and if you don't have one then what will result is an endless and exhausting discussion on whether that was appropriate what to do and so on and so forth so this is a tool for you it's not a hammer with which to you know Club people who say something sexist it's this is a thing that you can use because when the these kinds of incidents happen they create a ludicrous debate and they sap your will to live imagine if you decided on your bracing style for your source code halfway through development imagine the conversation that that would result in it's the same kind of thing so give people the ability and the power to point to the code of conduct and to shut people down on your behalf so it shouldn't be up to you to police it you can make the policing power available to your community by having a code of conduct and also the ability to lock threads and such

don't worry too much about somebody going off in a half um so if someone uh says well I don't like your code of conduct and I don't like the fact that I can't call people bad things I'm going to take your source code and go and do my own damn thing and that sounds bad but actually that that can be often okay because if they take their code and take your code rather and uh want to run it in a different way and do their own contributions then they'll probably keep it under the same license especially if it's a per a permissive license and then you can just merge those good stuff back if you even if they they do in the first place um in fact there are more than a couple of examples of Open Source projects outside of games uh where the project had a hostile fork and then it actually later completely remerged back into the main thing after everyone had cooled down with more good stuff so at the end of the day what you care about is contributions it's better to let the toxicity happen somewhere else if you can't stop it entirely so it's possible that you might think well this is a big burdensome thing but I guarantee that if your project is any kind of success then

you'll end up citing this code of conduct at least once without a code of conduct then nice people will disappear from your community and that is the worst thing that can happen when your community is brand new because a Cod of contact isn't the same thing as saying you can't swear it's saying you can't use racial flows it also indicates that it that you are serious about the project because saying that participating in your community requires a thick skin indicates your community is toxic and being in games I think we know a bit about that kind of thing so make it part of your induction process If someone becomes a core contributor make it very very clear to them that they are expected to enforce the code of conduct as well make it clear to them that it's as important as welcoming newcomers or having good coding standards um if you don't know where to start with the code of conduct the contribut a covenant look it up is uh fantastic it's a great template you can just copy it and use it in fact that's encouraged so please adopt a code of conduct so you might be thinking wow this is a lot to deal with you're a really busy person and you don't want to have to take on a second job that's why

we're going to talk about ways to reduce the burden on you as a developer so how do you as somebody who wants to get cont contributions reduce the amount of work that you need to put in in order to get good outcomes first make a list of stuff that you want not just a future road map just like a unstructured list of things it would be nice to have and then publish it so this gives people an idea of the kind of help that you're looking for when people if when people come to help you say yes doesn't matter who they are this is fairly obvious advice but it tends to happen not as often as you'd think because of the problem of people's egos people tend to get quite defensive of how their project is run so I would strongly advise you to just take whatever help arrives and merge every pool request you can find unless it's obviously incredibly incompatible give people the permission to do what they need to do so for example make people ators make people admins give them

permission to merge pool requests for you give them permission to integrate into whatever workflow you have it's very very difficult to screw things up completely when you're using git um you can always roll back say yes to people especially if they want to automate stuff because if somebody wants to set up a build server say yes and give them API keys if someone wants to create a bot that posts when new issues have been uh filed give them give them permission say yes cuz getting hung up on how you want your project to be run while you're already busy working on your game is a very easy way to run out of energy for both of them and allowing somebody else to help you out is your main goal here don't get picky if you're faced with the choice of either not doing something at all or doing it in somebody else's way that you don't agree with do it somebody else's way it's okay for mediocre contributions to happen because you can always come back and fix it your only question

should be is this contribution better than what it was before don't wait for the perfect contribution accept the okay contribution even to the point of accepting technical debt because you can always accept the later contribution from somebody else that fixes it the only way that you can encourage people to take the first step to contributing to your project is to make sure that first step is not burdensome make things easier to do in fact find things that are easier people to do take the tasks and break them up to smaller tasks as well well leave them in the issue tracker like tantalizing plums so an even better way to get a feel for how to run an open source project is to contribute something to an open source project yourself doesn't have to be much doesn't even have to be a long-term commitment just you know push something to an open source repo that you have liked even if it's nothing more than you fix a typo in the read me additionally uh if you participate in open source stuff you it's a really great way to uh add stuff to your list of contributions uh if you ever want to participate in

capitalism so um it's a really great way to develop street cred and make yourself known in this kind of community so marketing is as important for this kind of thing as it is your game you already have an existing marketing setup right right um so use all that existing stuff Twitter Word of Mouth even do screenshot Saturday um I did and Jan is a text based thing I just took screenshot of text it worked um uh also Chris D who did the marketing for Night in the Woods uh had a session yesterday if you weren't there go get it on the Vault it's fantastic um put the call out for help just ask for help just say I'm looking for help people will respond you can also encourage people to turn up by saying this is going to be great I love my project but it'll be go gosh it' be even better if I had this other thing as well more often than not that tends to have someone who already knows about the thing come along and say oh cool how you doing it and then you can assign them to the project um this

also ties into people feeling appreciated and included Additionally you should automate as much as you can if you have time to do it because and also if you don't have time to do it then ask somebody else to do it so things like build servers or a bot that closes the stale issues or also a bot that announces when a new release is available you can also even automate bits of your community so a lot of the social stuff can be automated as well the rust language project does this really well uh when per when someone sub mits their very first pull request to the project where they contribute code a bot replies to them right away with a welcome message thanking them and then sending them to the contributor's guide and the code of contct and everything they need to get started it also pings a human who is then assigned to this newcomer to help them through the process and it also this bot's quite clever it also reassigns that human um if uh either of the parties don't reply in time even a bot that just says thank you can be

enough okay so GitHub the company uh released this fairly recently open source. guide um and this goes into much more detail about the kinds of things we've talked about today um so I strongly suggest you check this out op source. guu I'll leave it up there I see people taking photos um you should open source parts of your game during production it can be really rewarding it's not completely effort free for you you can't just dump stuff on GitHub and wait for the bug fix to roll in that it doesn't quite work like that if you want to get something out of it there's some work to do but it's not as big as you might imagine it doesn't have to be a long-term massive commitment it made Night in the Woods production much much better and I think that it can make yours better as well so thank you all very much for listening um yeah follow me on Twitter you'll see in a second and tell me about your awesome open source project thank you

[Applause] so if you have a question I think we have a bit of time um if you can go to the mics that' be awesome oh yeah in case it wasn't obvious this is all in engine as well so now we're playing Night in the Woods uh you were there first yes hello hi um so I was wondering uh about contributor license agreements because you didn't bring that up um so if someone writes a chunk of code you put it in your game and they didn't assign copyright to you right what do you do okay so okay I should preface this with I am not a lawyer let alone a copyright lawyer so this none of this is legal advice however I can tell you what has worked for me in the past um assignation of copyright turns out to be way more complicated than you might expect especially when it comes to stuff like you know Estates if the person dies um so what we did on Yan spinner is we said um any contribution must be licensed

under MIT that's all you need so the copyright for Yar spinner is actually copyright secret lab which is me and yarn spinner contributors that way you have the right to use it in your game people have the right to use the code everyone goes I'm happy it's great so yeah you don't necessarily in my opinion need to assign copyright but again your knowledge may vary thanks Co hi what's your name hi I'm Jeremy hi um what are uh what's an example you saying there are some classic examples of a a community splitting and forking and then that fork uh after everyone cooled down sort of got reintegrated back into the original uh project and I was wondering if there's a a particular example that shines I know that the uh the The Gnome project which is a desktop um uh application suite and Al it's it's a desktop not just applications uh has had multiple Forks over its lifetime um and usually whatever Patches from the have filtered back into the main project uh

there are a couple but I can't really recall them off top of my head it doesn't happen very often but it has happened ghost mels thank you got to take shelter uh yes hi what's your name uh my name is jilan um so I work for a company in Ohio and like we do contract work with people in California and I'm really surprised that how similar it is that we have like the same problems and the same issues uh working from Studio to Studio with open SCE cord so I feel like that the biggest problem that we have is like two people will be working on the same problem at the same time and at the end they have to choose okay which solution do we have which code is better than this so do you have the same issue like not really um this is really a problem that's solved by really really open communication Additionally the fact that you can uh create a branch and publicly push code as the solution is being done like it's if the solution is so small that you could have done it on your own in a

single commit then really I don't think that's as big of a problem but you know this is really a thing that you solve by uh having the two teams uh work in the same repo yeah I have a second thing so I do a game development on Twitch and uh it used to be people doing game development twitch would just do their own project and they people would just watch them but now it's turning into this community effort where people in chat are doing the code with the the coder and adding audio and adding art and stuff like that so if people want to be part of projects like this twitch is a great place to go to and be part of a community so are you talking about live coding uh collaboration or are you just talking whoa um or are you talking about just general working together it's both yeah there there's a large spectrum of that you know sometimes it's really focused sometimes it's like open for anybody so um so on the second point which is um just collaboration on the same project um just jump into any project that pops up on GitHub explore or anything like that and yeah you'll be able to find something to contribute to and just get

you know part of that Community I'm less familiar with the with the live coding stuff but I kind of want to get into that myself okay cool hi what's your name uh Sienna lley hello hi so uh first thanks for the talk I thought it was uh very good um and I'm I'm curious to hear a little more about some techniques that have worked for you for when it's a good idea to Spotlight specific issues and which uh Channel you've decided to Spotlight them from because my open source project has several hundred uh contributors so we do have like utilize a lot of tags and stuff within the uh with within GitHub but um I'm curious to hear more about uh approaching other channels to Spotlight specific issues so you're talking about like where to go to find more people to contribute yes who are outside of the community that you already have I think that you should rely on the same kind of of techniques that you use for the game

itself so just you know don't limit your discussion of the project to people who already would be interest from doing it go to um your personal Twitter go to your games like your Studios Twitter and just say hey by the way in addition to the game we're working on we also do this if you're coder then please jump in um really it's just a matter of running around and yelling about it as much as you can everywhere you can and that's yeah that's really it thank you very much you're welcome I think that's it for questions so uh thank you all so much again for coming and uh [Music] yeah thank you