The following is a feature article I wrote that was published in Screen Education magazine (Issue 60). It’s basically the amalgamation of seeing literally hundreds of students’ heartbreaking projects born of over-eagerness and, ultimately, failure.
Scope to cope kids, please. Oh, and enjoy the read.
The Problem of ‘Over-Scoping’
Every year a slew of academic institutions invite video game industry folk to come and view their students’ final year projects. Games, game engines, mini-games, mods. No matter what they are, if it’s game related there’s one problem that is guaranteed to stand out every time; over-scoping.
It’s a term far too familiar in the gaming industry. No game wishes to bear its weighty moniker, no publisher wants (one would hope) a product where the possibilities become signs of failure, and — perhaps more-so — no developer wishes to be the cause of such critical reception.
Why? Because it simply means, someone, somewhere in the development process has bitten off more than they can chew and failed to reel it in, in effect, failing the project and its audience.
So, naturally, it’s not something developers wish to see evident in the work of prospective employees. It’s a problem plaguing academic development projects today. Which makes it even harder for academia to convince developers that there is any serious benefit a degree holding graduate may possess over a passionate, enthusiastic, self-educator.
However, perhaps it is a case of the pot calling the kettle black; many a commercial game, both large and small, blockbuster or budget, fail to deliver. All showing signs of promise as to what could have been.
Although there are many reasons why a commercial game could suffer these shortcomings, there is little-to-no reason why a teacher-led, student project should ever be over-scoped. Particularly the project said student is parading in front of highly experienced game developers — game developers that have most definitely been burnt previously by a poorly scoped project.
So how does one get it right? How do you gauge, so early in a project, the weight of seemingly futile decisions? Unfortunately the only answer the industry has at the moment is; experience, a lot of common sense, and design by subtraction.
Seeing as though most students have little-to-no experience, common sense is difficult to apply, so it would dictate that relying on purely, minimalistic design is ideal.
Beauty in simplicity. A well polished game of simple conception and masterful execution will always trump the grand desires and failures of those attempting mimicry of blockbuster titles. There are those students that try and remake the hack and slash epics or action-packed first-person shooters, literally, with four students to a team, and six weeks time. Yes, it is easy for students to be dazzled by the blockbuster games — as it is for commercial developers — but this is the road to ruin. When this happens, it is not only a failure of the students, but also their teachers/instructors.
Whether developing a project simply for a class assignment or activity, or whether it’s a major portfolio piece designed to attract interest from prospective employers, it is imperative that what is given the most attention is the students’ responsibility as developers to provide an end product that is of the highest quality and design integrity they are capable of.
Designers, artists, programmers, audio engineers, no matter the discipline, should assess the path ahead and approach the upcoming development as sensibly as possible, constantly reassessing and, if need be, realigning the project.
How do you intelligently scope a project? What are the methods? Well, it differs from studio to studio, from developer to developer. There are numerous processes and checks in place to battle over-scoping and so there is no hard and fast way to give students the magic solution, but the methodology suggested below is an amalgamation of some techniques that can help students approach their development projects with far greater sensibility and perhaps some promise of a far greater outcome.
Start Simple
When initiating a game development project, start from the start. The bare bones. Start simply with these two questions:
- Who is my primary audience?
- What are the project’s intrinsic restrictions (time x resources x budget)?
Once these questions have been answered truthfully, design perimeters (or guidelines) that the team can work within will begin to appear (i.e.; if you know the audience is 5-10 year old females, you’re not developing a first-person shooter). So with the knowledge of a target audience, and the restrictions of the project, a process of elimination has begun where, ultimately, the end result will be the team holding a complete visual meta-image (or ‘bird’s eye view’) of the project.
So with our first perimeters, we continue by applying some cold, hard facts of development to the mix. This is where it really becomes fun, as the focus will shift towards the gameplay design. Some examples are:
- I am to craft a positive experience for the user.
- From inception, it must engage the user consistently and constantly.
- The project must be achievable well within the capacity of the schedule (time), resources (people and tools) available, and budget (money).
Okay, so from these facts come the ‘common sense’ factor of preventing over-scoping. From this the team can see what is important for the end user; wonder and excitement (a), fun and engagement (b), a quality, well presented end product (c). This process is highly important as the understanding of these facts help remove the ‘me’ factor from a team and place the focus of game development where it should be, on the end user.
Now take everything the team has just discovered and roll it all into one final question:
- What experience will engage (insert audience here) constantly from beginning to end, whilst remaining achievable within the inherent restrictions of the project?
This is the question that will be dubbed, the ‘concept killer’. All concepts will be born of or tried against this question. This is the hardest part of the conceptual phase, if not for the numerous conceptual ideas teams will go through, it will be due to the surprisingly genuine challenge of answering honestly. Asking one’s self whether or not a concept is the right fit is a skill that must be learnt and continually practiced vehemently.
When seeking appropriate concepts the biggest thing that will help students is seeking inspiration outside of the medium. In this period of time, where concepts are being considered for development, constantly question everything. Try and find the intrinsic fun in everything even remotely enjoyable; Why is it fun? What are the processes of interaction? Can they be formulated into a rewarding game mechanic? If not, try again. Look to hobbies, go to a gallery, play and research board games, read a book, watch children play and question their inspiration for such games, take a walk, study nature in action, read up on scientific phenomenon, just simply opening one’s self to doing different and new things will inspire.
Going through this process all the time (not just when looking for concepts), will foster an ability to steer away from imitation by increasing one’s frame of reference. Which is a technical way of saying; it will make your ‘box’ bigger — far easier than attempting to think outside of it.
Some of the most brilliant gaming experiences come from the simplest of concepts. Portal (Valve, 2007) was initially a student project named Narbacular Drop (Nuclear Monkey Software, 2005). That team is now employed at Valve and worked on Portal. Another example of a brilliantly executed title with perhaps an even simpler concept and execution is Jenova Chen’s Flow (ThatGameCompany, 2006), developed originally as an accompaniment to a thesis.
When outlining a game design, one must ask themself; what experience am I trying to create? From there, the simplest, most streamlined possible approach must be taken, layering gameplay as is only crucially necessary.
Schedule Simple
A project’s schedule is something that is constantly monitored and managed, by all departments, from Quality Assurance (Q.A.) all the way through to Production and Management. Student projects are no exception.
There must be two levels to effective schedule monitoring, management and maintenance; the macro and the micro.
The macro is the major schedule. Allotment of tasks and resources, milestones, goals; all of this is included here. Although a team effort, there should be a producer role assigned to one person within a team. They shall be responsible for the macro management of the schedule and keeping the team notified and informed of upcoming milestones, deadlines, or concerns and problems.
Now for micro. This is the most important role, and for that reason it is the responsibility of every single person on the team. This is the assessment of all new ideas, concepts, prototypes, hiccups, reshuffling, etc. Literally assessing anything that arises, as it arises. The team must remain diligent and honest as ever here. One person slipping something through or failing to notify the rest of the team can lead to an inflated project and unwanted crunch.
Stay Simple
There will be more ideas flowing and appearing through the course of the project’s development than during the conceptual stage. More often than not, these late (or ‘on the fly’) ideas will also be far better, more intelligent ideas. This is of course due to the fact that the team is immersed in the project, having a far greater understanding of what the end product will be and (more importantly) what will benefit the end user.
Remember one thing; over-complication does nothing for a game design but give the user more to comprehend, adapt and apply. Constantly ask the question; ‘Is this truly benefiting the end user experience?’ Again, answering this truthfully is a skill that all game designers must possess. It is quite simply critical to the role of a designer.
Once that question is answered, another presents itself. This time an even more pertinent question; ‘Do we have the time and resources?’ Sadly, even if the game will benefit from the addition or amendment, the answer to this question may be ‘No.’ In fact, it is frequently the case that the best and brightest ideas will arise too late in the course of the project.
When this arises, the ability to accept it as an unfortunate situation, acknowledge the greater understanding gained and then move on with the project will always provide the team with a far better chance of delivering a higher quality product. For short, fastened ends are consummately better than lengthy, loose ends.
And… Strip Simple
Some of the greatest designers of our time will never be acknowledged for their greatest moments of genius, because those moments would be where they removed something from their game. A character, a sub-plot, a gameplay mechanic, perhaps even an entire world. A great game designer is a master of subtraction, moving their fine comb over every facet of the game, critiquing, comparing, cross-examining, finding and exposing those aspects of a game that bear the foul odour of complexity, ill-communication, redundancy, or worse… irrelevance.
Again, continue to ask that question of every aspect of the game; ‘Is this truly beneficial to the end user experience?’
Every facet of a game should come together and complement each other in the most wondrous ways. There should be balance. In everything. Music, sound effects, art direction, narrative, gameplay mechanics, gameplay systems, the user interface and structure elements, level design… everything
If the answer is hard to ascertain, perhaps dig deeper; ‘How does this particular mechanic support and promote this aspect of the player experience we are trying to develop?’ These are the types of questions all members of a development team should constantly be asking, because if you don’t need it… cut it!
Simple Sensibility
This sub-heading pretty much sums it up. With a sensible, realistic approach to the design and development of student projects, it’s not hard to figure out what not to do. Simplistic, well thought out designs will always be better end products than complicated, impulse imitations.
Student game development projects should be the grand realisation and wondrous result of years spent immersed in the technicalities and theories of perhaps the world’s finest, most incredible, most inspiring medium – the medium with perhaps the greatest potential to engage its user in the most powerfully emotional ways. Student projects should push boundaries, change attitudes, inspire veterans, and most of all show promise, not only of an industry and medium but the students responsible.
Don’t miss that opportunity. Develop simple, deliver big.
