Naming conventions for spawn points

This is technically specific to workflow, not pure design, so this may be the wrong place to discuss it, but I was wondering if there was anything approaching a standard paradigm for naming and keeping track of spawn points and other game logic-specific objects in a scene. My use case calls for a fairly large number of points (typically in excess of 200 per scene), and I've taken to using ObjectType_Scene_Number, as in SpawnPoint_ForestScene1_01, or LootSpawner_ForestScene1_03 and so forth. The advantage is that this is very simple, and it can be done procedurally by an editor script that just iterates through some list<T> of every spawn point in the scene and numbers it incrementally.

The downside to this is that it's not human-readable; if I want to write cutscenes or other content outside of the editor to spawn specific characters at specific locations, I need to have the editor open next to me so I can look up each point's name. On the flip side, if I make everything human readable (as in SpawnPoint_ForestScene1_UnderTree01 or SpawnPoint_TavernInterior_Table1Seat3), manually naming each individual point becomes a lot more annoying, and the level design workflow suffers.

So is there an established precedent I should be drawing from? I'm tempted to stick with scene + number, since it's extremely simple, but that will make it nearly impossible to read a scripting command and figure out what it's doing without looking up its spawn points in-editor.

 

From the few observations I've made, many people still do this sort of thing in the least efficient way possible. You at least know it's a problem and are thinking about it, so you're ahead of the majority already

I'd start by making an empty game object to organise different spawners in the scene, just to make the editor easier to use. Maybe even a hierarchy with just "Spawners" at the root, Loot/Enemies/NPCs/whatever objects under that, holding groups of other objects. Then either a single player spawner if it's that sort of game, or another object holding several player spawners for choices.

Since you iterate through it with editor scripts, I think it's a good idea to automate naming at the same time. Give everything a sensible tag, like lootspawner, monstercloset or whatever fits the style of the game. Naming the spawners after the scene shouldn't be necessary if you use the hierarchy, but now the editor script can reparent and index them with a unique number after the name.

If your spawners have some sort of reference object it spawns things near, it could become an element of the name too. You'd need to have a public field to drop a nearby object into so you can get some sort of geographical naming in there.

 

I'd probably follow orbs advice before what I'm about to suggest - because experience ^^.

Using what you know about the levels - it could be devised on top of a 0-1 grid layout (top down) so YOU know where the spawn points are located ie similar to UV coordinates. 0 to 1 vertical, 0 to 1 horizontal.
Then it makes it easy for you - if spawn point .03, .76 pops up, you know it will be located near the bottom right of the level. If the cut scene is located near origin of the level (.5, .5) you know (approximately spawn points .4 - .6, .4 - .6 will be the ones you want to use for that scene.
This is approximation coordinates rather than exact numerical identifier, but I think would be a lot easier to use/implement, if approximation is good enough.

 

Hmm, that's an interesting idea regarding the UV coordinates... I never thought of anything close to that. I've been spending a lot of the day messing around with the content creation workflow, and it's looking like cutscenes are definitely the biggest challenge- randomly placing objects is as simple as finding a spawn/item point that isn't currently in use, but when you're writing tons of scripting commands in the format #MoveCharacter Bob <somespawnpoint>, something like "SpookyForest_UnderSmellyTree01" is way, way easier to mentally picture. It makes the level design workflow a lot more obnoxious, but that only has to happen once per scene, and we're going to have tons of cutscenes in each major area, where I could see the simplified format really piling up and becoming annoying to the writers.

 

In addition to giving your spawnpoints a unique tag as orb suggested, what about adding a script? This way your editor addon can iterate through the scripts instead of going by GameObject name. And the script can register itself with a manager so you don't have to search the whole scene for a named GameObject when moving Bob to <somespawnpoint>.

The script could even have extra (possibly editor-only) functionality such as making sure it's sitting on top of the terrain, in case you raise or lower the terrain as you tweak your levels.

 

Yeah, make use of the component-based thinking. Registration components seems like a perfectly good solution. The component(s) could also set any tags, in case you search for things by tag in the editor hierarchy.

 

Oh yeah, we're definitely doing that; long story short, anything in my scene that the level manager or an NPC might need to locate, including spawn points and other NPCs, has an Entity component (bad name for something within an ECS workflow, I know). Entities are basically just an ID, a type enum, and a get/set/compare function, and one of the level manager's jobs when it first initializes a level is to run one pass of FindObjectsOfType<Entity>, then iterate through it and build a master dict of the entire entity tree and a couple of queryable sub-dictionaries organized by entity type. It's slow, but it happens once behind a loading screen. Once that's done, any calls to spawning/pathfinding/whatever start with a call to LevelManager.GetEntity(ID).

 

Is this going to be multiplayer? Doesn't sound like it, but in case it is you would want to separate data classes from components, and components are basically behavior and have a reference to the data class. The dictionary would still contain the components. But most likely you would have a dictionary containing the data classes also.

Sometimes projects just aren't far enough along to see where that will matter. So thought I'd throw it out there.

 

This particular project is singleplayer, but that's a great pattern that I've found myself using nearly everywhere else in the project; serialization in Unity is always a pain in the rear end, but I've found that everything becomes considerably easier if all actionable data is kept in a small serializable class that is held by a larger container (usually a monobehaviour) that actually enacts behavior. It makes scene setup more involved, but considerably simplifies persistence and saving/loading.