On the state of the games industry…

[Guest]

Hey guys, I've been working within the industry for about 7 months now and I thought I'd impart a bit of wisdom which may/may not help you with designing your next big thing or working professionally as a games developer. This covers a range of stuff from games industry predictions to design practices to professional etiquette. Also this is written mainly from my persepctive, so may not apply to some of you in other parts of the world. I'll update this with more points when I can.

1\. You better love microtransactions.

>! The first thing I want to talk about is the elephant in the room, in game purchases. Most of you hate them (I know I do). We are fast approaching an era of game design based on the idea of "freemium" content. Want that gun that looked awesome in the trailer? Well it will cost ya! Want to let your plants grow quicker in that facebook game you love? Pony up the dollars! Whilst the games themselves throw these payment plans at you, behind the scenes nothing is quite as corporate and sinister as it seems. The concencus is that developers of the games have most but not all of the creative control of development and that usually means they can be leant on by publishers to "include ways to make us more money". However, its not just corporate assholes that cause this type of game design. Making money is a beneficial thing to the developers careers as publishers will return as happy clients for future projects. Imagine, if you will, you were creating a game for Konami. You produce a kickass character action game with some of the greatest combat in a game ever. However, only a few people go out and buy the game. Unlike popular perception, devs dont really make a penny on game profits (they only get payed to develop the game) so rely on more and more projects to keep a roof over their heads. The publisher, whom in this case would be slightly worried, ponies out all the cash. To circumvent the possibility of poor sales, microtransactions are introduced to allow more money to flow out of a title from the crazy fanboys who can't get enough.
>! Games these days are incredibly expensive to produce, and they are getting more expensive with newer technology. Games need more assets, higher qualified (and more expensive staff) to produce those assets and more time to string the assets all together in longer more sophisticated testing procedures (EA uses a big rack of xboxes with testing procedures coded in, for instance). All of this pales in comparison to probably the worst expense of them all, advertising. Did you know that if a game did not advertise, it would probably cost about $5-6 in stores. Imagine how much money has to be spent on promoting a trailer at E3 or providing gameplay in industry interviews (yes, interviews to the press are a form of advertising too). Now do you understand why its so difficult to be a successful indie?
>! So what can we expect? More and more micropayments, thats what. From a business standpoint the next logical step is to start including pay-for-updates where bug fixes are purchased to improve the quality of a game without additional content. I can hear you screaming in your seat, but this is definately all legal. When you buy into an app purchase, for instance, you are agreeing to what you purchase as being adequate for the price you are paying. Bug fixes cost money to create, modify the content you already have and improve the overall game. Most importantly they can be opted into and out of so as long as companies dont force payed updates onto a player, this is all legally fine.

2\. Digital rights management for everyone!

>! Recently there was a huge issue related to the protection of copyright by enforcing a strict DRM policy. Sim City was probably the biggest DRM backlash in gaming history and put into gamers minds a very clear anti-DRM mindset. DRM, whilst sounding very menacing and evil, is actually a very morally right approach to content management. The purpose of DRM is stop stop digital thievery and assumes that gamers support the games industry and buy games instead of pirating them. Pretty straightforward. Basically, if you buy the game, it never applies to you. As a game developer, lets say you spent three years working on a game that you are very proud of and it gets published on steam. One week later it crops up on thepiratebay for free and all of that time, effort and money you sacrificed was pretty much pointless. Now lets say you were a publisher and you had invested hundreds of millions of dollars into this game. I think you can see where I'm heading with this. DRM gives developers the ability to stop people who never bought the game from playing the game. Simple.
>! The biggest issue with DRM, especially in games for a wider audience, is how it is implemented. So far as we know the only way to effectively control it is through a network connection to a controlled server. The server checks that the game is genuine constantly or through scheduled required checks (see Xbox DRM backtrack which needed you to log-on once a day). With Sim City, that meant a persistant network connection was required. But what if you don't have any internet? We could argue that the idea of server controlled game access is very much publishers restricting their games market. On the other hand, with the outset of better and more accurate internet connections it is becoming more and more feasible to embed it within games. Just think about the last time you didnt have any connection to the internet (hint: you're on it right now). This subject is very tightly linked with used games policies in that by controlling pirated games you are thereby resticting the usage of reusable content through game access keys etc.
>! As well as how its implemented, as game developers we need to understand the ethical implications of doing it wrong. On the extreme spectrum, Imagine you make a game and you dont allow anyone to play it? They payed the money for the content advertised, and you could be in for a massive legal battle for not providing it. Just look at what happened when Colonial Marines hit and people didnt get exactly what they thought they were getting. Applying third party control over game access is very iffy territory because you are interfering with a players purchase. You need to ask yourself whether you have the right to do that.
>! One of the ways companies have been able to get around heavily enforced DRM is through the afformentioned microtransactions and "freemium" content route. In essence, you have the right to the purchases you have made by way of registration (usually under the guise of socially connected accounts) and nobody else can duplicate that. You can copy the game as much as you want because the money generated from it is not obtained through actual software sales.
>! This, like microtransactions, will feature heavily within future generations of games as the world becomes more and more connected. We managed to dodge it in this generation of consoles, but it's coming folks.

3\. Love the work.

>! How many times have you heard the phrase "You have to enjoy making games to be a good developer." For this point I'm going to explain why this phrase exists, and its not for the obvious reasons you think it is. The general consensus of "Enjoying making games." is that its necessary to promote creativity, community and enthusiasm for what you are doing. Whilst all of these are important aspects of why you have to enjoy your job, this same phrase could in essence be applied to any career choice. There are some very different reasons as to why you have to enjoy specifically a career in games.
>! 1\. It affects you.
>! The hours can be murderous. In a normal game development cycle the ending period, or "Crunch time" of development is stooped in heavy double shifts, sleepless nights and ridiculous hours. Sometimes these extra hours can be unpaid (especially for indies) and simply 'expected' from a developer. So why put up with it if you might not even get paid? Reputation, that's why. During crunch time, the culmination of a very long software journey comes to a head, usually accompanied by stringent testing cycles and last minute additions to the game (sometimes ridiculous additions depending on the client). In order to protect the reputation of the company and get everything finished to deadlines, everyone has to work to the bone. If the software is late, jobs could be at risk… its that simple. If you don't at least tolerate the job, it's easy to get sidetracked (youtube anyone?) and frustrated. Even if you hate the job, you'll have to put up with the crunch period just because the game took a very long time to make and crunch is the last hurdle. But after suffering crunch once, would you be willing to tackle it again?
>! 2\. It affects the games you make.
>! The games industry is fast. Very fast. What the rules of play are one minute, the rules the next minute could be completely different. In a real world example, lets say a company decided to switch to a different game engine. Programmers, artists, level designers and pretty much everyone would have to adapt to this new engine speedily in order to stick to contractual obligations. If you don't enjoy working on games, you are by nature less interested in the small details of development and it can affect your final project negatively. Using the example case, maybe you were tasked to figure out the lighting worked for the engine GUI, figured out what you were asked but missed some key about light-maps that would later on be too late to implement
>! 3\. It affects the industry.
>! If you don't love game development you are technically stagnating the industry just by working in it. Everyone who's anyone in game design courses around the world are prying for a chance to slot into an industry with very few job openings. By taking a job, somebody else (who may be more interested in games) does not have that opportunity. Over time, the industry declines. Firstly through poor game releases (as seen in 2) which affect sales and lower the budget allotted for future games. Finally the industry declined due to unhappy workers (as seen in 1) reducing enthusiasm for prospective developers to enter the industry.
>! And that, dear friends is why you have to love making games to be good at making games.

4\. Its not about you.

>! What this section tries to explain is that a games career is not something that will make you famous unless you do something remarkable or unique. The most recent project I worked on is an app called Puzzler World contracted with a puzzling company in the UK called Puzzler. You can go and check it out if you want to follow my example here (the icon is a sun on ios and android). The first thing you'll notice is that the name of the company I work for (Finblade) is not mentioned within the app page itself, more interesting still is that to find the developers names you have to go into the about page and scroll down a considerable amount of text to find a "with thanks to our developers" section. This is after all of the presidents/CEOs etc of Puzzler themselves. I am incredibly proud of the project, however and have found oftenplace the reward is more people playing the game than understanding who is responsible for it.
>! Probably the most interesting part of game development, form my perspective as a programmer, is that a lot of the time you barely have any creative control over the game at all. When you go to work designers are busy throwing out design documents with every possible detail of the future title already set in stone. As a coder, or an artist we have very little say on what that design document contains. We can provide professional commentary on what is/is not possible with the system expected but we cannot alter the main format of the game in any way. Sometimes even designers have very little creative freedom if the game is contracted with another company (especially sequels and the like). This brings into stark contrast what everyone expects is a "do as you like" career.  So as you see, becoming famous in this career pretty much becomes near impossible unless you are a game designer. This explains why designing games is the most saught after job in the industry (even if its the least payed). The best example I can give for a coder saving a designed game is Spider-Man 2 for the PS2\. One of the coders (I can't remember his name, see what I mean) spent days and nights straight trying to perfect the web slinging of our acrobatic protagonist. Some of the work ate up a considerable amount of his own personal time, but he wanted it to be perfect. When the game came out and it was the most respected part of the gameplay, nobody even gave him an interview because they expected this was a designers work coming to fruition.
>!  
>! **Addition from Marsh:**
>! I have been in the industry about 6 months now so generally the same timeline as you. This document rings incredibly true. Though of course some of it depends where you work. I am at a indie company and as a programmer I get a great deal of say in what goes on in the game. I do not have the final word but we are welcome to give are opinions suggest features and argue why we dont want something in the game. Of course this is more the indie aspect where its all our game so everyone has a say. I imagine a lot of companies are not like this.
>! Games are made in between a few people in a team to hundreds of people in multiple teams. Whilst your contribution to a project may be substantial (say you developed the code that controlled an in game weather system) there are a lot of other people whom have provided just as much work and effort to the game as you. Shared credit is the responsibility of every game developer, even if it only makes you a name on a list in the credits. That's nothing to be sad about, though. A friend of mine left university and went to work for Rockstar as a localisation tester, the look of sheer joy on his face when he saw his name in the credits for GTA 5 is something I hope all of you someday learn to appreciate. Facebook photos inbound of just your name in a list of hundreds has never been so satisfying. At the end of the day, games are about the players and enjoying making games that players which will someday play. My heart goes out to the developers that work on projects which are scrapped.

5\. There's no bug-free games.

>! One of the primary sections of a software development life cycle is the testing stage. For this point I will talk about mainly black box testing. In black box testing it is the job of the testers to play the game in unusual ways to determine errors in interaction and response. In other words, imagine a tester has access to the game input, the process of that input is inside a big black box which he cant see into but if the output of the game doesnt match what the tester expects then there is obviously a bug somewhere. In the testing stage, usually using some kind of test log software (like etraxis) the tester places these incorrect outputs into a list of known bugs that need to be fixing. There are two main concerns that are problematic with testing, which I'll explain now.
>! Firstly, we cannot test for the absence of bugs only their presence. Using that logic we can assume that just because we haven't found any bugs it doesn't mean there aren't any there. In a game as big as say Skyrim, this presents a particular problem because the likelihood of the overall game community in finding a new bug is highly possible. The more possibilities there are in a game, the more possible routes code can take and the more things that can go wrong. To simplify, lets say we have a game based around pressing numbers on a calculator and a bug which only happens in a certain sequence of numbers (say 1543) being pressed. The likelihood of 5 testers finding this (with a maximum number of a million, say) are astronomically slim. Factor in 10 million players and you have a genuine issue on your hands. This bug may also cause other bugs and more substantial issues in the game itself. For skyrim, there are so many possible ways to play and paths to take its reasonable that perhaps one quest doesn't complete when it should. The ramifications could be that the quest is always stuck in your quest log or perhaps that quest was required to earn an achievement or trophy. Maybe it was even the last part of a major storyline. You can see where i'm heading with this. With games becoming ever more complex, with more assets and more player options it is becoming more likely that developers are missing bugs. This might also explain why so much of game features these days are very much "baby-fed" to a player so that the output can be more accurately controlled. Free-running in Assassin's Creed, for instance, doesn't require much skill to jump from one platform to another; you simply press a button and direction and let the game code handle the distance, angle, etc.
>! Secondly, with bugs, different platforms have different software requirements. If I was to use Android and iOS analogy here, it is much easier to develop a game solely for iOS than it is solely for android. iOS products are architecturally identical so it is much easier to predict a game working on a user device if it has been tested using the same device. There are so many types of Android phone that what may work on one may not work on another. Perhaps one device has a different sound codec than what the game uses, so there isn't any sound or perhaps the device simply doesn't have enough power to run the game. These are all things that complicate the testing procedure. This analogy can be linked very directly with the PC and console game markets. The reason consoles are so well preferred by developers are because all of the consoles are the same, in contrast to PC's which can have very contrasting specs.
>! There is much more to be said on the topic of testing, the effect changing requirements on duration and also white box testing techniques for instance. For this topic I think the above gives you a fairly transparent idea of some issues regarding testing and why we find ever increasing amounts of bugs in games.

6\. Games should be future-proof.

>! When developing a game, an important aspect of a game schedule is documentation. There are varying levels of documentation which can be included into a game for different parties of people. The idea of documentation it to provide textual help to someone who's going to be using the software. For a player it might be an FAQ, whilst to other programmers it might be the design document or comments within the code. For this point I'm going to talk about the latter and why it's important to document the software in order for it to be used later on by other parties.
>! In games where there is an intellectual property involved (say Batman) it might not always be possible for a games team to produce sequels. Perhaps the previous game sold less than what the publisher wanted or perhaps the team is working on a different game at the time. In any case, odds are that at some point you're going to have to hand the source code of the game over to another team so they can use it to manufacture a sequel (or similar game). In recent memory this can be seen as the latest in the Arkham series, Arkham Origins. It plays just like it's predecessor, but its a separate team. Behind the scenes, Rocksteady have given the source code for Arkham City over to the new developers. This exchange would have required some form of guide as to how to develop future titles using that source. Likely in a game as big as this one, there were probably some physical meetings with the old team just to make sure everyone was on the same page (there are reputations at stake).
>! The implications this has on design is pretty dependent on the importance of the IP and the likelihood of the game finding its way into other hands. For the Uncharted series, for instance, there was probably very little in the way of future proofing to a new team. One thing to take note of here is that new staff may actually replace old staff in the same team, so it's very much dependent on the likelihood of not just the same company, but the same people. In any case when developing your games you'll probably come across this from time to time. Even though your game hasn't yet been released, there's nothing wrong with preparing for the next one. That's all this pretty much is, preparation and understanding. All you need to remember is that documentation can take on many forms and you should be prepared for varying levels of extremity with it.

7\. Clients are all the bread and butters.

>! For this section I want to go into more details of how clients work and what is expected from a client based project. I'll try not to bog everyone down with the overwhelming negatives, but this isn't a rainbows and unicorns section. The reason this section is here is, apart from all the stuff I've mentioned in the above, I don't believe I've stressed the importance of client based development enough.  We're talking something that is probably more common than developers actually working on their own IPs and you guys should probably be apprised of what to expect from a business client.
>! In the games industry you have two different types of clients, the good ones and the horrendous ones. There are varying levels in between but for now we'll just stick to the two. The first thing you need to remember with clients is they usually don't have a clue how games are built (even the ones who's jobs are to be a client for games development). Its common to see inexperienced games clients expecting something that is virtually impossible or infeasible based on resources at the studios disposal.
>! For the horrendous side, I recently heard about a client who wanted fully 60fps 3D high definition characters on a 2009 Blackberry device and then be angry (and cite contractual obligations) when the studio said "You want… what?". The same client then had the studio work for months on a feature to turn around and say "Wait, I actually don't want that." You can't imagine the stress of working on a complex feature for a long time and then not even see it in the final iteration of the software. One thing you may have caught wind of in general blogs/memes is the communications issues between clients and studios. Sometimes expected functionality is difficult to express and game features turn out not quite as the client wanted. Sometimes the client likely doesn't know what they want and expect the studio to use their expertise to fill-in-the-gaps (I could go into a whole area of software life cycle methodologies built just to get around these two issues). The point I'm trying to make is that if you get a bad client, the odds are you are going to have a very long arduous development most likely full of stressful situations.
>! Sometimes though, you get a good client. A good client, I can say, is someone who does all of what I mentioned above but less frequently. However, good  (usually more experienced) clients can sometimes have their own little things that make them difficult to deal with which you guys should look out for. Normallythey have a better handle on the requirements/delivery side of things and can point out when you are not following the miniscule design document sentences to the letter (design documents for apps can be upwards of 90 pages). This can be because of development impracticalities or just simple human error... whatever the reason, these guys pick it up quick. Another thing you usually find with these particular clients is a small amount of talking-down to the studio. By this I mean speaking fancy tech speak to explain what they want and telling the studio devs to implement things in a particular way. Honestly though, most of the time it's just more funny than anything, with the majority of the technogarble making little sense at all, earning the reply "What the...?".
>! Like I said at the start of this section, clients are generally the bread and butter of development and getting a "bad client" is something all of you will have to deal with in the industry and eventually learn to have the patience for. A perfect client is something we can dream about, but it's never going to happen.

8\. Job Hunting

>! How does a developer find their way into the industry. I can't speak for every company in this regard as every business has its own practices and proven methods of finding good recruits. I can however point you in a solid direction on what you might be facing and how to improve your chances career-wise.
>! In topic #3 I talk about why it's important to love working in the games industry. This is something that studios look at very closely to determine how motivated you are about games. My recommendation on how to demonstrate this is through a portfolio and extra curriculum activities. First of all, an on-line portfolio with source code and playable games that you have produced in the past will give the company something tangible to look at. Secondly, doing stuff outside of education shows a commitment to making games as a hobby and people who make games in their free time usually know more about making games through self-learning. In particular, if you've created a game that will run on a mobile device (maybe you've made a small android app or something) taking that device into an interview and saying "I did this and it's had 1000 downloads" is a very strong argument for you being employed.  In games jobs, the most important thing to get into your heads is that its usually more about what you can show than what you can prove. If you have a college degree then that's fine, but you could well lose out to a teenager with a portfolio that better meets a companies expectations.
>! But how do you get an interview? When starting out you cant be picky with the company you want to work for. Sometimes, like myself, you end up in the perfect job just by not looking too far up the ladder immediately (the smaller jobs are the jobs standing in your way that give you the experience you need for the big ones). I went with a recruitment agency that specializes in game jobs and the first thing they asked me is if I was willing to relocate. You have to be able to make this sacrifice if you want to build your career. If you are fortunate enough to live in the same town as game studios, good for you, but a lot of the time you have to bite the bullet. Additionally,don't be afraid to fall into a market you don't know much about (like apps). If you're applying for a junior role, you'll be trained up fully. After the initial application phase you might be invited to preliminary interviews or other manner of assessment days (I had to sit an online exam) which basically measure your skill level in comparison to other applicants. Then, if you are successful, you'll get an interview.
>! In terms of what a company expects from a recruit, that entirely depends on the company and the role. If, for instance, you were looking at a senior 3D modelling job worth 70k upwards per year they may have different expectations on your professionalism and how much experience you need. The thing you should look out for is contractual strangeness. this does not apply to all studios, but I'm aware of some contracts with bigger name publishers (this also happened to me at IBM in fact) which require singular dedication to the companies benefit. Basically if you do stuff in your spare time, it belongs to the company. You sign away your creativity for the tenure of your employment. That may be something you want to ask the employer in any interview you have. Keep a look out for anything that shouts "im taking advantage of you".
>! Just as an extra note speaking of asking questions, don't be afraid to. I'm trying not to go into general interview etiquette here, but you are going in measuring up the company just as much as they are measuring up you. If something doesn't sound right to you, or you'd like to know something, don't hesitate to ask any questions. Some companies actually prefer it if you do, because it shows clear interest in their business. I know a guy I went to university with who didn't get a job with Criterion solely on the fact he didn't have any questions to ask.
>! Good luck.

Questions and Answers

Question:

> What languages did your company expect you to know, how much exp did they want you to have? Did they care if you went to Uni? How is it like working with other devs? Do you get advice from people you work with or are they entry level(jr) developers like you?

Answer:

>! I myself applied for a programming job and that role required a certain amount of, well programming proof. The company itself wasn't going to hire someone they knew wouldn't be able to adapt so they went out of their way to make sure I could. The exam for the job I spoke about in the previous question was a programming test where the questions were mainly theoretical. The point of it was to make sure you could read code and then explain what that code does. It wasn't so much as a "Write in this language blah blah…" as it was a "Here is some code written in a non-specific language, write what you think it does" or "Given this set of rules, write a function which does this...".
>! So far as games experience I basically had none. However, I did work a years placement at IBM as part of my university course which may have influenced their decisions. Having that year on my resume showed that I was willing to put myself out there and gain the experience that I needed for the jobs that I wanted.
>! They don't so much care that you've gone to university so much as they care that you are capable of adapting to a professional development environment. Much of the theory you learn about in university is very useful in your job so it likely affects how deeply the company looks at your capabilities. If for instance, you don't have a university degree, they'll spend more time looking at your portfolio and any source code you have written for any projects you have done. Its more about what you can show them than anything else.
>! Most companies implement source control systems (for work control) and are a quite welcoming bunch of people. You learn very quickly that game dev is about communicating ideas and solutions with these people. Sure it can be overwhelming at first, but you should slot in fairly quickly. In terms of difficulty, this isn't something you should worry about.
>! I work in quite a small team (11 people) and 3 of us are new guys. 3 of the guys are experienced coders. I try not to think of it in terms of supervisory and having like a corporate ladder structure. You get pretty close with all the members of the team in a situation like mine and when you need help, the experienced guys are usually happy to give it. On my first day my technical director gave me a £10 amazon voucher for a javascript manual, for example. However, just as much time you work you are being approached by these same guys with questions about your code (how to use it, what it does etc). Nobody knows your code like you, and there's a certain amount of responsibility (and pride) you should be aware of with that. Sure, you'll make mistakes, but that's how you learn.

[Vus]

Very nice article, I like it :)

[Guest]

Part 2 up.

[Matt]

Moar!

[Guest]

Part 3 is up.

[Orbegon]

I like it! Good work!  :D

[Guest]

Part 4 up.

[Richy420Rich]

Nice, informative. I like it Sporky. Thanks. :)

[SkywardRiver]

Good read

[Vus]

Especially enjoyed the last part, great work spork! :)

[Guest]

part 5 and 6 up

[Sn0w Beast]

Good Job Spork!

[Marsh]

I did not read the entire thing just went over the sections I found interesting.

I have been in the industry about 6 months now so generally the same timeline as you. This document rings incredibly true. Though of course some of it depends where you work. I am at a indie company and as a programmer I get a great deal of say in what goes on in the game. I do not have the final word but we are welcome to give are opinions suggest features and argue why we dont want something in the game. Of course this is more the indie aspect where its all our game so everyone has a say. I imagine a lot of companies are not like this.

Either way, definitely a good look into the industry. Will be cool to see where we both are a year for now and compare experiences :)

I do not know if you made the builds yourself but you should write a section on the App Store experience. Submitting builds to apple and working there plethora of in app purchases, rules, banking information tax etc is a nightmare. Its good to know what your up against so you can understand its hard and to persevere through it. It can definitely be a bit disheartening to have your app rejected (Almost always happens your first time). Though once your app is out it seems to get accepted a lot faster and without issue.

[Orbegon]

Very useful information!

[Guest]

Hey part 7

[Link]

I appreciate this post. Gives any of us who hope to jump into the field some insight. I'm interested to know though. How did you and Marsh go about getting into your companies? Did you have to bring something to the table? Also how did you find them? I just want to know what their expectations were.

[Guest]

Good questions, I'll write up some career advice in part 8 to tell you what companies actually expect. Expect it in about an hour or so.

[Guest]

Double-post means part 8 is up.

[Kusy]

tl;dr

Flappy Bird just made another 50 000 bucks.

[Sn0w Beast]

lmao

why do people even like flappy bird -_-

[Kusy]

There's also one thing. Don't take a QA job expecting to become a game developer. It doesn't work that way and QA is a pretty horrible job.

[Guest]

I added marsh's point about creative control into pt 4.

[Link]

What languages did your company expect you to know, how much exp did they want you to have? Did they care if you went to Uni? How is it like working with other devs? Do you get advice from people you work with or are they entry level(jr) developers like you?

[Guest]

Added a new Q&A section if you guys have any questions about this stuff. Included Dr.Kid's questions and replied to them as best I could.

[Richy420Rich]

> lmao
>
> why do people even like flappy bird -_-

Simple, supply and demand. The mobile market is on the boom, so a F2P as simple as it is, got popular.