 everyone. Welcome. This is your live stream with the actual developers who brought you Kotaikun and of course the person who invented the concept herself, Katie. And so I just wanted to get everybody together on a live stream so we can talk a little bit about how we did this and take any questions that we might have from anybody watching on Twitch or on YouTube but just to kick us off, let's first introduce everybody. Okay. All right, Katie you go first. Sure. So I'm Katie. I am a content marketing manager and I focus on developer marketing and for Kotaikun I was the product and project manager for all things so start to finish you know I just helped make this thing a reality and it was so much fun and I'm so glad to be here. Very nice. And Tom? Yeah, my name is Tom Sharp. I'm the director of Gossamer Games. We're the studio that brought Kotaikun to life and I worked on a bunch of things. We're a very small studio so we all kind of worked on a lot of different aspects but I helped with production, direction of course and for our studio and then programming, arts, animation, all those things. Nice. Nick? Sure, my name is Nick Gamm. I'm a senior developer advocate with Okta. I run the Games and Extended Reality community at Okta and I helped out with a lot of different things for Kotaikun and yeah I'm very excited that everyone's getting to play it and hope everyone's enjoying. Nice. Chris? Hey, I'm Chris. I'm one of the lead programmers at Gossamer. I mostly did like basically any of the online functionality and tying in any of the authentication as well as a lot of like just random systems throughout the game. Awesome. And I'm Heather Downing and the principal developer advocate here at Okta and primarily I got to focus on messaging and promotion to all of you guys who are watching today and of course I had a little bit of a hand in helping to get our site life. So let's start out with some questions and we're going to kind of go in chronological order here. Katie, why did we do this and how did you find a shop that could even do it? Yeah, so there are a couple reasons why we decided to take this project on. The first is that there's a lot of crossover between developers and gamers and we wanted to create something that's going to be fun and relatable and is going to sort of encapsulate the developer experience day to day in the office. But also there's kind of historically security in game development has not been great and we wanted to show that you don't have to compromise user experience to be able to create a secure game. And so we wanted to use some of the security principles that we use in our products to secure the game that we were creating and then also hopefully make something that was fun and relatable and hopefully something that you'll want to come back and play multiple times. I think you probably succeeded at that. Awesome. Okay, so let's say that you're getting ready to find who could build this. We didn't innately have game developers at Okta. So how did you decide on how to even find a shop like Gossamer? So we were working with Epic Digital. They're a part of Vox Media and they actually suggested Gossamer. They came highly recommended and we worked with Gossamer and Epic in partnership and honestly it was a great decision. We're very, very happy with all the work that they have done and I can't believe that honestly a team of two people was able to pull this together in the amount of time that you guys did. Oh, I totally agree. All right. So Tom, since you I guess run Gossamer, right, how did you approach the kind of pipeline for communication? Because I know that you didn't just work with Okta, right? You also worked with Production Studio, right? That's Epic, right? So tell me a little bit about how to how that navigation worked with figuring out what everybody wanted. Yeah, so this was a really fun project because it was very rapid paced. We did this I think in about like six months or so. So we were involved when Epic came to us with the idea and we said, wow, this sounds amazing because there's so much that we can see ourselves in this design. So you're like, wow, this would be such a cool project to work on. And the idea of doing like a hybrid between like a business simulation and a narrative adventure was a really cool idea for us. So we immediately latched on to that. And yeah, I think the communication pipeline was there was already a pretty strong direction for the game, which was awesome because we could immediately dive in and start executing. We ended up making a prototype really quickly. I think probably within a month, right, Chris? Something like that. Yeah, something like the first few weeks we had people moving around and interacting with objects and then off. Yeah. Yeah. And so we jumped right in and started kind of building the foundation of it. And then I think the biggest kind of newest thing for us is we worked on games, a lot of games in the past that have been like environmentally narrative driven. But this was probably our biggest explicit narrative project where there's a lot of dialogue. There's a lot of characters. And so coming up with a pipeline for having all the amazing writing coming from the Epic team and then being fed directly into the game was a really interesting challenge for us. And we tried a few different approaches. And we ended up, it was kind of a two part thing because there is the creative side of this, the creative freedom that the writers needed to actually like write the story that they wanted to write. And then there was like the technical implementation of it. And so we ended up with this cool system where we created these scriptable objects, a set of unity that we could really easily update that would not only write out the different narrative prompts, but also give the different options the player could choose, have the associated stats kind of with all those options. And then also leading to like a pseudo branching narrative where you could have follow up events associated with each event that you'd want to with each decision the player could make. And so we went, it took quite a while I think probably like a few months to really nail down the exact like data structures we'd be using to input the narrative in there. But from there it was just really figuring out like the best way of like still letting the creative people, the writers write the story they wanted to but fit it within the framework that the technical framework that we needed to implement it into the game. So many moving parts. Like it's kind of amazing how much you had to kind of tackle quickly. So this started though, Katie, when did this, when did we start planning this? Because that's a question I was asked often is how long did we actually work on this, like from conception? And then when do we actually start coding? I'm sure Gosmer you could help me with that. But Katie, when did the concept start? And then when do we start coding? So I might get this a little bit wrong. It was somewhere in October, November of last year was when we had the first meeting. And then when did you guys start coding? Was it like maybe for January? No, it was actually, it was, I think towards the end of October is when we started working on the first prototype. Yeah, it was really quick. Yes. So I know that when we were talking kind of just in prep, Nick had mentioned that there is like a separation that you guys had to think about from this, like the sim way that the writers would put together the stories of the sim game from the code. How do you separate that because they often would have updates, changes, like entire narratives. How did you do that? And that's for Chris and Tom. Yeah. So and Chris can speak to this, we originally wanted to have a really nice system because we knew that there were going to be a lot of frequent scripting updates. We wanted to have a system where we had like a either using a Google doc or using some kind of like spreadsheet. And we'd implement the scripting, the dialogue, and then as you know, you're getting into the engine, it would pull up those updates. That was like the first iteration we had of that. But then as the narrative kind of grew more complex, we realized that we couldn't really, the structure wouldn't really allow for that, that type of production. And so we ended up going with something that involved way more manual work, which was basically just having a Google doc that had a lot of color coding and a lot of like technical devices we could use inside of it. And then we would just go and kind of just copy and paste. And we ended up finding that that was actually the more optimal way of doing it, instead of trying to account for all the branching aspects in the way that narrative would fire within the game within like a single spreadsheet or something that became unwieldy very quickly. And so it ended up just being like the manual way of doing it was actually like the fastest and easiest way. Yeah, I think I had started developing the, like a script that would just automatically pull from the spreadsheet because we did have a spreadsheet with lots of different information, but like who was saying what, what the dialogue was, what stats were being affected, what events would follow up from that event, and a bunch of other information. And I think kind of as the scope grew, the scope like was always kind of changing and being modified as we submit things and get feedback. It was a very iterative process. So the events became more than just dialogue, but sometimes an event would then fire that we want to play pong, or we want to walk over to this place and do yoga, and that's like more of like an animation or do pushups. And so as we started implementing more of those things, we I guess kind of figured out that even if we had an automatic system, there would still be a manual process in terms of making sure that the animations are hooked up and making sure that any references are kept up. And I guess we were worried that if we had the automatic system, we would not remember which manual things to update, and we would potentially lose some things. And overall the script didn't update so much that it was like a huge task to put all the dialogue in. I think Tom had done like all of the level one dialogue in a day or something, just by himself. Yeah, fine. And I think a lot of that was I think the hardest part of implementing the narrative was just trying to figure out again like the technical structure that we'd have to have. So like what are all the fields that we need to fill in? So we need like the description and then we need we eventually ended up you know it involves so many pieces because not only do you have the dialogue, but you also have the UI that has to display that and then all the like backend systems that need to tie into every decision and then the animations that are tied with each one and then the overall structure in terms of like how do we save those events and track what the player is doing. It kind of it took quite a while to refine the system that we needed for this because it really is kind of at the heart of the entire game progress. But once we figured out that system and had it like all built at, instead of Unity using our scripted object system, it was very quick to just start going in and implementing all the dialogue that we had in the game. Yeah, I think Taylor had developed the I guess the UI interaction like how the events get fired and brought up and displayed on screen and I think she had developed that system at least like three separate times within the first like two months because we kept changing how we wanted to have them display or stack or not stack if you could get interrupted at which stage you would be interrupted and things like this. So that system kind of got built many times to make sure that was working fine. Yeah, again, so many moving parts. I have a question though if it's alright if I bring it up now while we're in the middle of our tail. I guess there is a rubber ducky at some point in the game. So I'm going to go ahead and show Lucy's question. She had an amazing time playing this on the stream on Saturday, but after beating the rubber ducky, the game would hang briefly and then when it comes back to life, next time you go to code it and makes you battle the duck again. Is that the end of the game or is it a bug? That would definitely be a bug, I would say. I think when you beat the rubber ducky you're supposed to sort of that is the end of the game, but you should be having sort of like an end sequence load up. We've heard a couple people have issues with that firing, but none that we've seen or heard from Octo or Epic, I guess. So yeah, it's a hard bug to track, but if you have any information that'd be cool. Nice. I do want to give a shout out to Micah who did work on this in the beginning stages. So thanks to Micah for this. I know you guys talked with him a little bit in the beginning too. Okay, I've got another question. So this is a 2D, these are two dimensional characters, but on like a 3D board. So talk to us a little bit about the concept of working on a 3D board and then go into the 2D character customization. Yeah, this is something that we went back and forth on quite a bit in debating a production because we're trying to figure out, we had some amazing concept art in the very beginning and we're like, all right, you know, we can just take this and if it's a 2D game, we can just use a lot of these assets if we format them correctly and turn them into spreadsheets and all these things. But we are a studio and we also worked with a number of artists on this project and they have a really great background in 3D art as well. And so we were trying to figure out what is the blend between how much do we rely on the 2D versus a 3D aspect of things. And we ended up going with 3D for the environment because that also we were trying to figure out like perspective early on. And we knew that if we didn't have a strong vision for the exact perspective that the camera would be in for the game, if we needed it and it was in 2D, we'd have to go and redo all the 2D art for the environment because it'd have to be drawn in a different perspective, depending on how high or low the camera is, if it's isometric or just top down. So we thought that doing 3D, even though that involves a lot of somewhat more technical complicated things, that it'd actually be more flexible and easier for us to change things around through production. And I'm really glad we did that because we ended up changing and playing with the camera quite a bit. And I think a lot of the things that we have in the game, in terms of like the camera controls and the ability of zooming in and out in certain ways and things, that just totally wouldn't be possible if we had stuck with just doing the 2D art for the environment. So yeah, we were able to do that. And I think it ended up matching the character art style really well. We ended up using some special shaders that are like flat shaded that are kind of more graphic in their appearance. And so it kind of matches well, I think with the with the characters. But then yeah, there's the kind of challenges that come with having two dimensional characters, walking around, navigating inside the 3D environment. I think Chris initially worked on the AI, right, for getting those characters moving. Yeah, that was like the first thing I made in the game. We had like a really early test in the first week of basically like little circles moving around opening fridges and stuff. Yeah, and I remember you had like all the desks set up and we just had like little squares walking around like going to a desk quote unquote sitting down. And then yeah, just kind of getting that general navigation. And that really led to then figuring out how we're going to do the characters because we knew that we wanted to have a character customizer as a big features in the beginning of the game. And we're trying to figure out a unified way of having a character creator, but also just having like a character system that we could basically retarget our animations or reuse our animations across all the characters. So usually if you're working with like a sprite sheet and you're using 2D characters, you animate a character and you create their walking their walk cycle and everything, but it's baked in you're creating the animation for a specific character. But we knew we wanted to use more of like a puppet kind of system. And so when we create a walk cycle and we create like a typing animation or anything like that, you wanted to be able to use that animation across all the characters in the game. And so we ended up using, so we developed the game in Unity. I don't know if we mentioned that before, but we ended up using, I think we have three packages that we used quite extensively for our characters. The first was the 2D Photoshop importer, which was really cool because we could have our, the artists go in create the characters. And specifically for their character creator, we ended up having a Photoshop document with every single like assets that the that any character could wear, if it's any of the different clothing, if it's the glasses or any of the different options that they could use. And we had it all on one giant Photoshop document, which ended up being pretty big. Is that like a sprite? Is that like a sprite? Yeah. So what would happen is you could actually save the Photoshop document directly to Unity, put it into Unity, and it would go and we could break that down into sprites directly within Unity. And so instead of having to like export them individually as PNGs or anything like that, we could actually just do it directly within Unity using the really cool plugin, the Photoshop importer. And so then we took that and once they were all broken up into different sprites into different layers, basically, we use the two experimental packages, the Unity 2D IK and the Unity 2D animation packages. And that basically let us set up rigs for our characters. Usually you think rigs, you think like a 3D character, or it has like a skeleton. And then as you're moving the skeleton is deforming the geometry. Well, Unity has a really cool package where you can do that with sprites and you can do it with 2D art. And so we ended up setting up these really awesome 2D rigs for our characters that would also work with our character creator. And we could use that across all the characters in the game and just have like this one really nice unified animation character system that would also work with our UI, moving around the 3D environments and all of those aspects. Man, I kind of want you to just share your screen right now, Chris. Yeah, because this is Unity. So before we go too much farther, tell everybody what the stack is. What are all the different technologies that we were used and for what for this game? Yeah, go for it, Chris. So I guess in terms of like the pre-production stuff, all the scripts and everything is done like in Google Drive. And then we plan our tasks and hack and plan where we assign everything to everyone. And we use that as our, I guess you would say our agile workflow. And then we use Unity for the game development, as we said. We built all the 3D art in Maya, I believe. We used Photoshop and Luis created from Epic, had created the character in Illustrator. We did a lot of the testing in the Unity editor, but we also had to test a lot of server functionality online. So we were deploying to Azure in which we were connecting with the Octus API to sign in on the Azure website. And then we were actually linking that up with PlayFab for, you know, saving user data. And yeah, I guess that's mostly the technologies. Do we have any more, Nick? Do we miss any? Well, I suppose Octa would be probably a big one in there. Yeah. Nice. And hosting on Azure. Nice. Well, you mentioned PlayFab, Chris. So talk about what it was like, like what did you use PlayFab for? PlayFab is a Microsoft product, right, in the Azure ecosystem. And what did we use PlayFab for? And what was it like for you as a C Sharp developer to interact with it? Yeah. So I guess just to preface this, I, before working on this project, I had like never really done any security work or like any online work at all pretty much. So this, like integrating with Octa and PlayFab was like completely new territory for me. But it was actually quite easy. I was using PlayFab basically originally. The idea was that Octa could give out codes to people for, you know, in-game cash or in-game rewards. And you could redeem them on this in-game terminal. And they would be uniquely generated codes that would be generated by PlayFab. But in the end that actually ended up being less of something that we wanted to do. And more so I just ended up saving all the user's data there. So I refactored the save system in the game to be more in accordance to what PlayFab uses to save. They save everything as strings. So we can push the data onto PlayFab for the user as well as to your browser cookies. And then if you sign in with Octa, I get a open ID connect value that I can associate to your PlayFab account. So that when you sign in on another device, it can detect that you have a PlayFab account from another computer. And it can sort of load up your save data and determine if you want to keep your local or online save data. So. Nice. I know that that was a new thing for all of us actually. PlayFab was something I think that Nick, you and I were in a meeting with some of our folks from the soft that make the suggestion. So can you talk to me about how you separated personally identifying information from all the other user data that was then sent over to PlayFab? Yeah, for sure. So essentially what we wanted to do was make sure that Octa was storing all personally identifiable information because we know that we could keep it secure. Octa being a security vendor, we wanted to make sure that any data that users were entrusting us with, that we were storing it in a place that we knew would never be exploited and would be fully secure. So what happens is Unity from C sharp code will using a JavaScript library essentially interacts with the browser in order to facilitate you know, OAuth or open ID connect. At that point, a user will register, authenticate their data will be stored in Octa. Octa will provide and meant a either basically an open ID connect access token ID token. The ID token is sent to PlayFab in order to authorize the user to PlayFab. And so the game data, which it does not include personally identifiable information, it just includes their save game and information about where they are within the game that gets stored within PlayFab using their ID token. And that's how it associates that user. So essentially, the only way for even the save game data to be accessed is for the user to authenticate and authorize, get that ID token and send that back to PlayFab. So Octa is sort of that centralized security solution that's ensuring that all of the other cloud computing systems that we use, you know, are authorized by the user and all the user's data is stored by them within Octa. And of course the user has full control over that data, you know, GDPR and everything they can go through and request deletes. And so it's really a great way of ensuring that the user is controlling, you know, their identity and what they provide to us. And then what they give us is secured very safely. There's a lot to this. Like you have to make so many decisions about where things are going to live long term. How do we just stand something up in an MVP versus can it scale what's going to happen with it? But when it comes to some of the challenges of like setting up the systems for further development, Chris, I know that you had mentioned something with me earlier about some of the like dialogue and event systems that had to be used for this too. So not only did we have to keep in mind our end users, but also our ongoing relationship with Epic and with Octa for adding and changing some of this stuff. So can you go into that a little bit? Yeah. So I guess to clarify the question, it's sort of just like, how do we keep this project in a place that I guess could be like modifiable later? Yes, that just and how does how did the dialogue and event systems even work for that? And like how much work is it to really change? Because obviously we were giving you changes all the time during this project, right? So you probably had to set it up so that it was manageable for that. Yeah. So I guess the thing that we really focused on in this game, because it was such a short development time, and we knew that we wanted to make two levels. And it's a very systems driven game compared to the other games that we've made in the past that are more content driven. We really focused on the early stages on developing a dialogue system and an event system where we could tie together any kind of events and that we could just kind of plug in new content and it would just work. Because we made the system in such a way where we just basically put in the dialogue, we implemented like all the dialogue for level one and level two in like a day. It was just really easy to just plug it in and make sure that it worked and just test it. As for developing, like so we've had a lot of like minor change requests to certain pieces of dialogue. Normally it's as simple as just knowing which dialogue piece and then going in updating it. I also have been using just command line tools to basically grep through the, because all of the script a lot of objects are serialized. So everything's in a text file basically. So I can just grep through all the files and ask for, oh I know in this one instance we said ping pong and it was capitalized but we needed it lowercase. So then I can see all the instances and then just change them really quickly. So yeah we just made sure that when we built it originally that it would be sort of a system that we could keep and wouldn't be super one off instances. We could kind of just plug data into it and then it would work. So if we wanted to go and make a level three all we would need is the dialogue basically and then we could plug it in and then we'd have to sort of tailor the more specific aspects about what would make level three different from level two. But in terms of actually triggering dialogue it would be a fairly straightforward process to get up and running. Yeah there is Unity is something that I see I'm a social developer, a .NET developer. I've never really messed with it but I know Nick you have and obviously Chris and Tom you have if somebody were to get into Unity for the beginning do you have like Unity specific advice that you can give to somebody? Let's say they they know the language but maybe not how Unity works. I know for me I think very synchronously just because I do a lot of web development and APIs but this is very asynchronous right and there's a lot of event driven things happening. So do you have advice for developers that are wanting to like mess with this ecosystem? Yeah Chris can probably speak really well to that. On the spot here Unity advice I guess I I guess most of the things I do in Unity aren't as specific to Unity as I guess they are just to C sharp in general. I think that's the thing because I started C sharp as a Unity developer. I haven't really created C sharp applications outside of Unity and I think the aspect where I have grown the most is when I learned the C sharp and .NET functionality that I didn't know existed. So I almost would rather have known C sharp and then grown into Unity. So if you can I guess get a basing and C sharp first and then come into Unity and learn the intricacies of Unity I think that would be really beneficial. Also I guess just something I've been more going for lately is I've been trying to design more data oriented as opposed to object oriented which Unity isn't typically great about but you know these coming out with they have like a new package called burst that lets you pre-compile a certain code if it's set up in structs and things that make running really fast and that's actually one of the things we're using that's built into the animation the 2D character animation they use burst so that they can actually pre-compute how everything should animate and move so they're not computing that on the fly all the time because it's being like run at runtime so I think if you can I guess learn burst and go more design oriented and learn the basic things of C sharp first that would be I think probably really good start. Nice all right so minigames let's talk about them that was like the big surprise on everybody's live stream when they were playing the game they're like what is this and I love the the reactions to the token they came they're like there are dots floating across the screen and I don't know and I loved watching the what is this but no explanation because that's what it was like for me to start messing around with Oath in general was like what is even happening here I don't know what's happening so it was kind of very real to life in that way but talk about like the design and how you how you went about about choosing them and coding the minigames for each part yeah so the minigames were a really fun part of development for us we love games especially narrative games like night in the woods and etc where you're kind of breaking up the core adventure the core gameplay with kind of these surprising moments because it kind of shakes you awake and captures your attention and makes you think and and play in a different way and so yeah there were a number of minigames that we came up with and I think yeah definitely the the token factory is probably my favorite just because I really loved the gameplay that's also the composer for the game did an amazing job on the soundtrack but I especially the bass just slapped so hard in the token factory game and I love that track so much but yeah we were it was really cool because we were trying to specifically with a token factory game trying to kind of use the gameplay as a as like an allegory for the process of of Oath and so that was a really cool kind of like design constraint because I think everyone on the team I think Chris was probably the only one who like really understood like what Oath was or like how it works and so it was really cool like learning about the process of how the requests were like moving and then then it was just a matter of like we could kind of we started by just drawing out like that process basically and then as we're drawing it out we're like oh well let's take this actual visual like this this drawn out visual that we have and and try and create some gameplay about it and so yeah it ended up and it was cool because we looked at actually a few very surprising very very unrelated games like um specifically papers please was one of the the games that we looked at for inspiration for that then for the hack attack we looked at um what I think was what is a flight control or something like that um we ended up looking yeah we ended up looking at a few different kind of unrelated completely uh games for inspiration for some of these things um I mean I got commander keen vibes from the hacker yes definitely it was so fun to watch people be like this is impossible you got too many things happening at once coming at you and then they would beat it the next time they tried it and they're like oh well all right it's not that hard and uh we did get pretty good at all the minigames on the team um where for us it was just like second hand nature but um yeah they were really fun to all work with because they're all different tempos different pacing and I think they just uh add a lot to the the gameplay and it was cool because we created each of the the minigames again very very quickly I say we got it like a basic version implemented and maybe like a day or two um and then it was just kind of figuring out again the the confusing part about that the whole narrative structure is then how do you figure out how to tie triggering into a minigame loading into a minigame like halfway through like this other type of gameplay and have that synced up with like the narrative and um structurally the the game is uh it's pretty complicated but I'm really proud again with the the system that we came up with that makes it very flexible and easy to work with yeah you guys should be really proud Tom I have a question for you real quick um I've heard you guys say a few times now that you created something in in just a couple of days and you created a prototype really quickly does that speak to um you know unity at all like the ease of development and and prototyping like could you have done that uh with other development environments um just curious there yeah I definitely think uh unity is is a great tool for rapid prototyping and getting things moving and working very quickly because there are so many like built-in tools that it has I mean we're kind of bouncing between both 2D and 3D gameplay constantly throughout this project and I think actually all the minigames I think are 2D right oh no I guess the drone minigame is has 3D elements but I think I bought this like 3D as well yeah yeah so we're talking I think you're right I think actually the the shapes are 3D shapes um but we're we're constantly bouncing between perspectives which is like a pretty crazy thing to do um and so that there were like that there are really great tools for 3D physics and 2D physics um and that we can uh you know we're using Unreal uh for some of our other projects too and that is that engine provides a lot more structure um and it's kind of intended for I think you know you have like a type of gameplay and you really have like the you know you're kind of defined or kind of bound by that in some ways um whereas unity you can kind of like for better or worse you can kind of go wherever you want to go um and go any direction you want to go and that is really great for a project like this where there the gameplay is very eclectic and kind of goes in a bunch of different directions but certainly you know it's the tools but also just the developers that we have working on the project um we're very good I think at just you know taking an idea and running with it and doing rapid prototyping and iteration and uh kind of refining like that yeah for the amount of time I think that it'd be very difficult to just roll all of this by hand and not use pieces I kind of think about this is like a Lego game we definitely did it with pieces that were pre-built instead of doing everything completely from scratch but when it comes to what you did do from scratch what was it that you did from scratch completely um that took a lot of time honestly I feel like it was just refining the gameplay sequencing it was really hard because there was a lot of I guess conflicting thoughts throughout the entire design process of like should this always be simulating should this be paused at certain points what UI elements do we want on screen um do we want this kind of camera so originally like the money would tick down and stats would tick up while you're talking to people while you're in minigames and then if you're in a minigame and you're playing Pong and then your tech deck goes up enough that it causes you to get hacked then you're in Pong and you're getting hacked and then sort of just we're always refining that and I guess going back and forth between Okta and Epic and Gosmin about what we thought the design should be and I think we in the end struck a better balance of pausing things more to let the player get adjusted and play Pong even though that wasn't really necessarily like the most stressful which was like you're kind of supposed to be working at like this stressful bad company but it ended up feeling a lot better to actually pause these things and I guess just the interplay between all of these systems where there's dialogue and you can get interrupted and some of the interruptions cause you to go places or open up different minigames and then the stats also are controlling that and then yeah it's just a lot of interplay there that as you can imagine has a lot of edge cases especially when we're trying to like transition out of a level or something and then suddenly you have to close all the UI and then as you're closing the UI you get a promotion because your stats go up and then you close everything and then the boss comes and tells you that you got a promotion because you just leveled up or whatever so yeah those edge cases I guess are definitely like and that whole system in general of managing everything because we also have random events so we have random events and scripted events events that are skippable via the headphones we have coding loop events the coding loop itself is an event there's ones where you trigger things and go to places and open minigames so that whole system is definitely what we spent the most time on. So then I want to ask each of you what instead of just what is your favorite part like what are you proudest of that you contributed to on this project or what part of the game are you proudest of let's start with you Chris. I think I guess I when I've worked on games I've worked on a few games now Sol at Gossamer and then I worked on Resilience and my senior project like the main games I worked on and in both those cases I never really got to work on like the character movement or anything really and or like the animation systems and that was like the first thing I prototyped in this game is just how do we get like the AI nav agents moving where you click and we have to like figure out where you clicked on the environment and then if it's a point of interest so I set up like this point of interest system for like your desk you want to be programming the refrigerator you want to open it the printer you want to like do something the fish the hamster you have to like interact with them so I guess the hard part about it was figuring out how to have you go over there and sort of override or tell the player what to be animating and setting up like a bunch of different rules and conditions so I have a state machine I try to behave your tree at first because I thought it'd be easier to do the AI and figure out how to move everyone but it almost was actually like asking questions too frequently when people are kind of not really doing that much they're either working or they're going and checking the fridge so sort of working out the AI making the state machine and tying that to well how are they supposed to animate if they're exiting like a point of interest do they have to like close the fridge are they opening the fridge are they looping through and they're actually at the fridge right now and then determining like how to exit those transitions and enter was basically a whole chain of sequences where you basically ask to enter and the point of interest also knows you're entered and then it tells you back and then it like calls back out there's like a whole series of events for your asking the exit you're waiting for an animation to finish and then you're actually exiting and you're informing all the other people too so that no one else is trying to use the fridge at the same time as someone else basically so as well as all the characters kept colliding with each other and they would actually push people away so if they were at the fridge and someone was trying to get to the coffee machine and they were in their way they would push the character out of the way so I put on like a like a balance that they wouldn't be allowed to walk in but the problem was the character itself would avoid themselves so they would kind of just push themselves all over the place so I had like a system to toggle it on and off based on if they were moving and a bunch of other crazy things that I wouldn't have to I wouldn't think I would have to think about I guess what about you Tom what was you think you're both proud of yeah I mean definitely the the character creator system stands out to me kind of as a whole but to give a different answer I guess something we haven't really talked about I would just say really the the user and face in general this is a very UI heavy game which is again pretty different from a lot of the work we usually do we try and do usually more immersive experiences that are more about the environment than the the UI but yeah there's a lot of really interesting UI tricks that we have going on where we're using render textures we're actually capturing like a video of gameplay or video of something and then rendering it as like a like a video basically as a render texture onto the UI and masking it and cropping it and just you know having multiple UI things popping up and so you'll be interrupted with something or you'll be on the coding loop you'll have that screen up which is its own UI canvas and then having another canvas pop up in front of that and then having another canvas pop up in front of that when you get interrupted again and figuring out like the sorting layer of all those things and figuring out what you can click on and what you can't and then again figuring out how all that stuff blends with having 2D user interface things hovering in the environment in a 3D environment and making the distinction between 2D UI inside of 3D space and making that work with all the different cameras and the camera angles you can do and having again all that working with the UI order and the sorting layers and blending the UI is very complicated it's a lot like web design in terms of how you make it scalable and responsive in all these things and I'm really proud I spent a very very long time not only on the design but also just the technical implementation of the UI so that's probably the thing I'm most proud of too. That's that's super in fact the the UI can get very stressful because of how well it was designed because it's popping up and popping up it's it's super cool you know just just I want to make sure we ask ask the DLC question here from our chat so I'm going to ask it to Katie you know the the question is will there be DLC for our game new scenarios new levels etc you know I know after you beat the game it says under construction what's the plan there. Yeah so I think that sort of is up to everybody you know if this game is successful if people like it if people want more that is definitely something that you know we would love to build out more of this we have so many ideas that we were not able to get to in the time that we had and I know like we would as the team we would love to make more levels we would love to keep iterating on the levels that we have we would love to be having new features so the answer is hopefully yes play the game and tell us what you think and then that will be very helpful in making that happen. All of you should be proud of what we accomplished here and thank you all for coming on our live stream and talking about it a little bit we're looking forward to releasing some shorter youtube clips of us talking about this too the dev diaries journey of this and I guess the last thing that I'd like to ask everyone to do is please please please go to code tycoongame.com play it give us feedback but also share it with people this is all based on how much demand we get if we're going to build more so please share it play it on twitch let us know and we'll retweet you so thanks everyone for joining and peace out