Game Resales and Project $10

I’m slowly bouncing back from a period of incredibly hard work, followed by a complete disconnect and resting period. I should hopefully be back to posting regularly again now that the game has gone gold and we’re moving on to the next project. I still have some emails in my backlog of things to reply to — if you’ve been waiting for an answer, I’m sorry about the delay.

Anyway, retailers have spoken out against the so called “Project $10″, saying it will cause consumer rage:

“The person you’re pissing off the most is the consumer,” McCabe told GamesIndustry.biz. “This affects [them] directly – they pay the same amount of money and yet the resale value is much reduced. From a retailer’s point of view, they’ll just readjust [the price] bearing in mind you have to buy the voucher.”

This is an interesting development. For those who aren’t familiar with the concept, the $10 project essentially puts a code in the box to unlock additional content online for the game. The code can only be used once, which means that buying the game new has additional value over buying the game used.

Consumers who buy a used copy can still choose to buy the online content, but for a fee (one would imagine $10, considering the name of the “project”, but I think it’s actually $15 for the current titles). It’s been done with a few recent games including Mass Effect 2 this far (awesome game by the way, I’ve been having a blast with it), and will be done for future titles, including Battlefield: Bad Company 2.

“EA’s project $10 move is aiming to stifle pre owned games sales, but what they don’t factor in is the damage this could have for them in relation to new sales,” said Day.

Wow, what a complete misunderstanding. This has nothing to do with publishers wanting to stop resales — it’s simply a business model where publishers can earn some money off of resales.

There are interesting parallels to be drawn for me, between the console and PC markets. Pre-owned games pose much of the same problem on the console market as piracy does on the PC market. The end result of both is the same: people play our games without a single bit of money ending up with the people who made the game. In the worst case, we end up paying a lot of money to keep servers online, while getting no money at all from the sale.

There has been a lot of whining from publishers and developers about both issues. Those of you who know my stance on piracy should not be very surprised that my stance on pre-owned games is very similar. Whining about it or blaming people for it is not going to help — yet you cannot deny that the fenomenon in itself is causing major problems for publishers and developers (just as piracy is) — there is no getting around that.

However, trying to “clamp down” on used games sales or piracy is pointless. Piracy is illegal, but unenforcably so which means that it doesn’t really matter. Resale is simply a business choice. While you might think that it is a bad business choice and that retailers would be better off long-term by staying clear of business practices that will kill their providers, they are making a ton of money short-term. There is no way they wouldn’t fall for that temptation, and in the end, any business choice that works for them is a valid one. Whining or arguing about it isn’t going to help.

This causes an interesting problem for publishers. One way would be to move to direct online sales only, but this excludes large chunks of consumers who can’t download large games or who aren’t connected at all. Another version would be to require online activation and to bind the game to a certain console or live/psn account, which simply wouldn’t be fair to the consumer and would cause a never-ending stream of problems and well-earned gamer hatred.

The middle ground, then, is to sell a full game to people through retail, but to provide extra value with unlockable content to people who buy the product new. It should come as no surprise that retailers dislike this — it will certainly cut a chunk of profitability out of the resale market. It will lower the value of a game for resale, which means it’ll be worth less to trade in. Will this annoy some customers? I’m sure it will.

Many people seem to be taking this as the publisher wanting to be paid twice, which I think comes back as the default gamer response to anything developers or publishers do to earn money being horrible and bad. It sometimes gets to me to see this kind of attitude with gamers. We can’t make games as a charity, and making these games on bleeding edge tech is extremely hard work, and the people in the industry are incredibly dedicated to their art.

The other side of things is that buying the game used will be cheaper, creating a much better “try before you buy” environment, where you can potentially buy the game used and try it. If you like it, you can buy the DLC that you would’ve got from the new version. This is sort of a win-win situation for the publisher and the consumer, but of course not that great for retailers.

To publishers, this is the option that provides the best value to consumers while moving to a new business model that allows us to actually start making proper money from games again, which could halt the current trend of studios closing and developers being fired.

I’m sorry if that takes money out of retailers pockets, but I really do think that the talented people who sweat blood making these games deserve the money more than people who only know how to push people to buy used instead of new. It may have been a good dream for you, but it was still a dream and now it’s time to wake up.

And yeah, retailers claiming to stand up for the consumer is nothing new. But just as with music labels claiming to speak for artists, they are simply middle men that are slowly losing their value.

What’s a Good Final Year Project?

Here’s a question from the mailbag, coming from a student doing games programming at a university, gearing up for his final-year project:

The degree I’m doing currently has been very much centered around graphical programming, aswell as using various programming languages to bolster our CV’s I would imagine. We’ve not really touched on networking, or AI at all. Our main language in graphical programming has been OpenGL too, we’ve dabbled with DirectX a little, mostly managed directX with XNA.

As a programmer already in the industry, could you give me any advice on the type, and level of project I should aim for, for it to be a suitable demo project to show to prospective employers? It’s difficult enough as students to find our way into the games industry; if we don’t know what employers want, or what is considered worthy in the eyes of the employer, it lowers our odds tenfold.

In a way, the answer to the question depends on what kind of position you’re trying for. I’ll try to answer with regards to as many positions as I know.

For starters, is graphics programming what you want to be doing? If it is, things like what graphics APIs you know become a lot more important. From what I know, most games studios that do windows game development have gravitated towards DirectX. With that in mind, having done a large(ish) project on DirectX could definitely be a plus. If all other things are equal, I’d definitely go for learning DirectX.

Not having experience with networking or AI isn’t all that much of an issue, unless you imagine going specifically for a networking or AI programming position (and even then, it’s more of a bonus than a requirement). One thing is clear however… if you’re looking to get into professional development at a large studio, you should be going for C++.

Now if we look past the technical requirements, there are a few things that can be said about such a project in itself. What you get from a good project is a nice entry into your demo reel — something to show off. This has a few implications, but most importantly something I’ve touched on before, in A Spectacular Failure: your project is going to be judged on emotional first impressions, not how technologically advanced it is or how nicely coded it is.

Your number one enemy is over-scoping the project, ending up with something that does lots of things, but does none of them in a great way. Come up with a good core gameplay for the game, and then polish it to a great shine. Fix all those annoying glitches and bugs, make sure everything looks as impressive as possible. It doesn’t need to be rocket science, as long as it’s well executed. In the end, what a games studio is looking for is a programmer who knows how to finish projects in a good way.

That doesn’t mean your project should be Space Invaders, but in general trying for something too big is more of a problem than overdoing something too small.

Finally, as an entry on your demo reel, make sure you make the game available in an easy manner. Have a page with plenty of screen shots, videos and preferably the game itself easily downloadable. Your coding ability will definitely be tested with some form of work sample as you apply to studios, so the code itself being available is less important. Reading code is hard, so it’s unlikely that someone will have time to read yours. However, having a finished game to show off is worth a lot, as is the experience of going through all the phases in finishing a game.

Other posts you may find interesting, relating to getting into the games industry and getting started with games:

• Getting Into Games
• An Exceptionally Stupid Idea
• Let’s Make a Game Engine

Getting Into Games — A Follow-up

My post from a week or so ago about the differences between working as a software engineer in a games studio and in other places generated a fair number of interesting comments and questions, both here and at various syndication sites. In this post I will try to answer and comment on the most common and interesting ones.

Working at a Games Studio

Getting started with something I intentionally left out:

Low pay. Good luck trying to buy a house.

There’s a well known discrepancy between salary in your average programming gig and your average games programming gig. I left it out of the original post because of two factors:

1. The difference is highly overstated. Salary varies much more within each class of work than between the two. While it is true I could probably get more money by switching to another job, the same is true for many others, and the difference wouldn’t be worth it to me.
2. It’s your choice. I expect you to make a well-informed choice on taking any job when it comes to what you get paid. Don’t just take any job because someone told you you get paid a lot in a certain business — make sure you get what you’re worth.

A second issue from the same commenter (and several others):

Yes, you have to come to work on Saturday and Sunday.

This is an issue in the industry, and I’ve seen pretty bad cases of it. Since I started coding games, the working conditions have improved by far though — and this doesn’t only seem to be my situation but applies to many others I’ve spoken to at other studios (mainly within EA though — would be happy to hear the perspective of other people). At the moment, from where I’m sitting, things are looking pretty good.

I’m not saying crunches don’t happen, I’m just saying they’re reasonably few, have a good purpose and focused time span, and include a time off compensation after the deadline has been passed.

The most problematic part of this is that it’s extremely hard to figure out if this applies to any given studio without actually working there or knowing someone who does.

I wouldn’t want to be the guy working on the next Madden game

Well, I actually know the guy working on the next Madden game and he is incredibly dedicated and seemed to love what he was working with last time I saw him. About the comment, he told me “Well we don’t want that guy anyway,” which is very true — the reason there is a Madden game every year is because there are lots of people interested in a new Madden game every year, and among that crowd there will certainly be people who are interested enough to want to work on the game.

It’s funny, because I sometimes hear the exact opposite of this comment at work. “It’d be so awesome to work on an iterative title where you just got to improve things and do all those cool changes that we have to cut”. Working on Madden is a pretty sweet place to be if you love sports games.

People sometimes seem to think that innovation only means new game franchise. There are lots of interesting developments and innovations within franchises, even within a “plain old sequel”, and working on one of those titles avoids one of the great drawbacks of the games industry: half the time you’re semi-panicking because your game engine isn’t in a shippable state and there’s a whole game team trying to use it to create a game.

That way, working on Battlefield: Bad Company 2 is nicer than working with the first game: the same chance for innovation, but less problems with others not being able to innovate due to the state of the code.

Getting started

A question that keeps popping up is any version on this:

I’m a frustrated web developer who’s always wanted to make the move into game development, but have yet to find the time to train myself and start shifting my skills over.

Any tips for someone looking to start out in that direction?

I’ve touched on this subject before, in An Exceptionally Stupid Idea, which tells the story of what I did. That post may be best applicable if you’re still in college, but there is a certain truth to it regardless of where you are. Time is money however, and with anything in life  you’ll need to do investments… so seeing where you could free up time is a first step.

What do do with the time once you have it? Well, the games industry is looking for a few things:

• Skilled programmers
• … who know the language
• … and with some experience of games

The third is actually somewhat optional, though most recruiters would never admit that. Becoming a good programmer is a hard topic to cover — more than half the stuff on this blog is already devoted to that, so I’m not going to comment further on that one.

Chances are slim you’ll be coding anything but C++ if you code games, so if you’re not already very familiar with the language, you should get familiar with it. It’s often said that good programmers learn new languages quickly, and to a certain extent I agree with this… but if the problem is complicated enough, you need to be a language expert.

Finally, getting some form of portfolio is good, even if it’s “just a side project”. That could also be a good project to use as practice if you’re not too familiar with the language. Further, it helps if you’re a gamer and stay on top of what’s going on in the industry.

This actually ties into another comment, which was the most compact piece of information:

C++

If you dislike C++, turn elsewhere. I personally think it’s an extremely capable language once you learn to harness it properly. It is dangerous without the safety equipment though, and sadly some of that equipment doesn’t work with games.

Other languages are starting to appear when it comes to games coding. I’ve heard examples of LUA, java and C# being used as scripting languages, and of course there’s UnrealScript. These can be extremely beneficial for iteration times and such, but the grunt of the software is still going to be C++.

Update: I should also mention another old post of mine about this: Let’s Make a Game Engine!

Games Programming

I tried to avoid getting into the details of hardware and the coding that goes with it in the previous post, since I love talking about these sort of things and I didn’t want it to become a rant but hey, you asked!

Console hardware (I’m looking at you, PS3) is made for pretty graphics demos, not simulation. If you work on the AI or physics, be prepared to focus your energy on low level optimisation and cache misses, because your AI code is never going to be any more sophisticated than a state machine.

Well… I’m the lead AI coder on Frostbite, and while there are lots of things to be said about the Frostbite AI, “no more sophisticated than a state machine” is not one of them. I agree, some things (especially physics queries) are expensive on the hardware, but that simply means you need to re-think how you do stuff.

SPU code is a vastly different beast from your average code. There are some bad programming habits that can completely destroy your code for SPUs… and among those bad habits are the ones that would lead you to get stuck on low-level optimizations. Once you learn how it works, there is an incredible amount of power in the PS3. I’d dare to say it’s still relatively untapped, and that as time passes we’ll see more sophisticated uses of it.

The limitations of console hardware is different. That doesn’t mean you can’t implement physics or AI, it just means maybe you’ve got to challenge your assumptions about how you implement physics and AI.

I guess the Parallelism approaches are a little different in both worlds. I bet you gamedev guys have been working with Data Parallelism for a while (i.e: programming the Playstation2 Vector units. I don’t think life is getting any easier on you guys with all those Cell SPEs to squeeze!).

In the enterprisey side, task parallelism is an emerging topic with languages like Erlang, Clojure and Haskell offering different abstractions for spreading computations over different hardware threads/cores.

The vectorization units of the PS2 are a quite limited way to do data-parallel work, so I disagree with you here — with the SPUs on the PS3, it actually is easier, because it’s less limited in what you can do with them. Vectorization units and other primitive forms of data-parallelism often work in lockstep, whereas the PS3 actually has a bunch of individual, highly capable although slightly quirky processors.

Games are full of data-parallelisable problems as well. Rendering is the classic example — the reason GPUs have been such a hot development the last few years is that rendering lends itself so well to parallelism. But there are many other things as well — the aforementioned AI is ideal in some ways, as it tends to be made up of lots of separate processes for different actors or entities.

Task parallelism is also something that can be utilized to a great degree in games since there are simply so many orthogonal tasks to complete. Update the UI, do physics simulations, calculate character skinning, play audio… I can’t go into details on that, but we do a whole lot of it in Frostbite. Sadly, you do end up needing to care about many of the details that using an abstracted language would let you ignore though.

Still, it’s one of the most exciting aspects of coding for me, since games are one of those applications that can actually use all the power of parallel computers.

Making Games

I hear from programmers every now and then who are considering trying to get into the games industry. Our projects are strange beasts that are similar to other software projects in some ways, yet vastly different in other ways. Still, if you look at it from outside, most of these differences will be hard to spot.

With this post, I will try to list what I see as the biggest differences between working on a game and working on a different kind of software project. If you have any questions related to it, please post them as comments and I’ll do a follow-up round.

The Passion and Dedication

It sounds like a cliché, but games are made by mostly gamers. In all the teams I’ve worked with spanning maybe a hundred, there’s only a few people that aren’t absolutely passionate about games, and completely dedicated to making kick-ass entertainment.

The enterprise coders I’ve worked with pretty much fall into two categories: the day job coders who don’t care much and the hackers that appreciate technical challenges. As you move into games, not only does just about everyone fall into the second category, but nearly everyone is also excited about the games themselves, regardless of the technical challenges involved.

If you’re looking for a place to work where your colleagues will be really cool, skilled people with a passion, then the games industry is where to look.

On a cynical note related to that, the abuse of this passion and dedication is what has given the games industry something of a bad reputation (and a well deserved one too). My impression is that working conditions have improved quite a lot across the board, even if there are still the occasional horror stories. If I were to give one piece of actual advice, it’d be to be rather thorough in your background checks on companies.

Creativity

Game developers live off creativity. Even the most simple churn-out-sequels factory will attract highly creative people, and studios will tend to cater to creativity to a much higher degree than most other software development companies.

If you’re highly creative, you will probably find it easy to fit in. My experience is that creative suggestions are almost universally appreciated regardless of source.

Cross-discipline, Bleeding Edge Development

Games teams are made up of a number of disciplines that vary depending on what type of game you’re making, but generally speaking you’ll at least have Designers, Graphical Artists, Animators, Sound Designers and Programmers. Our projects have Mission Designers, Environment Artists, Effects Designers and other disciplines as well.

In a way, this is no different than many other types projects where some end-users create some of the data for the system, but there is a major difference in the fact that the hardware platforms are either consoles or PCs with specs so high that they don’t even exist yet. The coders on the team will be creating a game framework, which is then populated with different kinds of content to produce the game.

The problem with this is that they’re using the software tools you’re building (like the editor and data processing pipeline) to create the game while you’re still trying to build the tools, only to run it in a game engine that is also not done yet.

It’s a bit like trying to produce a business application while part of your team is working on creating the source code editor you must use, and a different part of the team is building your compiler. In some magical way, the components must all mesh together so that not only are the tools done when it’s time to ship the product, but that content creators have time to do something useful with them as well.

This creates an extra layer of complexity to the projects that I haven’t seen anywhere else. Inter-discipline dependencies between disciplines that work in very different manners can cause common project management techniques for software development to break down, because most of the team isn’t developing software.

Performance Focus and Hardware Platforms

From a technical point of view, there is a heavy focus on code performance. This creates a different kind of environment, where some modern programming techniques are simply too expensive to use. It also means you tend to get good at optimizations after a while.

The hardware we run on is increasingly becoming paralell. Using all of the power in the PS3, for instance, requires a fairly well developed parallelism, forcing the shift from single-threaded to multi-threaded coding onto game programming long before most applications need to care all that much.

(Note that my view on the state of the industry is rather limited here. DICE is ahead with the Frostbite engine on current console tech, some other engines are hopelessly behind, but it’s always hard to tell what others have in development.)

The hardware platforms themselves can sometimes be immature and cause problems when you have to jump through hoops to get things working (simple example: graphics driver bugs).

The platforms themselves also impose other restrictions on your code, like the low memory cap of current generation consoles and extreme penalties for cache misses and branching.

Playing Games at Work (!)

I couldn’t leave that out, could I? Yes, we playtest our games at work. They’re a lot of fun, most of the time, so getting to play awesome games before anyone else is quite a perk. To be completely honest I must admit that there are times when it’s not much fun at all… but they are quite uncommon. And hey… you get to shoot your boss.

A Tour of the Games Studio

There’s a hole slew of misconceptions and weird comments that inevitably go around as soon as any large game studio announces a game, or releases a game, or… well, just about anything else. So with this post, I’d like to welcome you to a small sightseeing tour of how a games studio works, on the inside.

I hope to give you a chance to see how a games studio works — maybe it’ll create better understanding of what it is you’re saying when you chatter around forums about the latest greatest game from some studio, or maybe it even gives you valuable insight if you’re looking to get into the games industry.

The Myth of the A-Team and the B-Team

Somewhere in the DICE Office

As soon as a game announcement turns up, knowing fanboys will appear on all forums around, claiming grand things like “Wow, this sure is great. Now we know DICE has the A-team is working on this while the B-team was doing (other title here).” Substitute with “good team” and “bad team” or whatever you will.

The reality is not only that there isn’t any first or second-rate teams, but that the teams themselves don’t really exist as a concept. People move between teams constantly — some project doesn’t need any more audio work now, so the sound designers move over to the next one. Meanwhile, the programmers are fixing the remaining bugs and getting set to ship the game. Most of the artists left the project before that.

That means that there’s rarely a situation where a team in a large studio makes one title and then immediately goes on to make another one — more likely the team will split up and head to other projects. Some may jump on to help another project get the final bugs squashed, others may jump on to prototype a new game.

The Life of a Game Project

That leads us to the life cycle of a games project, because another misconception is that the team making a game will remain the same group of people all the way through.

A project generally starts out small. A few designers basically start up by spending some time trying to answer the simple question of “What game do we want to make?” Sometimes this is more straightforward than other times — but more often than not it is somewhat complicated and difficult. Even sequels usually start out in a state of “don’t really know what this is about”.

There’s this nice thought many people have about games as having this brilliant idea first, and then just making the game. This never happens. The project will probably get to some kind of rough concept of what they want to do, what kind of technology platform to use, what setting, and so on… and then go into pre-production.

The pre-production phase of a project is when the project starts taking on more people. Coders join, artists join, and most probably more designers join. The mission now becomes trying to prototype, test and prove all the different aspects of the game — figure out the core game mechanics, make art target concept environments, make sure all the tools needed work properly. The goal is usually to build a small section of the game as a proof of concept.

The project has probably been running for at least six months by the time it finishes pre-production and heads into production. It staffs up even more, and sets about building all the levels, missions, features and content needed for the complete game. The amount of time it takes to do this varies wildly depending on the game.

Still, through production concepts are refined. As playtests are done, the developers think of new ways to improve the game, and the new ideas are worked into the concept.

What You See Is All There Is?

By the time you hear of a project, it’ll generally be in production. Conceptual prototyping is relatively cheap, so studios can afford doing concepts for games as a test, and if they don’t turn out well then cancel the project. This means that at any time, your favourite games studios out there are probably doing cool stuff you have no clue about.

This way of doing things also means most views on the state of a game are somewhat flawed. By the time a game hits beta and you get to see it, it’s virtually completed and only bug fixing remains. Comments like “well this is an early beta, they’ll change lots of stuff” are quite common and somewhat funny to see — very few game changes will be done once a game is in beta.

That doesn’t mean quality doesn’t increase though — much of the quality you see in a game comes from the actual fixing of bugs, not the adding of features.

“Not that the devs are ever gonna care”

Gamers tend to show a pretty large dose of resentment towards game developers. In general, what you see is an announcement met with awe and comments like “this’ll be the most awesome ever”. This attitude then changes over time, until at release, the comments tend to sound more like “they messed it up”.

A strange aspect of this is that many gamers seem to be deep into the belief that game devs don’t care about them, about the games they make, or about anything at all other than earning a quick buck. This is strange because the games industry is not the place to go to make the good money while slacking — it’s generally a grind of long hours of dedicated work and not as well paid as other comparable areas (making business apps is definitely much more lucrative for a programmer).

Yet people still do it? Why? Because these people are gamers and love what they do. Maybe somewhere there are big-name execs that don’t care, but I haven’t met them yet. I’ve only met the EA execs who beat half the dev team on Battlefield: Bad Company (though dogtagging your boss is sweet indeed).

That’s all part of what makes the games industry such a great place to be if you love games — not only do you get to work with games, you get to work with gamers.

Yet most people seem to think that game developers isolate themselves in a small glass jar somewhere, and start ignoring the internet as soon as their project becomes public. Nearly every forum or blog post about a game has a bitter comment about “no chance the devs will bother to read this”.

Guess what — we do read stuff on the ‘net. Not only because we’re gamers but because we care deeply about making the best game possible. So why don’t we answer? Well, I think you could imagine what’d happen. Half the people would call you a liar, and the rest would bombard you with even more. There’s no way for a game developer to answer questions or opinions on a forum without immediately being subjected to at least twice the amount of new questions or opinions. We’d simply run out of time.

And well… at the end of the day, we have games to make.

For my own part, I’m more connected than most. Toss me a line on twitter if you have a question.