     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: "Insignia" What Went Wrong 1. Ambition. Our game was overly ambitious and we knew we were not going to finish every part of the project due to our coursework and exam commitments. Everything from installing software in labs, getting access to motion capture studios, and learning curves for software all took time. The team focused on areas relevant to their areas of personal interest and portfolios. Each student had professional, well-finished elements, concept art, user interface, database integration etc. for their portfolio but we suffered from a lack of a finished prototype. The end result of our ambition was the lack of a working prototype at the end of the academic year. We had various elements of a game but most of that was not integrated into the engine. We had a basic working version of the engine. The user interface, 3 RD person perspective, camera system and basic path finding worked but were very rough and clunky. Our technical demo failed to reveal any of the game design or game play ideas that we spent so long developing. 2. Engine. We spent a lot of time figuring out how to make the Unreal engine work as an RTS. We were ideally looking for something like Neverwinter Nights with advanced mod tools but in a modern setting with firearm mechanics, particle effects and physics. Since this magic game engine didn't exist we decided to mod the Unreal engine. This meant that everything developed in the engine for the game took too long. And while we had lots of extra help in terms of modellers, artists and animators, we only had two programmers, both of whom had little experience with such software complexity. As a result, the impact of the learning curve and the unfamiliar development environment meant that too few of our assets actually made it into the game engine. It would have been great to have a 3D engine that had RTS and/or RPG elements built in. Many students are forced to make small casual, flash or mobile games or mods for existing FPS due to the fact that the majority of available tools are only really for those types of games. And although the University of Bradford has PS2 development kits and a license for RenderWare, the support levels for these tools at the academic level are not viable for use on this kind of project.
3. Skills & Experience. As University students we lacked a great deal of the skills and experience necessary to make a full prototype RPG/RTS game. While we had plenty of opportunities to work on smaller projects, we were not prepared for the scale of the "Insignia" game. We had potential, enthusiasm, great ideas, good organization and planning. In fact we were better off than most other student groups, but we lacked many skills. Planning everything from development schedules and motion capture shoots to software builds were all problems we had to face, and coursework impacted on our schedules in unexpected ways. We attempted to solve these problems, the impacts were unavoidable. This had pros and cons. While coursework and planning stole the time we could devote to pure game development, it was necessary to develop skills in these other areas. As a result, valuable lessons were learned, but the project suffered. 4. Resources. We lacked the resources necessary to fully develop a full game. We produced the prototype on a limited budget of £200 Sterling. Most of the budget was blown on the six copies of Unreal Tournament and some copies of WOTgreal, an Unreal editor. The University provided a lab with computers, Internet access, development software and tools. We ran into institutional barriers within the University, with the IT department loathe to install certain software and vehemently opposed to giving us access rights to install it ourselves. We often found that they did a bad job and did not test the software they installed, leaving us to wait for a week or two before they would come down and try to fix the problems. The motion capture studio at the University presented us with similar problems. While it was an excellent resource, we could not get access to the lab until the last few weeks of the academic year and subsequently the data we got was never integrated into the prototype. Our own department gave us any resources we needed but getting resources on time and in a format that benefited us was the hardest part of the project. Having to wait for IT support and resources beyond our control generated significant delays. It was also difficult to coordinate the development done in homes with that being done on the University networks for the same reason. It would be helpful if there was a standardized and secure project management and file sharing facility or extranet available for the projects which would solve a lot of these problems. 5. Time. The biggest single factor hindering the project was time. We could only manage one 6-hour lab per week. While we individually worked on our game as much as possible, this usually amounted to only about 12 hours a week sometimes less. Each of the team members had an individual game project for their final year project as course, exam and module requirements. As good grades were our stated top priority, we were had to place our focus there. This meant we would often have to put the group project on the back burner. We would have been able to make a fantastic game if we were able to devote 40+ hours a week to it, but this was just not realistic. So we had to be pragmatic. Student projects mean you should expect disagreements over working in teams, being in the same room for longer than 5 minutes with each other and especially over creative direction. Some students don't work well in teams and will hinder your progress. Some will not like the game idea or the other team members and just drag their heels. And of course every student wants to be the game designer. It will usually be the first major group project most of your team will work on and that inevitably leads to team problems certainly added to the stress of exams and coursework.
6. Industry Support. When we went to seek advice on how to make our game, we discovered that there were few industry resources available. Game development studios do not share their information, techniques, time or ideas as a general rule, and tend to be overly protective or non-communicative. There is a huge divide in the knowledge within the game industry and outside of it. What can seem easy to a game developer can sometime take months to get to a very basic level on a student project. Game developers have solved most problems already and have resources and knowledge bases to tap into, while students have limited resources and help available. This can greatly affect your projects. Plan big. It's cheap to plan and then implement small features for a large game. If your game is small, work on polishing it and then polishing it again. Make demos of working elements if you can't make a full game. The primary sources of information we used were the excellent Unreal help pages, websites, community forums, blogs and wikis. Having solid industry support in terms of help, guidance and tutorials would be an obvious advantage to any student project. Maybe the solution is an inter-university Internet-based system where video game students put their work up and share resources, techniques and knowledge between different universities, projects and disciplines. Conclusion We had a fantastic year developing a game idea we all loved. The Dare entry was fun but we went into it with clear objectives. It would have been nice to qualify but we planned our project assuming we wouldn't. Competitions are useful, but places are limited and fiercely contested. Don't pin your hopes, academic success or future potential on winning or qualifying for entry in game competitions. Have a backup plan to complete the game in your own time. Think carefully about what game you want to make and your overall objectives and priorities (portfolio, grades, competitions) throughout your academic life and beyond. Don't compromise your creative and artistic beliefs. You will be forced to make many creative and personal compromises in your journey through the video game industry. Work on ideas that are fun and interesting to you. You will rarely if ever be given such creative freedom in industry. You will learn more from the mistakes and things that go wrong than you will ever learn from the elements of your project that worked out fine. Plan everything. Be pushy if you are told no by a staff member or a University department. Try again making a better offer or plead with them. We found that our department would provide us every resource they could. Getting those resources set up, installed and working the way we needed them was a much harder task. Focus on the stuff you can do. It is better in my opinion to have something completed and well done than something half done that doesn't represent what you wanted to achieve. Focus on stuff that does not need major resources, game design, concept art, ideas, background, stories that way you have the capability and material to make the game at a later stage in your life when time, resources and skills are more readily available.
_____________________________________________________ |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|