[Music] hi there i'm chevin um welcome to growing your code library with each new project um my twitter handle there if you want to follow me after the talk or ask any follow-up questions that's totally fine a little bit about me i make games primarily as a freelancer i'm also working on a game called mid-autumn right now which i'll talk about at a later point um so when i say i work as a freelancer what that means is i don't work for any particular studio most of the time i mostly um have in the in my his my career in games worked for a variety of studios on a contract basis sometimes that's like a week sometimes that's a month sometimes it's six months um and as i've kind of made my my career in games i'm sure in you know games career seminar you're going to see a lot of different ways that that people have careers and games but for me
i've noticed that what's really helped me is to in the same way that a lot of big studios have their proprietary technology that they develop over time to do something similar as an individual is to kind of take the stuff that i worked on and use that to help me make games faster and more easily and that's kind of what i'm planning to talk about um when i say code libraries so um a couple caveats up at the top pardon the pun um you know i'm just one person my opinion at the end of the day um might not be right for everyone so if you're watching this talk and what i'm saying really doesn't make sense for you feel free to ignore that advice um what i'm trying to offer here is um tools that help me address kind of the complexity of making games um often you know remotely with just you in
the room which is um very difficult when you don't have people to bounce ideas off of or anything like that so if that's something you're struggling with and you don't know how to approach that um here are some potential ways to address that so um big sweeping statement right at the top of the talk is making games is super hard already we don't have to make it harder on ourselves i think sorry i bumped the mic but um i remember when pokemon sword and shield came out um game freak got a ton of flack for daring to reuse their pokemon models across all their games and i'm here to say like absolutely do that that's exactly the way we should be making games people know what pikachu look like like like people know what pikachu looks like you don't have to like make a hundred different variety variations of things and reinvent the wheel every single time um you know if you if you have a chair in your game and and no one's gonna notice reuse it
if you have a dialog system it's gonna work the exact same way reuse it and that's the main philosophical kind of underpinning that i'm trying to um get across at the top of this talk is things are hard make them easier on yourself reuse things so you know i remember finishing my first project in games and and it was you know daunting to say the least but at the end of the day i think i got through it just because there was so much i didn't know uh and and i didn't really know enough to psych myself out but once that happens and you realize oh i have to make another game if you want a career in games you're going to be making a lot of games so um it's a lot harder the second time around because you know exactly what goes into games you know it went into the first one um and if you're stuck at this point i'm here to say you know there's a flip side is now that you've made at least one game
you are more infinitely more able to prepare and um i haven't just used this gif of batman here to be cute um i think this is a great analogy for for how you can approach things to make things easier on yourself right and it's clip batman's on the ocean and a freaking shark appears out of nowhere and he just has shark propellant in his utility belt like that he's he had prepared from long ago and i'm saying that we can totally be like batman now imagine that a game is just you know some combination of sharks um these are problems you have to solve or or features you have to implement or whatever they're all sharks now um you just have to do the exact same process right you you make sure that you have your bat shark repellent prepared and in this case we're going to be talking about co templates they go in a place you can find them easily right then that's your utility belt and when that shark shows up you just you you know pop that out of your utility belt
and you're good to go you know obviously that's that's an oversimplification but um you know when i'm talking about a code library what i mean is essentially a collection of helpful resources right and they should be reusable i'm probably going to be saying reusable a lot in this talk so i've bolded it it should be you know backed up somewhere you can access and i'm primarily going to be talking about code templates or pre-written code but it really can just be things that help you out so if you like using a particular software and you want to be able to access that easily if you have particular settings you like for that software you know then you want to write that down somewhere some kind of documentation or links to articles or videos that's all like that should all go in your code library in my opinion um so essentially you know going back to the shark repellent metaphor you want to make sure
that everything in your code library is again reusable but it should solve a specific problem um you know like the shark repellent is so like you know because it only fixes sharks and it doesn't solve anything else um it's lightweight it doesn't need a ton of setup you know self-contained and it can be combined with other things easily that's like the ideal um thing to go in your code library so let's talk a bit about how how you might maintain a code library right so what definitely doesn't go in um you know you don't want to put in full project files or like really specific kind of fiddly systems that are designed to solve something that won't appear in other projects um but as a you know as a counterpoint you should absolutely still keep access to these things because you might realize oh you need this exact thing from this
other project that that you wouldn't ever have guessed you need and in that case don't go to your code library go to your actual project get that specific thing and then check it in your new project but definitely keep out things you don't own or are not licensed to use or something that you know you currently are licensed to use but might become a headache in the future you know keep your code library you know helpful basically don't don't make it so you have to worry whether you're able to use something or stress out um have it be things that that you can just use at a moment's notice so the the basic process right of making a code library is is just like it's mainly housekeeping right so um the best time to do it is right after you've finished a project and right before you're starting a project however you know long that stretch is between those two points um you're gonna look for some code or or some assets in
an older project that you'll think you'll want to reuse you're going to get rid of any elements that tie that to that specific project you're going to make it really gener generalized so you can use it in a variety of different projects you're going to just name it something that you can find really easily um i mentioned this step because i think often when we're working on a project the code or assets or whatever are really specifically named so if you want to generalize that as well and then just store it somewhere you can easily access um in some way you can intuitively find it right so like make sure that you have a file organization system and i'll get into that a bit later um and like the main note here is don't worry about getting it perfect this is just like you know a habit that is good to cultivate um you know when you do it you spend a few hours spend a day on it and it's okay if you don't generalize it that well or if you overlook something right you want to think of this in terms of like a career-wide
span of time so each time you finish a project you're going to have an opportunity to review that revisit that and realize oh okay this actually was way too cumbersome to use and i'm gonna either get rid of it i'm gonna change it and you're gonna have plenty of opportunities to do that so um i'm gonna talk about how i kind of think about identifying things to go in a code library um so here is a non-shark based model of a game this is kind of based on how a lot of mobile studios kind of think about games but this is you know 50 i made this up for this talk so um it goes pieces core loop metal loop accompanying systems and i'm going to get into this so um here is an image from queen's gambit to help me out so um imagine the game of chess and you have your chessboard and your pieces and those are what i'm coining as game pieces so these are just
things that kind of go into your game things like character controllers or health systems or physics they're um you know the kind of building blocks right of your game um and then you go out a bit wider and you get what is your core loop right that's like the game of chess um those are things like your rules and your procedures so um if you you know if you're familiar with game managers or resource systems or loop drops they're the things that take your game pieces and turn them into a game um and then you have your metal loop um and i like to think of that as the you know a chess tournament right chess has its own rules but this is the meta game around chess that you're that you're trying to also um progress through so that's things like you know managers for your over world or your hub progression systems quests um different ways to kind of progress on a meta level um and then you have um accompanying systems which i think of as a tournament venue right like this is like not
necessarily even have to be used for chess this building or whatever so um these are things like your menus um you know localizing for different languages things to help with that button prompt saving systems these really could go in any game but are pretty much you know needed for whatever game you're making um and when you're thinking about games this way right it's really easy to swap things out well you can have a completely different metal loop on top of a core loop which means that that's how you're going to reuse a lot of these systems when you've identified these scripts and put them into place so um where now that you have right you've found some and you've identified some code where are you going to store it um you could use version control uh you know there's git perforce mercurial and you could use cloud storage um google drive so i'm going to be sharing some examples of like a code library later in this talk and i've just put it up on google drive
because that was easy for me um it really is just like use what is makes sense to you for you what's accessible um which is like what i'm gonna say a lot in this talk basically do do what works for you um so once you yeah once you know where to put it you're gonna organize it you know you can organize a lot around a lot of different ways i primarily organize it around systems so like i'll have a folder that says dialog or folders as menus or safer load and those will have you know a bunch of scripts that might be um you know dependent on each other which means i can just take all those things drag it into my project and um hopefully they'll all work but here's some potential other options right you could organize it around tasks right some people like to think of things in terms of what they're doing at the moment so you could have a bunch of scripts um that are helpful for when you're prototyping or whether you're building levels or animating um and and this might have a bit more
repetition of the types of things in there but that's also a different way to do it you could organize it around the game structure that i mentioned earlier right so the game pieces core loop metal loop etc if that helps you that definitely helps me like identify a lot of these things but it's not necessarily my favorite way to organize things because it's kind of hard for me to search uh and then you could organize around type i don't necessarily recommend this um because like you know it's like oh what what is a manager what is a controller uh is kind of can be arbitrary so i don't think it's a very intuitive way to do things um but if this is if this makes sense for you that's a potential option um so time for some examples okay good i'm doing great on time um
so i'm here i'm going to start talking about mid-autumn which is the game i'm working on right now i'm going to use that as some specific examples of of how i make use of my code library so mid-autumn um it's a it's a roguelite uh about blasting evil spirits um and it has a persistent narrative about asian diaspora culture um if you're interested in the game um you follow me on twitter um we're also having a kickstarter later this year and you can you know use that link to get to it um mid autumn underscore ks i realize it's underlined so i guess the underscore isn't obvious um so example number one right let's see how i used um a sound effects controller and i made it reusable between projects um so i'm going to talk about a project that i was working on before mid-autumn called blackcurrant which is just this little puzzle rpg game um that i had
and i had a sound effects controller in it um that plays you know sound effects when i need to and this script is basically just a list of audio clips um it has a couple basic methods so you know it can play an audio clip i can set the volume or the pitch um it also had a couple very specific um methods that's like play a random footstep or play a random blip of dialogue or play a random attack sound um it was also a singleton and um i want to make a quick aside let's talk about singletons um it's basically i'm i can't go into it in this talk but it's a class that you make that's globally accessible and there's only one instance of it and what's really great about singletons is that um you can toss it into a project and all of your other scripts can just
reference it right away so yeah if you need something that's easily accessible for a lot of different scripts only needs to exist once you know it doesn't need a lot of setup that's uh really really useful um and then a warning up top you probably don't want anything or most things in your code library to reference different scripts singleton's included because then you can't just toss it into your project but i definitely recommend reading up on these if if you're interested in making things kind of easier for yourself um so anyway yeah so we have the singleton we have the sound effects controller so um [Music] let's see what did i do here um this is yeah so this is just an overview of the same scripts here so um again list of audio clips here's like some examples of how the um
the methods might work right so i would just write play and i'd have like the type of the sound effect or i'd play a random footstep um and this is what i did to generalize it right so it's still very similar you know i still have a list of audio clips still have that basic play method um i added a couple things that i might want um in other projects um just based on on what i thought might be useful so like you can change the pitch but you can also change the pitch across semitones um you can also it also takes a custom audio clip so in the old one you know i had to add this um i basically every time i want to add a sound effect i had to add to this list of audio clips and that can be kind of cumbersome if you're tossing it into a project so now i can do that or you know if i have another script that has a specific audio clip i can just
like use that as a reference and play that um and then i got rid of all of these specific play random footsteps play random dialogue blitz because i didn't know if my game was going to have footsteps or dialogue or attack i don't know so it's turned into this kind of more general play random method um that just gets fed a list of audio clips so now if i have my character controller it can have a list of footsteps in it and just send it to the sound effects controller with that list and play a random one um and that's kind of the main idea here when you're generalizing these these scripts look for these methods or things that are um that have assumptions about the type of project you're making and take that out right um if if that's helpful so let's see um here is you know another example of how these um methods
work so you can still do like play you know and say the type of sound effect that you want to play or you can you know play random give them right the the list of footsteps from your player class um you can also play um the player's attack sound like and then raise it up three semitones and do whatever you want with that if you want to have your game be more musical so um example number two right is going to be extending the same dialogue system for two different genres so in the past example we talked about that process of generalizing script so now we're going to start from same generalizable script right um and implement them into two projects with different needs so um you're going to start with a dialog system and i'm going to use black current and mid-autumn as specific examples so in black current i just have little speech bubbles that popped up
above the character's head and in mid-autumn we have dialog boxes at the bottom of the screen there's a character on the side of it and their name is is also presented um so under the hood these both use the exact same dialog system or rather the same starting point um so this is the generalized script right it's got a dialogue line which are your lines of dialogue it's a it's technically it's a localized string that i use which is set up for localization uh but let's for ease of purposes let's just say it's just text and then it has a reference to um the speaker you're your actor um the actor has a name it's got a unique id i recommend um having unique ids in a lot of things because um every single time i make a game and then i don't put unique ids and things and then i start trying to save things and reload
things i i just go back and add ids to things because i realize i needed i needed them so that's super useful i'm calling that out um so yeah that's your actor it's basically just the name is is the main thing with the actor and as a reference to it and then we have what is a story beat right so like this is you know hard to name but it's called a story beat because it's just that like kind of segment of story and it's just um a list of dialogue lines right so um your lines or your individual things in the conversation your story beat is just that list of it and it also has a unique id because again that's super helpful um so for black currant um these were the constraints right the dialogue is occurring kind of parallel to gameplay um at times so sometimes you'll be walking around and a speech bubble will appear um all of the dialogue events are fully authored so that means i've gone in and i've
written every single thing and they appear linearly in order as as i expect them um the game has 3d characters they move they have animations uh and the speech bubbles specifically appear over the character who is speaking and i think they're also tinted based on based on which character is speaking so this is what i did to those three generalized scripts um to make it work for for black card so you can see that i if you go and compare this this actor script is now completely gone um and it's been replaced by a character data script which um was just a more robust uh thing that i already had for the characters um the dialogue line now has a reference to character the character data instead of the actor it also added a thing for animation or display time right so now these dialog lines can play an
animation at the same time or they have a reference to it and i can control how long that line appears when that speech bubble appears um and that character data was just this really robust script that you know it moves the characters it um tells the characters what their like you know abilities are but it also already had references to where their you know character was in in space what their color was um so it just made a lot of sense to fold that in into the system and then the story beat class you know just got a couple um like tags essentially like should should the speech bubble advance automatically should it freeze the player in place um should it make like little letter boxes come in for cut scenes um and it's yeah besides the big character data change it's it's not too overwhelmingly different um and um so for mid-autumn right in comparison um the dialogue
it drives gameplay progression so what that means is things will happen based on whether or not you've heard certain dialogue so like you'll get different enemy spawns if you've heard a certain conversation or something like that um and we kind of spawn in everything from a procedural dialogue pool so it's not linear there's a there's a random kind of chance of which conversations you're going to get um and unlike black current the dialogue box is always going to be in the same position on the screen they're 2d characters um they they don't really animate um and each character has a higher resolution portrait so if you look at how this has changed right you'll see that in comparison to black current which had most of the changes in that after character data script to account for the 3d characters you don't need to do that for mid-autumn but i needed to add a ton of stuff to the storybeat class
and i will go through that so like the dialogue line hasn't changed much there's like a portrait index that's there in case you want to use different character portraits um the actors um have nicknames that appear kind of underneath their their name um they also have an associated color they also have a default location so in um blackcurrant i didn't have to worry about that because all of the location where the character is going to be was handled by the the character itself but in mid-autumn i need to place specific characters based on where where they're going to be for the conversation to make sense so needed that i also needed you know references to what how the different portraits they can have um and then yeah the main meat of the change is in the story beat class because of accounting for this procedural narrative elements so um each story beat now has a
reference to the actor not the dialogue line itself um because sorry the dialogue line still has a reference to the actor but the story beat also has it because i need to know which um basically every time um and a different character appears with dialogue i have to go through each of the story beats that are associated with that character and then put a random one in there so the story beats now also need to know um which character it's associated with um they have things like priority so like higher priority story beats will appear sooner than lower priority ones um they're associated to a location and they'll move the character to that location um if that's the story that you've picked they also have these last four things which are like beats to unlock beats to disable prerequisite beats concurrent beats because so much of the gameplay is driven by dialogue events then you need to know like okay
the players heard this conversation what other conversations are now possible or what other conversations should not be possible because they contradict the ones you just had um you know what conversations need to already have occurred for you to hear this one and don't like populate it if they haven't occurred yet and also um are there any conversations that should appear at the same time so like an example of that is um a character telling you hey you should go talk to this person and then you know later on in the hub area you'll run across that particular person and have a conversation with them and you want both of those to be um to be present at the same time even though it's random so that main kind of conclusion here is you can start from this like really simple generic starting point um
which is purposefully right doesn't have a ton of functionality uh because i i don't know what i'm going to actually want to do with each project yet and then they can really really change over the course of development and like you know already the this is like you know open to changing more right like i think i've added um things for like like voice over functionalities here so that's also going into um like the actor script or things like that and and keeping your generalized scripts really simple makes it a lot easier to do stuff like this instead of trying to cram functionality into it okay yeah so example number three is going to be extending a generic enemy controller to add variety really fast right so
um in mid-autumn sorry voice geez in mid-autumn um we started with this generic enemy controller um it's full of virtual methods right and the reason i'm using virtual methods here is that they're kind of not super cumbersome to use um when i let's say i wanted to make a child class right so like let's say i have the enemy controller class and i want to make something like a fast enemy and i had a virtual method called move um the really useful thing about virtual methods is i can change that move method to you know make sense for that new enemy type but if i didn't want to touch it it can have a default behavior that just works like all the other enemies and i don't have to override it so like the comparison there would be using something like an abstract class which kind of has to um override and make changes um so it's really useful to have um a way of structuring these enemies where
i can make them they can modify them for their like unique elements and then not worry about everything else so i'm like okay this enemy is gonna know how to walk i don't have to re-teach it how to walk every single time i make a new enemy um so starting with that kind of very basic generic controller it had these kinds of methods like an awake method that kind of just sets up initial starting data or or relationships references a setup method that kind of gives the enemy everything it needs to do to function um there's an on spawn method you know if i want to do something when it spawns for the first time like you know like maybe some enemy like spawns and there's like an immediate explosion then there's a number of things that have to do with how the enemy behaves so choose next state is like oh how does it the enemy decide am i going to chase after the player am i going to
run away from the player am i going to go to a particular part of the area or something like that um enemy behavior update is great for like you know things that need to be called essentially an update function so it's like oh does this enemy uh constantly need to be tracking the player's health for whatever reason maybe that goes in the behavior update um or if something um needs to be calculated based on the player's health or something like that right um has an attack function um in mid autumn a lot of the enemies have ranged attacks so that's kind of like what that that um default is has a take damage function and you know where it gets hit and there's recoil or has some invulnerability and there is an on die function so if i wanted like an enemy to explode when it died or if i wanted um a certain dialogue event to trigger when it dies that's what i could use that for
um and this is all just in the generic enemy controller that i had um from my code library so the first step was to add some specific functionality based on the constraints or the design goals um that mid-auto needed so um if you are looking at this little gif here you can see that when enemies attack they actually have this little like vfx stuff that plays right at the start of their attack so enemies needed to be able to play certain vfx or particles or things like that at specific points so i added a method um that does that um i also didn't initially have this melee attack uh method here in the base enemy controller but this is the really useful thing about starting with these generalized classes is you can have this class you can make kind of a couple subclasses and i was able to realize like oh i'm implementing this melee attack like you know three times i'm just gonna move
it into the the bass clash really quickly uh and because the scripts are so lightweight to start with that was really easy to do especially early on um so all the enemies are capable of melee attacking even though like half of them aren't gonna aren't gonna ever use that um i also added like this tag system for the enemies so for example um in this clip right here you're seeing um these turtles with like the yellow kind of outline around them and so they have a shield up which means if you attack them you're not gonna damage you'll damage their shield but they're essentially invulnerable while that is up and i can know um from the player's point of view right that that enemy has a shield because it has a tag that says shielded i can add that to any enemy i want so i could do something where it's like oh if the player has the specific attack maybe it has a special effect right if
you attack a shielded enemy maybe it makes the shield explode so i can i can know that you know from just the enemy's properties so that's the thing i added um that was necessary for this game but again like you know if i was implementing for a different game i might i might not need that so um it's it's important to keep it like you know light and add them later up um the enemies also have you know little pop-ups of text that appear when they take damage let's say like five six or whatever the amount of damage they take they have little health bars that update um and they also can sometimes trigger dialogue so if i wanted them to do anything in particular when the dialogue ended like use a specific attack or something i added a method for that which kind of ties into how everything in mid-autumn is super dialogue driven um that even the enemies have like dial specific uh methods so the first kind of enemy i made with this um after setting all that up was just a simple melee enemy these are our face
cuddlers they're just these little floating heads um that kind of move slowly towards you and then when you get too close they'll lunge at you so i changed the attack method to essentially remembering that i have this like generic melee attack function so when it attacks it just uses the melee attack function instead of anything else um it used to be more complicated than that but i actually simplified it more and then um once i made this enemy i added two types of tags right melee enemies and ranged enemies because now i can differentiate between them and then really quick the second enemy i made was just a um a radial attack enemy controller um in reality i made the ranged enemy um next probably but but this is just um a thing that like i did um almost immediately after that which was we had ranged enemies and i made one that could do kind of a circular attack instead of
a regular range attack and all i had to do is again modify that that virtual attack method and now this enemy works and both of these enemies the melee and the ranged are essentially the same enemy maybe their settings are different maybe their health settings or their speed or things are different but the the actual script besides from the attack method are functionally identical um immediately after that i was able to add shielded enemies which i mentioned earlier so these obviously from the the length of the um the text here took a a little bit more modifications to the original script to add shields right so um the setup method changes because i need to set up the shield the update method because i need to check oh is the shield up or down or what's the shield health or is something happening based on that and the take damage method obviously is the main one that's changed where when
you take damage instead of just taking damage it just checks oh is your shield active and if so you don't take damage um added that enemy tag for shielded so that the player can check or or other things like the the game manager can also check for shielded enemies or things like that if i ever wanted to and i added two new virtual methods and i think this is where that level of variety starts to snowball is when you start adding more virtual methods in your child class right so now i added a method that says take shield damage so when your shield takes damage this is what can happen uh it might not even take damage if i don't want it to right and on shield death when you're when if the player ever you know does enough damage to your shield and it drops does anything specific happen right you could have the shield explode when it when it takes damage or something like that um so the really cool thing about this is now i have this basic shield enemy and that's how they all work but i could
easily make a harder version of a shielded enemy for later on in the game or like a variant that kind of builds off of these and is essentially a shield enemy but with a couple twists really easy to do that i would just override the shield damage or the shield death method or something else and once i had these first three then i moved on to making a like a quick boss enemy right it was really simple um to do this and and the really cool thing about this you can make bosses really unique really quickly when you have all of these virtual methods to kind of modify as you want right so um you know i modified its uh choose next behavior method because this is a boss enemy it has a more complicated logic behind why it does things uh it has some unique attacks um it has some special you know logic with its take damage for example oh once it takes you know half of its damage it enters like a rage
state or it triggers its second phase of attacks um and then on on on die i basically just trigger like a dialogue event so that you know some cool narrative stuff happens when the boss dies and then i added an enemy tag for bosses which is basically being used so that um oh if you go into a room and there's a boss an enemy with a boss tag um a special health bar is going to appear over it or something like that so real quick right four different types of enemies um and then i made a second boss because uh why not um this is very similar if you look at this one the um comparison here is that i didn't need to actually i probably did actually change its attack method i probably just didn't include it but um this uh boss has a lot more narrative kind of motivation so it has like some unique setup elements again some unique ai and
why it um attacks you at certain times um this boss i think what i ended up doing was when it takes damage it builds up like a resource and if it has enough of that resource it will use its more powerful attacks so really quickly was able to just implement kind of a rubber banding mechanic where if you're doing really well against this boss he's doing uh more damaging attacks and if you're not maybe he's going to avoid those and then again triggering some special dialogue when this boss is defeated um and then yeah here's like a completely new type of enemy right after making those two bosses and three enemies i was like um kind of thinking about what is a new kind of twist uh that we could do for like a second area and so this is an evolving enemy that starts from this tiny little mushroom guy and they kind of hulk up into this bigger mushroom guy um
and yes it still like surprisingly didn't take a ton of work to make right like i changed how the behavior update works because it just has um a check for if the if the enemy is evolved or not and it does uh the typical behavior if it's evolved and if it's not evolved it's going to be kind of trying to evolve which means it's going to go look for little resources to eat and and get enough of those to evolve um and then its attack again is uh different because it just checks you know if it's evolved do this better attack if it's not evolved do this weaker not as good attack um added a new enemy tag for evolving so i can check if there's any of those and new virtual methods here for what happens when you evolve and what happens when you devolve which i haven't used yet actually in the game but it's there in case i want to have something where like oh the player does a ton of damage and the the enemy defaults um
and then let's see yeah this next enemy i think this is the last enemy that i've included in this uh talk who is just a toxic enemy controller um and this enemy just kind of passively um puts out kind of damaging particles if you get near them um so just yeah i needed to set that up in the awake method update that um and modify its attack added a new enemy tag and really quickly this you know each time i worked on this you know it took me maybe like an hour to make each different enemy type and a lot of that was fiddling being like what do i want so the really useful thing with all of these using these kind of pre-written code templates and then being able to make this is when i wanted a new enemy it was really quick to just pop in that enemy controller script set it up and then just start focusing on variety and and what i actually wanted the design to be um and when you set this up in a way that's
that helps you it's like you just have uh all these levers you can kind of pull to make things work more more quickly and effectively um and so i was able to focus a lot more on that so yeah let's just kind of to summarize everything how did reusing all this code taking a code template kind of throwing it into mid-autumn actually help while i was working on the prototype for example so it was really a lot faster than it would have been um i you know i was able to work on this on my own project right essentially um while still maintaining my main kind of living in games which is which is working as a contract a freelancer and when i'm working on mid-autumn i don't make any money off that so i still need to uh do do other work so i don't have a ton of time to work on this when i'm working on it it's usually
like a couple hours to four hours maybe like a week um another thing that happened is right i mentioned black currant which is just another prototype i made back you know last year or two years ago or something um and when it takes you less time to prototype you don't have to sink as much investment into each um project that you work on so it was real easy for me to just be like i'm gonna stop working on that one i'm gonna work on this one or i'm gonna move on to another one i think when you take more time to prototype things or to test things out there's a lot more opportunity for sunk cost fallacy to kind of sink in and then for you to feel like oh i've spent so much time on this i've got to keep like doing something with it um so that's like my main takeaway from this is is making things easier making it take less time to do things makes it
easier for me to throw things away for me to follow different directions um and ultimately right um putting the code library in made the unity engine which is what i was working in more comfortable to work in and i think that's the main thing we should be trying to do especially if you're a solo developer you don't have a ton of support um when you're just working in your room you're not like in a in a space with other people sometimes you want to make sure you're comfortable you know like sometimes for me as a freelancer i'm gonna have to start a project ramp up and and finish it within a week which is incredibly challenging sometimes so i spend as much time making sure that my work environment is as comfortable and supporting my my kind of productivity as possible and um yeah just not having to think about okay how am i gonna implement this
um and spending more time on okay this is what i want to do um was super helpful um another way it helped was in shareability so i was working on the mid-autumn prototype i probably started it um last end of last year and after about a week or two the builds were essentially self-playable like they weren't necessarily fun or good or anything like that but um you know i tossed in menus i tossed in um saving you know which is not usually what you have when you're making a prototype um but what that meant was that you know i i had all that kind of core lube in and it was a much more functioning prototype than um i otherwise would have been because i was reusing a lot of this code that i already had um i had more time to work on debug features so like if uh when i shared the build of with people for the first time it had um
like a menu in the top right corner so you could just like skip a particular room of enemies or you could play whatever dialogue event you wanted to kind of break the game and get into a particular state and yeah and you could kind of switch between the hub and the dungeon you know at any point and then normally if you're working on a prototype you don't always have time to make those debug features and it's really um difficult to to justify spending time on that um but you know having that having the menus having saving meant i could just send a build to someone so when i started you know collaborating with other people or when i started emailing people about the game or things like that i could just send a build i didn't need a ton of instruction um i could pretty reasonably expect that they'd be able to play it so that's like super super helpful when you're when you when you're especially this past year when you're working completely remote when you don't have a ton of
um of any means really to to sit next to someone and walk them through what you're working on being able to add that extra functionality quickly super helpful another thing that code libraries have really allowed me to do when my own projects are like on contracts is to target accessibility you know a lot of the time accessibility features uh don't get implemented because people aren't thinking about them from the start of a project but when you are kind of putting together a code library you can make sure that you have at least like starting points for a lot of these um features so like controller remapping right that was something i worked on on a past project and when i was working on mid on them i just tossed that in into the settings menu and um you know it has the same bugs that it had from the previous project perhaps but um it's there and i can continue working on it um you know
have a setup to help colorblind testing making sure that that's working you know high contrast mode and just more types of settings um because you know once i've implemented that setting once for most games that's that's pretty much how it works right volume isn't going to change that much um across games or or your resolution or things like that unless you're making a very specific game and then that's the the really helpful thing is everything that's specific you get more time to work on and everything that's not you can reuse the stuff that you want to use um and the other thing that was really helpful right like is is exactly that right increasing um your scope as in spending more time on those unique things um i'm sure i mentioned a bunch of times that i got to spend more time on design art narrative last night less worrying about how i'm gonna do things i was able
to experiment a lot on like high priority features so for example we spent a lot of time on our combat system how that works should it be more straightforward should it have kind of this more um unique idiosyncratic way of working and if i wasn't solid about all the other stuff that had to happen like menus and moving the character and things like that i absolutely wouldn't have experimented on that i would have picked like a more straightforward easy to do option um and that would have been that um also you know using pre-existing tools right like dev tools take an incredibly long time to actually be useful and if you've made a couple in previous projects and you and you have them ready to go they can really speed up how long you're able to implement things in mid autumn we had like in the prototype
like 200 different narrative events to really test the whether the procedural narrative was working which meant i had to implement 200 narrative events and um thankfully i had a tool that helped import a ton of like um text into the format um for my dialogue system so that really sped it up you know by taking something that would have taken two weeks and scrunching that down into a day or two is uh is a huge win when you're you know when you have like you know really a month to work on a prototype sometimes um if at all so the other last thing is that having things like these code libraries um makes it a lot easier for you to help out with you know your friends your colleagues um the games industry is a very small industry and um it's really really great to be able to share things with each other if you have
something that works so um you know i put together a sample library for people to check out here as well you can you can access it at bitly gdc code library um and yeah like if you didn't if i didn't have a code library set up already then when people ask me like hey how did you do this or how did you do this sample or or this particular feature could you help me out i would have to go look at my code and kind of make it um like actually shareable before sending it out um but instead i can really quickly be like here is this kind of generic version of what i started with um if you want more specifics then we can like talk more um and that's super helpful um and also like when i'm on other projects right when i'm doing the primary the the main part
of my career which is kind of working on contracts um i have my own kind of library of resources to work to reference when i'm working on this project so you know let's say i have to build a dialogue system for a different studio um and they have a number of constraints or they've partially implemented it i can kind of reference my own work to be like oh well maybe if you know i did it this way or modified it here that would help with some of the issues that that particular studio or team is having um and it makes you more able to be competent more able to be timely on the things you're working on and um yeah it just makes you a better collaborative member of teams i think so um i want to say right at the end that you know i think as game developers we should be avoiding like reinventing the wheel and and making things from scratch as like i
said at the top of the talk and instead you know if you want to make your game just a hundred percent wheel like some crazy biblical angel do that you know like if you can get away with that i think that that's the way that people should be making games um my favorite like moments in games is when people are like oh i never realized that was the same exact thing um in that previous game but it's just been reused and recontextualized and i think that you know code libraries are the way that i get around that and do that so um that well i totally forgot i made this slide but um as uh to tie everything up imagine that a game is now some assemblage of wheels and also sharks and and everything like that and to conclude games are super messy they're already really hard to make you know do the things that help you get through
the end of each workday and make yourself comfortable to work on them i hope that this kind of concept of using code libraries and using pre-prepared stuff to apply to your future projects um helps you out in terms of making your future projects seem less um intimidating and just remember like that if you've made something before then you can totally do it again and what's more your past self is going to be able to help you in more ways than you can imagine so you know keep hold of your work refer back to it um and organize it in a way that helps you all right that is my talk um thanks so much for listening um once again i'm trevine if you have any follow-up questions for me or
um you want to follow me on twitter or you want to learn more about mid-autumn please do so my twitter handle is right there on the slide and thank you so much you
Auto-generated captions from YouTube — names and numbers may be misheard.
Distilling the key insights…
Game Developers Conference · 2026
Jason Schreier · 2026
Comments