Firstly, could you introduce yourself, tell us what games you’ve worked on, how long you’ve been designing games and what you’re favourite games are?
My name is Simon Neech and I’m a Game Designer at Fuzzyeyes Studio, creators of the upcoming Edge of Twilight.  I’ve been officially involved in the game industry for around 4 years (within 3 separate studios) although I have been following its development and products, in one way or other, for decades.  Titles I’ve contributed to so far are: Destroy All Humans 2, Fury and Battlestar Galactica but as a hobby I’ve played, modded and tinkered with hundreds of games before these.
My list of favorite games is in constant flux; the release of new titles has me swinging between genres varying from simple puzzle games to detailed RTS’s. The platforms I play these on are similarly varied: from PC, to Xbox 360, PSP and recently the iPhone.  My favorite game at the time of writing is Anno 1404 but this could easily slip to Battlefield 1943 in the next few days.

You started out as in QA right?  Can you tell us a bit about the transition from QA to game design?  Is this a path you can recommend to people wanting to get into the games industry?
QA was a fun and rewarding experience which, although I didn’t know it at the time, allowed me to acquire skills that would assist me in my future career. I gained first hand experience with the production process that included stages of game development, asset pipelines and even commonly used jargon.  The transition period between the two careers was fairly smooth; I basically went from identifying and documenting bugs within games to creating the bugs myself!
But yes, I would have to agree that working in QA is a great way to break into the industry. Of course, game companies employ testers to assure the quality of their product and not to lay groundwork for a potential career in design; so you need to start down this route with the correct attitude.  When I was first employed, I was overjoyed just to have a role within the industry, in whatever capacity.  I dedicated myself to this position until I found myself in the right place, at the right time and with the right level of experience to start down the design path.  Realistically, I could have continued to do QA for a lot longer and would still be regularly skipping happily to work to this day.

When we worked together you came up with a pitch for a game design almost weekly.  Talk us through the process you take when turning an idea into a document you can pitch to the team.
A simple way to develop a pitching method is to practice on anyone with the patience to listen.  Feedback is your friend, even though it can be devastatingly honest.  My personal process starts with a broad idea. I mentally play through this game idea; over and over until I’ve clocked it on hard difficulty and unlocked all the achievements. When I’m satisfied that it’s something worth developing further, I then document it.  This is the stage where major design flaws become apparent; the relationship between the games constituent parts can often reveal fatal inconsistencies.
My pitch documents consist of two parts: an introductory overview followed by descriptions of the individual features that make the game unique.  The overview should address the basics, such as genre, perspective, platform, intended audience etc. The feature list includes the elements that truly define the idea. These need to be refined into easily relatable terms, while avoiding the trap of micro-explanation; something that will quickly lose peoples interest. The end result should be a few condensed pages, using examples of similar games to clarify points if necessary.

Many people I talk to aspire to becoming a game designer.  What recommendations would you have for game designers who are looking to break into the industry?
In preparation for a design position within the industry, there are many avenues of study that will teach you the tools of the trade.  But before this, I would advise potential designers to simply analyze the games they enjoy playing.  Scrutinize the graphics, sound and gameplay; immerse yourself in the nuances of story and narrative and imagine ways in which you could improve them.  Like most products, the technology and art of games are built upon the many iterations that comes before them.  Having a firm understanding of these, to see what’s been done well in the past and what has not will prepare you for the design challenges ahead.

You’ve used a number of game engines for the various games you’ve worked on.  Could you tell us a little about what you like and dislike in an engine as a game designer.
Overall, Unreal 3 is the engine I have the most experience with.  It’s a powerful design tool for developing games such as Edge of Twilight.  Prior to this, I’ve worked with propriety engines and have even used the accessible editing tools that often get bundled with commercially available games.
As a designer, I consider versatility as the most important attribute of an engine; the ability to accomplish unforeseen tasks at a scripting level really assists the smooth flow of design.  Currently, I work on many facets of the game, but mainly concern myself with camera implementation used to observe the game world. The Unreal engine has allowed me to implement a wide variety of camera techniques, despite its freecam FPS roots not being generally designed to achieve this.

Do you think the growing team sizes and budgets for games is good for the industry?
I think the growing budget of games is a double edged sword.  On the one hand, a large budget contributes to high production values, enhancing the gameplay and narrative experience.  On the other hand, huge budgets carry inherent risks and these risks create a tendency to mold games into predictable, clichéd and ultimately safe titles that achieve little in breaking new ground.
Fuzzyeyes, as an independent developer, balances big budget production with the freedom to explore new possibilities, especially in regards to mature themes. Our storyline, aimed at an adult audience, would probably be toned down in a more mainstream studio.
Of course, as in other creative industries such as film, there is a niche to be filled for games with a wide range of budgets; anywhere from many millions of dollars to free!

You’re currently working on “Edge of Twilight” at Fuzzyeyes.  Can you tell us a little about it?
Edge of Twilight is a third person, action adventure game set in alternate, steampunk themed, universe.  For those not familiar with the term;  ‘Steampunk’ is an aesthetic style based on a modern interpretation of  Victorian-era society and engineering.
The player will assume the role of Lex, an outcast bounty hunter who is a cross between two opposing races; the industrial Athern and spiritual Lithern.  Game play will be split between combat, puzzle-solving and exploration. These elements will in turn be split between two parallel planes of reality that only Lex can traverse; the Lithern influenced night realm, and the industrial, Athern dominated day realm.

What would be your perfect project to work on?
For me, the perfect project would be to develop a game that I truly wanted to play on completion. In this regard, all the games I have worked on can be classed as ‘perfect’ projects! As a long term personal goal, I would like to work on a game from my own repertoire of ideas; taking it from the very initial concept stages right through to release.

• Firstly, could you introduce yourself, tell us what games you’ve worked on, how many engines you created, how long you’ve been programming and what you’re favourite games are?

I started programming as a 10 year old kid, with the Apple 2 computer my Dad bought.  My life’s passion has been making and playing games.  My work life started out porting games between Consoles, Arcade machines and PC.  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.   I’ve worked on a number of projects that were not real high profile.  Some that people might have heard of are Krazy Ivan, ManxTT Superbike and The House Of The Dead for PC.  More recently, Battlestar Galactica  for Xbox.  An interesting side project was not  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.  As is normal in our industry, roughly half of the projects I’ve worked on have been canceled at some point.  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.

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.

• You read through the source code of a lot of engines and SDK’s.  Can you tell us which ones you use, what you gain from this and whether you would recommend it to other engine programmers?

To be good at programming, you really need to read and write code, lots of it.  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.  If you like a particular game, perhaps Fear, Half Life, or one of the Unreal or Doom games, I’d recommend downloading the SDKs.  Make a mod, or try to figure out how things work.  Sometimes the public source code is complete, other times it will just allow access to the engine via an interface.  I hesitate to mention specific engines or libraries, but I will anyway…  I think Ogre does lots of things the right way for rendering.  Bullet is becoming a solid physics system.  Raknet is an excellent networking layer.  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.  I think that Microsoft’s effort on the Xbox 360 development tools make it the most enjoyable console development experience yet.

• You were one of two people that created GameMonkey Script, can you tell us a bit about what lead you to creating it and the lessons you learnt writing a scripting language.

GameMonkey Script is primarily the child of Matthew Riek.  He was the compiler writer and has a brilliant mind for such things.  I wrote some of the run time components and default bindings, and have been maintaining a public build since the code was released.  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.  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.  The project it was intended for was canceled, but we thought the language was so cool, we sought permission to release it publicly.  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.  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.  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.  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.

• Where do you see games and game engines going in the coming years?  What are your thoughts on multi-processor support within game engines and in general game coding?

We may have hit a small plateau with game visual quality at the moment.  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.  Games commonly contain familiar systems of audio, graphics, physics, networking.  I think there is room for improvements at two ends of the system.  1) Internally, integration of existing systems, the way game entities are configured and coded, in particular, working with content from the creation process.  2) The user interface, as a combination of hardware controls and on screen visuals.  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.  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?  I was happy to see Nintendo attempt new things with the Wii and DS systems, at the hardware level.  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.

Multi processor systems are here to stay and become more numerous.  This really is a big problem for game developers who will be under pressure to make more use of the hardware.  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.  Algorithms that look simple for a single threaded system can gain a lot of complexity when turned into versions that take advantage of parallelism.  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.  If you look further down the track, all multi processor systems will do is shift the bottleneck to another part of the system.  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.  This is the opposite to how hardware is currently going.  The cost of memory cache misses and mis predicted branches is extremely high.  Not all interesting algorithms can be broken down into CPU plus scratch memory/register size chunks for accelerated processing.

• What recommendations would you have for young game engine programmers who are looking to break into the industry?

1)    Read and write code, diversely, as mentioned earlier. Study all areas of game development.
2)    Don’t focus too much on just Graphics, Physics or other fun system.  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.  Use yearly GDC notes and site like Gamasutra to read articles about game technology and tech issues.
3)    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?
4)    Don’t expect to be a one man band, or start a job in the exact position you would like.  Have a good attitude about working with and communicating with other people.
5)    Do think of the game industry as a realistic place for a career.  There is plenty of work and plenty of interesting challenges.
6)    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).
7)    Don’t forget tools.  They just may be more valuable than the run time technology!
8)    Don’t forget performance, but don’t let it decide the interface.  Remember John Carmack’s success.  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.  And that is a commercial advantage.  More performance always allows a better use experience, more content, and quite reasonably, more carefree content creation, because care = time = cost.

• You’ve done some work with C++/CLI and C#, can you tell us your thoughts on how these will fit into the games industry in the coming years?

C++/CLI pretty much just puts the entire C# language inside C++ so the two can work together seamlessly.  I love it.  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.  The .Net API finally nails shut the coffin of the horrible MFC and Win32 APIs, so UI and platform features can be accessed pleasurably.

At present I use C++/CLI for tools and C++ for games.  I would not be surprised to use CLI languages in future games themselves.  I know other people are doing that already, and Microsoft is forcing people to do that with the Xbox XNA kit.  I’m not convinced it’s time to leave native code yet, at least not for internal, technical systems.  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.

• What are your thoughts on developers using in-house game engines versus off the shelf game engines (like the quake engine)?

The companies I’ve worked for have used a mix of internal and licensed engines.  Because I enjoy the technical more than gameplay side, I am biased in my opinion.  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.  In those cases, I think the better decision is often to fit your game within the existing framework rather than try to make modifications.

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.  With licensed technology, you typically have to pay tens to hundreds of thousands of dollars, per product and per platform.  If you develop technology yourself, you accumulate the technology over time and own it.  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.

• Do you think the growing team sizes and budgets for games is good for the industry?

I will admit I don’t like big teams.  Small teams are fun and productive.  Team members communicate quickly and efficiently, there is a level of accountability in small teams since everyone knows what everyone else is doing.  There is more variety in work because people don’t just specialize in one area for the duration.  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.  The risks of a project going bad are greatly increased as well.  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%.  Thinking that efficiency can ever reach 90% or so is pretty much impossible.  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.  In the end, the larger team may be more successful, IF the project is finished and is accepted by the market.  That army of unhappy people just may produce a game who’s commercial success recovers its costs and then some.  Think of the risk though, and the rate of cash burn on big projects.  So to re-answer the question, good? No, inevitable? Yes.

• What would be your perfect project to work on?

I enjoy research, solving interesting problems, and more the technical side of games.  However, the most important thing for me is to work on a game that I actually want to play.  This should be the norm for our whole industry, but it is not.  I’d like to work on a small team, with complimentary skilled people, who have good attitudes and love games.  Is that too much to ask for?