The idea of my failed game project still rumbles through my mind. Also the idea of ION Storm of running a team which concentrates on design is very interesting to me. Ok, I’m a programmer, Ok I love developing on a game engine, but how would it be having a game engine already done and setting up two or three separate teams working on their own games? It would be an interesting experiment setting all this up to get it started. A fact that we shouldn’t loose out of focus is that this would be only an experiment. That means that of course fun should be the main push. I thought of this now for over three weeks and would love to realize some experiment like this. I already wrote in my blog “The rise and fall of game projects” about the failure of my game project, but expanded my thoughts as you soon will notice here.
What exactly would we achieve with this experiment? First of all it would be a simulation of what ION Storm faced that days. We would see if Romero’s idea of running a company with design as law would succeed when changing some factors. I must admit it’s difficult for me to write those lines. As a software developer technology is always law for me, but the basic idea of ION Storm was so great I think and I also think that yes ION Storm would have succeeded but I won’t start a discussion of what things should had have to be different. Back to our project, another interesting point would be to see which team pushes the used engine most. That would indicate how teams handle technology and how design. And that’s exactly the point what we would like to find out. How would a team handle a given technology and how would this look like compared to the other teams. How much would the teams be influenced by the design documents and how would they implement it into the final game.
Let us think about it how things would be set up.
The core team
What we would need first would be a core team. I call it core team since this team would be responsible for the engine. Yes I know I said above we would use an already ready-to-use engine, but there are always tasks to be done so let’s say we would recruit two or three coders which are responsible for bug-fixing, creating the main tools like editors etc. The core team should also be a support team for questions coming from the game teams. The core team would also set up the project management tools, the issue trackers and so on.
The game teams
The game teams would consist of the graphic artists for textures, sprites anything graphic related. Also some guys for sound and music would be great. The game teams need a storybook (design document for the game they want to produce). Depending on how extensive the game shall be at the end some coders would also be necessary. They will create the actual game and if necessary some additional tools. Every game team should have a project manager. This guy can be either a team member mentioned above or a separate person. He holds the team together and dedicates his time on keeping the project alive. He is the interface between the sub teams of developers, mappers, artists. By extending those “administrative” tasks to a project manager a game team can concentrate on their actual work. Creating the game.
In fact we could have 1-n game teams. That would just be fine. But it would only work if the game teams would be complete teams. The funny thing is that the teams would be really separate teams. No communication would be allowed between the game teams only between the members of the same game team since they should concentrate on their own work.
General rules
- Game teams start simultaneous to develop their game
- Tools must be set up before development starts so that the game teams can fully concentrate on their project
- Every team has a fixed period to finish the game project. the period will be specified by all the teams before starting the development. This period will be the deadline
- Every team may develop a game they want to, as long as it is what their design document specifies. If the design document is about Pac-Man and your result is Donkey Kong than you failed so the project managers are given full creativity to create something they like
Do’s and don’ts of the core team
the core team has to provide:
- the engine bins
- the development environment. That includes the header and library files n eeded to use the game engine
- code examples of the main engine features
- a complete sample application of the game engine
- a documentation of the game engines API
- project management tools. That includes a project management for each game team to schedule milestones, assign tasks, issues and a communication center like a wiki. All the game teams would have access to their own project management tools so that all game teams work under the same conditions
- the engine specific tools needed for the game engines specific file formats like importers/exporters for 3rd party tools, mapping tools or editors etc.
Do’s and don’ts of the game team project managers
- the project managers are not allowed to communicate neither with other project managers nor with other game team members. They have to concentrate and push their own team
- the project managers have to meet with the basic team once a week. In those meetings they have to report in short about the current project progress, about the state of resources and about their project in general. This meetings can be held very short but are necessarily since the core team will use the information for the final statistics. Although you might find it more useful to concentrate on work those meetings are very important to detect later on mismanagement and or improve some time or project critical paths in the several project states
Do’s and don’ts of the game team members
- the game team members are not allowed to communicate with members of other teams.
- if the game team members want to switch game team they have to contact first their own game team project manager and after that the project manager of the desired team.
Conclusion
The above notes are just some thoughts I made when reading the ION Storm story. My notes about the experiment are ideas how I would handle that stuff. Of course the ideas and thoughts above are few and incomplete but the that’s the point. The experiment should only give some impulses and ideas. The rest is up to the project managers. To tell you the truth I will maybe start this experiment as soon as I have the time to build up a core team and get some project managers for the game teams. Maybe some parts of the notes above seem to lead to rivalry between the game teams but that’s only for getting some competition between the teams to push them to their best 😉
Now what do you think? No no I don’t mean why ION Storm failed. I would like to know your opinion about the experiment above. Would design really be law or would the game teams start mailing the core team about requests on new features? Would the games released by the teams be on the same technical stand or would they differ much? Would single game teams be able to push an engine to the limits or not and if they would be able, would they be able to push the engine driven by the design document wanting to have the game as it was written or driven by their ego to include the latest state-of-the-art features? Would an abrupt engine swap make thinks different or not? Would an exchange of game team members or even game team project managers make thinks more difficult? Would the project managers manage to handle their resources or not? Would they also achieve to complete their tasks keeping their team together?
So many interesting questions sadly no answers. You could expand that list till eternity, but you will only receive an answer if you try it out.
The idea of starting simultaneous teams to create something on their own (and I really mean on their own) is quite an interesting task especially when I thing of how different the results could be. If you have tried something like this please share your experience with me. I’m always interested in game programming projects since they are the only ones who do not fit within an usual project concept.
