Author: by Alan O'Dea

Introduction

Our ‘Insignia' project was a first round finalist in the 2004-2005 Dare to be Digital student video game competition. The project was the major group component of our final year studies on a BSc Interactive Systems and Video Games Design course at the University of Bradford, UK.

The process of pitching our idea was highly informative and gave us an industry perspective, insight and positive feedback from the judges. The pressure of competition also helped really focus the team's efforts rather than the more nebulous approach of most student projects.

The game was conceived as an RPG/RTS game in the vein of UFO. The game design detailed a dark modern world where corruption and conspiracy among the world's great superpowers, corporations, governments and religions forces the player into a morally ambiguous fight against supposed evil. The player manages teams of highly trained military operatives whose mission is to track down the underlying truth behind these conspiracies. The game focused on adult themes, typical and atypical power groups, and a modern role playing setting laid over a mission based tactical RTS.

The core team consisted of six game design students and a number of other students enlisted from various artistic and creative media degree courses: computer animation, 3D modelling, etc. The game system was based on an academic D20 licence provided by Wizards of the Coast, utilizing the type of rules system seen in Neverwinter Nights and Baldur's Gate. We also used the Unreal Tournament engine, modified to run as a 3D RTS engine, and we used the on-campus motion capture studio to help with character animation.

We entered Dare for industry feedback, and the experience value, believing (correctly as it transpired) that "Insignia" was not a normal kind of candidate for Dare. We had discussed pitching a smaller game concept, one achievable in ten weeks, but the team preferred to create something ambitious.

The judges commended our work, game design, and presentation material. They raised concerns that our game background was too adult for commercial application in the risk adverse video game market and was far too ambitious for a program like Dare.

What Went Right

1. License. Obtaining the D20 Licence from Wizards of the Coast provided the impetus for our entire year's activities. After obtaining the licence we approached the University and suggested forming a student team with the objective of entering game competitions and promoting the University and the video game design course.

2. Team. Our video game design course had plenty of students with diverse skills. We recruited a core team of six students, covering the skills of programming, design, art, audio and production. We supplemented this core team with recruits picked from the other degree courses throughout the University, bringing 3D modelling and animation skills in as we required them. We had a lot to achieve and we split the main tasks based on the individual skills of the core team.

Two members of the team focused on programming primarily in the development of the engine and the implementation of the D20 rule set within the game. Two other team members focused on art assets: one on concept art and storyboarding and the other on user interface, logos and website graphics for the game. Another student developed the music and sound effects. I developed the game design material and managed the entire project, organizing support from the University and managing the competition entry requirements. The entire team worked on the motion capture material. External team members used the game design materials, storyboards and concept art to animate and produce the character models for the game.

3. Priorities. We decided that our first priority was to receive good grades, our second to produce a good portfolio and our third to enter competitions. We also wanted to run the development process as close to a real game project as possible, so we had regular lab days where we only worked on the game. We also wanted to give students from other courses the benefit of working on a video game project.

The core team got exceptional grades and added a great project to their portfolios and got the chance to pitch that project to industry professionals. Choosing our priorities early on allowed us to focus on what really mattered during the year. Obviously our primary concern and major deadlines centered on reaching the milestones imposed by the University for grading. It would have been easy to get lost in the development process and let production slip away from us if we hadn't addressed our priorities at the very beginning and throughout the academic year. So for every production decision we made, we asked 'is this going to get us higher marks at the end of the year?' and if the answer to that question was 'no' then we didn't focus on it.

4. Freedom. We had a very strong desire to make an adult-targeted game dealing with weightier subjects than your average modern RTS/RPG. We weren't interested in telling teenage fantasy fulfilment stories. Or background wasn't planned to be a homogenized, easy to market, derivative game. Our game was intentionally grim, dark, and morally ambiguous. That was the game we wanted to make and the University was happy to let us work towards that end.

This worked very much to our favor. We had great belief and enthusiasm in our project and our ambitions. We received very positive feedback from the University early on and this directly lead to them granting us many resources and freedoms not available in previous years or to other teams.

The University gave us access to our own computer lab allowing us the freedom and privacy to work on our game. We were initially allowed to hand pick our team which is not a normal policy of the University. We were granted access to the motion capture studio. We were also granted support by the IT service to install any software that we needed for the project.

5. Dare. While we were required to make a group project as part of our final year game studies, we wanted to take the project further. ‘Dare to be Digital' was a great opportunity to move in that direction. The effort of gathering and preparing our game material for a pitch late in the academic year provided a wonderful opportunity to focus the team. We had a fairly clear indication of the milestones necessary for academic progress.

It was harder to evaluate what was required of our Dare entry. We spent a lot of time discussing what we should focus on and strategies for presenting our material. This process alone was a great way of sifting through the essential and non essential elements of the game. Dare requests a market and commercial assessment for each game entered. We spent a fair bit of time researching the market for PC based RPG/RTS games. This was an enjoyable and informative process.

We got some really great feedback from the Dare judges. Yes, our game background was over the top. Yes, our game was far too large and ambitious to take into the Dare competition. But they also said we had excellent ideas. They told us they could see the team members working in the game industry and commended us on the game presentation materials that we presented.

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.

_____________________________________________________