Understanding The Ecology of Games Development (Notes from UWE Talk)
These are the notes from a talk I did at UWE on Monday 21st. I was asked to to give an overview of the games industry, to talk about how the games industry works, about commercial logics and creative dynamics, consider the pipelines of development, division of tasks, story and game design interactions etc. To look a little at how a developer company works, the relationships with publishers (if you have any), pipelines, asset development, stages of testing and coming together of elements and so on.
So here goes. Firstly I put ‘ecology‘ in the title of the talk. This is very deliberate. Understanding the games industry is not a separate entity but instead a series of entities interlinked with each other and with other media and technology industries. The best way to understand it is to think of it as an ecology. There is much more on this idea, that of Media Ecology here.
Second – it is worth asking, what is a game? With so many forms, platforms and areas, this itself becomes an interesting question..
The best place to start is with this graph:
It shows how the composition of the games ecology has changed since 2004. However the trends it shows go back even further. What you can see is that a few years ago the newer forms of online and mobile games emerged and grew and grew. They are now about 50% of all the industry and projected to keep growing. This is a key point. We are now in a post-App world and while that does not remove the market for consoles and PC games, their growth (in value) has not progressed in the same way. In addition, these new platforms (mobile & web) mean that publishing is not quite the same as it was either….
The Traditional Publishing Route
This still exists and will continue to. It’s how we did a game like Savage Moon. In this model you pitch an idea to a publisher, either your own original IP or something they’ve asked you to look at. That pitch as a minimum really needs to consist of screenshots mocking up how the game will look, a short (seconds) video showing how the gameplay will look and an outline design of a page or so to explain the game, platform/s and who it might appeal to. If they like the idea, they will offer you the money to develop it. However, except in rare cases they will own the IP post-development and control the distribution and marketing of the game.
The Newer Publishing Models
Again, its plural for a reason! As networked forms of media (the web etc) transpired, the control over distribution that publishers had enjoyed came to an end. Physical distribution is expensive. You had to put the game onto a physical format and ship it to a chain of stores to sell it. Now that distribution can be digital via mobile, online, p2p and so on, the cost is now very, very low in comparison. In addition to this, new platforms like the iOS and Android offer a space to self-publish games where the barriers to entry are low too. As a result we see a whole host of models emerging from purely self published (Fate of the World) to hybrid models of part-finance (Star Wars: Battle for Hoth was an example of this) and many variations in between. The advent of new platforms also means that games can be developed as adverts, promotions or as engagement by non-games industry institutions (Filth Fair is an example of the latter).
The Development Process
To make a game you start with an idea. This should be an idea of what the gameplay is and should not focus on the narrative as yet. This is key – games are about gameplay and not narrative. They can work together but often don’t though there are rare exceptions. There is more on this here. Then to make the game you need as a minimum; design, art and coding. These can be separate people or one person with all of these skills but in general the more ambitious the title, the more people (and/or time) you will need to create the game. There are other roles in game development such as sound and production, but to start development, the crucial roles stated are necessary. The designer then writes the Game Design Document (GDD) that collates the vision of the game, explains every aspect of the game from front-end menus to the stats system. The coder starts working on the game engine (or using a 3rd party engine) and the artist starts making a few key art assets for the coder so s/he has something to work with. And it builds from there…. The relationship with the publisher is key. You all need to have the same vision for the game, or it can be very difficult.
Once production starts, if you are funded by a publisher, you’ll have milestones to stick to (so you get paid£$£!) Each milestone will have set art, design, audio and code tasks that need to be completed. You should be working towards an Alpha – a version of the game where everything is in but not working yet. Then its on to Beta where all of the major bugs (crashes and things that stop you playing the game) are fixed. Then you aim for the Master Candidate. That’s the version you think is done and ready for release. While in the networked age, you can (and should) iterate a game over and over – these should be about adding more functions and features and not fixing bugs.
Quality, Speed, Cost – Pick Two!
This is an old business adage but still holds true. What sort of a games developer are you going to be? You can’t do all three. Amazing games such as Modern Warfare 2 cost hundreds of millions to develop and distribute. They have staff teams in the hundreds and take a couple of years each to make. But then the rewards are reaped; over a billion in sales in the first week. Casual games can be the work of one person and still make lots of cash (see Minecraft). Some can be a labour of love, the amazing Braid was a singular vision that took a couple of people a long time to make (but it was worth it!) The studio behind Angry Birds made 43 games before they had the big hit. In that time they learned a lot about making games but to some extent there are numbers and luck involved.
Testing is an often overlooked area of games development and is a weakness of the newer forms of publishing. I’ve downloaded iPhone games with shocking crash bugs that you’d simply not find in a PS3 title. (But then before control slipped, publishers could be shockingly blasé about releasing buggy games, hoping to clean the mess up with patches later…)
There are two sorts of testing; QA (Quality Assurance) which focuses on the game working, not crashing, not having bugs and being of a consistent quality of speed, art and sound throughout. Testing for this is a skill and needs to be thorough. A producer should be playing the game at this point so they are aware of any bugs or issues. You need to try and break the game. For example, in text entry areas, what happens if you hit any key and don’t let go? In a tutorial when the AI trainer asks you to shoot a target, what happens if you shoot him instead? Believe me, on release the player will try all of these and more.
Second is gameplay balancing. This involves playing the game from a design point-of-view over and over. Each time you play the game, you are refining the stats in areas to eventually craft it into what your vision is. This is about making a solid difficulty curve so it starts easy and gets progressively harder. This is tough because as you play the game lots, you naturally get better at it so your judgement as to the difficulty is impacted. Others should also be playing to assess these levels too.
And good luck!
The games industry is changing and fast, which makes it an exciting place to be. I do hope to be playing one of the titles you have all developed someday soon and thinking ‘wow, I wish I’d thought of that!‘