A Look Inside My Five-Year Game Project

[Music] hey pals welcome to a new video today what i wanted to cover was insignia as a project i started working on it in 2016 so it's been about five years of new unity versions and content and systems and mechanics and i know that many of you as you know new developers want some sort of insight into what that journey is going to look like so if you have a giant project like mine planned i think this video will be awesome to show you what it's like to actually work on it i want to show you how do i manage all the content and data how do i know what to work on next when i wake up every morning how do i know whether the content that i'm working on is good and how to finish it so strap in and let's get to it so working on a five-year project how do i wrap my head around it and and how do i wake up every morning and actually do the work the first thing that i wanted to talk about before we get into it is just some of the logistics of what this project is about and sort of constraints that you should be aware of before you take any advice or information from me the first of these constraints are the stakes so what exactly does this project look like for me uh and what are the what are the things that guide the way that i work on it so the first is that i'm committed to a full-time personal investment on this project this is my essentially full-time job the reason why i can do that is because i have stable funding from content creation so making these videos making my stream my patreon stuff like that funds the game development so far it hasn't always been the case but at current it's it's possible uh i'm not making a lavish living but right now what that means is that because i'm funded enough to continue living like this i don't have a hard time limit so i am committed to doing whatever it takes to make the game that i want to make in the time that it takes to make it this means that a lot of my practices and general development strategies tend to shift around the idea of how do i make the best game possible rather than how do i make this finished as soon as possible although that's really important to me knowing that i don't have a hard time limit means there are certain times when you know things like scope increase are warranted or possible and i can justify those so those are my stakes what are my priorities so given that i have funding and i have time my priorities are to make the best game possible this is basically like i have a vision for what the game should feel like to play and when i'm playing testing the game i'm always evaluating whether or not that's worth it and when i'm working on the game i'm asking myself if i'm heading in that direction and if i'm not then something needs to change and the second thing is to be a good director so long term in my career that's something that i want to be able to do i want to be able to lead a team and to build games like this with multiple people in a way that that shows that i actually understand how to do it and how to drive people to do it so i'm really committed to understanding whether my processes are good and what's worth spending time on and stuff like that so the project management side and also just getting the best game possible out of those processes that's something that i spend a lot of time thinking about as i'm working so now that you know my priorities and you know my constraints let's talk a little bit about the unity project okay so here we are in the unity project this is the same project that i started working on in 2016. that means it's been around for five years i started the project on unity version 4.7 i believe and at the time you know unity as an editor was very very limited there were i believe no 2d tile systems i don't think there was a timeline shader graph didn't exist lots of features didn't exist but it was still the best engine for what i wanted to build and for the skill set that i had so i knew how to write some code in java i didn't know much about c sharp but it turned out there's a lot of overlap between those two so it was pretty straightforward to learn and i'd actually been doing a few ludum dare game jam stuff in the meantime so i've been playing around in unity and i was finally comfortable enough to actually start using it so in the last five years project has changed a lot and it's grown a lot like just logistically i've talked about the amount of scenes in the project you know there's over a hundred for a long time you know i've just been accumulating these amount of scenes because it's an adventure game it's one of those things where every scene contains level data that's unique to that level and it's not really something where you would reuse a scene for multiple different locations in the game because every location is unique that goes for things like sprites as well right if this was like a puzzle game and you had like four or five different kinds of blocks or whatever that made up the game well then you would only need so many of those but because it's an adventure game and it's got a narrative and characters you know defining the sprites for those characters is a unique job for each of them right and so this number of things accumulates with the size of the game more content you add the more sprites the more scripts the more uh scenes that you have and that's the case with scripts too if you're an engineer you're probably thinking well you know you should try to define functionality once and use it in as many places as possible that's true but again in an adventure action game there are still things that are going to happen incidentally in the game one-off things that happen that have their own scripts and that number accumulates too to wit the number of things that are no longer being used also accumulates so old sprites old scripts they're hard to find it's hard to know just looking at the project directory like when something is unused and so in general this stuff accumulates i will say for a pixel art game the actual size of the assets is very low this project after a chapter and a half of development over five years with all the revisions and all of the you know scenes and everything in it is still only 300 megabytes so for a while i was using onedrive to save a lot of the art files separately to the project after a couple of years it it struck me that i could just save the project files for all of the assets in the unity project so things like a sprite files they can just sit in the project they take up kilobytes of space and if you use version control the actual version control systems won't really care about the project files being in there they'll actually store them and save the revisions and there's really just no point to having a different project management system for things like art project files and game project files if they're this small maybe if this was a game where a lot of the 2d art was done in photoshop and the art files were really big i could see why you would want to keep them separate but for the purposes of updating sprites i mean it's so easy to just be able to open up a file make a change export it to the same directory that the project file is in and then have that update immediately in unity because the project file is in unity right it's in the project one other thing before we get on to the tools that i use that's kind of important to know just in terms of like project bloat and size has to do with something that's outside of the project itself it's the way that your project is perceived in the general public so whenever you put a screenshot or a game demo out there if your project is as long as this one like five years plus you're going to be updating those things over time right it's very ambitious to think that you will design the logo for the game once and then that's gonna stay there forever or any screenshot that you develop five years later is gonna be representative of the game it's just not you're gonna be a better artist a better programmer the production value is gonna go up the scope's gonna increase just because you're better at making games now but you won't be able to take those back you can delete stuff off your twitter but what's the point it's actually great to compare the old stuff to new stuff it's just worth noting that you won't have full control over the way your game is represented if you put a demo out people will play that demo doesn't matter how old it is you'll still get people playing it and giving you feedback about it so a project like this becomes harder to manage over time let's talk about how i deal with a project this large okay so you've heard me talk about it before the game has lots and lots of scenes in it and if you watched my video about uh tiles in unity and whether or not they were good there was a point where i was sort of commiserating over the fact that tiled has this really cool world map feature and since then i've actually gone and built my own kind of world map scene visualizer uh in unity and i've done that specifically to help me understand the scenes a lot better here is a tool that i built called scene graph and it uses unity's graph view experimental library and this library is kind of based on uh it's it's the foundation of things like shader graph and vfx graph so i've had to hack apart a lot of the functionality here like these nodes are arbitrarily sized and the ports can actually connect to any other port the default graph view setup is directed which means there are inputs on the left outputs on the right and everything moves left to right whereas this is kind of like an undirected graph and i can just have any ports connect to any port that i want this also manages the door connections so if i have a scene and it's got three doors and they're in this configuration they'll show up here and if i want to connect those to another scene i literally just drag the ports to another port this is far and away way way easier than what i was doing previously so previously what i had to do was i would have all of my scenes i would have to remember the names of all the scenes and if i wanted to navigate to a scene i'd have to click on it okay load it up and then i would have to remember where the doors were or at least find them here and if i found the doors what i would do is i would actually like write the string name like the title of the door in the corresponding scene that would go to and it was case sensitive and then i would have like a scene reference for where it would go in a small project this makes perfect sense this is fine right if you have a project that's got like like three or four scenes maybe it's a game jam project that you've been working on and you maybe want to take it a little bit further there's no need to spend a week and a half working on something as big as this but on a five-year project when you have hundreds of scenes remembering the names of every door and having the contingency for them functioning be based on case sensitive names of the doors right such that if i change this if i just happen to change this name then its corresponding door and the next scene will break that's untenable that's insane building something like this is a time saver in the long run for me and the longer your project goes the more stuff like this becomes not only useful but like mandatory it's necessary to build stuff like this this comes with the added bonus of actually letting me be able to navigate to whatever scene i want so if i want to go outside the town i click this here i am outside of town and i can view the world map spatially too i can assess like how big parts of the game are spatially i can say oh this is like a really big scene here should this be split up into a couple different scenes like what happens in this scene i can make critical design decisions about the world like this is a dungeon down here is this dungeon too big right is it is the player going to get bored going from this to here to here to here to here just to acquire this item these kinds of decisions can't be made looking at this right and in general i've had to invest a lot into tools like this to allow me to work with the content of the game right the actual story the characters to actually work with those in a way that is as streamlined as possible because there's just too many hats to wear in order to make the content so managing it needs to be super duper easy so this is one example another one that i really love is the sequence editor and the sequence player so sequences in insignia are essentially just uh cut scenes and they usually contain dialogue so here we have some of the first dialogue in the game we have almond and his mother talking to each other when i first built this i just wanted there to be a nice editor for me to be able to type text into and what i would do is i would just uh it's it's like a list of objects they're scriptable objects and you essentially just type the stuff in here and then you pick a portrait there's a scriptable object for the character as well and those are defined elsewhere that contain the portraits so for the longest time that's how i built these and these also contain things like animation prompts so i can add here an animation and the animation just i can say like which character in the game i want to do something with and i can give it a sheet that animates like a like a sprite sheet and i can say what frame and what frame rate and i can flip it left and right stuff like that i can also play sounds as well and at the very very beginning this was suitable right to get the game into a demo state that i could take to pax and show off in like a 10 minute demo this was fine but as the game's gone on i've needed to do more and more sophisticated things and the demand to have more and more sophisticated uh tools to actually let that happen has gone up so one example is now i have this importer and what the importer is is like when i'm drafting this stuff if i'm just like designing a conversation between two characters i don't write it here like this it's too unwieldy it's as user-friendly as it is i write it like this right i go in here and i start typing like a script as a script writer this is good because i can review it and it's nice and clear but then if i want to bring this into the game i'm having to copy and paste right like i'm having to like go here and paste the content and set the character to be the character who's talking and that was just something that was kind of taking too much time i realized that like this is pretty possible right like i can i can tell what the character is based on this text and i can i know that it's delimited by the colon and i know that everything after that is content so why don't i just write a script that lets me copy this paste it into a box and then generate the conversation and that's actually something that works now i can go to a new sequence here it's just a scriptable object that i can create i can paste the data it checks all these names are unique which they should be for a for a story that a player is going to read you wouldn't want two characters with the same name i press import and it generates it itself these include the characters as well and i can choose to show the portrait for each of these and from here the only thing that i'd have to set is just the expression on the portrait if i want them but over time having portraits on every single line of dialogue is something that i've moved away from so some of these i won't even show the portrait maybe just for the first line i'll show the portrait for the two characters faces beyond this uh one more thing for the dialogue system that's become more important is the actual sequencing so the timeline came out in 2018 i think it was and at first it was kind of a bit unstable but as it's got a bit better using the timeline in a cut scene makes sense to me and there's a bit of you know stuff that i've had to think about to make this work like the actual point in time in the cutscene has two representations there's like where you are in the dialogue and then there's where you are in the timeline so i wrote this thing that lets me essentially sync this with the timeline so this is a cutscene you can see here i've got the dialogue inside these clip tracks so this track is just a sequence and the clips inside of it are are the lines this auto-populates when i plug the sequence in and what basically happens is that i can set a flag on each of the dialogs to make sure that the timeline pauses if the dialogue isn't up to that part yet so in this first line right we have this camera movement that i wanted to do to sync up with the dialog the camera movement happens but if the player doesn't press any buttons it won't pass beyond this point until the player presses next this isn't perfect but it's a step forward that's made the game a lot more easy to manage and to direct and actually lets me tell a better story so the reason why there's even a camera move here is in this scene i wanted to do kind of an homage to monty python the main character armin is trying to get into this city and there's a dude who sits up here and doesn't let him in and he's kind of a bit snobby and tells him to go get lost when i designed this i wanted the wall to be really tall but i wanted it to be able to fit inside of one scene so because it couldn't i thought well i need to do some camera motion here and there's an opportunity to have some humor in this as well like when the camera looks up and down how it moves up and down this is something that as a director you want to have control over so being able to do this inside of a scene as easily as this is really important it's just a practicality again if you're trying to design a game you don't want to have to be dealing with so many different points of contact to make those design decisions right if you want to make a joke in the game and you have to write a script and design some sprites and you have to write the dialogue and have all of those things work in combination before you can even test them and every time you test them it takes another 10 minutes of changing numbers to make sure that the comedic timing is right for example it's just going to take too long and get too frustrating so a lot of my work has gone into building tools to allow me to yeah work more directly with the actual creative aspect of the game that goes for the scene graph and for the dialogue system now you might think as a way of like recuperating the costs of that time investment if you've decided to build a tool like this that it would be a good idea to sell these on the asset store as yet i haven't actually been able to justify doing that because the amount of work that goes into releasing a tool that's for general use is really really high and once you've released a tool supporting that tool right so that other people can use it in their games reliably is another investment on top so imagine like all of this stuff it's full of dependencies on insignia but that makes it easy for me to build and easy for me to change and make assumptions about if i was to build it for other people's games then connecting it back into my game would be harder but also supporting it as a tool as a thing that's out there would be so much work there's feature requests there's bug fixes documentation that needs to be maintained it's a lot of work and there are tons of them like the biggest one i haven't shown you yet is retrobox this is my animation system for actual sprites the main character he has frames for the animation i can just press play here and you can watch it the frames have hitbox information and the hitboxes show up on a timeline here that's kind of like adobe flash it's kind of like there are keyframes and empty frames i can set different kinds of hitboxes like a physics box a hurtbox hitbox i can set stats for each of the hitbox so i can set damage values and stuff i spent like a month and a half building this and it's something that i've tried to come back to one thing that's that's worth noting is that when you do work like this it will make what you're working on faster but as you use it you will see that your needs tend to become clearer or change as you're working on the game and that almost always means that you either have to accept the limitations of the tools that you build or spend even more time doubling down to adapt the tools to your new needs or clearer needs this can seem like scope creep but over time i've learned to sort of understand it as scope revelation right it's more that you've realized that what you wanted all along was this now that you've been working with a version of the tool well what would be really better is if the tool did this and i if i had known that i would need this then what my tool does now isn't it so i need to do something this is something that i really felt down about for a long time right not being able to like know for sure the scope of my game and then the more i build it the more i find that things are actually needing to be bigger or take more time or be changed and how do i actually write my requirements you know in advance in a way that i know they won't change and ultimately you can't if you've never built this kind of game before like how can you know if the tools that you're building are going to need this feature or that feature until you're using them you could try to set it in advance but i just feel like it's super impractical to do that and i think you risk over engineering or under engineering anyway and if you have my constraints where you're just trying to get to the best product then there's no sense in assuming stuff in advance you might as well just make the tools in the best way that you can make them that fit your needs as best as possible right now and then modify them on the fly as best you can so that's what i do so that's how i deal with a project that's growing every day the next question that i wanted to cover is how do i actually know what to do every day how do i know what to start when i sit down at the beginning of my day and we can cover that right now so this is a scene in chapter two and it kind of represents uh the entirety of chapter two it's not fully complete in terms of its art some of the arts really nice and polished some of it's really rough there are assets from different chapters in here and as far as the story goes you know you can you can walk around you can go into the next scene it's kind of like a rough version of what it will be uh but it's not there yet right the whole thing's like buggy and and kind of broken and that's just that's just where i'm at right now when it comes to making a game like this on your own you have a lot of different jobs to do adam as the developer has the role of being an artist being a writer being a director a project manager we have scenario design and the quests we have game design for mechanics and things like progression systems there are so many moving parts that this game needs to do and orchestrate in a way that's cohesive and feels fun at the end of the day that's the goal right needs to be fun how do we even approach thinking about where to start and if something's not right how do we know what to do next this is something that i struggle with still it's very very difficult to digest something of this size how do you manage the pacing of the story as it's being told in the level design in such a way that the player doesn't get bored as they're running around doing whatever they're doing so i can draw a line of where i expect the player to go in this second chapter i know they start up here and they move through here and they come down here and and i can sort of draw that chain of events but managing their actual experience in a way that guarantees or at least gives me the best chance to know that they're having fun and that they're doing things that make them feel engaged and being driven and propelled by that story is very difficult you know if you can imagine a team working on a project like this everyone would be doing their version of a draft or a prototype and you would involve those those roles um in harmony as you sort of polish a more and more higher fidelity version of the thing you're building so in movies that's like storyboarding with voice acting versus you know rough pass or animation versus final animation versus like at the very very beginning like a table read with games uh especially when you're working alone this parallel process has to be done in serial so the obvious place to start would be story right like the actual plot of what the game is about and what the chapter is about that's been done a long time ago so story writer me did that like two three years ago and coming to this chapter now as like a developer and trying to like implement that story there are a very very sort of like broad and roughly connected set of dependencies that things work on you could take a few different approaches right you could say well let's build out every scene as a big empty space with the doors and we'll just connect all the doors and let you just run through the space we don't know what what the scenes look like we just know that they are there and how they're networked okay that's not not bad now we want to bring some story in i suppose we could write like a very very rudimentary version of the story in like simple simple english that just says person says go here other person says now go here so that you don't invest too much time in writing things that would be better expressed as camera work or whatever whatever you have the problem with this super duper gray box approach to writing the game is that as a solo developer implementing those prototypes takes so long that you're not at any point in that process able to appreciate the thing that you're building as a player as like a player i want this place to feel like a living bustling city i want to make sure that that the vibe is right in the right way that makes you feel like wow this place is alive and and the people whose stories are being told here are real that thing that i'm trying to achieve will not basically be appreciable until all of the things come together but it's also the thing that's most important and so for me what i've basically been doing is chasing that because the validation point is actually that it it's the feeling it's it's not really that all of the tasks are done so this kind of brings me to this idea that i've heard story writers uh talk about a lot which is the architect versus the gardener approach let's head into leonardo for a second so the architect versus the gardener is something that i've heard george rr martin talk about when he's writing game of thrones i think he talks about stephen king being an architect and himself as a gardener i'm not sure if that's correct but that's how i remember it and if essentially what this is is it's a way of describing uh approaches to writing stories right and in my mind i kind of compare this to the uh different kind of like software design approaches of top down versus bottom up so the architect's job what is it right it's to it's to come at a problem from an abstract or structural point of view they don't worry necessarily about the details at least not at the very beginning they're sort of looking at the plot of land and they're saying what kind of structure can we build in this plot of land that we know will be suitable and they do have certain responsibilities when it comes to the feel of the of the place like they know where the light's gonna come from so the room has a lot of space it feels good but they're not the interior designer right they're not the gardener they know there will be a garden but they don't really concern themselves with those details the gardener on the other hand they're concerned with the details and the way those details feel right they prune they make small changes over time because they're working kind of like in the weeds about the actual nitty-gritty things that make up what it is that they're designing i don't like to think of this as an either or i like to think of this as approaches that you switch between or at least i try to switch between them there are certain things when you're making your game if it's an adventure game with a story like mine where you can make certain sweeping story decisions at the beginning you kind of have to you have to know where you're going generally speaking but you also have to respect the feel of what it is you're making and what players are going to be experiencing so just because you decided that that a certain thing would happen whether or not it feels good or whatever isn't something that you can appreciate from here and so if you just make a decision at this top level and then carry it out all the way until the bottom and you decide that it's just not right at the very end it's too late like you're gonna have to redo a lot of stuff or cut major things um in order to revise that stuff what tends to happen in game design this conversation is approached differently for different genres so i think for small projects this gardener bottom-up approach where you just think about the feel of the game is excellent when you're working on a small project the feel of the game right the actual nitty-gritty like experiential elements of like the moment-to-moment gameplay if you let those guide the entire project and you keep it very singular then actually it's not really going to be the case that you're going to find that something that you designed was wrong because there's no constraints that require for it to be right right there's no like story with a continuity that needs to be really really excellently balanced because you've you're just the whole thing's led by the mechanics for example right this is a good approach and a fast approach to making something that feels good and it encourages people to make uncomplicated things but if you want to make something bigger you have to come to grips with the fact that like there is going to be if this is like a five plus hour game and there's story and there are characters there are aspects about this that need to be straight right the continuity of the story needs to be straight the the continuity of the world needs to be clear like does it make sense for this character to go from here to here are there plot holes like the actual structure and the foundation of like the things that happen in the game those are important right that it needs to happen in a certain way because it needs to make sense the question is how the hell do i resolve this like we've identified that it's really hard to make games and everyone knows that but what's the process by which we try to actually mitigate this and the way that i like to think about it my my take is rather than thinking about it as like something that you approach top down or bottom up it's kind of like sculpture there's this famous idea um that i believe it was michelangelo don't don't take me up on this it could have been somebody else that the process of building or creating his sculptures was really a process of freeing the model inside of the stone okay and i really like this idea i really like it because it carries with it this metaphor that you actually need to approach the problem from different angles what i do is if we think of these facets right like we start with a block that's got different sides to it and we can think about the process of making a game like an exercise that has different sides to it so there's like the gameplay right there's the story we could think about like the production values like the art right or the sound all of that stuff you could think of as different facets and if you just pick one and you try to find the shape of the of the sculpture just by hammering away at one of these things then you might from one angle get the right shape okay you might get something that's like generally good from the angle that you looked at it but the overall result will look kind of wonky right because you'll have one face that's right and then everything else will be will be completely flat so instead what what i do is i kind of come at it from different angles constantly and i choose when to swap angles when it becomes too difficult to to move on overall i don't try to constrain which aspect i'm working on i just work on what feels the easiest to work on because it generally means that i'm actually on the right path so as an architect i built this scene for its significance in the story for where the different npcs need to be so i know there's a merchant in this town i know that armin has to go through the town i know certain plot beats have to happen at certain places so i decide to make them all into this scene right so from a from a large sort of like top-down perspective the fact that there needs to be a scene here and that it needs to take place in the daytime and that the main character passes through from left to right that's sort of set right that's easy to do but merely saying all that stuff needs to happen doesn't contain any information as to like what the place feels like the fact that there's a scene here doesn't tell me how big it really needs to be but on the flip side as like a player and an artist i do have ideas about how big the scene needs to be i do have ideas about whether it's supposed to feel grand or populated whether it's supposed to feel open versus closed all of those concerns that are more emotionally driven and have less to do with the pragmatic side the the continuity side those things are much much better explored through art and i don't really want to leave those things till last because it's actually really important for me as the as the director that i know that this is settled so what do i do i start sketching i l i drop the pen stop trying to write characters stop trying to write npc interactions because i don't even know really if the npcs should be on this side or that side or what order you do the quests in like that's all in flux right i've got an idea about what i think it should be but i don't really know as a player until i'm playing and so i need to build the space out i used to feel like i had kind of like an 80d right like why can't i focus on one thing uh and i've learned to understand that i do it this way because it's natural it feels good to do it this way and one of the biggest most important things that i take away from this process that i think is actually really invaluable is the emotional value that i get out of defining these scenes right like coming into this space as rough as it looks seeing it with my eyes not just as a bunch of gray boxes or you know just an empty space but seeing like an archway and the clouds and the buildings looming over i feel like i'm there and it makes me so excited to keep working on the game like little things like that are so important because i'm not a robot like i i am making a story stories are things that you know are designed to affect people on an emotional level the emotional side of making the game for me is really really linked to the actual emotional side of playing the game and when i see places like this after drafting them really quickly and just putting them in i feel like what i think the player will feel and that is enough to actually guide bigger decisions in the game some of those architect decisions are actually motivated by the gardener decisions and likewise the garden of things are are contingent on satisfying architect things i don't know any other way of doing this as a solo developer than trying to approach from different angles until you start getting some momentum and that's the next thing that i wanted to talk about i wanted to talk about how to actually finish this project how do you make a game that takes five years to make any closer to being done so insignia is a huge game and there are so many parts to it it's it's something that i've been working on for five years probably three of those were full time three and a half maybe and there are still probably about three more to go before the game's you know in people's hands you know on the steam store or on switch or whatever it is and over the course of this process it's been very easy for me to lose my sense of stability emotionally about the process and i think that a lot of people who work on games will inevitably come to this point where they feel like they don't have the confidence to continue because they're not getting the feedback from the process that they're doing the right thing especially when you're working on a big game you don't get that feedback often that what you're doing is good if you're working you know in a team or in any other kind of job outside of game development um you would expect that people in a senior position to you will tell you if you're doing the right thing and they'll point you on the right course if you're doing the wrong thing and in game dev especially solo game dev it's hard to do that so what are the things that i've learned to do and not to do in order to stay feeling good about the game and to stay motivated about it and to actually work towards it being finished the first one which is going to be kind of controversial is i have stopped setting deadlines for milestones of my game for a long time deadlines were something that i would set with expectations about how long it would take me to finish certain parts of the game i would say to myself oh if i can just finish chapter one in six months then i can finish the rest of the game in two years right the problem with this thinking is that it assumes that you know anything about how long it takes to do the thing you're doing and if you're making a game that you've never made before or doing anything new you don't have that information you don't know how long it's going to take you can try to track your work you can try to make estimates based on the work but game dev is full of curveballs and as a solo developer it's kind of not really worth trying to do if it's not actually gonna make the game come out any faster that's the line of thinking that i've arrived at because the emotional cost of missing deadlines constantly makes you feel like you aren't making progress which is a lie you are making progress as long as you're working on the game as long as i'm doing things that make me feel like i'm making forward progress not not necessarily the same as like scope creep like we could talk about scope creep another day and and when just to not make the game bigger but to make it smaller that's one thing but if you're actually making forward progress in my case the story if the story is closer to getting done when i'm working on the game it doesn't matter how long i think it's going to take it just matters that i'm that i'm getting there i understand that this is a luxury that i have as somebody who doesn't have a set deadline and if you do have a set deadline then you may have to come to terms with the fact that you cannot control the output of what you're making as in you may have to finish the game early to meet your deadline because you just don't have infinity years to work on it you might only have six months and so my advice to you there is like the more projects you work on the easier it will be right the less novel what you're working on is the more you'll have concrete experience to say how long stuff takes but in my case with this project it's never been the case right everything i'm making is new to me this is the first time i've done this so i don't know how long it takes to implement the third chapter of my game i just know what the third chapter of my game is so as long as i'm in a position where i have that security to keep working on it i will keep working on it at my pace so instead uh as a way of kind of like enforcing accountability what i try to do is rather than set deadlines i just set milestones this is one of the milestones in the game this is some art relating to the first boss in the second chapter so each chapter has two bosses there's like a half boss and like a like a big boss and this is the half boss in chapter two working on concepts for this character building out the arena making decisions about how the fight should go even if those aren't the final decisions is forward progress what i do is i just think like okay this week i'm going to spend some time working on this character and if i can make decisions in this week i'll feel good about it that's basically it i can't say i expect to get this much done this week because i don't know how long this boss is going to take sometimes what i'll do is is compare how fast something similar took last time and i can say okay as long as i'm moving faster i can feel good about it that's something that's worth doing i think but at the same time you may not always have those apples to apples comparisons and so forcing yourself to compare with your past self you know isn't necessarily going to be a rock solid choice i think your goal should always be that you're learning that you're making progress and that you're not repeating the same mistakes that you made before that doesn't always mean that you'll be working faster than you before sometimes you hit a plateau and that's just it that's the pace you work at but as long as you maintain a positive attitude and are realistic about how hard you're working whether you're making something that you love whether you are proud of the time you're committing and the the effort that you're putting in that's all you have control over so why would you use any other metric to guide how you feel about what you're doing you can only do what you can control so that's how i've decided to define how i stay on course and that's how i've decided to feel about my process let's uh let's do some final thoughts so i think if you want to take up a project that you think might take a number of years just know that it's going to be a longer project than you think and if you're in this position or want to be in the position that i'm in i hope that the things that i've said today have given you some context as to what to look out for and what to expect personally i feel really positive at this point in the process i don't regret any choice that i've made so far i think everything that i've done has led me to where i'm at and where i'm at right now i'm very positive about this positivity comes from the responses that i get from my audience which i've built over this time interactions that i have with industry professionals like publishers or other developers i think it's important to have your own standards i also think it's important to gauge what you're doing by looking around you and seeing the feedback that you're getting it's important to be realistic and sometimes it's difficult to see what's realistic and what's feasible when you're working on something this big so staying grounded by giving other people a chance to give you feedback is really important but ultimately you are the one who has to resolve that feedback back into your course correction you are your own captain so best of luck i hope you enjoyed this video and i will see you in the next one hey pal thanks for watching and thanks most especially to the patrons and twitch subs who support this channel and my gamedev project insignia to find out more click the links in the description below and if you like this video tell youtube by clicking the like button and then youtube will tell me and then i'll make more videos that's nice thanks again and until next time [Music]

Channel: AdamCYounis

Views: 88,667

Keywords: game development, pixel art, game dev, game, video game, indie games, stream, vlog, dev log

Id: XpFeKaC7Wu4

Length: 47min 25sec (2845 seconds)

Published: Mon Sep 06 2021