 Wonderful. As the slide says, this is about games. This is about the games of the way games should be written, about games libraries, games mediaware, and with respect to open source obviously, because this is false then. Because most commercial games will not or won't, for some reason, use open source. There are several reasons for this. One of them is that the libraries aren't written the way that games programmers use libraries. It's slightly different when you're doing a game to, you know, a web server or a web processing app. So what we're going to do is we're going to look at why the badness happens, how it happens, how we can correct that. And obviously, since I wrote this thing, we're going to be promoting SGX for whatever reason. But first, the obligatory ego slide that tells you all about me and where you should listen to anything I have to say. Yeah. I did a book a few years ago on cross-platform programming. So how do you write a game on PlayStation and make it work on the Xbox? Not quite as easy as it sounds. And then wrote another book on open source and game development about the libraries, about the way they're used. I then did a show on the internet, a little podcast about beer where I review beer. Just switch one of the three people genuinely want to talk about. So today I'm going to talk about games. So the first thing we're going to do, if we're going to do a library, we're going to have some common ground. You've got to start from somewhere. So obviously this slide says, where is it? Well, obviously integers. They're completely common everywhere, except on the PlayStation 2, where you change, Xbox is a little bit different, so we can't rely on integers being the same. So we've got no common ground there. The standard library, as it says, is standard, but there are so many standards to choose from. They aren't the same. In the C library, which is what all professional games programs use, there's a little function called Q-Sort. You're probably aware of this from the C standard library. Q-Sort does not do a quick sort, even though it suggests it. All it does is a sort, which means if you've got two keys that are the same, which is legitimate and loud, they could be swapped if your library happens to do a non-Q-Sort. This will cause you bugs, and you won't know about it because it's a different standard. Sorry, can't use it. And the Gnu compiler isn't actually available everywhere. It's not available in the Wii, amongst other things. So I was wondering, what do I put here? Are we going to start with some common ground? What's that base level? Language is the invention that makes all others possible. I thought that's quite a good quote myself. I should have put it there. So we're geeks. We deal with languages every day. Scripting languages, programming languages, functional language, everything. What does that mean? Is that object? Is that object? What is an object? Is it available? Is it a container for data? A container for instructions? Data and instructions? Data but not instructions? A procedure? A function? A specification? An instance? We're not really good at this common ground language thing in reality. And when it comes to engine, what's an engine? Most people say, oh, I've written an engine. No, you've written a graphics library that wrappers open GL. There's a difference. We need to have some kind of common ground that we can all understand. And as soon as we've got that, we can't even move on. Well, next thing, we all rely on everything else. Open source is very good at this. We rely on other components. That's not so good in games. All of a sudden, your standard little renderer needs 27 other things to build, half of which are available in the exports or the PS3, so no games program is ever going to touch it. So what sort of components? Well, this is a fairly easy example. A building library. You've got a mouse. You move the point on screen and you click on a button. That's fairly easy. But you go and get your mouse position and you know you can't because it's not cross-platform. Mouse on X is quite different to mouse on Windows, which is different to the way the Wii pointer works. So let's abstract it. Well, you can, and you can create this little get cursor position, but it doesn't work. Who says you're using the left mouse button the whole time? You're using a joy pad. You're using a joystick and a button. Which button? If you've got three players all joining a multiplayer game and any of them can join in, you can't even say, is button pressed? It's not going to work. And games have to handle this. There are so much pieces of source code out there that if your thing doesn't slot in and work, no one's going to use it. There's enough source data. You say, well, that doesn't work. I'll try this one. I'll try this one. And when you find out they don't work, you write it yourself. It's going to be quicker. So we've got to solve these problems. I have this problem as well. Everyone has this problem of display and processing. Web developers, bless their cut themselves, are the worst at this. They'll write a little chunk of PHP processing. They'll output some stuff. They'll write some stuff. They'll process an output process. You can't mix them. Games, we have a few benefits. Because let's face it, all graphics are visual. So we can mix in the processing and the output, the display, the nice funky stuff. Because graphics are always visual. In every single game, we're always working with graphics. Oh, no, we're not. As soon as you suddenly realize your game engine is meant to be running on a server, there's a little game called World of Warcraft that some of you may have heard of. Some of you have probably World of Warcraft spouses as well have been lost to the game. Sometimes, graphics engines do not run on graphics hardware. So you've got to sort, if you've got a mesh, a character mesh that walks through a door and your graphics engine is saying, can I walk through that door? All of a sudden, you run it on a piece of hardware that doesn't have the graphics. Your game doesn't work. So you can't just, what you would normally do is run the graphics engine to do stuff for you. I said in the notes to the slide, by the way, I would talk about the human aspects. And this is it. Humans are awful. If you could write software about humans, it would be much easier. Because basically, they'd not let change their code. If it doesn't work, they're going, well, yeah, if I change it and I make your stuff work, if it breaks to someone else, I'm responsible. I just understand that I don't want to be responsible for breaking people's code. But humans are problems as well as the code. So we're going to solve this problem as well. Fill out what we should actually give up at this point. Fear not. There are three steps to the problems that happen with games and games libraries. There's the human-human thing. How do we arrange for humans to do work and not make everything break? There's the human-computer thing. How do we have common terminology? How do we make sure that we convey our ideas correctly? And we have computer-computer things, making sure APIs are OK, programmed by contract, things like that. Where will start? Where will start at the beginning? The engine means everything. It doesn't mean a graphics renderer with a math slide be hidden in the middle somewhere. It means everything. Components. These are completely independent things. If the audio component relies on the collision system, or the graphics relies on the collision system to get a mesh through moving through a door, it's wrong. You don't need that amount of interplay. You don't need the drivers. These are common. You can have a collision system which work on every platform. You don't need a graphics driver to tell you that. And you can then write your drivers that just say, OK, now push some polygons. Now make some sound. This can work on any platform. And you just write probably a thousand lines of code if that to make it work on any of these other platforms. Something obviously which I can't release is the WEE code and the DS code, which also does it in less than a thousand lines. Same engine. Just separate driver code. Separate the driver code to drive a code with the main abstractions. Base everything around a core. Obviously, since it's SGX is something that I'm involved in, the SGX core is the way to go. This is the language quote from earlier. Language makes all other inventions possible. The core makes everything else possible. If we say, let's have a common set of types, and this is one of the really important ones, unfortunately. Run at the bottom. Everyone says, oh, I will pass an integer to this function and it will do stuff. What's all that we integer? Two byte, four byte, side, unsigned? Create a common set of types and if everything uses these set of types, we all know what we're doing. No one can be saying, oh, no, I thought you were going to be unsigned. Oh, no, I thought I had 32 bits here to play with. Common set around everything. Abstract things. If you're doing cross-platform work, the key word is abstraction. Just hide everything else away from the lower. The entire standard library, Q-Sort, everything else, hidden away by a little lower. Functions happen to begin with SGX because that's the engine. But just hide them away a little bit. So if there is a problem in Q-Sort, doesn't sort that way, at least it will on all the other platforms because you've abstracted it. I learned how to do green about halfway through doing these slides. It's good for me, okay? I didn't do this good stuff. Uncouple your code. When we talk about, oh, a mesh could move through a door. Yes, that is a physics type of problem and it is a bit of a graphics problem, but actually in reality, it's geometry. Separate away. Have a common set of geometry code that processes polygons, processes meshes, processes a square versus a line. All this sort of stuff doesn't rely on graphics. It doesn't rely on anything. It can be used by graphics and can also be used by the sound code. If you're trying to work out, can I hear this noise and can the AI run after you? You can use exactly the same geometry code, but it's not in the graphics engine. It's in a domain which is separate and relies on nothing other than a core set of types. Create a skeleton library which is just the sheer basic bones that says this is how you access information. And templates are always good, so you can basically take something and compile it and it just works. One of my pet gripes and a lot of things is source code on Linux. If it's not on the disk or it has an issue sometimes. Single turns are a wonderful thing. I know a lot of people hate them, but in engines it's really quite cool. You start by creating an engine. This creates a global pointer inside its memory. So your initialization routine calls this and that's platform-specific. It generates the platform-specific pointer. But then everything else in the entire engine uses this generic. Very, very simple. And this stuff, it may go through to platform-specific, but it can also go through to the basic driver, which means you can share the code for four or five different drivers without changing anything. Something a lot of people think, oh, but it's just a global. So why don't we just call it graphics underscore apply texture? Well, that means as soon as you go to another platform, you need to copy graphics apply texture to every single platform. Or if you change the interface or you add functionality, you've got to go back and add it to everything. Whereas if you're doing a sort of a class hierarchy, and this is also a plus, plus, obviously, you can tell from the syntax, if you do the class hierarchy thing, then you can write stuff that's common and all the drivers can use it. Create nice interfaces, obviously. Giving to the rich, taking from the poor. Go back to the gluing example. We can't just go in and take a mouse pointer. We can't just say, oh, give me the joystick position, but I'll work out which of the three joysticks wants us to say okay at this point. Take it from somewhere. Your game, your game is the only thing in the world that knows if two joysticks can hit okay on this screen. Your game is the only thing that understands how it should work. So get the game to say, okay, give me the joystick position, give me the buttons. And then send that message back down to the input, to the GUI system. Because that way you can have a nice layer up here and it can talk this way. Somebody will go, oh, that's a lot of processing. No. When you realize you're pushing thousands of polygons out of the screen, you're pushing megabytes and megabytes of data through your pipelines. It's an extra two bytes to take an XY position from this library and give it over here actually a process. It's not a block. And it means that the libraries will fit in with everything else. And that's the key point. Libraries want to play together. When it's open sourcing, you can just take and you can recompile and you can build and you can shuffle around. Very easy. When you're in a game, people generally aren't going to be doing that. They will take, they will run it through and if it doesn't work, they will move on and rewrite it. So a punctuation is wrong. No. Yeah, that's the way. So if we have about a minute and a half left, I can do questions on games or beer since I know which one most people want to talk about. Including Frank. Unless I've actually covered everything and we're about to run out of time. No, we'll do about a minute. I took quick. Yes. The NDA is actually forbid me from mentioning them at the moment. There's one which is meant to be out on my phone in the middle of March. But because it hasn't been announced, I'm not allowed to say what that one is. There's a TV, a children's TV show. There's a re-game coming out, which will be in the August catalog for August, I think. Again, which you can't quote me on because it hasn't been announced formally. It's in that as well. There's another couple of educational games that it's being used in. Plus portions of the engine have been used in previous games. I've been writing games for about 14, 15 years now, including this guy from Vendetta based on Bruce Willis character who goes around in a vest. We did a game on that. There's portions of this code from there because it's the engine I thought. I could write it in work or I could just copy the code I've written. And I don't like rewriting things. So several of them. Come on next year. I can tell you all about it next year. They're actually all cross-platform. The die-hard game was out on GameCube, was on PS2 and on Xbox. And there's also a PC platform that we use internally for development. It's much cheaper to have a PC running the game than it is to buy an Xbox dev kit or a PS2 dev kit. So they are all cross-platform. One of my tenants is development. 15 minutes is an awful long time. You don't realize it until you get up here. Yeah. If there's anything else, I'm going to... I would say... Perfect timing. Thank you.