What is your favourite way to make a level scenario?

Hi guys!
I would be very interested to learn how do you prefer to setup you level scenarios in your games (I mean a set of triggers wich track some conditions and run some actions on events).
What are the best practices? What is you favourite way? What way do you like least? Maybe some tools do you use for this?

I have not so many experience in gamedev, so I tried 2 ways only in my projects: individual scripts (with some common triggers functionality) and visual editor (hierarchical triggers structure with custom inspector drawers). And both of them are acceptable for simple scenarios (10 or less triggers), but showed their limitations when scenario becomes rather complex.

I will be very grateful for your opinion and for any prompts, hints and tips

 

Typically I ask people for feedback in the game design section of the forums. I also make a habit of reading through other peoples posts there that ask similar questions to mine before I post.

 

You are like a passive aggressive version of @JamesLeeNZ

 

Hmm... actually it was not a feedback request, but question about best practices... but OK, I'll close my question if it breaks some rules here...
PS what about similar posts - all of them ends with smth like "you should work hard to get what you want".
Maybe I missed something, but all I found is like this...

 

Well then go by that

 

The answer to this question is almost always it depends on your game type.

 

Just as @BoredMormon said the "best" way depends on your game.

This is just a natural part of your project. One of the first things you should do after designing your game (concept, rules, basic level layouts, etc) and before actually beginning any development is to look at your design goals and come up with the "best" way to fulfill them. For me "best" in this context means the simplest way of achieving what I am after. This may take several iterations continually refining things until you have the simplest (yet still easily expandable in case you get a great idea later on) method possible allowing you to build your framework as quickly as possible.

Don't be afraid of spending time trying multiple ways; in fact expect to do so. Each new solution you come up with and test provides valuable experience you can draw from in future projects. Your initial solutions will improve and you will find you "nail" the best design faster with less iterations as you gain experience but expect to always learn and improve.

If you want a better answer more specific to your current project you'll need to provide more specifics about your game when asking your question. Describe what you want to accomplish in detail.

 

thanks for the answers guys.

finally, your told me something like "find your way by yourself"
I know that this is the mostly right answer, but often useless unfortunately...
I hoped someone share his usual ways to to this, like "I usually use A-method A-cases and B-methid for projects like B, because ___ and ___". but it seems like all methods are under NDA or are too costly know-how to share it
I dont believe that you reinvent the wheel for every project you work on

about my game - of cause I'll post it in WIP forum when I will make all gameplay features I conceived. Hope I'll do it this month already. But it will be about gameplay, not about scenario editor

anyway - thanks to you all for participation

 

In a way I guess it can be seen as reinventing the wheel for each project but what I meant is that different approaches will work better for different games.

I think (based on all of the videos I have watched) the usual way is for people to simply plop down prefabbed GameObjects throughout a scene to design a level. Then they place colliders here and there and so forth. So that may be your best bet.

My personal preference is to use some kind of map editor. For 2D this is a 2D tile map editor. When I create a 3D game I will buy or build a 3D world editor just depends on what is available on the Asset Store. I don't use the Unity physics system and prefer to have a data structure that I can easily access at any moment to not only determine what should be drawn where but also check for collisions and pull out other data such as object spawning, preset enemy and item placement portals and so forth. It is just the way I prefer and find this sort of data driven approach much more productive than designing in the Scene Editor. I find the Scene Editor and normal workflow very tedious. Dragging objects here and there. Creating colliders here and there. However, you might like that. A lot of people seem to love that part about Unity. A lot of this just comes down to whichever way works best for you and your game to make development as easy and quick as possible.

 

I think there are some best practices that apply to any game type. The Discussion forum seems like a good place to discuss them.

• Organize your GameObjects as children of empty (0,0,0) GameObjects that act as "folders". Don't put all your GameObjects in the root level of the scene.
• I like to organize static world GameObjects in their own "folder" (empty GameObject). It makes it easy to mark the entire folder static.
• Define and adhere to an organization scheme for the other GameObjects. This does depend on your game, but here are some ideas:
  • Separate folders for Triggers, Characters, and Managers (data-management GameObjects with no physical representation in the scene).
  • Or separate folders for geographic areas of the scene (Porch, Foyer, Kitchen, Bedroom, etc.) You can even use subfolders in each of these for Triggers, Characters, etc.
    
  • Add a Test folder containing temporary GameObjects that let you press Play and test the scene immediately. It's much more pleasant than loading your title screen scene and going through menu scenes just to test out a change in your level. You can also add temporary triggers to jump your player to the area of the level that you want to test.
• Make every GameObject (as much as possible) a prefab. This will make it much easier to maintain changes. As you're saving everything as a prefab, it may seem extreme and silly at first. But after you have to make a few changes to GameObjects, especially GameObjects that appear in more than one scene, you'll be a convert.

Any other "universal" best practices?

 

I see this more as project related best practices instead of level design BUT I definitely agree with you. Organization is very important. I use some naming standards (well standard for me in Unity anyway) such as prefab names all prefixed with "pf", gameobjects with "go" and so forth.

I have tried exposing global variables on each script as needed and on one master script holding all settings. Each approach has its pros and cons but I think I prefer the single master settings script because it wraps all of that stuff up in one spot. I don't set references to gameobjects and other scripts and so forth in the Editor because that is kind of like creating a hardcoded dependency. Instead I set that stuff dynamically in scripts. Although I am considering using a ReferencesManager component in the future. Setting references on that from the Editor and then any other class can get a reference from it.

I really dislike the way the videos I have watched encourage tight coupling and binding references in the Editor.

 

Wait what? I typically see the editor references as less coupling and dependency then something actually written in the code. Unless you are doing some design pattern tricks.

I'm missing something here, care to elaborate on how you set the references up?

 

Basically any single gameobject that needs to be referenced by many other things is a singleton. The rest of the stuff is all built dynamically instantiated from prefabs pooled in my ObjectPool singleton which begins with x amount of objects and can grow as needed. General communication is performed with my NotificationsManager class (a singleton). Access to scripts / specialized communication is run through interfaces. For example, if an object collides with another, the object that detected the collision (I use only raycasts and boxcasts) uses the IInteraction interface of the other object and uses that interface's methods to communicate with the other object.