 So, game development in Ruby is my talk. My name is Andrew Nordman, but unless you either birthed me, married me, or I owe you substantial amounts of money, you probably know me as Cat or Cadwellian. I talk on Twitter about code, beer, and my kid at Cadwellian, and I ship a lot of code at Cadwellian, or I try and release just about everything that we make at Agora Games, under the Agora Games repository. Speaking of Agora Games, my day job, I work at Agora Games, which is a game services platform for game development studios. The big thing that we do is we create middleware for major game development studios and independent game studios alike to create things that they don't generally have time for or want to offload or cause multi-title things. For example, leaderboards, matchmaking, community sites, statistical analysis, things of that nature. We've worked on a lot of really cool projects. Some of the more notable ones included Saints Row III, Mortal Kombat, Guitar Hero, all sorts of cool stuff. Additionally, Agora Games is part of Major League Gaming, which is an eSports company. We do a lot of really cool online and live event games. In particular, if you're interested in StarCraft II, Halo, Call of Duty, Black Ops, or Tekken or Mortal Kombat, right now we're actually going through one of our six live events of the year at MLG Dallas. If you're bored tonight, feel free to go to majorgaming.com and check it out. However, my company didn't pay me to come to this event, so that's the last that you're going to hear about my day job. Instead, I want to talk about how I accidentally left text on my slide. No, I actually want to talk about a little bit of history of why I wanted to do this talk. I have a rather complicated relationship with the Unreal Engine series. Yes, I started out working with it back in the Unreal Tournament days, the original, not 2003-2004, at the time where they released the Unreal Editor, and it was a great opportunity for someone who wanted to start working in game development, but didn't want to have to deal with the lower level complexities of games, dealing with renderers, game loops, all that craziness. It was so perfect for someone in high school who wants to do something other than sleep in class. It was a great tool set, but the problem that I had at that time was that I was running on a terrible 2000 computer, and it had some rather major stability issues. Generally, I would end up having to load up the engine, go take a shower, come back, and the computer had finally decided to load up the environment so that I could start working, only for me to open up the level that I was working on and go do something else for another five minutes. As a result, I got to make some really interesting stuff with the level-leveled designer and start working with scripting, but ultimately I just had to walk away from it because of the fact that when you can only do so much with the stability of an environment, eventually you're going to find other things. So I did find other game development related stuff to do. I stayed away from the Unreal series for a while until Epic Games came out with the Unreal Tournament 2003-2004 and completely revamped the Unreal Editor engine to 2.0, but most importantly created the Make Something Unreal Contest. I don't know if any of you are familiar with that, but what it was is Epic Games decided that they really wanted to bring up more modding capabilities and bring in more excitement for their new engine, so they created a contest where they would give away thousands of dollars worth of prizes and moneys to poor saps that want to deal with modding and bring in more promotions. And being someone that was eating ramen noodles very frequently, I decided, hey, I should come back to this engine. So I jumped back in, I had also gotten through and replaced my terrible 2000 with something much faster so that I could actually load the thing up and started diving in, and that is when I realized that the editor itself, while having stability issues, wasn't necessarily my problem. The problem is that the Unreal Engine is split up into two components. The first component is Unreal 8, and what it's focused on is on level design, the event trigger system, particle effect management, effectively all of the things, what I like to call the non-technical technical aspects of game development, anything or you don't necessarily need to do a whole lot of programming to and you can view through a GUI editor. In particular, it was very useful from a mod perspective because you could, within one click, load in an instance of whatever you were working on. And that was the great stuff. That was what I loved working with. It was very straightforward and quite nice. And then there was the other side of it, Unreal Script. Unreal Script was the core component that glued everything together so that you wouldn't have to go down to the C++ level. And it was designed by Epic Games and inspired by Java It's a rather verbose scripting language which has some rather awkward OO principles. I'm going to bring up a sample here. And there were a lot of language components that they just kind of threw out of the way, like constructors and destructors are gone. Who cares about that sort of thing? And I generally found that my main problem was in dealing with this scripting language, but I didn't really find much better than it, so I ended up working with it anyway. So here's an example of some basic Unreal Script code. This by no means exemplifies all the problems that I have with how Unreal Script is structured, but if you look on the left, the first second slide actually deals with describing your mod and you end up packaging everything out into several sub-components and you see the extension in order to handle bringing down your other stuff, but its definition of default properties is how you would essentially define all of everything that's going to be structured without having to create an initializer because constructors don't exist. And you'll notice that there's no semicolons, no commas, no method of... I'm not even really sure what it is that they're trying to accomplish by not having any sort... It doesn't make sense. The default properties doesn't really make a whole lot of sense other than I'm going to list out a lot of variables. Moving on to the right, there's an example of a pawn object which within the Unreal system is essentially a person or an entity that's moving around within a given level. In this instance, I'm creating my own version of a pawn which I'm going to be using for a side-scroller, which in order to do a side-scroller, you don't want people to be going around in a complete XYZ system. So we've extended it and you'll notice a really weird thing about the definition of the class. For example, one file is one class and there's no form of wrapping because you'll notice on the first line at the end is a semicolon and nothing braces it all together, which already was a little weird, but extends UDNPawn and depends on UDNPawn. That's a little confusing. What is actually happening here is that you're pulling in the UDNPawn for extension from the inheritance perspective. However, if you want to override another method with your own definition while still having access to the parent method, you have to depend on it, otherwise super doesn't exist. Yeah, interesting. So you'll notice the simulated function tick is the method that I'm trying to override here and off the bat, super looks weird because super is no longer a definition of the method, the parent method that you're trying to call, but the parent class. So now you have to refer to the individual method even though you're in that particular method. And again, you see your default properties of silliness. So I'm not really a fan of this. I didn't really like this. And at the same time, I was also working in school for building my own game engines and using the torque engine provided by Garage Games. So again, I walked away from the Unreal Engine going, you're good, but I got to deal with something else. And then later this year, for work related things, I decided to jump back into the latest version of the Unreal Development Kit. And what was interesting about the Unreal Development Kit is that it ended up extracting a little bit away from the modding community and focusing more on building games using the Unreal Engine. And more importantly, being able to use them outside of just PC games. You can use UDK in order to create mobile games as well. And since that's relevant to my work interests, I decided, hey, I like pain. Let's see if anything has really changed. And they've done some great things with the Unreal Engine, major improvements to the Unreal Engine side, but Unreal Script mostly changed. And so if I was going to end up working on this with a regularity, I felt like I needed to create something that decreased this pain. I had worked in other languages. I'd worked on the lower end. I've worked a lot with Ruby. Maybe I could find some sort of way to correct this pain. So I got the idea after working with a lot of CoffeeScript, maybe I could write a cross compiler so that I could write Ruby code, run it, and then convert it into Unreal Script, which UDK would pull in. So I thought, yeah, this is a good idea. I talked to some people who were like, yeah, this would be a great opportunity. So I created Unreal RB. Written in Ruby, Ruby code in, Unreal Script out, felt great, started work on it, and you'll notice that if you try and Google Unreal RB, you won't find it anywhere. And the reason for that is this was a terrible idea. The biggest problem that you have with trying to build this construct that I was running into, aside from poor performance, was that I was trying to build something that was not, that was completely changing how Unreal Script worked with the engine. You couldn't get down to the lower levels of C++ with UDK because that required a game engine license rather than just access to UDK. And while I'm no longer eating ramen noodles five days a week, my discretionary income of throwing around $3,000 or $4,000 in order to get access to the engine not really high on my priority list. So what ended up happening was it really just evolved into a really primitive DSL built on top of Unreal Script. It functioned, but it didn't, all it really did was just rearrange some code, shuffle it around, and didn't really function the way that I was hoping for. So saddened by it, I threw it away, and I just resigned myself to writing Unreal Script. But the reason why I talk about all of this is it got me to thinking that Ruby is a really great language in the game, for things that are being used in the game industry. And there has to be some way to be able to compose the great components of Ruby into game engines and games themselves. So I started looking into how we could solve this problem. So let's shuffle all of these things together. So there's really three paths in game development that I want to talk about today. The first is using game libraries as a means of building games in Ruby. That's the intro that most people, if you're interested in or googling game development in Ruby or Ruby games, you'll start down that path. The next is trying to use existing engines that already are out there in a scripting fashion to inject Ruby in. And the third is just building an entire game engine using Ruby or with components of Ruby built in. So we're going to first talk about game libraries. Game libraries are designed to abstract low-level game internals. The main components there, therefore, is to not have to worry about input collection, rendering, and the iteration timing. The main goal of it is that you don't really want to know about how you do the low internals of starting an event loop, pulling in the inputs, triggering all that stuff. You just want to start making games. This focuses on ignoring engines entirely and you get to focus on building a game. You got a game idea? Let's start jumping in. So these are your minimum requirements. Those three pieces there have a main game loop handler, have a graphics renderer, and an input handler. And most Ruby game libraries are built on one of two, either Ruby game or Go-Soup. And there are a lot of extensions and derivatives. The most prominent one, and the reason why a lot of people will Google Ruby games or Ruby game development and then promptly stop looking, is Ruby game. Ruby game is the easiest one to pick up because it's Ruby and game in the name. However, it's not actively maintained. The last time that commits went to it was over two years ago. So people see that there's nothing really going on with it and they go, wow, that's not great. But it did do some rather interesting stuff because it did a purely Ruby implementation. It uses the SDL library for being able to handle the lower level components and it focuses on everything in Ruby all the time. Conversely, and the one that is more actively maintained than I would recommend if you're interested in trying to make some games and get into Ruby game development, is Go-Soup. It is actually a C++ library that uses a Ruby wrapper with Swig and also is accessible on doing iOS applications. It uses OpenGL for rendering and it's actually been a lot of interesting work that has gone into it up late. So let's take a look at the anatomy of a game within Go-Soup. We've already talked, we've got those three core components that a game library needs to have in order to be really effective. So when you're dealing with Go-Soup, you need to create a subclass of the Go-Soup window and you can only use one instance of this subclass and for the reason being that at a lower level in order to be able to handle rendering you need a device context in order to be able to send out your rendering commands and Go-Soup has tightly bound this in with the concept of the individual game so you only ever have one window and you need to act accordingly and it implements these three methods. So here is the bare bones of a Go-Soup application. You need those three methods that handle. So you add your game logic, you add in your rendering logic and a single button down event which operates kind of conversely from what you might expect in that you're not looking for when an event happens. This is more of an event triggered, and somewhere has been pressed. Here's the idea of the particular button that's been pressed. Figure out what you want to do with it. So when looking into Go-Soup I decided to make a really primitive blackjack game. If anyone has actually played blackjack you'll know that this is a poor implementation because you can't split your races, you can't double down, and there's no benefit to winning. But it does help us exemplify some of the problems with using game libraries and some of the other components. So first we're going to take a look at the initialized method in blackjack and you'll notice that there's a whole lot of resource rendering. It's just a lot of initialization of Go-Soup images, you need a Go-Soup font in order to write anything out to the screen, and that self is actually a reference that is necessary in order for the image to be rendered because it's taking that hardware context that is bound within game Go-Soup window. And this is really very primitive for a game. Not a whole lot of resources are going into here. I have extracted out the 52 other card initializations here for the sake of putting it on the screen. But I almost considered not just because it emphasizes one of the main problems you have which is that resource management is not a core component within Go-Soup. So what a resource manager really is it handles the creation and deletion of resource handles so that you don't have to care is there an instance of this currently in existence in memory? How do I need to handle the implementation details? It's an abstraction layer in order to say I need this, I need to render this. I don't really care if it exists right now in memory, just do it. And this is really an important component that isn't really represented. So here's an example of a primitive resource manager using the same resources we had before. We've created our resource manager class that handles registering all of the information all of the particular resources that could ever be used in the game. And then all you're using in order to handle it in the game loop is call resourcemanager.image pulls in whatever the basic handle is and now you're just focusing on calling your draw methods. So looking over into the update and button down methods the other two methods that are required in order to make a game you start to see within update we're starting to do a lot of conditionals for game state because at it's core blackjack you got two aspects you're either playing or you're not. That's a fairly simplified version compared to some additional complexities so we're only using Ips but now what if we had a third option? What if we decided we wanted to add a cashier or if we wanted to add in a nice menu system or start adding in a view for high score or what have you we would start adding a lot of complexity to the single update method and conversely our input handler is also something that is going to be toggled based on a particular game state so that's going to get even bigger and you can see here we've got two states or do we have a game in progress or is the game over then do one otherwise do the other in terms of button handling so we really need to abstract that out so that is the even further emphasized when you take a look at the draw method for rendering we've got a lot of if game we're changing up what the rendering context is based on the state of the game and this is where the addition of a game state manager is really necessary it contains all of your game elements your game logic, your UI elements, all of that stuff and it contains it so that it can say I want to create, I'm at this point in the game this is all of my relevant information, let's load it on it and that is something that is definitely lacking within many of the game libraries that are out there so this is really what that's looking like, you've got your primary game loop which interfaces with your game state manager you have multiple game states that are containing this game logic rendering and input handling and the resource manager that's handling spreading that across all of the game states and that's more of the ideal scenario for these types of games and looking at blackjack which is rather small, we've already started running into all of this additional boilerplate that's not fun to have to write for every single game so what I want to get into now before we expand further is the idea of entities and that's the idea that everything within your game needs to be represented in some interactable faction and they are really the building blocks of the game anything that's going to ever interact anywhere is going to have to be represented as an entity somewhere and in traditional engines this is really more of the base class of anything that's in there so the reason I start with that is because there's been an excellent library by the name of Gamebox that built on top of Gosu which handles these exact things that brings in the concept of a Gosu window is really more of a stage and you're showing a play your entities are being represented as actor objects which handle all of your interactions within a particular scene which holds your game states you have a single stage manager that controls all of the individual scenes coordinating the actors and handling all of these particular managers and finally you have a stage manager that micromanages all of the sub components these sub components include physics resource management input handling configurations anything that you would really need in order to handle that abstraction layer and it's been a really interesting project that has tried to get rid of that boilerplate by considering it more as a play that is being put out in front of you that you're interacting with so here are these stage hands so in summation the game library component they're really great starting points for game developers and people that are interested in game development there's a lot of boilerplate that gets put into them because they're designed to be so primitive they're designed to be easy to get into and you don't need to know much about game development in order to get them going but they're also not very performant because of that fact that they've abstracted out all of those core components so much so game libraries are a great starting point where can we go next let's build Ruby games with engines that are fully end to end in Ruby game engines they're allowing the developers to focus on game specific logic not low level internals but they're definitely more isolated components and are closer to the operating system they're handling the low level interfacing so that you can build more in higher abstractions so the first one we're going to take a look at is Slick2D which is a great Java library you can access through JRuby there's been a lot of development on it and one of the nice aspects about it is because it's a Java library you can package it up easily into a jar file and be able to transmit your stuff from person to person a game that I made with that is called Breakout which was actually just an extension of the Slick2D Pong application that Peter Cooper did he didn't made an excellent article about video game development with JRuby I took the stuff and said hey it's almost breakout and I wanted to start introducing some additional concepts into there some of the new components that were added with breakout from Pong is that now you've got multiple levels going on Pong was just the single level so you've got more problems you've got more physics calculations and you've got a lot more rendering you've got a lot more components that are going on because you've got individual handles of all the individual blocks the other aspect that's different from on Slick2D side versus say Gosu is that there are more internals that are directly exposed instead of having the Gosu window that combines your game state and your window handling they've split those out and you have your game instance as well as your game container also the input handler is part of that game container so now you can do more interesting things with input handling like mouse events for example or being able to trigger whether buttons have been held down or not you also have more access to the renderer object before the only way that you could really handle it is have your context and in particular objects that handles whether or not you could output anything to the screen so you're getting a lot more of that individual subcomponent functionality that is necessary if you're going to start adding more complexity and games get complex really fast another alternative is the JMonkey engine which is if you wanted to move into the 3D aspect all of these previous ones were 2D game engines which is more 3D this is also built more towards the traditional game engine that splits out every subcomponent into its individual class and it's up to you to start interfacing with those classes however of late they've instituted a component called the simple application which is actually closer to a game library which is nice for people that want to eventually expand their capabilities but start out with something small that game libraries have which as you can see is really just three methods that closely affect what Gosu already has and the other aspect that's nice is multi-threading via thread pools very easily in your initialization you can start pulling in multi-threading and that is going to be necessary I'll be talking more about one of the problems that we have with game engines is that concurrency is a big deal so let's build a game engine with Ruby what is a game engine a game engine is a component library that consists of all of these internals and it allows the non-game specific work to be off-loaded for game developers and it provides all the hooks that are necessary if a game needs to drop down into the engine level over there that's a list of all of the major components of a game engine if you're going to build anything substantial you need engine setup, you've got your main game loop your input handler and your rendering you can see that everything we've talked about it's started to handle those components a close representation of game engines but you need more if you're going to build anything of substantial sizing so what are the challenges with building a Ruby engine because as far as I'm aware no one's ever really done a full end-to-end engine from the ground up in Ruby the big ones are concurrency, cross-platform support library interfacing support memory management and code compilation so let's talk about each of these individually concurrency there's been a lot of discussions at this conference about concurrency and possible opportunities when game development you have a lot of components that need to work concurrent, for example the renderer you can never really allow the renderer by itself to be blocked by other components the simple fact that your frame rates will drop and the user experience will be very poor conversely you need to be able to not have your renderer blocking everything else that you're working on you need to address the issue of concurrency so the first thing that people go is hey, threads, we can do threads threads are great, spin up some threads start rendering in one thread, put the other components in another thread and we'll just have the game loop negotiate the discussions between all of those well that only works to an extent first up, Gill global interpreter lock bad news bears for games even if you manage to have multi-threading going on, you still need the ability to have IO going on and you have a lot of different components that need to be invoking the global interpreter lock frequently fortunately we have some implementations that don't have that problem JRuby, Rubinius and MacRuby the easiest one of that being JRuby given the fact that it's multi-threading and it's thread pools are a lot more easier to interface with and customize cross-platform sports this is the one thing that not looking at it from a game engine perspective is what I would consider a big flaw within Ruby's development is that our support for Windows is bad it's gotten better, but it's still bad trying to interface with Windows just based on the fact that yeah it's Windows, great we all know that there are some problems with Windows as a whole but we shouldn't be just discarding Windows as something that is just too much of a pain to deal with there are a lot of issues with some of the core libraries and standard libraries within Ruby for Windows support we already know that okay forking is not allowed but just trying to deal with a low level internals have caused some rather interesting problems with libraries that have tried to address this issue for example OpenGLFFI is a great opportunity to try and abstract out all of the OpenGL calls across languages however to date Windows support is basically non-existent as a result of a lot of problems within Ruby core there have been some interesting attempts at trying to resolve it however ultimately that language has basically been that library has basically stagnated over the last couple of months as a result of it and that makes it even harder for trying to be able to come up with game engine because you don't necessarily want to build an engine that only runs in one particular operating system of your choice JVM helps mitigate these issues by running on JRuby through the JVM helps mitigate some of these issues but I would like to see something other than JRuby be an option I like the project there but I get bored of trying to say throughout the speech that JRuby is the answer to some of these problems so one of the ideas that was proposed when I was talking to people about this problem is could we pick a Ruby implementation based on the operating system so for example the engine when you're compiling it or trying to build your game on top of it as you're installing detects what operating system is this designed for and what are we releasing it as and use the relevant Ruby implementation you could be using Mac Ruby for OSX you could be using Iron Ruby for Windows in that particular situation and at this point I don't think that that's necessarily viable given the fact that there's a lot of gotchas between implementations due to the fact that there's not a strict adherence RubySpec for example if we had everybody running 100% on RubySpec then this wouldn't necessarily be a big problem the next part is operating system input interfacing if you've ever tried directly through Ruby dealing with mouse events I encourage you to not try because it isn't fun trying to get the idea of mouse movement positionally against the screen as well as the idea of holding down a mouse and rotations is a rather big challenge and that's kind of important for a lot of different game types you can use some C and C++ extensions in order to get down to the lower levels in order to try and bypass that but if we're talking trying to create a purely Ruby game engine this is a challenge and something that will need to be overcome within the language in order to make that happen but JRuby can interface with it I don't manage to get a mouse to be able to detect it properly but that mostly has to do with being able to interface with JVM and Mac Ruby can do it as well memory management the big problem that we have going on right now in particular with MRI is that the Jarbridge collector is in real well authorized for really long running processes and a lot of creation and destruction as you're going through especially as you're going into the 3D area there's a lot of destruction due to occlusion calling and the concept of objects being rendered based on your position in a given location so you need the ability to start tuning the performance of the garbage collector and the ability to have all of these things running at a particular time because when it comes to game development the creation of resources is a really expensive component so that is a big problem that we're going to have though JRuby has some great tools for performance tuning and runtime in GC this is one of the things that we're going to have to deal with if we want to create a real JRuby engine and finally this is big 4 if you're trying to do any sort of commercial game game releases and that's code obfuscation there is a bad deal if you're trying to create a really good game your code's exposed free game don't have to worry so much about piracy when your code is all completely out there and that's not, that's great if you want to build a free game for people but when you're trying to make some money off of it that isn't so good which means that adoption in the game industry is going to be minimal so we need to deal with how we can obfuscate the code while still being able to compile it while still being able to run it easily JRuby can mitigate this by packaging it through Warbler but that doesn't really eliminate the problem because you're still being able to open up the jars and if you understand how it's working be able to pull out the code I think that for most people that would be enough however if we're looking for a larger adoption in the game industry that's not going to be sufficient so new tools for that are going to need to be built so with all those problems a game engine doesn't feel like something that we can really do in Ruby that's a lot to have to overcome I would love to see the potential there but I just don't think that we're at a point yet where a pure Ruby engine can be built so let's go back to that original idea of what we were doing with Unreal Script and Unreal RB which is that Ruby's great for trying to handle this entire level scripting option but the main problem we had with dealing with Unreal is that we were trying to cram Ruby into something that was not designed to be constructed that way but what if we took it as a candidate as we were building a game engine in something other than Ruby what if we designed our engine so that Ruby is fundamentally a core component of the engine as our scripting language so that way we can ignore some of the main challenges that we had we don't have to worry about our cross-platform situation because our other lower level languages are going to be able to handle that and we focus more on the higher abstractions that the engine itself are creating for us so some of the benefits that we have here is that we get to start using some of the great opportunities of Ruby features for DSL creation it's a lot easier for modders because now we're dealing with something closer to natural language that's complicated which means that the people that are focusing more on creating levels, creating mods and creating new interesting content that don't necessarily have programming backgrounds now have an easier level of adding into it plus there are a lot of components with logic mix-ins that would be a great boon for people that are building games and modifying games simply because there's a tradition within the game industry that everything seems to deal directly with sub-classing and looking at the tree hierarchy of a particular entity results in some massively tangled code-classing being able to switch that over more towards a mix-in state and being able to inject some of the game state into objects in a more Ruby fashion would help benefit some of the creation and allow a lot less of the technical hurdles and dependency conflicts it also allows a lot more isolation for a particular scripting languages and we also have just removed that code obfuscation problem because dealing with it at a scripting level we now don't have to worry so much about our extensibility and the hidden aspects of it it's still a bit of an issue but nothing nearly as bad as trying to build an entire engine from scratch but the challenges that we have with it are performance because looking at Ruby it isn't designed to be super small and super compact running Ruby as a scripting language inside of another language now you have to embed that entire runtime in there which is rather large and if you're already dealing with performance problems from the game engine's perspective and trying to clean up memory usage and CPU usage as much as possible you're now having to worry about an additional overhead so that would make it an even harder barrier for people and finally Windows support still sucks for Ruby so you're still having that particular problem enter mRuby and the thing that I have absolutely loved over the last couple of months in working with and researching mRuby's and if you haven't figured it out already is a lightweight footprint smaller scale implementation of Ruby designed to be embedded it's like screams use this for this particular subset it does not have a full implementation of Ruby and it is easily bridged with C and C++ and also with other languages though I haven't done it myself and it doesn't make an assumption about an operating system so across platform problems that are inherent within Ruby are now mitigated now the downside to that is that Ruby is not mRuby is not a full Ruby implementation several things that you would expect a Ruby implementation to have for example require doesn't exist because it doesn't assume a file system so you have some special challenges dealing with Ruby because you don't have everything that are necessarily there but I would argue that that is a better place to be at when dealing with a scripting engine than to have an overly large and bulky version of Ruby in order to have to deal with in terms of memory management now some people have already started adding in some of these features and I want to talk about two in particular one is a fork of mRuby that has started to add a lot of the critical components that you would be able to you would want to have for something on an operating system this particular fork ends up having as in the kernel require so you can actually start bringing in other files it adds in the option of IO and also for socket communications which is important if you want to deal with any sort of networking multiplayer capabilities additionally another side that I think will eventually get put into mRuby trunk is there's a pull request currently out on mRuby mRuby that adds a library manager for C and Ruby extensions to mRuby that actually at compile time when you're bundling up all of mRuby it will start pulling in your sub gems and compiling them in and it has actually been rather interesting at its memory footprint because it is only increased by a few kilobytes just by adding this component in which means that now we don't have to worry about additional overhead with gems but the big thing despite the fact that the name is similar to RubyGems mRubyGems is not RubyGems it is not designed to at the runtime start pulling in libraries instead it is designed as a manager to start pulling in compiled compiled runtime versions of those gems and those libraries it's meant more as a concrete library interface not as the ability to start injecting in functionality at runtime so let's take a look at some engine scripting examples what can we do now that we're using Ruby built into as our scripting language I've got two examples of common things that I would prefer to be writing rather than Unreal script one of which being a rail gun and another being a health pickup by adding in the syntax capabilities of Ruby within there we can now start focusing on bringing in individual module inclusions for bringing in hooks adding all that capabilities and that is a lot easier than trying to write out class rail gun extends UT weapon it depends on UT weapon and start adding an additional functionality there and conversely health pickup you start bringing in additional modifiers and the nice aspect about that is that not all of this has to be written in Ruby in order to start adding this capability you could be writing C code and you could be dropping down into the lower level and accessing the engine internals and no longer have to worry about being confined within your particular but the lower level language so the last part that I want to talk about is that I am announcing that I am starting development next week of a full Ruby engine that was built on C++ using the embedded embedded engine it's going to be using the OpenGL rendering system and I am really excited about the possibilities here starting next week is our company's every other month hackathon so we go 24 hours writing out the first spike is going to be during that but I am going to be releasing everything and starting to document the process of how this engine is going and I encourage anyone that's interested in working on that project or following it to talk to me afterwards about some of the plans for it it's a cool opportunity and I think that Ruby has some great potential within the game development industry and solves some of the main pain points that people have from a modding and game extension capabilities it just happens I have some challenges that we need to overcome in order for it to gain a little bit more mainstream capabilities and I really hope that soon we can start addressing some of those problems and get Ruby out into an area that I think has been a little bit neglected in its route I would like to see Ruby in a spot where the major project that people notice when you're talking about Ruby is oh do you work with rails I don't want to have that be the main driving thought that people have for a particular language so thank you for listening to me ramble this is my first conference talk and yeah it's been fun thank you very much it looks like I have a few minutes for questions and if we run out of time then I'd be happy to talk to more people afterwards or over lunch I think that in that particular instance when you're sorry the question was that mruby doesn't have concurrency support built in so what are the impacts of that I think that if mruby is being used more as the scripting level it's being put up on a higher level that you're able to have the emphasis on concurrency being more with the parent language of the engine rather than the onus on mruby so it mitigates it but it certainly doesn't resolve all the potential problems no so the question was I mentioned that jruby can handle some of these things but it sounded as though I wasn't super happy with it and that's not really my stance I feel that it's great that jruby can handle these things I think that we need to be able to have more than just the jruby implementation alone be the answer to our problems I think that we can address some of these concerns and other implementations if we put the initiative on that but I definitely love the fact that when I'm researching some of the challenges that we have here that my first answer ends up being jruby can handle that I'll be posting the launch on Twitter and posting it up through Ruby news as soon as the first spike goes through twitter.com and it'll be out there the question is do I know anything about using Ruby as the scripting component within Unity and the answer is no but I'm addressing that at work next week so hopefully I'll have more insight on that and as part of the process I'd like to document that as much as possible anybody else no alright well thank you very much