I found this statement in another post from the Wizard of Id

"So it isn't a problem with the engine and a bigger problem with end users not optimizing their levels and blaming the engine, effectively using resources and balancing levels has been an issue with users since FPSC classic."

I am having major performance issues with an old dense map where the system freezes for a second or two and then catches up.

The Wizards comment seems to address this... Can someone explain Optimizing and Balancing levels??

Thanks

I think he mean that most users do not think about how to use the assets in a perfect way.
Where did I need a high resolution texture, where not?
Where in my level is physics necessary and where not?
Is it really necessary to have active AI all the time and which scripts need to run?

And you can ask yourself these questions with shaders, lights, objects, weapons and so on.

I didn´t say, you should go as far as .kkrieger, but at least you should try to optimize your game like any other professional studio did.

For me I do the following to maintain preference:

- Camera Distance set to very low
- Terrain Size sliders set very low
- use fog to mask hidden terrain and camera distance falloff
- I use HIGH or MEDIUM for grass shader quality (never HIGHEST).
- I use static trees more than animated trees
- I keep bloom settings very low
- I avoid lightrays on complex maps
- I try to use similar models on my maps to reduce draw calls ( (i.e. same rocks different rotations and scale)
- spread out your enemy characters and dont use too many per map
- I rarely ever use models that use texture sizes more than 1024x1024
- like mentioned above, i use "alwaysactive = 1" sparingly (i.e. a door should never use alwaysactive)
- terrain areas the player cannot see are flat

The only engines that typically do the optimization for you, are map editors for existing games. But even with their restrictions and limitations per map, people who have no concept of optimizing may still experience lag/performance issues. So its really all about understanding what each aspect of whats in your map is doing in relationship to memory consumption.

This is worth a read.
From the master Wolf: Optimization for End Users

Edit:
Bloom really lifts the look and feel of any level, but I always turn it off. On my system, even on a flat level with just one model and bloom set to 1, creates a stuttering effect when moving around, even tho the frame rate stays consistent. So while it looks great it feels terrible.

Reliquia....

I don't have much more to add than what the other respected users have mentioned above. Wizard of Id's comment is correct, as to others that have mentioned tips and tricks in the present and past, not every solution may fit the problem.
In classic, if a hidden mesh was present causing lag, the only way around it, was build around it, or revert to a save where it was not present.
I am curious is this localized or in general on your map?

for me, i do lots but heres some of my main tips:

static/prebake lighting, definitely not lots of dynamics!
trigger enemies
make sure if your map is large, most of it is culled at any one time
never have 2 whole vistas visible at once, usually a wall on at least one side of the player
polycount/drawcall budgets and intense optimization thereof (for me its about 60000 polys at any time max)
do not use terrain/do not lightmap terrain
OVERLAYS--- make billboards out of stuff you can never walk to
all settings lowest except entity
no gameguru shaders (all shader sliders at 0)
camera distance ALWAYS less than 13 MAXIMUM
atlas texturing (all media on one single giant texture)

Yay I am famous

You could write a book on the subject matter and people have.The biggest issue I found with Gameguru users in general is creating flat terrain outdoor levels. If you have a look morning mountain stroll level I created many moons back which forms part of gameguru, that level is massive but the terrain isn't flat and is littered with trees, entities and AI and you get a decent frame rate out of that level and I didn't even had to use triggers to spawn AI, it contains well over a 100 AI.

Long corridors, is another frame rate killer.Users also try and fit an entire game into a single map, it's completely unnecessary none of the big studio do, even open world levels is highly optimized and uses specific level rendering techniques which gameguru doesn't possess, it definitely requires some ingenuity and planning and sketching a rough map of your level.

Gameguru makes it extra hard as content produced for it has to be used in all possible ways, in studio games if there is a static box or wall feature or entity like a building the player wouldn't be able to access from behind, polygons is removed from it which allows for far more detail in general, in gameguru that is not the case and content isn't suited for such large detailed levels.

You far better off splitting a level in parts, instead of try to cram every thing in a single map...

i had noticed that gameguru seems to have almost no problem with large amounts of characters unlike its predecessor. It just seems to be if they can be seen from far off that can be taxing and show the cracks. my tips are about half for framerates and half for general map optimization.

i seem to notice the less gigantic of an area you show at once, the less wonky framerate jumps you will have. I try more and more lately to use forced perspective and skyboxes for backgrounds too.

Draw calls and polycount really are the main areas of slow down in general and AI of course. Get those down and you tend to have a more fluid experience. I found that AI tends to be the biggest killer even on a heavily optimised map. I haven't tested the latest version though, AI may have improved.
This map ran pretty well considering its size and density. Originally it was lucky to get into 30 fps but I had it running way faster by the time it was completed. All I did was optimise the draw calls and reduce the polycount on all the objects. Although saying that, it was a long laborious process and I was sick of the level by the time I had it completed. Especially when AI was tested to much slowdown or at least more than a mere 10 AI should. I'd need a few more than that to make it look busy and not a ghost town. I included a demo of the level to get some feedback on speed which is still available.
https://forum.game-guru.com/thread/216180

If DX11 has been implemented right, polycount apparently "should" be less of an issue than it used to be.

I've been doing a lot of looking about on the internet for advice on poly-counts for game ready assets the last few months, and pooling and averaging the recommended poly-counts for game ready assets, and while doing that i came across a lot of little references that apparently with Direct X 11 texture size seems to factor higher than poly-count a majority of the time. Whether or not that's actually true or not, i don't know, nothing I've read had any sort of officialese to it, it's just things people have posted on various forums, but hopefully it's true and now that we have Direct X 11 in Game Guru that will be the case here too.

One thing i've noticed when researching recommended polycounts, is that the general consensus for game ready assets is a lot higher than i thought, i've been trying to keep all my assets below 5k, but apparently very small items should be below 10k , and handheld items, like mugs, phones etc should be below 20k (for foreground/HQ scenes).

So i'm torn with what to do, do i go with the advice i've researched and seems to be general consensus, or do i go with what i have been doing all along, for example I've just started on some kitchenware models, and the mug is around 7500 tri's, the figures i researched say that's way below the max poly-count for that type of asset, but my gut says it's double the poly-count i want.

Well when it comes to GG lower will be better, Unreal and Unity for example will handle far more complex objects better. But, polycount is nowhere near as important as draw calls. They do add up after awhile though so staying low on your assets is a wise choice for GG generally.

Drawcall count is King generally though for any game type 2D or 3D. So for example in the demo scene above I linked to, if I had 2 objects close to each other of the same type, I converted one to load into Blender, cloned it and saved as a single object. This reduces GG's main object count by merging the two into one and also halves the draw count for those objects. Rinse repeat, sometimes you can merge several objects that have the same texture you can get big speed increases for it. I also added LOD stages later on, but i am not convinced they helped.

Polycount is a very 'artist' and 'engine' variable, what's good for some is not for others, the same for texture size at the moment I am using this scale for my workflow:

Low Poly = 0 - 5000 max
Med Poly = 5000 - 10000 max
High Poly = 10000 - 20000 max

texture size for PBR I am using 2048x2048 mainly and 1024x1024 for small assets what I can save in ploys I put into textures and the normal map with a lot of detail seems to be ok at 2048x2048

I am also using .PNG to create my maps and when happy I only export to .DDS once, DDS is very lossy the more you save it the more 'artifacts' show up on your texture so any edits I do on the PNG's then export to DDS.

Again all this is personal preference but this is what seems to work for me.

I strongly recommend anyone wanting a good example of an Optimized Balanced Level is to take a close look at how the level Mountain Morning Stroll was designed. This level was designed by the person who talked about "Optimized Balanced Level," Wizard of id. The first thing that impressed me was that he used 100 AI characters. It was their placement that made it work and kept the player on his/her toes. Also, can't ignore the terrain design. Fantastic.

for gameguru, i strongly suggest cutting all of those polycounts and texturesizes in half. know your audience!

remember as well that the size of the texture and the polycount of the objects do not determine the quality of a scene. replacing all of your lowpoly details with extremely high-res textures and high polygon meshes will not suddenly improve the look of your game dramatically, but rather drastically decrease the frame rate.

it's important to use as sparingly as possible, at all times.

for asset texture size, there is no need to use a 1024 or 512 texture on an asset that will never take up more than 200 pixels of screenspace. if an object takes up 200 pixels of screenspace at the closest the player can get to it, then it should have a texturesize more like 128 or 256 if you're being generous. i tend to go smaller than the actual amount of screenspace by a bit since with the lighting, the shaders, the shadows, and the way 3d engines nicely blur blown up textures and their normal map details, most won't notice except people nitpicking specifically to pick out faults.

To be honest you need a fairly powerful PC to play this. On my old system this ran in slow mo. I don't consider this demo to be anything like optimised. Now the Escape is far better imo, as that ran fairly well even on my old system and is even better with my new one