Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Developing the Development Process This document is a glimpse into problems and solutions encountered as team/technical lead/director over 5 released titles with 4 out of 5 titles delivering on time for the last 11 years in games and 5 years in business working and leading multi-user business system projects. A lot of this may well just seem obvious but I am always amazed at how many projects do not have even some of the more basic points established, inevitably causing the project to delay or lose focus and end up being canned. The quotes are more or less accurate from individuals within the game development community. “So, we’ve got this idea right , your in a sub , underwater or summit, and you can dock and walk around, just like tomb raider and then you can go above the water, maybe, and fly to another planet…I think !!!” One of the main problems we faced on a couple of titles we did was a lack of ‘the champion of the game’. An idea would spring up from the misty depths of someone’s consciousness, a proposal drawn up and presented to a ‘game board’ and then subsequently a prototype started, unfortunately, even at this point, the game had become so ‘designed by committee’ that it had lost its ‘champion’ so to speak. The one key member of the development team who assumed all responsibility for the direction of the idea and how it would grow, that would show confidence and conviction to the idea, this is not to say that others cannot contribute or changes made to the design due to constraints/schedules but they, at the end of the day, were the one person that could be relied upon to know ‘the game’. It seems obvious that we simply call this person ‘lead designer’ but the role is far more than a title, it is the leading light the artists/programmers and management call on for direction and confirmation. “If I want a million sprites on screen, then you’re the programmer and I’m the designer and that’s what I want!” What makes a good designer? no doubt there are hundreds of answers, but one that we found again and again is a designer who understands and works within the constraints of the system. This doesn’t mean they should restrict ideas and design to technology/schedules but take the technology/schedule constraints into account when creating a design and applying it. This also means that they are flexible when situations change, be it technical or schedule that have an impact on design. Design without constraints is not design, it is merely dreaming. “Scheduling! your in the games industry now, it’s a creative thing, we don’t schedule” Schedule, a word that seems to be hated by most programmers and artists and not always understood by producers. A schedule isn’t an anchor that restricts design, programming or art creativity, it’s a lifeline that allows us to see the realisation of a game as a possibility. There is nothing in a game that cannot be scheduled, design is not a black art that requires an indeterminate amount of time, many of us have been in the game industry a fair while to know what works and what doesn’t to some extent. For those areas where it is an unknown, contingency should be built into the schedule. One of the most helpful methods we’ve used when starting a schedule for a project is adopting a business practice known as the ‘brown paper model’. This simply means taking 2-3 days out with the leads of design, art, programming and a producer, pasting a meeting room walls with sheets of paper, then writing down everything related to the game (required art/programming/design, other assets etc.) on those sheets. Once that is done the items can be sorted into chronological, art, programming, design categories to start a proper schedule but we have a good basis of the items required to realise the game. “It’s not my problem!” Within game projects we have always found it to be vital that a clear lead in programming, design and art existed. Nothing is worse then having a problem with the art or code and no-one making the final call, or even worse 2 leads in the same category making conflicting calls. Of course there may be hierarchies so for example you could have a programming lead on the engine, one on games and another on the consoles but one should still assume overall responsibility. Without this conflicting standards arise, no-one person takes overall control and we end up with the classic ‘it’s not my problem’ quote. This also benefits change control, as any major art, design or programming decisions need only be communicated with the leads and then they are responsible for ensuring it follows down the hierarchy within their respective field. “Whoo, glad that’s over, now we can forget about it..” Projects tend to go through very different emotional phases, the initial enthusiasm and ambition, the striving determination, monotonous periods, longing for end, refreshing boost of inspiration when the game is demonstrated or a preview article written. But there tends to be one common emotion at the end of a game project and that is the sense of relief that it’s done, over and now onto the next project. Unfortunately its at the end of the project that we can gain some of the most important information from our experience by doing a post mortem, but with the overwhelming sense of relief and the desire to ‘move-on’ this more often than not is overlooked. We have found the post mortem is an excellent opportunity to discuss all the things that went right but most importantly what went wrong and how we can improve.