Hi everybody. I'm Eric Arnold. I'm a studio architect of programming, and today I'd like to talk about empowering content creators and a little bit of the design philosophy behind our engine, and how we got to where we are today. So, historically at Volition, from one project to the next, we'd take the code base, we'd roll it forward, we'd add stuff to it for the new game, just continuing on that way. So there were things from the free space and descent days that got carried forward up through Saints Row. That resulted in a very programmer centric kind of clunky work flow in some of our pipelines for the content guys. Meant that programmers had to be involved to do simple prototyping in the game, it wasn't something that design could do easily on their own. It was very cumbersome. We had work flows that would require the level editors to create things in Macs and try to export the entire city at once, which was not ideal to say the least. So post Saints Row IV, going into PlayStation 4 and Xbox One platforms we decided to reevaluate what we're doing and how we want to go forward for the next round. We evaluated the existing engines like Unreal and CryENGINE and Unity as well, to see what people were doing and why they're doing it that way. See if we could gain anything from them. We really wanted to focus on iteration speed and removing bottlenecks so that the content group could work fairly independent of programming. Allow them to do their jobs quickly and find out what is fun in the game. One of the big things that we created for this is a visual scripting system similar to Kismet and Unreal. It lets the content guys get in and test their ideas out in the game instead of just writing docs and handing it off to programming. It has turned out to be a big benefit. We've had even audio guys that go in and create very complex memory systems so you can interact with different objects and a different order and it will react to based on what you've done. It's really neat to see something that complex done without any programming involved in it at all. The other big tenet we've gone with is we want everything data driven as much as possible. So instead of hard coding limits and sizes of everything, we let the game just decide on the fly what it wants to use memory for and how it wants to load things. It makes it a lot easier to expand the game later through downloadable content, because the game just sucks up whatever data is available when it starts and it goes from there. Another one we want to do is being able to edit your data really quickly once it is in game. So we have a system we call Live Update where if you're editing an object in the tools framework the changes will show up in the game in real time. It allows a lot tighter iteration loop for content guys to dial in exactly what they want for damage numbers or speeds or things like that. We also did a lot of upgrades on the programming side with the new engine. We have a reflection system where you can tag up data structures and they will automatically show up as editable objects for like weapon damage values and range values, that kind of thing. You don't have to write custom table code to populate the data, and then code on the game site to load it up and decide what to do with it. Its just all handled under the hood. It makes it a lot easier to get all the data that we need into the game in a consistent way. We are very much package aware. What a package is if you haven't heard of it is on the new consoles, it's basically discrete chunks of data that you have to be able to download and once you have it you can play that chunk of content without necessarily having all the other content downloaded. So that means that you can start playing the game very early. It also means that if we add downloadable content later, it's effectively just a new package and you download it and the game picks it up and starts playing with it. It doesn't treat it any different than the data that's shipped on the disc at the beginning of the game. We have standardized tools such as all the visual scripting system, our material and shader editor, even our animation editor. They all use common framework for creating nodes, wiring up graphs. Any kind of similar functionality we want to use the same framework so that any improvements we have. Will get applied to all of them, but also so that the content people feel comfortable moving from one to the other because the user experience for them is consistent. And we also finally have a true engine layer, whereas before it was just a bunch of code that happened and turned into a game. And some of it would get shared between games, but it would always get modified. Now we have a very hard split between what is considered engine that will be common between all games and then the game level code. And to the point where we're expecting to be able to develop multiple games on the same core engine code, literally the same code at the same time which would never have been possible before. So big takeaways that we're working towards is that you want to do anything you can to empower your content creators. They're the ones that are going to make what is fun in your game, so the easier it is for them to get things in the game and then test it, the better, the more fun your game is going to be. And then code side, the more you can reuse systems the better, because you're not continually rewriting them. Any fixes that you implement get applied across the board. It makes it a lot more consistent and stable. Thanks for your time. Hi everybody, I'm Eric Arnold, I'm a Studio Architect of Programming, at Volition. And talk a little bit about how I got to where I am today. So, I started programming when I was in grade school at a Saturday morning class at the local community college. It was basically write a for loop that, for 1 to 10, print out i. And from that point on I was hooked. I went out and bought my own books, I got any programs on computer, I used a very old 2D standalone engine called click and play to make a bunch of my own games. It was basically anything I could do to learn to makes games, to make stupid utility projects, to catalog all my CDs that I had, whatever it was I wanted at the time just I just wanted to program and I went out and I did it any time I could. Then move on to college, went into computer science. I helped start the Spartasoft game group. Then as a group we helped get the game program up and running. So again, just very, stay active, stay involved try and get out and do as much as you can outside of classwork. For one it helps you to learn but also that's the kind of stuff that we look for on an application to see what are you doing beyond the minimum requirements of I got me degree. It just helps show that you have a strong passion, that this is what you love, you want to do it, you're not going to let anything stop you, you're going to go out and do it on your own even if nobody gives you a job doing it. The Spartasoft group, one of the things that helps do both while I was there, and then since I've been out, is to network with people in industry, with past alumni from the programs. So I keep in touch with all my professors, I try to get graduates that are coming through that they say are good to check out Volition. We have six or seven guys from Michigan State here now. It's just a really great way to get some advice, get some critique, some feedback on what you're doing. It really helps to get personal recommendation from somebody at a company when you apply there. It really makes you standout in the application pile. So got through college, then after my junior year I had an internship with Volition that I got because I just walked in the door and gave them a CD and a resume that had all the different projects I'd been working on on my own and said hey, I'd like to come work here for the summer. It wasn't an advertised position, it wasn't anything that you know I'd heard about through somebody, I just decided I wanted to do this and so I was going to make it happen. So they gave me a position through the summer. I was basically just an entry level programmer working on the red faction PC at the time. At the end of the summer they offered me a full time position. I told them thank you every much, but I'll be back in the spring if that's alright, I'd like to finish my degree. But, internships are a great way for you to gain experience, for them to see what your skills are in a very low risk way because, its a lot more difficult to hire and fire somebody then it is to have a temporary intern for the summer. And it's just a good way to see if this company is a good fit for you. So I'd highly recommend if there's a place you want to work, definitely try to get an internships there. Typically in the later half of your college career because by then, you'll have enough skills and foundation to do your job instead of just somebody else and have them teach you to do it. So you can be productive for them and it's more helpful that way. So when you go to apply for an internship or full time job, I definitely recommend submitting a demo reel. It should be your best work, people that are reviewing the applications don't have time to sift through 100 of your homework assignments to see the one project that really shines. It should also have links to videos as well as runnable executables if possible. Typically, again people don't have a lot of time, so they'd rather watch a two minute highlight clip on YouTube instead of trying to install and download and get drivers configured correctly to get your game running. So if you can at least show them, here's what it is. Now if they're really interested they will try and go and install it and play it. But if they're having trouble with it and there's no video, they'll probably just move on. You should also limit it down to just a handful of your best work that's representative of what you can do so that they get a good sense very quickly of your skill set. One thing I would recommend is don't hyper specialize too early. People coming out of college, we tend to think of as generalists. Just are you, in my case, a good programmer is what I'm looking for. I don't care necessarily that you have a specific interest in rendering, because we may not have a rendering position. So if that's all that you want, you're already limiting your opportunities to get into industry, but once you get here it's great that you want to be a rendering programmer. Once we have a slot open in rendering, we'll look internally before we look externally. So if there is people that want to get into a certain area we'll do what we can to shift people around and make that happen. So it's basically, don't limit your search based on what you think you ultimately want to do because you may be wrong, you may find an area that you like much more. But you also don't want to limit your chances just to get your foot in the door and then you can move on from there. The other big thing when you apply is, please personalize your application, don't just send out a form letter, or even worse, no cover letter at all. Those I basically just pass on immediately. If you can't spend the time to research the company a little bit and show to me that you know who we are, what we're doing, and explain to me why you would be valuable here then it's not worth my time to try to figure that out. It's on you to present yourself in the best way possible. Once you are past the first stage of the interview process, remember that it's a two-way interview. That it's also you figuring out if you want to work there, as much as if we want you to work with us. A lot of people just sit there quietly and don't ask questions of us. They just wait for us to tell them things. And that just shows me that they're not very passionate or they're not very good at communication or I don't know what. I can't tell because they're not communicating. So have a list of questions ahead of time. You want to get to know the company, the people at the company to see if it's a place you really want to work. Hopefully this was helpful. Thanks for your time.
