Man hours for Rainbow Six 3 type game

#1

Quote:
Play types: death match, capture the flag, team death match, single shot kill no respon DM and TDM
Option for: choose weapon a start no pick ups, choose avatar at start, choose kit at start

All of this is easily achievable.

Although Torque is derived from a game engine that was predominately created for an fps game, it is lacking in many key areas to make a decent fps by today's standards. Here's where you'll encounter problems:

- Rendering of high poly weapons in first person view with animations
- Matching first person animations to third person animations
- Projectiles. High speed projectiles have issues with collision detection, especially across a network. Also particles attached to projectiles are created too late and inconsistently
- Sounds for weapons with a high rate of fire

There are solutions to all the above, some even in the form of resources on this website, I mention them as if you are wanting to create a quality product these are some of the issues you will have to iron out.

As far as time frame is concerned, well that depends on how good you want your game to be, the number of people on your staff and their level of talent and expertise. I would allow two years as a rough guide.

- Tim

#2 I notice your are using the C4 engine. Why not TGE? For the above reasons?

#3 What is the size and experience of your team. This will be the key determinant in making a game on this scale and determining a ballpark estimate for their time. Their experience with Torque or whatever engine you decide on is a huge factor in determining how much scheduling. Taking someone who has never used TGE, and who is relatively new to C++ for example would require a dual learning curve that you will have to schedule for before you begin even beginning to estimate how long it will take to make the game itself.

As to the question about C4, though not directed at me, I'll answer a bit from other people who are using it and as a licensee myself. C4 is an extremely clean, robust, upper-current gen/next-gen engine. It's pretty to look at and fun to program for. There are some definite limitations (such as the hardware targets which are beyond anything that I am currently thinking of hitting, or networking and terrain). Many of these are being worked on by Eric and other people in the community have come up with their own ways of doing things, whether it be to add in a network library or roll their own terrain. It's nice, it's clean, it's inexpensive. But you will still have to have some powerful programming knowhow to make it work for your gametype. But you get that with any engine.

EDIT:
I just noticed your gametypes which did not remind me of R6 at all. Rather they reminded me of Quake and Unreal. You might be interested in talking to Tom Feni about what it took him to get common CTF functionality into his starter kit.

#4 This all is extremely easy to do...

I did most of what your wanting to do in less then a week, and then a couple days to work out bugs.

#5 Isaac please email me mpearson at cryptosurf.com

#6

Quote:
I notice your are using the C4 engine. Why not TGE? For the above reasons?

I'm actually using both engines. TGE for prototyping and C4 for more ambitious projects.

As Isaac states, the basic mechanics for an fps are all extremely easy to do in Torque. Making one that's exciting, fun to play and breaks away from all the other Torque created fps games is not. Creating weapons, an important part of an fps game, in Torque that actually have a nice feel to them is not so easy. To date I haven't played an fps game or demo made with Torque that had a good feel to the weapons. Machine guns are clunky and fire erratically, movement animations don't exist, projectiles are slow and inaccurate, particle effects look old and outdated, etc. Don't believe me? Download some fps demos available on this site and tell me what you think.

It will take time, bug fixing and rewriting of source code.

#7 I have sorted out most of this stuff (in TSE, not TGE) and the real bugger was the erratic fire sound and animation. You have to move this stuff over to the client completely, which is the approach many other games use to have non-latency affected fireing.

I'm not saying you should calculate projectiles and whatnot on the client. I am saying you should replicate the fire state on the client and not wait for the server to send states to you. This way you will get a nice and responsive sound/animation, but it might not always be accurate to the real simulation. This is no biggie though, especially not with rapid fireing weapons.

If you're serious, spend a weekend looking trough shapeImage and how it manages states on the ghost and on the server and seperate the two completely (it is already seperate to some degree). Tons useful and time well spent.

Edit: Grammar.

#8 I can a level if you do this project, I own 3d World Studio and a large number of industrial city textures. My email is Methril at shaw dot ca.