N00b question - Level build approach

Hi all,

Just a quick question on Level building theory and how to keep the resource level in check (Because I suspect the reality of resource management is very different from just “Place objects”, “Load Object”, “Play Game”)

So specifically, I’m playing about building a Desert Strike style isometric shooter. Watching old clips of Desert Strike gives me a rough idea of the size of the map, and the sort and amount of objects and scripts required, and how much Update() power is going to be needed.

So I could sit down and build the entire thing and put down enemies and so on. However, being a n00b a this I’m wondering how much of a strain this would put on the engine - some of the Desert Strike levels for instance might take 3-4 minutes flying at full tilt to cross - and if there’s some accepted method of building and instantiating Game levels that I should know about.

E.g. Break levels into smaller levels that load as you enter them? Only instantiate enemies when the Player comes within visual range? Or “turn them on” when the player is close? Does large Prefabs take up less or more juice than, say, the built in terrain builder?

…Or am I just worrying about nothing and Unity will handle a reasonable large, non-egregious, Game scene without too much hassle?

Cheers!

Its a top down shooter so you will not have the troubles of a free camera. I would say it will be pretty easy to get good performance out of it

2 Likes

It is also worth keeping in mind that desert strike/jungle strike games were all about having huge tiled textures all over the place and actual number of objects in game was small (due to hardware limitations).

I think you will not have a problem with performance, as long as you use static meshes for the landscape.

1 Like

Hey - thanks for the reply

I’m running it in 3d, but fixing the camera at a set angle to create 2.5D and moving it along the x and z axis via the Update() function…is that what you mean by not having free camera issues? If so does simply code on the Update() not take up much oomph then?

That’s pretty much the plan - have quite flat, tiled ‘terrain’ with a reasonable amount of open space (don’t want to keep crashing every time you blink), but obviously over the course of a level you could easily run up to a couple of hundred bad guys, and that again in terms of buildings, pick ups…again I don’t think that’s far off desert strike/jungle strike levels considering the amount of stuff you could shoot.

Can Unity handle this pretty easy? I presume by using static then you are lessening the load significantly?

Jungle/desert strike never had hundreds of enemies. I played jungle strike a lot. You’re looking at dozens. Not hundreds.

For example, take a look at this map:
http://www.vgmaps.com/Atlas/Genesis/JungleStrike-Washington,DC.png

This is 20 or 30 destructible objects total.

When enimies spawn there are almost never a lot of them. 20 or 30, again.

Unity would have no problem handling this. Unless you go over the top with polycount per enemy.

Like just about everything it’s entirely dependent on your own skills. A new developer may struggle to get good performance, but Unity itself is capable of a hundred thousand or more with the right approach.

https://discussions.unity.com/t/681124

Ah ok cool - looks like there’s some terminology I’m misusing. So…

As a point of reference, so we’ve got something common to work off…here’s the first level playtrhough from YouTube for Desert Strike (Gameplay proper starts at about 3:40)

https://www.youtube.com/watch?v=ceyLmiIkwO4

What do you mean by destructible objects? Are you literally talking about things you can ‘destroy by shooting’? If so do you mean in terms of “on camera” at any given time?

I’m sure I’m thinking of something else - in the first minute alone there’s 9-10 enemies, 2 good guys, 4-5 tents, 2 Radar Stations, and a road block that can all be “destroyed by shooting”. Not to mention I think each individual panel of the fences around the Radars can also be shot.

That’s one small area of the entire level…So what do you mean by your definition?

(Sorry about this but I don’t have much experience in correct unity/programming language)

You will have perfect control over how much of the scene that is seen in a single frame. Occlusion culling will be very effective.

1 Like

Destructible object is anything you can blow up in jungle strike. Usually it is a static or animated tile which switches to an alternative state when its hp run out. An “enemy” is a separate thing, because it can move around.

Also, I mean total in the level at any given time, and not on camera. Sega genesis had 72 kb of ram total, and could run at 7 Mhz. The levels were very sparsely populated, and instead featured enemies that could shoot you down quickly if you didn’t fullfill an objective first.

For example, in the beginning where the heli blows up the radar - there are 4 objects onscreen total. Helicopter, radar dish and AA turrets.

Next screen - 5 objects. 2 enemis, 3 groups of tents, and an npc.

Actual example.

Six objects on screen total:

3274218--253134--2.jpg

One group of tents is a single sprite/object/entity that acts as a whole.

Rocks and plants are painted on background. The background is a tilemap and is not an object in usual sense.

For modern hardware the whole scene is a big joke. It is possible to throw hundreds of individually controlled enemies and get manageable fps without any optimization.

UNLESS you go out of your way with high polycounts (like modeling each enemy in high detail), throw mesh colliders onto everything, forgot to utilize static meshes and go overboard with lighting (which jungle strike didn’t even have).

But even in this case you’re very likely to end up with playable framerates.

1 Like

Ah right - so similar to Desert Strike I can set the camera angle so it doesn’t show the horizon, the adjust the culling distance so it only shows what’s visible, which will always be at a fixed distance? Right?.

Farclipping plane + occlusion culliing.

edit: Farclipping will not do much to a top down shooter though

Ok cool. So basically as long as I don’t ever clutter my levels with high-def stuff, highly interactive “Stuff”, and make it Static where possible, that should be ok. Cheers.

Just one other thing - you mentioned enemies Spawning above. Is that because common practice to only instantiate enemies when the Player gets within a certain point? (So something like a empty game object that sits on the map then fires an instantiation script when a player interacts with a large sphere collider?)

In our game we sleep any agent that cant hear bullet fire from the players (Becasue of distance). If they are not active and seeking player offcourse

Sleep?

Is that a technical term or do you literally mean you turn off all scripts controlling action/movement?

You’ll need to playtest it. For a jungle strike kind of map you could actually keep objects active in the world, but the problem is they won’t be doing anything useful, just eating cpu time for no real reason.

So you could put them to sleep, if the player is far away, or could spawn them when you need them.
Making them sleep is a better idea, because spawning might require extra motions/effort to get it right (plus you might need spawning pools).

I’d recommend to go with “putting them to sleep” appraoch for now, and just start experimenting in unity editor. If you hit performance problems anywhere in particular, you can ask for help again on forums.

For now I’d recommend to try making first prototype where all enemies are already present on the map and see how well that works. If it doesn’t work well, consider making objects sleep or spawning them dynamically.

2 Likes

YOu can disable component on an object. When that happens, the component no longer calls “Update” methods.

You can also disable entire object, which will effectively remove the object from the world.

I’d recommend to concentrate on doing tutorials and experimenting in editor for now.

Ah right - thought as much

Cheers for your help!