 I think when we're designing a new game, one thing we always try to start with is thinking about the player's perspective, because I think a lot of times as a designer you kind of start with the mechanics, and then that leads to like the dynamics, like in terms of how players are interacting with the systems, and then that leads to like the overall user experience. And I think one thing we always try and start with is starting from the very end and thinking what is the experience that players are feeling, and then working backwards to figure out, okay, how are they engaging with systems, and then what are the mechanics that kind of shape that? And so I think from the beginning, we wanted to start with, again, capturing that feeling of you're trying to do your job, you're just trying to get through your tasks, but you're just always being pulled out from it, and kind of really capturing that like emotional struggle that I think developers tend to have with just being super frustrated in terms of, you know, you're working right in the middle of something, and you're about to solve something, and then you get pulled away to go feed a hamster or something like completely ridiculous. So I think for us starting with the player's perspective and then working to figure out what are the mechanics and what's the narrative and everything that would support that design. Basically, each week, we sort of plan out our tasks in hack and plan, which is basically just like a productivity tool. And then from there, yeah, we get into Unity. We have 3D modelers, Nina was working on the 3D models for the game and sort of inside of Maya. And then I do most of the programming along with Drew and Taylor. We all use Visual Studio or Visual Studio code. And then Unity is a really great engine. It just has like a visual interface for you to drag around objects. You can attach components and you basically script everything out of Visual Studio and C sharp. And then we were deploying it to Azure. So we had some HTML that was being created after the build. And then we were hooking it up to Azure and hooking up to Okta. I guess that whole stack was completely new to me. I had never really done any networking or like web programming before. So getting up and running in Unity and connecting out to PlayFab was super easy. You basically just download their SDK. They have like a whole API interface that lets you have like host data on their server and you can pull it down really easily. You can connect user accounts anonymously through a GUID system. And then when we linked in with Okta through their API to get user data, we were able to use an open ID connect that linked to the PlayFab so that we could have the data on PlayFab store the user's saved data and then link that to their Okta accounts and then so you could play across device, which was really cool. But it was a really easy system to get up and running, I guess. We work in both. We're actually working on a number of Unity projects right now and then also an Unreal project and we've been working with Unity longer. I think in general, Unity is typically more accessible to kind of get into. We've definitely the learning curve of kind of getting into Unreal on the mix of blueprints and the C++ code and all that stuff has been an interesting mix for us. But I think in terms of preference, you know, both engines are super useful and have amazing features across the board. I think some projects are better suited for one engine versus the other. Certainly working on a mobile game or a web game or, you know, a game like Code Tycoon, I think makes sense in Unity. But, you know, when we're working on a more cinematic, like third-person adventures or anything like that, I think Unreal and the graphical fidelity that it provides and still the tools that we can use to create like a more cinematic experience, I think works really well for us. I think Unity has a lot of good features that are more suited towards like what Tom was saying, that are more web-based or 2D. Unreal is definitely more of a 3D engine. Unity is as well, but I feel like the 2D capabilities are better in Unity. I've also worked in Game Maker Studio recently, and that I really like for 2D. It's quite different, actually, from the other two engines. It's kind of hard for me to get into, even though I'm really used to Unity and Unreal. I started working in Pico 8, which is, for those that don't know, it's kind of trying to emulate like an NES sort of architecture. So, you're developing 8-bit games, and the engine is itself the engine as well as like a storefront to host all the games for free. And you can download games, see everyone's source code. You can play around. You get to make the music in there, the sprites. You program the game, and that's really cool. That's definitely really interesting. I really like the low-level stuff. I'm actually really interested in making my own game engine. And I've been following the Handmade Hero series, which is making a game from scratch and see with no libraries or anything. So that's definitely more akin to the lower level stuff that I'm interested in. I would say if you're getting started in game development, it depends on what aspect of game development you want to do as well. If you're looking for programming, I can definitely speak the best for programming. Tom might have better advice for art of design or something. Definitely start small. I even now I keep to this advice and I'm really bad at it. I always have really grand ideas that I want to go and pursue. But it's just really hard to keep up with something if you're having to learn every step of the process. If you're only learning maybe like one or two things. It's definitely a lot harder to get bogged down. So starting really small and also I think learning inside of an engine is really good. Using something like Unity would be great to get started in. But then also going back and learning more of like the fundamentals of just base computer science so that you're more versatile of a developer and you know not just how Unity's API works, but maybe you might know how it works beneath the code, which is really helpful if you're trying to become really serious about. Game development, so I worked, I think, primarily on like the content implementation side of game development instead of the more online integrated side. And I think one of the biggest challenges that we had was trying to figure out how to implement the narrative content because trying to figure out how to do narrative in a way that is easy to update the text and the copy and then also figuring out how to really have a flexible system for firing those off. Again, the design of Code Tycoon is really interesting because there are simulation aspects and then which are very like nonlinear kind of free form. And then you have these linear narrative aspects. And so trying to figure out like how to to wrangle all the narrative bits, store it within the game engine and then have it fire off when it's supposed to. And then also having effects on your stats whenever you choose certain options. Having all that system working was something that we developed over pretty much the entire course of development. And I think the solution we ended up coming up with was using, I feel like we had actually a number of scriptable objects set up where we could basically have text objects. And then we ended up coming up with a really nice system where you could have a description and then you would have the different options if it was a multi-choice response that we'd presented to the player. And then within those we'd have the metrics that it would affect. And so we had this really nice data structure visually represented inside of Unity using scriptable objects. And we could use that. We also had another scriptable object system for calling those events. And so we had kind of like these layers of data structures that would let us organize all the data. And I think it took quite a while to figure out how to organize all that stuff. But in the end, I think we ended up with a pretty solid modular system that let us basically implement, I'd say, the majority of the narrative contents. I would say it probably took maybe like three or four days to get like the bulk of like the entire narrative into the game because we had a really robust system for that. So that's probably that was from my perspective, the biggest challenge. But it's also probably the thing I'm most proud of for this project. I was primarily working on like not much of the game stuff for like the latter couple of months of development and focusing more on the online stuff. And I think the hardest technical challenge for me was in like the last month of the project, I wanted to re-architect the saving so that we could properly save all your data locally to your cookies as well as to PlayFab. And then based on if you had signed in with Okta and if you had pre-existing save data, pull down the online save data and then sync the two together. And I don't think it would have been that hard of a problem if we had just architected it well from the beginning and saved data well from the beginning. But we weren't really thinking of that as, I guess, a high priority. And so we had like a lot of when we re-implemented the event saving, we were saving like each event's name and GUID as like a string. And then when I was re-implementing it, I wanted to save the data like sparsely so that we wouldn't be using a ton of data on the server. So I had to kind of re-implement it back into a state where we could be sort of sending up like bitmaps of indices for like events in arrays as well as we had like a whole another classification of like these world events that aren't through like the normal event queue. So handling those separately and making sure that those could be handled pretty sparsely as well to make sure that we're not using so much data that you'd have to pull down tons and upload tons and have to check against all these different factors. It'd be like really easy to just pull down a bitmap and then compare the two. So that was probably the hardest aspect for me. For me, I think it was getting Unity to interact with the browser. You know, Unity doesn't have really anything built in for OAuth or for any type of authentication concepts. So we kind of had to build it ourselves on that side. So it took the creation of a JavaScript library that allowed the C sharp code to talk to this library that then talked to the JavaScript and the HTML. And so that in itself was painful to implement. And then it was really painful to debug like even to this day, Chris and I get the joy of trying to figure out why we're getting a specific error when we can't use debug points when we can't step through the actual code because we can't run it locally. We have to host it in order to be able to have all the JavaScript pieces work together properly. So it's a little bit painful and it does go to show why we're wanting to spend more time on security within things like Unity and Unreal. More tools would definitely, I think, be helpful there. But I think for me, that was the biggest challenge.