Okay, thanks everybody for coming today. My name is Joel Dice. I'm an engineer at Fermion. And I wanted to talk to you about one of the projects I'm working on at Fermion. The funny thing about this is it wasn't really intended to be a project. It was just going to be an afternoon experiment and a little time to find out if I was able to build a cloud native app using WebAssembly and Java. And the answer to that was no. And a more practical person would have stopped there and gone on to more productive matters. But I actually decided to dig deeper, find out what was missing. And so that's what I'm here to share with you today. And not only did I find out what was missing, I started to piece things together and added some new tools to the mix to actually make it work. And now I've become somewhat addicted and now you have to listen to me rave about it today. So to set a little context here, this is the vision probably very fresh in your mind after Luke's talk here that we have, which is you should be able to take any language you want.  And that could include application plugins, it could include serverless functions, stored procedures and databases, and of course the web browser. And a couple things to notice about all these places I've listed here is that we want to be able to provide isolation. In pretty much all these cases, we have sort of a mixed trust model where you've got code possibly from multiple origins, certainly that's going to happen in a web browser but potentially in any of these cases. And you want to separate them from a security standpoint and a privacy standpoint. There could be sensitive data you're handling. There could be a multi-tenant situation that you need to support. So that's really important. And the other thing is in many of these cases we want fast startup time. In the browser you want a page to load very quickly and start being interactive very quickly. You want fast startup time in terms of HTTP request handlers in a serverless scenario. In a database you want to be able to run a function on a piece of data hundreds and thousands of times and you want the latency to be minimized for each of those runs. So that's going to be a big theme here is isolation, sandboxing, whatever you want to call it to ensure that separation of concerns, separation of data, separation of resources. But today we're going to focus in particular on JVM languages, Java itself, Scala, Closure, Kotlin, whatever your favorite JVM language is. We want to see that work in all those environments. So we'll start out by looking at some of the traditional tools you would use in Java development and then compare those with what you'd use today to develop web assembly components and then see how we can combine those. And then we'll look at why you would want to do that and also why you might not want to do it. We'll look at performance, what sacrifices, if any, do we have to make to achieve that level of isolation? Is there a throughput versus latency straight off? What have you? And then we'll look at some of the limitations of the current state of this tooling and how we can remedy them over time. And then I've recorded a quick demo. The law of demo says if I tried to do it live, it won't work. So let's pre-record, which I had to do like six takes. But so I want that work to pay off here. And I'm going to show you the result. All right. So in Java land, it's all centered around so-called Java byte code. And we basically want to start as an application developer, whether I want to write my program in Clojure or Scholar or Kotlin or Java itself. All of these are going to compile to Java byte code. And that Java byte code can then be run on what's called a JRE or a Java runtime environment. And that environment has two pieces. It's got a virtual machine that interprets the byte code, executes it. And then it's got a standard class library, which provides the APIs and basic tools that you would use to build an application. And the main function of those APIs is to provide access to the outside world. Operating system functionality, networking, that sort of thing. So how does that compare with the WebAssembly component model development experience? Well, it turns out it looks very similar. It shouldn't probably surprise you. If you've been around computing for a few decades now, you'll recognize that Java has already sort of covered a lot of this ground with mixed success. Certainly there were Java applets back in the day running in the browser. You could run it, you know, the whole idea was write once, run everywhere. That's what we're trying to do with WebAssembly. We're trying to do it better. But it's not surprising that we're following a similar pattern. And so here, you take your favorite programming language again. You compile to a WebAssembly module or component. And then you run that this time in an environment that very much resembles the JVM. But this is a WebAssembly runtime. It interprets just in time compiles what have you the byte code in the WebAssembly file. And then we have various APIs to interface with outside world. That's what Luke's talk was about, is modularizing those APIs. But right now we have Wazzy for interacting with POSIX style systems or something that can be made to look like a POSIX style system. We have Web APIs, if you're running this in the browser, that you can create JavaScript shims for. And then you can run that anywhere. So what would it look like to combine those things? What if your favorite programming language is, in fact, Java or Kotlin or what have you? We want to be able to do the same thing. And so in order to do that, we've introduced a couple of tools here that might not be familiar to you. The first one is TVM. And I've since created a friendly fork called TVM Wazzy. And this is a tool that takes Java byte code and will essentially transpile it to WebAssembly. And then that WebAssembly can be run as usual on a WebAssembly runtime according to the world to use Luke's terminology that has been defined for your application. And so any compatible host that can host that world will be able to run it. And you'll run it as usual. I mentioned worlds to mention the other tool, which I think Luke also mentioned, which is WitBindGen. And this takes a set of WebAssembly interfaces and generates bindings. And that's the second big contribution we've made here, which is Java bindings. They landed probably about a week or two ago in the WitBindGen repository. So now you can generate Java bindings. And if you know anything about the Java ecosystem, it's very easy to reuse those bindings in closure and from Scala and so on. So one set of bindings makes it usable from all of those languages. So next question might be, why would you want to do this? This looks a little more complicated, right? Good news is these tools are actually sort of hidden behind the scenes. You don't really have to work with them directly, as we'll see later.  You've got a WebAssembly. But there is extra complication, extra things that could go wrong potentially. So why would you want to do it? Well, first let's look at why you might not want to. First of all, if you are well served already with the Java ecosystem and your team knows Java or Scala, what have you, and you're used to the tools that are available in that ecosystem, you probably do want to stick with that. If you're well served, if you're writing long-lived stateful applications and services, that's what Java was made for. It's got decades of optimizations and fine tuning for those sorts of things. If all your code is trusted, you're writing a monolith or microservice that all your dependencies are vetted, Java does really well there. And then as we'll see in a moment, the JVM has maximum throughput. It's the hotspot JVM from Sun and now Oracle has been optimized for decades. It's an amazing piece of technology. And so I would sum this up as by default, if you're using Java, you should probably use the JVM. Especially if it fits the workloads that you have. And so when we would consider WebAssembly here for Java, it's kind of the flip side of that. Many shops these days want to be able to use possibly a mix of languages that are JVM friendly and not so JVM friendly. And the hot thing these days is building services out of stateless functions, the whole serverless paradigm. And as we saw earlier, short lived functions have applications and databases, smart contracts, etc. Those cases are not necessarily what the JVM was designed to handle. Whereas WebAssembly, that's kind of its bread and butter. Untrusted and or multi-tenant code. This is definitely something you've seen the browser, serverless. If you're hosting a platform as a service, or you're choosing a platform as a service, you want to know that there's strong security and isolation guarantees, that your data's not going to be leaked. Through side channel attacks or otherwise. So a strong sandboxing model is super important. And then even if you're not in a multi-tenant context, these days, any modern app is going to have a long list of dependencies and transitive dependencies. And for Java developers in particular, the whole log for J fiasco is fresh in mind. And people have been talking seriously about how do we deal with this? How do we address supply chain issues? And that's a multifaceted problem. But one of those facets is sandboxing and limiting the scope, the capabilities to use Luke's term that are available to a dependency. And so if you were a Java systems administrator a few months ago, you were probably asking yourself, why did my logging framework make network calls?  With WebAssembly, that's a non-starter. First of all, you wouldn't give your logging framework network capability unless it specifically needed it. And even then, you would restrict the set of hosts it could access. And class loading just isn't really a thing in WebAssembly.  So, but one question often comes up, certainly came up in my mind when I was working on this, is what about performance? Is sandboxing expensive? What cost am I paying to achieve that sandboxing? And so here's a chart, performance is a complicated subject. It's hard to sum up in a single chart or set of numbers. But what I've done here is I took just a handful of little example, CPU heavy types of problems and benchmarked them in various execution models. So just the main takeaway here is what I said before, maximum throughput is what you would get from OpenJDK or any other modern JVM. And that's what we see here in the blue. That's OpenJDK with no attempt at sandboxing. We're just trying to get the best possible performance. And then over in red, we have TVM plus WASM time, a popular WebAssembly runtime. And we can see how performance stacks up there. And then in the yellow, we have OpenJDK again. But this time, we're actually trying to sandbox it. We're actually forking a process for each invocation of our function here. And so we see that has a performance impact. And just for fun, I threw in GrawLVM's ahead of time native compile option, which also with sandboxing. Just to kind of see how WebAssembly with TVM stacks up against the other options you have for sandboxing Java. If you've been around the Java ecosystem for a while, you know that there were originally, I should say, past tense ways to sandbox code within the JVM. That's been deprecated. The security manager, if you're familiar with that, that's been deprecated. There's no planned replacement. So these are really the only viable options you have for sandboxing Java. And the main takeaway I want you to have here is that TVM and WebAssembly are competitive with your other sandboxed options. You do lose a little bit in terms of single core raw throughput, going from a non-sandbox scenario to a sandbox one. But for a lot of us, sandboxing is non-negotiable anyway. So we don't even need to look at that. And the other thing I want to mention here is that even though performance, there is a performance hit, you can gain some of that back because pure sandbox functions where you're spinning them up very quickly and then tearing them down often don't need to garbage collect.  Plus these things are embarrassingly absurdly parallelizable. Each invocation has its own memory, is not sharing state with others. You can horizontally scale these things to the nth degree and win back some of that performance that you lost in terms of pure CPU single core. All right, so all this hopefully sounds pretty good. We've got strict isolation. We've got competitive performance compared to what else is out there. We're buzzword friendly, we're modern, we're hip or cool. So what's not to like about this? Well, there are some limitations. They're all addressable, but they're worth mentioning. Right now the WebAssembly support in TVM itself is experimental. It was actually intended originally as a tool to transpile Java bytecode to JavaScript, and that's still its bread and butter to be run in the browser. So there are some bugs hidden there. It works really well for the most part, but there's bugs and we're going to need to address those. The standard library is incomplete, there was a deliberate decision, and I think it was the right one not to reuse the OpenJDK class library due to licensing concerns, the GPL, and it's maybe not so business friendly nature. Reflection, if you're a long time Java developer, you know that reflection can be like there's a drug that you tend to use to solve. It's the hammer you use to solve all the problems, and many upstream dependencies might need it one way or the other. And that takes a little bit of extra upfront development effort. And then the wazzy component model that Luke talked about earlier, it is under rapid development, that's a good thing, we're making rapid progress. It also means the tools are churning, the interfaces, with bind gen, every day the interfaces change and whatnot. So it takes some work to keep up with. And then finally debugging and profiling, if you're used to visual VM or debugging in Eclipse, the experience for WebAssembly is not nearly as slick. It is doable, it could be made better. And let's see, so in terms of next steps and ways we could improve, it's basically a reflection of the last slide. We wanna get more TVM test passing. We want to add more features to the standard library as popular third party dependencies need those extra features. We need to stay current with the component model as it evolves. We need to ideally generate some debug info. There's various formats such as Dwarf, which Wazemtime supports. And it would be really cool to be able to just open up your favorite debugger and see all the local variables, see the line numbers and whatnot. So we wanna get there. And ideally we implement the JVMTI interface, which is the standard interface for Java applications and debugging. And then finally, the current generated bindings are not necessarily, they're more a direct translation of the WebAssembly interface types. They could be made more idiomatic in terms of error handling via exceptions and so on. Right now they're very usable, but could be better. So given all that, let's see this in action. Let me see if I can find a moment please. So this is my prerecorded demo. Sure we got volume here. It's gonna snap back into place, that's silly. My goodness. Linux on the desktop, what do you know? Let me, got it. It uses wazzy and spin SDK to handle incoming HTTP requests and translate English words to Spanish words. It uses wazzy to access the file system and load the dictionary of words. Also just to show off outbound HTTP capabilities, it can optionally proxy a response from another host. I'm not gonna spend too much time looking at this code right now, but you're welcome to check out the link at the end of the presentation. Here we have the spin manifest that defines the environment that our application will run in, including the list of hosts we're allowed to make outbound HTTP requests to, as well as the set of files that will be available in our virtual file mount. In this case, that will include the dictionary from English to Spanish words. So let's go ahead and build the app that just invokes the maven command we specified in the manifest. And that looks good. So we'll spin up to run it, bring that to the background, find out what cloud is in Spanish, nube. And since I'm already logged into my free Fermion cloud account using GitHub, I can go ahead and spin deploy, which we'll send it out to the internet. And then I can share this URL with other people. Go ahead and test it real quick. Find out what goodbye is in Spanish. Adios. And there you have it. Adios, amigos. Thank you. All right, so that's about it. That was the demo. There's going to be a link here. There's all the links. So the benchmarks I showed you, the results I showed you, those are available in a repository here. There's a link to that and as well as the demo I just did, the application and a few other resources, the link to the Java binding generator in with bind gen and then TVM wazzy. I should just note I didn't make this clear earlier. TVM wazzy is a friendly fork of upstream TVM. We do have a PR open for upstream TVM. We'd like to get it upstream. It's not clear whether that really fits the mission of TVM as the lead maintainers see it. So it may not end up upstream, in which case we'll just maintain a parallel friendly fork going forward. So I think we have time for questions. If anybody has any questions, I'll self-explanatory. This is awesome. Thanks for presenting. Just wondering if you talk a little bit about the translation between Java bytecode into WebAssembly and what's compatible, what's not. How do you kind of polyfill any gaps? For sure, yeah. So the question was, wanted to hear more about the translation that TVM does from Java bytecode to WebAssembly. The first thing to know is because WebAssembly currently doesn't have garbage collector support, doesn't have exception support, doesn't have any notion of reflection and whatnot, that all gets bundled into the WebAssembly that you create, the component. And the cool thing is that amounts to about 180 kilobytes in the Hello World case. That's kind of where you're starting from. So very minimal. Otherwise, Java bytecode, if you squint, it's not that different from WebAssembly. Things like working with floats and integers and so on, that translates almost one to one. The stack model and the register model is a little bit different, but there's a straightforward transformation. Higher level instructions in Java bytecode, such as invoke virtual, invoke interface and whatnot, those all have to be kind of built out of the WebAssembly primitives to do lookups. So there's a whole static memory segment that is instantiated in the WebAssembly for virtual function tables and that sort of thing. But it compiles down to a pretty efficient code, and I'm sure if the proposals to add garbage collection and exceptions to core WebAssembly gain traction, then we'll see that become an even smoother and more straightforward transition. Does that answer the question? Cool, anything else? So in the course of your experiments, I'm curious to see one of the things we tend to see is this, the idea is really easy to see WebAssembly in fast firing functions model kind of thing. A lot of the things like Java.net, like I'm from Microsoft, so it's a similar model in approach, are based on sort of the idea of a kind of a heavy scalable middle tier sort of concept. It's long running, it can do all kinds of cool things. In the course of this experiment that you were working on in this project, how did your thoughts evolve with respect to sort of where the strengths and weaknesses were a little bit more than what you just said here? Did you have things where like, oh, actually we can do that or oh, no, that's not really the thing we should do and so on? Yeah, well, so I was coming at it from the point of view of spin. Matt and Radu talked a bit about the whole idea behind spin and it was very much this mindset of serverless functions and whatnot, so I actually have about two decades of development experience in Java and have worked on those big monolithic long-lived servers and whatnot and I think there's still a place for that, there always is going to be a place for those but I'm really excited about the component model and in the serverless context for basically, starting with stateless functions, using that as your super horizontally scalable building block and then using a distributed data store whatnot to kind of store your state, between requests and so on, to build those distributed systems and so it's really, I think it's a matter of opinion and also a matter of use case whether microservices and nano services and serverless are appropriate versus a monolithic big iron server and I think you just need to know your problem domain well enough to kind of make that decision. I don't think there's ever gonna be the right, a single right answer so that's why I was trying to be very balanced here. I think a lot of people just should stick with that Java model that kind of just long-lived stateful service model and but I do think there's room for a different model depending on your use case and again, being able to reuse this in the context of databases, in the context of blockchain, in the context of the browser, I think we're just seeing a lot of different places people wanna use Java or any other language and that's what this is all about. All right, that's all I got. Thanks for coming. All right.


Breath of the Wild is an amazing game, but we spent a long time waiting for it ever since it was revealed in 2014 I had been waiting with baited breath just to hear anything about this game I've put over 300 hours into this game now, and I still am discovering new things every time I play It's just such an amazing vast world But it seems looking back that this game has gone through a lot of changes in the many years of spent in development Looking at the map that was shown back in 2014 It seems to be relatively the same with small differences here and there But how much has the game really changed and can we find all these spots from back then? I actually decided to go back and take a look at all of the old trailers and Find where those locations ended up being in the final game Let's start with the more recent and work our way backwards I did a pretty heavy analysis way back when on the story trailer and the life in the ruins trailer But I never did an analysis on the E3 trailer from 2016 And I'm pretty well versed in the world of Breath of the Wild now And I was able to actually find all of the locations in the trailer Starting from this panning shot, which actually turned out to be in the Necluta region We can pretty much shot-for-shot remake the trailer, but this is a really recent build of the game So finding all of these areas wasn't too challenging, but what if we take a step even farther back? Do you remember in 2014 when we got this gameplay demo at the game awards? Okay, so today why don't we show a glimpse of how the new Zelda game is shaping up? Sure Then I remember this little gameplay segment really capturing my imagination But where is this now in the final game thanks to the map that they actually show? It was pretty easy to find this spot being just outside Hateno village You can see that the area remains pretty much the same but also really different With some subtle changes to the elevations of the mountains and actually the cliff that Link is standing on himself being scaled back And shortened the region's tower having moved as well But other than that a lot of the area's geography has remained relatively unchanged So if we follow Mr. Anuma off of this cliff when he uses the sailcloth which became the paraglider It cuts here, and I was always unsure of just how far away he went But it turns out that it's really close by actually in fact. Here's how far I had to go to find this spot The cliffs have been again altered just a little bit I was able to find the spot thanks to that rock formation off the edge of the cliff But here's the confusing part next they say that they're riding to where the tower is But then suddenly they cut to all the way down to Lake Kolomo between Central Hyrule and the Great Plateau They would have had to ride out pretty far to get to that spot if the map has really remained this intact So they really haven't stuck close to their destination at all In fact, they went way past it and way far away They ended up over here by these two pillars which we now know are the Farron Woods region and Again, this is still pretty far off from their target and where they started They had to have been riding for a while Although the enemies aren't here anymore in the final game Miyamoto was right that we are close to a well what he called a dungeon But turned out to be a shrine near this place But it's weird because they were riding in from the north and then they ride back out towards the north again Which means that they must have already crossed the bridge of Hylia to get to this point Only to turn around and cross again So I've marked with pins on the map about the route that they took and again It's kind of very confusing that they went so far from what they said was their destination, but oh well It was just a gameplay demonstration Not something to think too heavily into but what if we go even farther back? We had such silence about this game for so long It can't be any surprise that what little information we had became so well known and so iconic So do these areas still exist? I mean this was the first time that they revealed the game But this was only a few months prior to the game awards footage, right? So do the areas from this very first original trailer still exist in the game? I mean everything else seems to be pretty well intact from 2014, right? Well, if we take a poke around Sort of some of them do why don't we start over here where link rounds this corner These statues still do exist in the game, although not exactly in this formation It's really hard to find but the closest I can get is this area near the zonai ruins here But it gets a little confusing from there. This does not connect to any open fields So they must have been having this pursuit for a long time to have gotten here I'm not really sure but the only corner I can find with this giant snake statue like this Does not have this bird statue in any close proximity to it, although Rounding it does take you right to this little bridge area here But on the other side So either that they flipped a bridge or something or they recorded just a bunch of different footage Either way, it doesn't make any geographical sense with the final game Again, it's possible that the game has just changed so much since then that this used to be how the map was But it isn't anymore. But again, only a few months later We got that game wards map, which is almost identical to the final release So it's just very confusing in retrospect, but I know the question that everyone came here for This screenshot of Hyrule Where is this in the game? I mean, we do have some landmarks that are in the final game Well, we just have to try and triangulate where this area is I did a lot of digging and I realized that The villagers and buildings are probably gone, but maybe just maybe this area does exist in some form in the game So what landmarks do we have to go on? Well, the dueling peaks are far in the back and you also get to see Hyrule Castle and Death Mountain And another sort of spirally looking mountain, which I've actually figured out to be the peak of Awakening If we pin all of these areas and triangulate them that does bring us to the Necluta region But where? Well I did a lot of digging around and I think that this area has been dismantled and reintegrated separately into the map Here we have what looks like the cliffs of quints And we have some Bacoblin or Bacoblin and camp camp tower thing But none of these close to an open field like this And there's a few other problems that I've run into For example, the dueling peaks seem to have flipped with the smaller side being on the south instead of the north And not to mention that Death Mountain seems to have grown substantially But I wasn't able to find any open fields that would give us this angle of all of these landmarks Just it just doesn't line up We did see in the game wars trailer that the elevation of some mountains has changed So my theory is that this area has just become a different area that they've built mountains on top of it They probably flipped the dueling peaks for some reason at some point in development to better line up with the geography of this world But it's just impossible to find an area exactly like this The best bet is that it lines up somewhere around here And that at one point this area was more open field and became a mountain That they just started building mountain on top of it But that's really the best we can get in all honesty. I believe that our best bet is either mount duncel or mount taran It's really sad though because for a long time. This was all we had of breath of the wild All right guys, maybe I'm thinking too hard and digging too deep into this But let me know what you think down below in the comments and as always Thank you so much for watching. If you want to see more videos like this, please subscribe to nintendo prime And I'll see you all next time. Bye. Bye


I grew up of course playing a ton of games and I knew that games were what I really wanted to do. I had no idea how to get involved in them, but I ended up going to Drexel University in Philly and they have an amazing game design program there. And I actually, we were lucky enough to be at the right place at the right time where there was a brand new program opening up called the Entrepreneurial Game Studio. And it was kind of this program for students to take, a lot of times when you're going to college creating games, unfortunately, a lot of your games just end up dying kind of like in the classroom. You turn it in as an assignment and then it's dead. But there's a really cool program that started up for getting students to release their games commercially. And so we joined that project, I was one of the first members to be accepted, and I ended up performing Gossamer Games, which is something we're still doing like six years later, I think. So yeah, it was kind of being at the right place at the right time. But I knew I wanted to get into games just because of, I've seen kind of firsthand how impactful the medium is. And I think out of all the entertainment mediums that exist out there today, I think there's the potential to have the most impact working in video games. And so I knew that that was where I wanted to go. And it's so exciting to be working on all types of projects that are kind of shaping the future of what the medium can be. I guess I always wanted to develop games. Ever since I was little, I remember I would just think about games, not in a programming sense. I never really programmed until I got to college. But I would just kind of draw out like the levels on paper and like what the characters were and what kind of game it was. I would kind of like make descriptions for them, I guess. But yeah, getting to Drexel, I graduated high school in 2015. So then probably in like 2017, I joined EGS and I was lucky enough that in like one of the first meetings there, I actually saw Tom speak about Seoul and they needed a programmer and I was like, eh, I'll just shoot my resume, I guess. And then I actually got the job there. So I started working just part-time whenever I wasn't doing schoolwork on Gossamer Games for Seoul in like 2017. That was like the first real game project I ever worked on. I hadn't really worked on anything that was more than like a two-week project before that. So that's where I got most of my development experience. And then just through Drexel pretty much otherwise, I just graduated last year and we had a big senior project that we had worked on for about nine months to a year in like a city builder that was sort of like where I got a lot of my other experience. So basically all my experience can be summed up into those two projects. Well, I learned to code through games with the release of or when John Carmack made the decision to open source the idtech engines, I used them and I started reading them and I started learning how to hack them up and I started taking them apart. And that's how I learned to code. That's how I learned C and later C++ with idtech 3. And then I went to film school. Then I worked in broadcasting. Then I ended up in tech and then I focused on security. And somehow I'm back to doing what originally kind of gave me the passion for development in the first place. And I've always been a gamer. Like Chris spent a lot of time thinking up how I would design this and reverse engineering how they designed that was something else that I did. And kind of similar to what Tom sort of said earlier, you have a real ability to reach people. What really fascinated me with games was just this whole storytelling aspect, this whole ability to reach so many people and affect so many people emotionally and just it's powerful. And I think using games in a way of just interacting and to just really creatively express yourself is just a really exciting thing. And I just have always been drawn to it. And so I don't know that I consider myself to be a game developer at this point, though I am pretty well versed in Unreal and Unity. And I've been kind of along the edges of the industry for most of my life. I've been trying to develop games forever. And so it's just always been a passion of mine. Yeah, so we're Gossamer Games. We are a tiny independent video game studio based in Philadelphia. And I think there are like five of us working on this project now, so very small, but we work on a variety of projects specializing in adventure games, narrative games. And yeah, we work on platforms, mobile, console, desktop, on all different types of projects with clients and also on our own original work. In terms of working with Okta, we were actually it was really cool. We were approached by, we have an awesome video game community, development community in Philadelphia. And so we were talking with one of the studios around the area and they'd actually gotten in touch with someone and they didn't have the capacity of taking on any more work. And so they reached out to us and were like, hey, this sounds like a really cool project. We think y'all would be a really great fit for it.  So we got in touch and yeah, the rest is history. We were really interested in creating something a little bit different and something that most tech marketing departments aren't really expanding into the video game world. And specifically with developers, there's such a massive overlap between developers and gamers. And we're really hoping to create a game that can capture the experience of what a developer faces every day in the office, whether it's actually trying to get coding done or dealing with coworkers and dealing with productivity off-sites where you don't actually get anything done. So we wanted to meet that intersection of developers and gamers and speak to some of the pain points that developers experience but also make it fun and make it light and make it something that you would want to play on a Saturday, not just something that's worked really good. It was a really cool process talking about creating a game for developers capturing our experience. And that was a really cool opportunity for us because we could kind of see ourselves in the protagonist and the player's perspective. And so we wanted to create a game that was capturing a lot of the... I know, so I'm on the production direction side of things and so maybe Chris can speak more to this but I do know that I am always a person bothering Chris as he's coding. And it was really cool working on a game where we wanted to capture that dynamic because I think it's probably common across software development not even just video game development but you'll be working on something deep in the code and it just seems like the universe is inspiring against you to pull you out of that as soon as you're getting into your flow and solving the problems you're trying to solve. So we wanted to create a game about that dynamic and really create a game that was kind of hybrid simulation hybrid narrative that was all about the experience of developing. With something like this, it's so different and it's so new and it's not something that you really expect to come from a company like Octa. And we're so excited about it that we just want to share it and we really hope that people are receptive to it and that people want to play it. And also we're hoping that people are going to learn a little bit from it and maybe be inquisitive and if you learn something about Auth that you didn't know before then that's a win for us. So we really want to provide it more as a sense of enjoyment and maybe a resource and we feel like something like that should be free. First and foremost, I think I want to know if we did a good job of capturing what it's like to be a developer in an office environment. Like I hope it's relatable and I hope that it's funny and it's tongue-in-cheek and the humor comes across. But yeah, I just want to know did we hit the nail on the head? Did we get it right? Is this what your life is like? Or are we totally off face? And also I want to know if we had fun. Like that to me is the most important thing. Did you enjoy playing the game? Did you learn anything? Would you play it again? I think it's really basic but I think for me those are the most important things to hear. I am very curious to know how many of your co-workers you see presented or portrayed in the game. Because I think it's very true when we were first sitting down and going over some of the scripts and some of the characters. I could totally tell like I think who was I identifying with. But I could see like all of my co-workers and people that I worked with in the past I could see like little elements of their personality kind of all scattered around. So I guess yeah, like did we hit that? And yeah, did we kind of capture exactly what I said before? Did we capture kind of the feeling of the trials and tribulations of being a developer and kind of the balance between doing your work and being sucked away from by all these distractions? I would love to learn if any of the game caused them to have interest in aspects of security or development security that they didn't have before. We didn't really want to spend the time making you, forcing you to go through an educational thing, if you will.  Did that make you question and want to learn more about security and have you been able to to find those resources to learn more? If not, we really want to help you with that. In an ideal world, I would love for this being a vaulting project. I think that there were a lot of really great ideas that we had that we just didn't have the time to fully put into motion. And there's definitely a backlog of things that I think were just really, really, and we didn't have the time for. So I would love to see some of those things implemented. I guess that just depends on how many people want to play. And if it seems like it's something that people are enjoying, then I would imagine that we will definitely, we're going to keep this as a living thing as long as people want to play it.