Here an example list following on from previous post. It''s just an example off the top of my head, there''s no estimates, but it shows how to break things down into a prioritised list with MUST have, SHOULD have, LIKE to have, and WONT be having features. It also shows breaking the project into 3 phases, with working prototypes being delivered at the end of the first 2 phases, and these prototypes evolving into the final product for the final phase. What is important here is that if you have severely underestimated the work, or overestimated your team''s capabilities, or ran into major hurdles when trying to work together, at least you have something that is finished with the early prototypes which you can hand in.

Prototype 1, week 3, MUST have features:
1. render an object as a triangle
2. render 2 or more objects as triangles
3. provide support for objects to be added or deleted from scene whilst app is running
4. get camera moving in world just turning left and right and moving forward and backward using keyboard
5. render a flat floor
6. allow objects to move with velocities, so the engine updates positions every frame
7. provide simple object collision detection (bounding spheres)
8. provide simple mechanism for steady framerate (not too fast)
9. add shoot function which creates an object (bullet) at the camera with a velocity in the direction the camera is facing, no up or down orientation just straight ahead
10. provide a hit feature whereby if the bullet object collides with the other objects, those objects are deleted from the scene
11. provide a scoring feature whereby when there are no objects left the level is complete, a message is displayed and the game ends.
12. test what you have done on other computers, especially those that your teachers/lecturers will be using
13. fix bugs found in testing
14. retest
15. ensure that the required documentation is complete, e.g. game design guide, engine design, user guide, etc

If you can do this, then congratulations you have produced something that could be classed as a FPS, albeit a very basic one, and you have finished your first game as a team. The player can move around, the scene gets updated, and there are these triangular objects (the enemy/targets) that the player must shoot. Hopefully, depending on the team''s skill levels, how you work together, how much effort you put in, this is completed by week 3, however you never know it might take 8 weeks. Nevertheless prototype 1 is finished, and if necessary this can be the final product. If you are on schedule then you can go on to the next phase of the prototype, if not you can just polish up what you already have (for course work, documentation is always the best thing to polish up last minute, since you''re less likely to break documentation).

Prototype 2, week 5, SHOULD have features:
16. support for texturing (objects and floor)
17. support for more complex object formats, an object can be made up of multiple triangles (a mesh), an object can consist of simple primitives likes blocks, spheres, cylinders, cones etc.
18. different types of objects (some are enemy/targets others are static like blocks, trees, houses)
19. support for textured skybox
20. sound effects
21. simple object animations (e.g. explosion when object is hit)
22. read in level information from a text file (e.g. objects, types, positions)
22. support for multiple levels
23. add mouse control
24. test what you have done on other computers, especially those that your teachers/lecturers will be using
25. fix bugs found in testing
26. retest
27. ensure that the required documentation is complete, e.g. game design guide, engine design, user guide, etc

This prototype should make the game less basic and more interesting with textures, simple 3D objects made out of more advanced primitives than just triangles, multiple levels, etc. The enemy do not move or they might just be targets you have to hit. As before, if prototype 2 is finished, this can be the final product if necessary. If you are on schedule then you can go on to the final phase of the prototype

Final product, week 8, LIKE to have features:
28. enemy objects AI, they can shoot back at you
29. handle the player being hit, reducing player lives, ending game if no lives left
30. add enemy movement and animations (simple enemy, simple animation, like hovertanks rather than something walking)
31. support for more complex object formats, perhaps reading in object format from a file, or using a 3rd party 3D model format
32. show the player''s gun from first person perspective
33. test what you have done on other computers, especially those that your teachers/lecturers will be using
34. fix bugs found in testing
35. retest
36. ensure that the required documentation is complete, e.g. game design guide, engine design, user guide, etc

You would be doing very well if you finished this final phase of the project, my guess is that you will not. This isn''t a problem because at least you will have something that looks finished to hand in with the prototype 1 or prototype 2. During the project stick to doing things in order, dont start prototype 2 features until prototype 1 is complete even if they are more interesting. Dont allow feature creep or new features to be added. If there is some work/feature you haven''t foreseen, then give it a priority in comparison to the other work and place it in the prioritised list, this might mean that some lower priority features are pushed out of the product completely (e.g. 31 and 32), or some feature is moved into a later prototype (e.g. 22 and 23 moved to final product phase). Some of the things to do at the end of each phase aren''t really features they are things you must do and are immovable (e.g. testing, bug-fixing documentation).

Finally, whilst it is important to have a prioritised list of features, its also important to make it clear to everyone what WONT be in, e.g.

Product WONT have the following features:
1. There will be no complex terrain, just flat ground
2. There will be no complex collision detection, just bounding spheres
3. There will be no indoor levels
4. There will be no 3rd person view, so you don''t have to worry about modelling the player
5. The player will not have the ability to get out of their vehicle
6. There will be no level editor
7. There will be no large levels, since there will be no bsp or complex frustrum culling, therefore only small levels will be supported
8. No joystick control
9. No shadows
10. No lightmapping
etc.

Don''t underestimate how difficult it is to work in a team on the same application, I know you originally thought that 2 programmers could work on their own applications (game, and level designer), but I think a level designer is out of the question for 8 weeks, so you will all (2 out or 4) be working on the one application. This is where it is important to split the application design up logically. Also 4 people working for 8 weeks doesn''t necessarily mean 32 man weeks of work. How much time can each of you devote per week, if its 4 days per week rather than 5 (9 to 5), then thats less than 7 weeks each (28 man weeks total). If only 2 are programming then thats 14 man weeks on programming, etc.

Best of luck

quote:Original post by Kazgoroth
Also, it might help you to already have another more feasible design written up and ready to go if your trying to convince these people to do your project instead of this other guy's unreasonable one. Yes, I know you said you have an alternative idea, but how about some design documentation you can show them, otherwise its really just your word to them that your idea will actually be more feasible. Maybe you could even have some code done if your up to it.

Ok, that's a very good idea, i'll try to get on that.

quote:
One other thing that may help you convince them is to get an open-source FPS engine and/or game, and show them how complex and long the source code is (I'd suggest either doing it with the lead guy absent, or with source thats licenced in such a way as to be unusable to you, just in case your leader decides to use it instead of it helping you convince the others the project is unfeasible).

That sounds like a good idea, but even if it's licenced i think he'll say, "This makes it even easier, cause now we have somethign we can look at to tell if we're going in the right direction or not". I think if i tell my team that most likely we'll end up building a game where you're a triangle, you shoot at triangles, and you shoot triangles, that will convince them that this game is a shitty idea. Of course i'd rather just switch groups. My idea is an advanced version of pong, it's much more reasonable to expect cool graphics from that type of game in 8 weeks than his right? Or should i expect to be using triangles for everything too?

abstractworlds: thanks

[edited by - tieTYT on April 17, 2004 2:37:06 PM]

For my graphics unit at uni I made a very simple FPS style demo in about 8 weeks. I stress VERY SIMPLE. It consisted of one large room (No portals etc), shadow mapping, 1 weapon, basic physics, basic collision detection, and no model for the player (you can''t see yourself in a fps ).

During the construction of this FPS I ran into all sorts of nasty suprises that you can only see when you reach them. I had one particularly bad one with the collision detection that took me about a half a week to resolve.

What your team wants to do is over ambitous in the extreme. Just my simple FPS chewed up a huge portion of my time and many sleepless nights. The media construction for you game alone will require atleast one person going fulltime and that would be just for the utter basics. The animation (keyframing, kinetics) will require another person full time. The graphics/core system will require another fulltime and the game layer will require another. And all of these will have to be done concurrently whilst ensuring compatabilty with each other. You are in for a nightmare of a ride that will very likely end disasterously.

And if you are thinking of adding multiplayer to your game, FORGET IT, it will cause a whole case load of unforeseen problems even greater than those you will experience in all the other areas of your game design. If you include multiplayer your entire game engine has to be built around it and you will need to handle 101 whatifs for network communication. You cannot slap the multiplayer portion onto your game after you have mostly completed the game.

Go for something simple, maybe a 3d asteroids or space invaders clone.