Hello everybody. Happy Monday and welcome to OpenShift Commons. Today we're going to do another AMA briefing on a wonderful project, CubeLinter, brought to us from some of the folks at Stack Rocks. And we have Michael Foster here. He's going to introduce himself and his colleague Vishwa. And we're going to get an introduction to the project, where it's at, the roadmap, and have time for Q&A at the end. So without any further ado, Michael, please tell us all about CubeLinter, the community, and where it's going. Awesome, yeah. Thanks for the intro. Again, I'm Mike Foster. I'm a cloud native advocate at Stack Rocks, and I'm joined by Vishwa.  Hello everyone. Hey. And Vishwa is the lead maintainer for the CubeLinter project. So he's here to direct me if I get off course about anything. Vishwa is going to be my go-to guy as I would just walk through CubeLinter, talk to you about the community, demo its functionality, and hopefully have you joining the community after. So let's just get started. So again, what I'm going to cover, just going to go through an introduction, why we decided to create CubeLinter, where it fits into the ecosystem. Again, show you how to get started, download, integrate into your pipelines, just general workflow. So I'm going to show you how to use CubeLinter and the CubeLinter Lint functionality. I'll show you some of the more advanced features like configuration and configuring the policies and setting some flags so that we can ignore checks and enable checks. Lastly, I'm going to get into integration. So show you kind of where the real power of CubeLinter takes over as part of your CI pipeline. And we're going to talk to Vishwa about what's coming next in the pipeline, some issues with the project roadmap looks like for CubeLinter. And again, how you guys can all join in. I've already introduced ourselves, but again, that's Vishwa, I'm Michael, and I'll send some links at the end. So if you guys want to contact us or learn more about CubeLinter, we'll be happy to talk to you. So what is CubeLinter? So it's a CLI, right? It's a command line interface for Linting Kubernetes objects. These Kubernetes YAML files can be in the form of Helm charts. They can be just regular YAML files. And what we're going to do is we're going to use the default policies that are baked into the CLI to then let you know if there's some configuration mismatch, if you have elevated privileges and things of that sort. So because we have all these policies, we can configure certain policies, enable and disable them so we allow for some fine tune policy enforcement. And because it's a CLI, it's Go-Based, we have simplicity in design. It's something easy for you to integrate. It's a binary, right? Just download it, install it, add it to your CLI pipeline. Very easy to work with. And again, YCubelinter, because there's all these different policy options out there right now. And so we at StackRocks kind of saw that DevSecOps really wasn't catching on. And there's a reason for it. You can have all these tools, doesn't necessarily mean your developer's buy-in, doesn't necessarily mean it's easy to use. There's a knowledge gap, right? For some of these tools, maybe you have to learn another language. Though we wanted to keep the project simple, keep a relatively low knowledge gap in terms of being able to implement it. It is a Kubernetes-focused project. So some of the other policy applications are a little bit more wide in scope. This is for Kubernetes. So you know that that's what we're going to support. And that's what we're moving forward with in terms of policies and all our integrations. And really, Cubelinter is just there to identify misconfigurations as close to the source as possible, right? So we want to enable developers and CI pipelines to catch just issues as close as possible in a declarative way. And the checks are also there to give knowledge for further growth for users. So not only are we linting the files, but we're also showing you why the policy was created, documentation. If you're unaware of why the policy is there, you can go into Cubelinter into Kubernetes documentation and find out more. In the end, the end goal is that you can build operational policy, you know, within your organizations or teams. So something that can be implemented on a personal level, across a team or across an organization. And I'll show you how to do that. Okay, let's get started. I'm going to take a quick journey over to the Cubelinter project. So Cubelinter can be found on GitHub at Stackrocks in the Stackrocks GitHub repository, Stackrocks slash Cubelinter, where here you'll find everything that you need to get started. Vishwan and this team have done a great job at creating a dock site, which I personally like using a lot more. That's not dark mode for me. But yeah, so we have everything here installing Cubelinter, building from source, the usage, how to get involved in the community and the license as well. So again, you can install because to go binary, you can build using go, you can build from source. You can use a Docker container to run Cubelinter as well. And there's a bunch of other actions in here. So let's say you wanted to implement Cubelinter into your GitHub. And as a GitHub action, there's options for that as well. And a couple of demos that just examples that I'll showcase as well moving forward. Now, one of the big things that I want to show you before I go on to the C of the command line and showcase Cubelinter are the default checks. So Cubelinter has 19 default checks. And not all of them are enabled. There's 13 enabled by default. And Vishwan, correct me if I'm wrong, but really the reason for having 13 was we didn't want to overwhelm users. Not all these checks are necessary. And so we wanted people to be able to go use Cubelinter and see the core checks without being overwhelmed by all the errors. So, you know, focus on those core, you know, six to eight checks that tend to pop up. And then as you start to get more comfortable, you enable all the checks, and then you'll get things like, you know, unset CPU requirements, unset memory requirements, which aren't necessary, but should be enforced. Yeah, that's that was the there's some that, you know, we want people that we think we're opinionated and we're like everybody should follow them. And there's some that we know not everyone is going to be able to follow them. But these are like good practices. So we want the checks, but we didn't want we wanted them to be more up them. Yeah, just to add to what you were saying. Yeah, and the description and remediation in the checks also allow for you to run and run all the checks, you don't necessarily need to have an action on them, right? But it will showcase and help you move through it now. This will come up a little bit later too, as we get into customizing checks. But Cubelinter is built off of these templates that you can actually change and alter depending on your needs. So there is a required annotation check that basically just says, you know, you should have an email of some sort for somebody to contact you for this Kubernetes object, you know, we don't necessarily need that, but you can also alter it. So like, let's say you're a team, and you require an annotation of, you know, testing, or maybe you have if somebody's running an object, they need to put their name in as an annotation. You can set all that and configure the policies as you need them to. So there's some flexibility in what you can configure. Now, all I really have to show you the documentation because the real stuff is in the command line. So for this walkthrough, I've actually created a little demo repo, which has all the examples that I'm going to go through today, a few and we'll we'll post the the link up at the end as well if if you get lost. But yeah, so M foster rock slash Cubelinter walkthrough has all the manifest that I'm going to be going through today. And I'm going to be doing this in Visual Studio code. So in that repo, we have a list of manifests here. Now I've split it up in a weird way. People might be like, Why is there so many folders here? I did it to kind of showcase how Cubelinter works and works effectively. You could realize they could put all these demo files in a single file and just lint through them in one go. But we wouldn't really want to do that's not really doesn't really make sense and can't scale, right? So what I find really useful is Cubelinter lint lint everything underneath a folder, right? So we break it up, we apply the policies to each folder, respectively. Now just wanted to solve that question because it comes up kind of often. Cubelinter simple install I use brew to install it because I'm using a Mac right now. But it's very similar to Cubsetl, Cubelinter. It's going to have the available commands for me. There's the checks help lint templates and version command help is always there, you know, dash dash help dash h will always help you and give you a description as to what the commands are. Version is there to show you the version downloaded, obviously, and the checks and does you all of those default checks that I had showed you previously, right? So we have, like I mentioned before, the unset CPU requirements gives you description and remediation and a link as well if you want to find more documentation for more details. The other aspect here is the templates command. So just like the checks we have the templates command here. Now the differences is the checks are built off the templates, but the templates allow you to change some of the keys and values in the parameters of the check, right? Which I'll showcase more when we get to the config file. But just to kind of show the differentiation between what a check is and what a template is, the templates are there to help you build custom checks off of and the checks are the default ones that are built into kubelinter. Moving on to the good stuff. So we have kubelinter lint and we can technically lint and it will take all the YAML files underneath that folder. So because I have all the YAML files split up into all these different folders, you can see I have 54 lint errors. Now let's wait too much really to go through and check. So we probably want to be a little more specific about what we're linting. I have a couple compliance YAMLs in here and I have one that is non-compliant and I found eight lint errors. So what this YAML looks like is right here. So it's a non-compliant app. We have, for example, an AWS secret key that is in the YAML file should not be there. We have a server's account that doesn't match up in terms of labels. So there's and there's also what we're forgetting is there's a lot of information missing here. So we don't have un-set privilege access. We don't have any drop capabilities, any Linux capabilities that are set up. We don't have a UID or GID that are set here. So there's a bunch of other information that's missing, which if we go into the console, we will be able to see. So we, like I said, I ran the checks and these are the default 13 checks, right? And we found eight lint errors. This is not the default 19 or the total 19. So you can see we have an environment in our secret, you know, don't use raw secrets in an environment variable. Instead, either mount the secrets as a file or use a secret key ref. And then we showcase, you know, if you want more documentation, here's how you would solve this problem, right? Same thing. There's no read-only root file system. The remediation is, you know, set read-only root file system to true in your container security context and go from there, right? This it's pretty straightforward for that example. Now what I can also do is if I use the help flag, I can see the list of flags that are available to me using kubelinter lint, right? So I have a bunch of flags here. I have add all built in, I have config, I have do not add, do not auto add defaults, and I have the include. Now add all built in does exactly what it says it's going to do, right? It's going to add all those 19 checks. So originally we had 13, we want 19, we're going to do an add all built in. So you can do this directly from the command line. We can do a add all built in. And now we have 12 errors, right? So we've run six more checks against it. We've realized that it violates four of those default checks and these are going to be, yeah, so there's no memory request or limit set. There's no CPU request or limit set. Run is non-root, it's not set, for example. And, you know, one of the ways we can go through this is we could just tick them off one by one in here until we, you know, fix the issue. So something as simple as, hey, I got rid of this. Environment variable, run add all built in and I have 11 lint errors, right? One way to go about it. The other way, so you can do a do not auto add built in, you're going to get a warning, no checks enabled. Now one of the reasons why, and I've had this brought up a couple of times, is why did we even add that? Why did we add a do not auto add defaults? Like you're running the command, what's the point? Well, the reason is, is because you think we have 19 checks, we can either add all of them and disable them as we go down or we can, you know, disable all of them and include them as we go up, right? So if we say, maybe we really only care about running as non-root, maybe, you know, we just want to make sure that our containers are not running as root and if they are, we're flagging them for an exception, right? What we can do is, we can do a do not auto add defaults and then we can do an include string, include the run as non-root command, right? And so now I found one lint there. So really useful for flexibility. Now the next thing that's coming up is, why would I be doing this on my command line?  It doesn't really make sense. It's not fast. It's not scalable, right? That's where config files come in. So instead of running something like this, I can use a config file in order to run the checks. I'll show you, for example, what that looks like. Now you saw the flag for the at all built in set to true. I can create a config file to basically run the same sort of flag and then I can also list all of my include and exclude arguments as well. For this config file, normally you'd have an exclude here. I've just commented it out. I have all these checks. They're all set to true. So I should get that 12 lint error message that I had before. Let's just make sure that I'm in the right space though. Biggs have eight, which should be 12 unless I'm skipping something. Maybe I have something that skipped out. But you can do the exact same thing with I have a do not auto add default set to true as well. So just like the other one, there's a do not add or there's an add and there's a do not add and I can run the exact same check against it as well as my formatting off here. Yeah, I'm just trying to figure it out that it's probably something like that. Yeah, I think it's probably like a tab or something like that that's off. It's because it's not. Yeah, so just as an example, we'll just say that I did all the checks. I can exclude specific checks. So if I was going back to the adult build-in, I have an unset memory requirement check there and the run is non-root. What I can do is I can tell the check to exclude and maybe we want to get rid of the run as non-root check. I can do that and then again everything's declarative. We want to comment things out when we make changes. So we're going to, you know, exclude the specific run as non-root check and we have seven errors. So if we go through, we'll see that that run as non-root check is not there now, right? And one of the reasons for the config file and being set up that way is the declarative nature of the ML files in Kubernetes objects, right? We want to use that declarative nature so that we can pass on information to other teams. So for example, let's say if a user was using kubelinter and you found out that that team and that microservice that they were working on had some specific requirements in terms of checks. Well, we can set up a policy around just kind of that baseline enforcement of checks and we just create comments to say, hey, you know, this specific operator or container or pod or something like that requires root access on the host and we can basically make a comment in the ML file and in the config file as well so the next person coming in understands why that decision was made. One of the interesting ways is because it's a CLI, you can really just apply it, can just route all the different folders. So not only do I need to do it to the non-compliant ML, but you basically can string all the commands together. So what I found really useful is to create kind of these default config files so you can see I have a couple examples here like maybe I have specific checks that I want for the cart's database down here. Well, I create a config file and then I just point the CLI towards that config file, check that folder and I have, I do it as a process of a couple steps in the CI process, right, with like a GitHub action or a GitLab runner or something like that. You can't always use config files though and there's always like specific exceptions. So instead of just having everything in the config file, we also wanted to give you the ability to comment things out in the, excuse me, in the YAML file as well. Just to showcase this, we have this ignore check annotation that allows you to ignore specific checks and document while you're doing it. And I'm kind of beating up on the run as non-route example here. For the example of this annotation, the, I'm going to actually take it out of here first, disable that. So hopefully you guys didn't get lost in that back and forth. Yeah, so we're back to eight lint errors, right, because I commented out the run as non-route. Now if I save this file, what I should get, I should get seven lint errors because I'm commenting out I'm telling you when to ignore this check and I want to ignore the run as non-route check. You don't necessarily need to write a description, however it's highly recommended you do. You can leave this an empty string, but the whole purpose was to allow users to document why they were ignoring checks or why they were disabling or enabling checks, you know, directly in the YAML file, right, and it's just one way that we can say, hey, we are, you know, avoiding this security process. We're aware that, you know, this is let's say not necessarily the best practice for securing our container, but this is required, here's why, getting contact with this person if you have any other questions, right, just to give you another example, let's say we, a developer would probably put this in just to not have any limits, but we can get rid of that and it got rid of two lint errors. The reason is because you're getting rid of memory requirements, high, a limit and a request, so we got rid of two errors there, and you know you can continue down, do CPUs, so I find it really a good workflow for, you know, looking at applications to have a config file that allows all the defaults enabled, and then you just go through and you just basically pick off and document exactly why you're making these decisions and do they need it, is there something I forgot to mention, right, and, you know, just simple descriptions in order to help you out. Now, I've got a question real quick. Sure. Is there a no excuses mode where you can't use any of those annotations or strict code? Yes, so that was actually brought up, there is not a you can't disable this mode, the, one of the things I brought up to Vishwa was because it basically defaults as a non-zero exit code, right, when it trips, so as part of like a CI pipeline, you technically could annotate your way out of no checks, right, so your developer could push something, check the way out of it, and you wouldn't be able to see it, so one of the things that's in the pipeline is basically so that even if there's an annotation for disabling it, it still prompts basically an output of like this is the check that was disabled in this YAML file, right, so that even if somebody did annotate it and somebody else was reviewing the work, they would still, it still trip a, trip a wire, but actually, no, there is not a, yeah, basically you're saying like you, you can't disable any of the checks, don't believe Vishwa, is there an option for that? No, but yeah, totally agree that we should add it. Yeah, adding it to the roadmap, that's a great recommendation, on to, cool, I was going to say, you go in and go and open up an issue. I can open an issue, I'll open an issue. Do it. All right. Well, yeah, we'll have it before the end of this, this session. Okay. All right, so moving on, we, so we basically just looked at all of the default policies, right, up until this point. The custom checks allow you, and this is one of the things that Vishwa has worked with, to enable some flexibility in the different objects that you can apply it to. Right now, a lot of the objects are deployments, there are a couple that are services, and, you know, as the project moves forward, it'd be interesting to get feedback from the community as to which objects and checks, you know, that they would like to see. So for some of the custom checks, for example, I find really useful for required annotation as a check. If I showcase that demo, sorry, the template, we'll see basically the options, the parameters that we can change in these checks. So here's the required annotation check, and we can see there's a flag not carrying at least one annotation, so it has to match the provider pattern. So basically, we can set the parameter and the key to, you know, kubelinter slash demo, for example. So if I went to the, I went to this non-compliant app, if there was no check that was kubelinter slash demo here, it would show the flag.  And what I found really useful about this is like now admins can enforce best practice for annotation throughout their YAML files. So no longer can somebody push something without their email attached to it or, you know, not actually, you know, adding the correct labels. So if you have like different, let's say you're in GitHub and you have different repositories for different teams or something like that, you have different config files for each team, all enforcing, you know, the exact same, or the exact same different annotations for each team so that you can like keep basically that, let's say, neatness across teams and then into your cluster. The other thing too is some of the parameters allow you to change the object kind. So this is an example where I'm specifying labels, but I want to specify labels to the service object kind, so it'll check. Basically the services, if I did it for carts, for example, it would check the service to say, hey, is the right label here? No, it's not. We need to make sure that that label is there.  There you go, and it'll give you some sort of mediation. So please add environment label to service, dev test staging production, just as an example. Now what this looks like, and I have this as excluding basically everything, except for run as non-root, because that's what I'm picking on today. It's a tough Monday for run as non-root. I'm going to do the config eb carts, because that's the one we're looking at, and I'm going to do it against the, so you can see we have the checks. We have an at all built-in set to true, and we have this exclude, right? So we're excluding basically all the checks, except for run as non-root. And then we're implementing custom checks, which is a required label release deployment. We're calling, it's a specific name for this check, so we're calling the template is required label template, and then we're giving it a unique name. We're specifying the parameter, and the key that is changing, so there has to be an environment annotation there, and then please that environment label.  So you can see, or semicolon equals on, you can see there's no label matching right there. And this is, I think, an example of both a, they're looking at the service, and we're doing required label release service. It's like a duplicate here. But yeah, either way, you can see that there's both checks that are coming out. And if I wanted to get rid of that check, for example, don't do. Really, it allows you a lot of flexibility to play around and configure your policies as you want it to see, as you want them.  You know, they're not really going to work with security. So what we wanted to do is we wanted to create a tool that is in the developer's hands that can be applied in an automated way as part of their pipeline, and also gives you a lot of flexibility. So let's say admins want to enable best practice onto their development team. Well, you can implement this as part of your CI pipeline without actually triggering a build fail just to give educational feedback to them. And I'll show you kind of what that looks like. In this repo, I have a GitHub workflow. So I have a config file for a GitHub action. Now, like I said, if you trip, if Cubelins are limped, trips in error, you'll get a non-zero exit code, which would technically, excuse me, cause your build to fail. Now, you don't necessarily have to fail it if GitHub actions, for example, allows you to continue on error, right? So depending on what branch you're working with, maybe your devs are starting off and they're new to Kubernetes, we don't necessarily need to have, you know, 54 lint errors and build fails all the time. So what we do is we run it with all the policies enabled and maybe we say continue on error is true, right? Then you have a meeting on Monday and you say, okay, well, I'm going to open up tickets because there's 54 lint errors and I want you to fix these eight before Friday, right? Doesn't necessarily, again, need to fail the build. But next Monday, when it comes back, we're like, did we fix those main security issues? Yes. Okay. Well, maybe we can fix two more, maybe we can fix five more, right? So we're not actually hampering developers, but it's just making those little changes in a way that, you know, kind of makes like allows teams to communicate and collaborate. In this example, I have basically two jobs. I have a test job and I have a staging job and the staging job fails when you run kubelinter lint. And what that looks like, if I go into GitHub actions, so I can see that the test phase worked. And one of the reasons why it's useful to, especially when starting off, have that kubelinter not fail is because a lot of the times when you're building these pipelines, if you get a non-zero exit code and it fails, you actually don't get to continue the pipeline. So in this example, I have two commands here. So I have like a lint and another lint because I want to apply different config files, right? Now applying different config files, this means that if this first command fails, the pipeline just stops. It doesn't continue through. So I found really useful to create a pipeline where it basically, it gives me all of the output, right? So I'm going into GitHub actions. I can come in here and I can see all of the output from both commands with different config files. I can then look at them, you know, go and have a conversation about what do I think are maybe the top two that we need to fix, right? Run as non-root, probably the top one. That's if it's not needed. So we can just prioritize. We can say, hey, I don't really care that much about your service not being labeled because it's in deployment. We'll fix it, but you really need to change this from run as non-root. And then you can push those specific policies down. And all we can do to do that is, well, you can set it so that it passes on tests, but if they want to move it to the staging branch or if they want to move it up, it's going to fail. So, hey, by the way, here's your feedback. If you want to keep going, you know, we're going to fail the build. So at some point you need to, you know, bring the hammer down as an admin and say, hey, this is not what we're doing.   So you have five teams, eight teams, 20 teams, they'll need to also go and say, hey, like what do developers need? You know, we'll give you flexibility in terms of how you can figure this, but then we also expect a little bit of just following best practice and we'll give you feedback as to what errors you're tripping and what we think you should focus on. Right? That was the goal of CubeLinter. One of the main reasons why we did it in the CLI phase is because Dacrox has Rock CTL, which is like an image scanner and all and gives you a lot more functionality towards just images in terms of further developers. So we have kind of those paired CLIs and which thought it was really useful to if we're going to be Kubernetes focused, here's your image scanning and then here's the configuration of the images in the cluster thought it was a good whole lifecycle approach. And then obviously when you get into the Stacrox, the sensor collector and more of the the user interface then you get whole lifecycle Kubernetes security management. So again, it's that first stop developer checkpoint for figuring out where your security vulnerabilities lie with Kubernetes and hopefully it gives you enough flexibility to be able to adopt and grow from there. Now, I think that's Vishwa, did I miss anything of major importance? Any functionality? Nope. Thank you. Got everything. So thanks, Foster. I'll hand it off to you. You have the roadmap which it sounds like we need a we have a new issue coming in. So we should add that to the roadmap. Yes, I just saw that. Cool. Cool. So, hey everyone, again, I'm Vishwa and I'm one of the engineers working on Kublinter and thanks, Foster, for going over that demo. I'm going to be giving you a high level overview of the things on our like near to medium term roadmap. So, obviously one big component of what we're adding is more checks. And there's a few different things here. There's like one there's like more checks along the lines of what we've written. Another is a feature request we've heard from some people is to have some checks that map specifically to certain compliance checks and allow and not just add those checks but allow some way of tagging checks with metadata as to like these checks will help you. These checks are required for you to be in compliance with this standard and things like that. We want to consider additional resources that we don't yet consider in our checks like network policies pod security policies and things like that. And like checks based on those so a simple check could be like does your deployment have a network policy? And if it doesn't it should because otherwise it can talk to anything and more complex checks could be allowing people to to write like more fine grained rules on network policies like you know don't allow network policies that are overly broad or whatever they want. And so that's like something we're thinking of. Another one big one that we've heard is custom resources. Right now we support like all our checks basically work only on like native Kubernetes objects like deployment services demon sets and things like that. But you know with the latest versions of Kubernetes like custom resources are becoming a bigger and bigger thing and we're trying to figure out what's a good way to support them. And this also includes and it's not in addition to custom resources there's like other things like you know OpenShift for example has its own resources like security context constraints and deployment configs and that's another thing we would want to support as well. Another is better customizability. So as as you saw in the demo you currently allow you to specify checks through basically having these templates that we provide and allowing you to like parameterize those templates. But we are thinking of ways to allow more flexible specifications of checks for cases where that works because right now if you want to write a totally new kind of check you will need we will need to update go code and like release a new version of kublinter which is not ideal. So we're still figuring out how to design this but you know some ideas are the simplest on the spectrum is like something like using you know like JSON parts allowing people to specify JSON parts or something to say like this this field in the YAML should be equal to this whereas a more complex thing along the spectrum would be like allowing people to put in you know rego policies and use what they use in OPA with kublinter. Another big few things that we want to do are like usability improvements. There's a bunch of things around this that on our roadmap but some of the ones that they're thinking of automated rewriting in cases where it's possible like obviously it's not going to be possible everywhere because in many cases we can just tell you like something's missing and you need only you know what is to be added but in there are some cases where things on our own are similar to what many linders do and that's something we would want to support and then more convenience command line flags so you know people have asked us there's a few requests on this and we've added some like some of the command line flags you saw Michael use were added in response to use a feedback but people have asked us for things like you know I was to ignore certain parts easily and things like that so we there's like a bunch of those usability related things that we need to do and then finally and I did see there was a question about this we really want to do native integrations so that's two big buckets like one is with IDEs so you know VS code is I think the one we've got the most request for we would also probably do IntelliJ and you know the JetBrains family as well as Lens which is Mirantis is open source Kubernetes IDE and we think that's a good fit for something for us to integrate with as well and have been in conversations with them because they very recently released like an API that makes it easy for you to integrate with it and then CI systems you know we do have a GitHub action that we publish but we do want to make it easier to just drop it in to like CircleCI or Jenkins and things like that it's right now it's not terribly hard to use because it's just a binary and you can download it and then or run it but we in my experience like the easier you make the more pluggable you make these things the more it just removes a lot of friction and makes people much more likely to use them so Yeah, Vishwa you and I Yeah, worries you and I have talked about creating a repository with a bunch of basically best practices right like I I have six config files in that repository I think it'd be very useful to to kind of showcase like hey here's some you know default config setups that you can use along with different actions whether it be like GitLab Jenkins GitHub as well so Yeah, yeah, absolutely we should definitely add that to the roadmap Yeah, yeah, absolutely Thanks Michael that totally agree um problem Yeah, so that's that's a little that's a high level overview of the roadmap and our roadmap is managed entirely on our GitHub so we use GitHub projects which allows us to basically use GitHub issues as tickets and then put them put them in this context of the roadmap yeah so I guess Michael is showing you Yeah, all right you can see and we you know where as people file issues we typically add them to the roadmap or deduplicate them and like update another ticket and that's so that's what they're using to to manage look at Paul he Yeah, thanks Paul that's awesome he snuck right in there yeah that was that was a very quick issue open like that got that number 128 too BAM yeah nice round number very pleasing yeah all right anything anything else Vishwa that you wanted to chat about just yeah I think the last slide was just about like helpful links but you know we already went over those but maybe just maybe maybe just forward one more yeah so definitely will yeah so this is the link to our GitHub which you which I think some people have posted in the chat already to link to Paul's issue we also have a docs website that Michael showed you we you can also communicate with us by you know filing issues for sure and sending PRs but you can also join Kublinter on Slack and then and for the link to join the Slack is on the GitHub so if you just go to the GitHub page and search Slack we have an invite link that you can use and we'll take you right into our our Slack workspace and all of us are on it and you know we try to be pretty responsive so if you have if you just want to like talk to us about anything like that's probably the lowest friction way for you to reach us and yeah try the Kublinter walkthrough that Michael has put together so you know we like in closing we are not this is probably the first not the very first but this is among the first open source projects that you know we've done at Stack Rocks we and they're like learning a lot about this as we go through with this specific project and we we've been happy with the response we've received so far and we're looking forward to engaging more with users and trying to figure out like how we can make this a better project that's like more useful to our community so definitely looking forward to hearing from you I think one one thing was specifically interested in as you know how are how are people using it I think we've we found that people do file issues when they run into bugs so when they have feature requests but it can sometimes be hard to figure out like is this are these just like the tip of the iceberg of people using it and like there are many people who use it but don't actually get around to filing issues and so any I guess what I'm trying to say is like any input on how you're using it is welcome even if you don't have like a concrete suggestion or request just because that's interesting to for us to hear about but that I think that's the end of our our presentation so thank you for listening and I guess we'll take questions now awesome thanks one thing do you have any open community meetings set up yet or anything like that or are you still just mostly doing it through the the mailing list and issues connecting with your end users and folks is there but yeah so we have of the just getting started on doing that so we actually have an AMA that's coming up believe on this 16th is that right Michael I think so don't call me on that I'll look it up right now as you're as you're going on yeah that's that's going to be a first 40 into this so I can I can just pull up the link and post it on the chat it's just after this but yeah that's going to be our first 40 but until now it's just been slack and guitar okay and so for the most part it's stack rocks engineers working on this yeah we've received a few contributions from users but we are you know and we are most of the contributions have been internal so far and you know the PR like approvals and merging is currently just stack rocks engineers right now well it seems and I was talking with Michael a little bit before everybody got talking today and we hit the record button about how this seems like a nice complimentary thing to what you have for products as well the products are more based on examining images so you know I would think that this fulfills you know a need for this this piece of the work and I was just wondering how this relates maybe to operators because we talk a lot about using operators versus Helm charts and YAML files there is is there any work going on Vishwa around the operator framework or examining that not not specifically like we haven't we haven't done anything specific to operators here of we again like since we're analyzing the YAML files to some degree you know if you if you are able to render the operator into a YAML file into like it's final YAML files like the tool will work but yeah the things that we are we focused on at least at the beginning have been better support for Helm charts so with Helm charts we we don't require users to render them like we kind of use the Helm libraries under the hood and if we detect that it's a Helm chart we just automatically like render the YAML the templates and I don't know checks on them and another thing we've heard requests for is customize as well with some people use to manage their configs but yeah that's a good suggestion and something for us to look into yeah it would be interesting to see how that works there have been a couple of things that have come up in the chat Noel has a list of issues that he's seen other customers from his perspective and I love the acronym over my dead body I don't know Noel if you want to share that list with them and walk through that a little bit have to unmute you go there if not and you probably got that other question covered with a VS code in your road map talk and the other question I think was around comparing what you're doing with CubeLinter with what goes on in OPPA the open policy agent can you talk a little bit about that? yeah so that's that's a really good question and it's something you know we we've thought about as well I think we concluded that like we ended up building this because we found that for us internally so this actually came out of like internal pain points that we had that's that was like the initial you know like spark of us building this and then that later you know we decided that this could be something we open source but with OPPA and CONF test like you can achieve many of the same results but we we found that this what we're building here is more focused on Kubernetes and that's that allows us to do that allows us to do some things which are more Kubernetes natural like for example the way we ignore checks by annotations for example like we've been able to build that into the tool because we have this assumption that we are working on Kubernetes YAML files and the another one is how we are building native support for hand charts and we're just like if you see a hand chart we just render it like our tool is more Kubernetes aware so I think that Kubernetes awareness is one big thing that we felt that we could do in a custom tool and the other thing is we also are kind of opinionated about certain defaults checks that you know we wanted to enforce internally and we figured that it would be nice to have those like built into the tool so that if someone downloads it they don't need to with CONF test and OPPA there are like rule sets available but we wanted to make it something where like we also kind of guide users to what's saying like these are the tools that we think should be enabled by default and they're actually built right into the binary so those are the couple of reasons we decided to build something something different and we do I do still think that the OPPA language is very powerful much more powerful than you know the kind of language we've built but that comes complexity but we're also thinking of a ways to make our ways to like use the OPPA language in our policy configuration so like I mentioned the roadmap we're thinking of ways to make more flexible policies and one of the ways we could do that might be like allow people to specify rego files and so essentially for people who want that added flexibility they get that right and coob linter but they also get the convenience of you know all our other coo specific features so hope that answers the question answered mine I hope it did for everybody in the chat as well and Noelle Noel I think you've got your speaker fixed your microphone could you hear me now I can hear you now there you go yeah perfect so I put those lists of things together over the last while because it's what we're seeing with very large customers of OpenShift is it's not necessarily the developers that are struggling with these things it's it's large operations teams or even small operations teams that have a large number of third-party either vendor applications or in-house development teams where they spend the majority of their time getting stuff onto the cluster and then spend the rest of their time trying to figure out what's gone wrong so things like missing readiness probes and all that type of stuff and especially in the FSI space we've seen things around you know when you you're working in service mesh is MTLS enabled on service mesh or not so it's kind of more granular things but it was around basically how do we enable those customers to actually kind of set up kind of standards that have to be enforced do you know what I mean for to get the application out there so the kind of if you if you think of like things like SonorQ for code this would be the equivalent for for Kubernetes or OpenShift resources you know that's the kind of stuff we've seen so far yeah this is a very thorough list too of policies yeah and a lot of these checks are actually implemented in kubelinter and the other thing too is obviously stackrocks is a more complete you know security tool that basically looks at all these checks and allows you to enforce either as part of the pipeline or in the cluster right yeah so it's I don't know if if that's like a subtle me just saying hey like the stackrocks basically does a lot of the stuff yeah it does yeah yeah listen here so yeah no it's it it's good and it's actually great to hear that the developers aren't the ones having an issue I've I've always found when I've been working with customers especially like an consulting rule it's it's just the issue of like fine-tuning policy across different teams right it's it's the admin aspect of kubernetes because the multi-tenant when you get multi-tenant setups it just becomes a little more complicated so a lot of our tools are focused around users but users at scale right because security only really works when people buy in and so we want to make sure that the tools are set up so that we're not just kicking people out of the cluster we're you know it's more of a security observability tool with the ability to enforce policies right that's that's the goal but yeah this is really cool repo thanks for sharing this Norris yeah second that Noel it's really useful and we're definitely going to be looking at that to steal ideas for kubernetes so thanks for sharing I'm going to say giving us issues and and giving us ideas what is this Noel you want to come join the team keep it it sounds like a game plan here this is great it also sounds you talk Mike a little bit about having some best practices config files as well so setting up sort of recipes and cookbooks for people to to use as best practices in their own organizations and I think maybe some of what Noel is listing here are our best practices things were for different platforms that were were deploying to so it's actually some really cool work to go through and collaborate with you guys on so yeah this is awesome yeah we're almost to the end of the hour I'm not seeing any more questions in here I'll I'll ask the one out there Hugh Blinter is there any plans for sandboxing it into CNCF where you know what are the the next steps for you guys as a project yeah we we actually don't have a great answer to our long-term plans just because we have just been focused on the short and medium term so far I think we've kind of been focused on just the project is only three-ish months old at this point since we released it and so we've just been kind of focused on understanding like how are people using it and trying to make improvements to it and I think you know when we released it we didn't know what to expect whether like nobody would care or whether like people would use it and we've been happy it's exceeded our expectations for like people have been interested and have been using it and I think you know now is a good time to think about things like that again this is something we don't have a ton of experience with at StarCross because this is our biggest open source project and so I think it's just something we need to figure out but yeah to answer your question we haven't given that a lot of thought so far to be honest well it looks like from the interest in it today and the work that you've done you're on the right path so I think you'll think we're gonna follow you guys actively and see and see how this goes and have you back again with the next release of it so this is awesome so um thanks very much for coming today it we totally appreciate the the overview and the deep dive into it and look forward to working with you guys more on this so take care everybody and then I will post this video and the slides up shortly to the YouTube channel awesome on OpenShift so yeah thanks and along with Noel's list of suggestions there so awesome thank you so much for having us it was yeah thanks so much for having us Dianne it was great and thanks for listening everybody and for your engagement to your questions


So, astronomy has guided humans since the start. Considering that Aboriginal and Torres Strait Islander people have the oldest continuous culture that we know of, there's a lot of atmosphere cool and physical accuracy that's embedded within our stories and our culture. Indigenous peoples and communities and knowledge systems can really teach us how to connect with our environment, but I think it also opens up Western science itself. It adds a huge amount of depth and practicality. I studied a lot of different Indigenous stories related to a phenomenon called a moon halo. A moon halo is where a light ring forms around a full moon and I was able to use my knowledge in physics to be able to show that those stories accurately reflect what is happening in the atmosphere and can successfully be used to predict stormy weather. Really the skills that I learnt from the University of Newcastle have allowed me to be able to get this far. They showed me that anyone can really do what they want. It doesn't matter what your background is. I hope that I can show people how important our role is here under the beautiful sky we have and show everyone that this is something really to treasure. I'm Carly Noon and I'm a proud Camilla Ray woman and a University of Newcastle alumna.


The Chinese Coast Guard released videos on October 22 showing its vessel blocking a Philippine boat supplying forces in disputed waters of the South China Sea.China's Coast Guard said in a statement the Philippine vessel had ignored repeated warnings, crossed the bow of the Chinese ship and deliberately provoked trouble, causing the collision. Manila responded by condemning in the strongest degree the dangerous blocking maneuvers of the Chinese vessel Beijing claims sovereignty over almost. The entire South China Sea, including parts of the exclusive economic zones of the Philippines, Vietnam, Malaysia, Brunei and Indonesia. The Permanent Court of Arbitration in 2016 said China's claims had no legal basis.


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 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.  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.  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.  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.  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 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