It really depends on the code behind it as well. Bad coding can ruin a great looking scene with average polycounts
That era of computing had characters from an average of 500 - 800 polygons.
The essence of a great model is low as possible in regards to polys, with a great looking texture.
This also applies to game environment, once you get the hang of it, you will develop your own style and thats probably more important then anything, so you dont look like everyone else, and hence your game will shine through.
As an example, think of a street light.
lets say it has 3 sides for low, 4 sides for medium and 5 + sides for high quality.
3 x 2 = 6 polys, we are just thinking about the straight pole for now.
4 x 2 = 8 polys
5 x 2 = 10 polys
now lets say you had a game with 50 streetlights somehow all being displayed at once.
6 x 50 = 300 polys, but with 50 seperate objects.
8 x 50 = 400 polys, but with 50 seperate objects.
10 x 50 = 500 polys, but with 50 seperate objects.
Individual object amounts can also create a slowdown as the game system has to evaluate each one and decide whats in front and whats behind etc..
300 - 500 polys is not much for an average system at all, but lets say each pole was 500 polys.
500 x 50 = 25000 polys.
Ask yourself as well, how important is that particular media to the overall game.
If your flying by them in say a car game, they should not require that amount of detail.
if by chance the game was a poster sticking game, where you stick posters all over town onto the poles, they would be more related to the game.
The best reasoning to follow is this.
[1] How important is the 3d object to your game, if its not important drop the polycount.
[2] How many of these objects will be displayed at once. factor the amount by the polycount.
[3] Does the camera distance to the objects warrant it to be super detailed?, imagine a top down world with a long camera view, a very low polycount with a great texture will look very similar to a larger polycount object from that distance.
[4] How does it run on your computer with the collision and mechanics of your game, a model might behave well with your test loading of just that object, but when you start to add the mechanics it might slow down a little.
[5] Once its running on yours well, you have a starting point, from there test it on friends machines who might be faster and slower then yours to see what problems pop up. One machine might be slower but due to its video card it might handle more objects and polys on screen then yours etc..
In order to evaluate your engine well, create simple primitives with the amount of polycounts you wish to acheive and textured with the size of the texture your assuming is what you want.
It does help to animate them with a simple pattern so thats factored in.
Imagine a sphere with say 500 polys and a limb of another sphere with say 100 polys. This way your testing a 600 poly object with a texture that can have a simple animation as well.
If your computer can handle say 10 of these on screen, but the 11th one craps out the framerate you have found the edge to your systems capability.
This way you keep tweaking this testbed with simple 3d objects, but with the polycounts your aiming for. Later on replace the models with the simple primitives you exported from your favorite package.
