next »

[Hima]

  I was wondering if there's a standard way in the industry to measure a game engine performance? Or when is it to say that the engine is 'up to standard' or ok? I'm making a game engine for my project and that's what my teacher told me to find out in order to measure whether my project works or not.

  In case if there isn't any, what do you think should be a good way to measure the performance? I think I should compare it to other 2D game engines, but any suggestion on how should I do it would be really appreciated.

Thank you in advance ^ ^

[Overkill]

Well, frame rate in frames per second is a pretty standard (or at least "good") way to measure real-time performance. If you're getting less than 60fps, it usually becomes visibly choppy. 30fps is probably acceptable, but preeetty skippy.

Games should only dip in FPS when there's lots of processing going on. When you've got an empty screen and nothing especially taxing being updated behind-the-scenes, you're likely getting the max FPS your engine is capable of doing.

If you have vsync turned off, you better hope you get way more than 60fps on an empty screen, or you're probably doing something wrong somewhere. And make SURE your average game scenario will fit nicely around 60fps or above. The only time your game should be choppy are when it's got a lot of stuff happening at once, like in a shmup with 5000 bullets coming at you. And even then, you'd probably like to avoid that, if you're making a bullet hell shmup

Make sure your game uses sane timer code, so that it can run smoothly across different machines. If you notice bottlenecks, eliminate them through your own intuitions, or hopefully, a profiler if you can.

Really, comparing performance to other engines is really only useful if you know that your game is running below your standards. If two engines are capable of getting high FPS, and both have cool games, the underlying performance issues are less serious.

[David Pittman]

Measure the number of triangles (or sprites, if you're doing a 2D engine) you can draw while maintaining your target frame rate (60fps, ideally, but many commercial games settle for 30).

Measure the number of pixels you can fill at that rate. These things are more hardware issues than engine issues for modern 3D games, but your vertex and fragment shader efficiency still matters.

Maintain a *steady* frame rate--amortize the cost of expensive algorithms like pathfinding across multiple frames if necessary, and avoid page faults if you're working in an environment that uses virtual memory.

Measure the number of animated characters, the number of lights in the scene, the number of physics objects, etc.

Measure how your performance is affected by increasing the complexity of the scene. Spatial partitioning and frustum culling should be used to avoid rendering things outside the player's view, and broad-phase collision detection should be used to avoid testing O(n^2) physical collisions.

Measure your memory usage. This is easy to overlook on the PC (and difficult to test realistically without a mass of content), but it's critical when developing a competitive engine for consoles.

Where possible, compare your results to modern engines. Build extremely dense maps for UT3 or HL2 that push those engines below acceptable frame rates, and then see how your engines compares. Can you get more or fewer animated characters and dynamic lights in the world before performance degrades past playability?

[Klaim]

Triangle count is less relevant than rendering pass (batch) count these days.