I’ve worked with a lot of awesome people in the games industry.\u00a0 I’ve learned a lot from these people and I thought a great way of sharing their knowledge and wisdom would be to start a game developer spotlight.\u00a0 This is my first attempt, I’m interested in people’s feedback.\u00a0 I worked with Greg on Battlestar Galactica and on an unreleased title before leaving Auran.<\/p>\n
I started programming as a 10 year old kid, with the Apple 2 computer my Dad bought.\u00a0 My life’s passion has been making and playing games.\u00a0 My work life started out porting games between Consoles, Arcade machines and PC.\u00a0 I’ve been programming professionally now for 12 years . I have worked on what would be called engine technology for each of the three companies I’ve worked for.\u00a0\u00a0 I’ve worked on a number of projects that were not real high profile.\u00a0 Some that people might have heard of are Krazy Ivan, ManxTT Superbike and The House Of The Dead for PC.\u00a0 More recently, Battlestar Galactica\u00a0 for Xbox.\u00a0 An interesting side project was not\u00a0 a game, but kind of like Auto Cad for Grandma, a 3D virtual home construction and decoration program that contained a lot of technical challenges.\u00a0 As is normal in our industry, roughly half of the projects I’ve worked on have been canceled at some point.\u00a0 I’ll try to refrain from long rants about the crazy way the game industry works and hopefully say things that might encourage young developers, in particular, programmers.<\/p>\n
Here’s some of my favorite games: Master Of Orion, X-Com, Total Annihilation, Unreal Tournament, Battlefield 2. I’ll throw in Rescue Raiders as a classic and Mass Effect as a recently enjoyed title.<\/p>\n
To be good at programming, you really need to read and write code, lots of it.\u00a0 With the internet, open source, and mod friendly companies, there is plenty of source code to read, to learn from, as well as use to give your project a boost.\u00a0 If you like a particular game, perhaps Fear, Half Life, or one of the Unreal or Doom games, I’d recommend downloading the SDKs.\u00a0 Make a mod, or try to figure out how things work.\u00a0 Sometimes the public source code is complete, other times it will just allow access to the engine via an interface.\u00a0 I hesitate to mention specific engines or libraries, but I will anyway…\u00a0 I think Ogre does lots of things the right way for rendering.\u00a0 Bullet is becoming a solid physics system.\u00a0 Raknet is an excellent networking layer.\u00a0 The Doom3 (and related) SDK is quite elegant. The DirectX SDK is a solid place to start with graphics, sound, input and even basic maths.\u00a0 I think that Microsoft’s effort on the Xbox 360 development tools make it the most enjoyable console development experience yet.<\/p>\n
GameMonkey Script is primarily the child of Matthew Riek.\u00a0 He was the compiler writer and has a brilliant mind for such things.\u00a0 I wrote some of the run time components and default bindings, and have been maintaining a public build since the code was released.\u00a0 We surveyed scripting languages and their use in games (and tools), and zeroed in on Lua, which looked like what we were after, and was gaining credibility.\u00a0 We almost used it ‘as is’, but after discussing what features we wanted, as C\/C++ programmers, making games and tools, GM was birthed in a very short time.\u00a0 The project it was intended for was canceled, but we thought the language was so cool, we sought permission to release it publicly.\u00a0 Now, with more experience using scripting languages in production, and being exposed to mature managed languages like C#, we realize with hind sight clarity that we didn’t make all the right decisions.\u00a0 The GM language is still fun, flexible and simple, and has a growing community, as well as street cred, having been using in a number of games and on a variety of platforms.\u00a0 I don’t want to raise expectations about the future, but I am hoping Matt and I can put our lessens to use and show something exciting in the future.\u00a0 I would like to say that there is no such thing as the ultimate language, but there are ‘the right tools’ for a job, and in my mind, there is currently the need for native, managed and embedded languages.<\/p>\n
We may have hit a small plateau with game visual quality at the moment.\u00a0 The kind of specs presented by current PCs and Consoles allow stunning visuals but it is hard to see where a big leap could occur.\u00a0 Games commonly contain familiar systems of audio, graphics, physics, networking.\u00a0 I think there is room for improvements at two ends of the system.\u00a0 1) Internally, integration of existing systems, the way game entities are configured and coded, in particular, working with content from the creation process.\u00a0 2) The user interface, as a combination of hardware controls and on screen visuals.\u00a0 With (1), we need simple and flexible ways to define behavior of everything from breaking floor boards to boss character robots, accessing and using art, sound, movement, and interacting with systems like collision, physics, navigation and networking, so this is still a challenge to ‘get right’ and provide new levels of interactivity.\u00a0 With (2), I am convinced that most current games are let down by their interface, which is the single most important part of the game, I mean, that is where the player meets the game, what could be more critical?\u00a0 I was happy to see Nintendo attempt new things with the Wii and DS systems, at the hardware level.\u00a0 I recently enjoyed playing Rainbow Six Vegas on Xbox 360, renewing my faith that ‘shooter’ type games and a tactical experience can be done and done well with a console control pad.<\/p>\n
Multi processor systems are here to stay and become more numerous.\u00a0 This really is a big problem for game developers who will be under pressure to make more use of the hardware.\u00a0 Unless there is a significant break through with compiler or CPU technology that eases the burden, multi processing and multi threading will add pain, and create a new generation of really hard to debug programs.\u00a0 Algorithms that look simple for a single threaded system can gain a lot of complexity when turned into versions that take advantage of parallelism.\u00a0 Ideally you want to put independent bits of code on different threads, but when the number of threads (I will say threads instead of hardware CPUs that may run those threads), increases beyond 4 or 8, we will have to consider restructuring single tasks into parallel versions.\u00a0 If you look further down the track, all multi processor systems will do is shift the bottleneck to another part of the system.\u00a0 I personally believe that to take the next step into amazing simulations and interesting virtual worlds, we need fast random access to large volumes of memory, and use algorithms with deep and varied conditional branches.\u00a0 This is the opposite to how hardware is currently going.\u00a0 The cost of memory cache misses and mis predicted branches is extremely high.\u00a0 Not all interesting algorithms can be broken down into CPU plus scratch memory\/register size chunks for accelerated processing.<\/p>\n
1)\u00a0\u00a0\u00a0 Read and write code, diversely, as mentioned earlier. Study all areas of game development.
\n2)\u00a0\u00a0\u00a0 Don’t focus too much on just Graphics, Physics or other fun system.\u00a0 Game Engines are more about the whole process of getting Level design content and Art content into games than on those exciting, but limited game systems.\u00a0 Use yearly GDC notes and site like Gamasutra to read articles about game technology and tech issues.
\n3)\u00a0\u00a0\u00a0 Think deeply about the interface to the game components and technical systems. How would you feel, if compelled to be the end-user of your own code?
\n4)\u00a0\u00a0\u00a0 Don’t expect to be a one man band, or start a job in the exact position you would like.\u00a0 Have a good attitude about working with and communicating with other people.
\n5)\u00a0\u00a0\u00a0 Do think of the game industry as a realistic place for a career.\u00a0 There is plenty of work and plenty of interesting challenges.
\n6)\u00a0\u00a0\u00a0 Don’t be put off by the thought that all future games will be made from the one\/few licensed engines (and if they are, be the one to make or work on them).
\n7)\u00a0\u00a0\u00a0 Don’t forget tools.\u00a0 They just may be more valuable than the run time technology!
\n8)\u00a0\u00a0\u00a0 Don’t forget performance, but don’t let it decide the interface.\u00a0 Remember John Carmack’s success.\u00a0 Any high school student with a PC and DirectX\/OpenGL accelerator can render a 10,000 polygon level at interactive rates, but Carmack did it on a 33mhz 486.\u00a0 And that is a commercial advantage.\u00a0 More performance always allows a better use experience, more content, and quite reasonably, more carefree content creation, because care = time = cost.<\/p>\n
C++\/CLI pretty much just puts the entire C# language inside C++ so the two can work together seamlessly.\u00a0 I love it.\u00a0 No longer do I look enviously across at Visual Basic or Java programmers who can whip up UI applications, I now have all the tools too.\u00a0 The .Net API finally nails shut the coffin of the horrible MFC and Win32 APIs, so UI and platform features can be accessed pleasurably.<\/p>\n
At present I use C++\/CLI for tools and C++ for games.\u00a0 I would not be surprised to use CLI languages in future games themselves.\u00a0 I know other people are doing that already, and Microsoft is forcing people to do that with the Xbox XNA kit.\u00a0 I’m not convinced it’s time to leave native code yet, at least not for internal, technical systems.\u00a0 The new managed languages do offer a bunch of features that improve high level coding, however half of these features could be added to C++ if the standards process would ever hurry up and be implemented widely.<\/p>\n
The companies I’ve worked for have used a mix of internal and licensed engines.\u00a0 Because I enjoy the technical more than gameplay side, I am biased in my opinion.\u00a0 What I do know is that modifying some engines to meet the need of your game can be a major effort that puts into question the value of using a licensed engine in the first place.\u00a0 In those cases, I think the better decision is often to fit your game within the existing framework rather than try to make modifications.<\/p>\n
I would say, it depends greatly on the kind of game you are trying to make, the kind of people you have to make the game, and finally the companies future plans.\u00a0 With licensed technology, you typically have to pay tens to hundreds of thousands of dollars, per product and per platform.\u00a0 If you develop technology yourself, you accumulate the technology over time and own it.\u00a0 On the other hand, the cost of making and maintaining the tech can be high, the staff may need specialized skills, and hiring people with existing engine experience may not be possible.<\/p>\n
I will admit I don’t like big teams.\u00a0 Small teams are fun and productive.\u00a0 Team members communicate quickly and efficiently, there is a level of accountability in small teams since everyone knows what everyone else is doing.\u00a0 There is more variety in work because people don’t just specialize in one area for the duration.\u00a0 So, no, big teams and budgets won’t make the industry more fun or productive, but will likely be done because it can allow for more content and higher quality content.\u00a0 The risks of a project going bad are greatly increased as well.\u00a0 When I talk about productivity, I have seen large teams working at well under say 30% productivity, while a small team can work at about 70%.\u00a0 Thinking that efficiency can ever reach 90% or so is pretty much impossible.\u00a0 Humans get tired, have to solve hard problems and have to work together, and that doesn’t even account for the interaction with publishers, which from my experience usually decreases productivity further due to delays, changes and restrictions, amongst many other issues.\u00a0 In the end, the larger team may be more successful, IF the project is finished and is accepted by the market.\u00a0 That army of unhappy people just may produce a game who’s commercial success recovers its costs and then some.\u00a0 Think of the risk though, and the rate of cash burn on big projects.\u00a0 So to re-answer the question, good? No, inevitable? Yes.<\/p>\n
I enjoy research, solving interesting problems, and more the technical side of games.\u00a0 However, the most important thing for me is to work on a game that I actually want to play.\u00a0 This should be the norm for our whole industry, but it is not.\u00a0 I’d like to work on a small team, with complimentary skilled people, who have good attitudes and love games.\u00a0 Is that too much to ask for?<\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve worked with a lot of awesome people in the games industry.\u00a0 I’ve learned a lot from these people and I thought a great way of sharing their knowledge and wisdom would be to start a game developer spotlight.\u00a0 This is my first attempt, I’m interested in people’s feedback.\u00a0 I worked with Greg on Battlestar Read More<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"enabled":false},"version":2}},"categories":[109],"tags":[32,112,44],"class_list":["post-96","post","type-post","status-publish","format-standard","hentry","category-interview","tag-game-developer-spotlight","tag-game-development","tag-interview"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/pgEc5-1y","_links":{"self":[{"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/posts\/96","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/comments?post=96"}],"version-history":[{"count":0,"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/posts\/96\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/media?parent=96"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/categories?post=96"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.doolwind.com\/blog\/wp-json\/wp\/v2\/tags?post=96"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}