Difference between revisions of "Release Raptor:Level Editor Basics"

From Arcen Wiki
Jump to navigation Jump to search
 
Line 54: Line 54:
  
 
Note that the game makes a backup every time you save your level with actual differences in it, so you can save super frequently (these are miniscule) and never lose any work.  All the old versions are there in case something gets messed up.
 
Note that the game makes a backup every time you save your level with actual differences in it, so you can save super frequently (these are miniscule) and never lose any work.  All the old versions are there in case something gets messed up.
 +
 +
=== Autosaves ===
 +
 +
The game is super frequently (every minute or so, plus every time you hit playtest or quit) saving autosave versions of your levels into a raw Autosave folder.  You will probably ignore this almost completely.  However, if something goes wrong with what you are editing, then this is where to go back and find your work!
  
 
== Troubleshooting ==
 
== Troubleshooting ==

Latest revision as of 13:00, 22 July 2016


Step 1: Finding The Level Editor

Not that we want to hide it, but we also don't want it right in the face of everyone who starts the game. So you have to go into the Misc tab of the settings menu and click to turn on the level editor. Then it will appear on the main menu for you from then on.

Step 2: Learning The Hotkeys

There is a help button in the editor. Be sure to use it! There are TONS of super-useful hotkeys in there. They can save you just oodles of time, particularly if you're swapping out a bunch of skins on objects, or needing to select things en-masse, or needing to replace existing objects with new ones in the same place, or duplicate existing objects... the list goes on.

You don't need to memorize everything in there at moment one, but there are a lot of tools in there that take the editing experience from something that is tedious and takes forever into something that flies by. Once you get the basics down, don't stay in tedious-mode! :)

KEY CONCEPT: Exterior "Doors"

Interior Vs Exterior "Doors"

You might be making a chunk of a level that has one or more rooms in it, and in that you might have some doors. That's all well and good, and those are called "interior" doors. It doesn't mean they are inside -- indeed, there's nothing to say this couldn't be outdoors or a cave. But it means it doesn't leave the current level chunk you're editing.

EXTERIOR doors are very important, though, and have a blue portal marker on them, with a trio of lines pointing outwards from them. These doors are how the level chunk may be connected to other level chunks by the procedural generation.

Minimum of Two Exterior "Doors"

Every level chunk you create MUST have at least 2 exterior doors or it cannot be used by the procedural generation tool. But ideally they should have more than that -- it increases the variability of levels in how they use this level chunk.

KEY NOTE: "Doors" does not mean actual doors. It just means connections from one level chunk to another.

Example: So in other words, in an apartment you'd only have one literal door out of the apartment. Who has two apartment doors leading to hallways? Makes no sense. But you MUST have two "exterior doors" out of the apartment -- so what to do? In this case you use the "exterior wall hole" or the ceiling or floor variants -- ideally a mix of all three. These then represent places where holes were improperly smashed into the apartment, which is great for purposes of thematically letting you move around.

Occluder Bounds

Wait a second, I thought we were talking about doors? Yep! This is an important concept related to that. In the bottom rightmost part of the level editor, there is a little OCCLUDE button that you can toggle on and off. This shows a cyan bounding box that defines the size of your level chunk.

This is always a rectangular box. Aka, if you make your level chunk so that it is a diagonal zigzag, that's great and I'm sure will be very fun to play in, but it creates an overall AABB (Axis-Aligned Bounding Box) around whatever you create. When the procedural level generation is happening, no two AABBs can overlap at all. This is done for speed, mainly.

Why do you care, particularly in a section about doors? Well...

Exterior Doors Must Be At The Occluder Bounds Edge And Pointing Outward

This is why you care about the occluder bounds. If you have an exterior door, it has to be on the very edge of this blue box, and pointing outwards. If you place it inside the box somewhere, even though it's on the "edge" of your nice zigzag level, it will cause all sorts of overlapping problems during procedural generation.

When you save the level you are working on, if you notice your exterior door suddenly shooting forward from where you placed it, this is why. It's putting it aligned to the AABB of the Occluder, so that you can actually see the mistake you've made and then decide how to fix it. The alternative is invisible errors that only show up in munged-up levels.

Thematic Questions About Exterior Doors

In a lot of cases, we're trying to create verisimilitude with real-life architecture, right? Aka, maybe we're making an apartment building. So that means that apartments come off of hallways, and stairwells come off of hallways, and apartments do NOT come off of other apartments. If we are neighbors, you don't get to your apartment by walking through mine.

The problem with the above is that it is BORING. We want the feeling of realism, but more interesting paths through the level. What to do? Same as most games: destruction!

In an apartment, for example, please do what you'd normally see and only put in one front door. Make it make sense! Then there are "wall holes" and "ceiling holes" and "floor holes" that you can put in place. Most of the time those will look like ordinary floors or walls, which is great. But other times those will provide a valid way for me to get from my apartment to yours: just bust down the wall.

That breaks up the flow of what would otherwise be very boring levels, and allows for level constructions that are constantly surprising even though they are set in real-world familiar environments.

What You DON'T Have To Think About

You may now be thinking about what I said about rooms having to connect to other kinds of rooms in specific ways to make sense. Aka, there's not a front door of one apartment that opens into another apartment's front door. Don't fret! So long as you set up your level chunk in a way that makes sense when you look at it isolation (aka it only has one front door per apartment), then the procedural level generator logic will know how to use it. The logic about halls and stairwells and all that jazz is defined based on what folder you have saved your work in.

About Backups

Note that the game makes a backup every time you save your level with actual differences in it, so you can save super frequently (these are miniscule) and never lose any work. All the old versions are there in case something gets messed up.

Autosaves

The game is super frequently (every minute or so, plus every time you hit playtest or quit) saving autosave versions of your levels into a raw Autosave folder. You will probably ignore this almost completely. However, if something goes wrong with what you are editing, then this is where to go back and find your work!

Troubleshooting

Something Doesn't Fit!

1. On the one hand, the object may have an error in its definition that Chris needs to fix. You can go ahead and place the object if it is just slightly off, and he can fix it and your object will self-correct itself.

2. On the other hand, it is more likely in a lot of cases that you have bad rotation on your object. Most objects have a "front" (including walls), and they don't line up properly if you have things with their fronts and backs mixed up next to one another.

2.a. Doorjambs are a common one with this -- you typically just need to rotate them if they stick out of one side of a wall more than the other.

2.b. Walls themselves may seem not to line up sometimes, too. Once again that is a case of just needing to rotate them. There is a little wireframe box that helps show you the "back" of the walls. If those all line up properly, then the walls should as well.

Moving Around The Editor Feels Slow!

If you're using the pan and zoom functions, that is indeed a very slow way to get around the editor -- this one or the unity editor, for that matter. The panning and zoom tools are excellent for little detail movements, but that's what they're made for.

The true movement around this space is meant to work like an FPS game. Hold down the right mouse button and then the WASD keys will move you around while you also are able to move the mouse to point where you want. Superduper fast!

Even that only gets you so far, though -- things get hairy when you're near something but it's a bit above or below you. In those cases, that's where teh Q and E keys are your friend. As in many "6 degrees of freedom" shooter games (Descent, etc) -- or the unity editor, once again -- this lets you move up and down.

Between holding the right mouse button down and then using WASD+QE to move and using the mouse to look, you can zip around the levels really really fast.

Oh! Of course, if you're not using the shift key to "run," then of course you'll still be slow as heck in either zoom, pan, or "right-click-hold move mode." This is because often you'll be doing detail work that means you want to not move too fast. But then when you do want to move fast, hold shift and you'll zip over to wherever.

If you've played many shooter games, then most of this should be pretty second-nature except for Q and E.

I Want Opposite Sides Of A Wall To Be Different Colors

If you want to do this, then simply put two walls back-to-back. Walls have an orientation, and if you rotate them in the opposite orientations to one another they will fit perfectly against each other.

My Test-Start-Location Raptor Is In The Wrong Place!

Oops! It happens to the best of us, no worries. If you built your level in such a way that your test start raptor is either in a place that is inconvenient for you, or even outside the level, then you're going to want to move the level, not the raptor.

Ctrl+A does a select-all in the level editor, so that you can quickly move the orientation of your entire level chunk if you need to. This way if your raptor test starting point is in the wrong location, you can move the level around it. Note that this has absolutely no effect on the actual in-game level chunk when it's being hooked up procedurally into a larger level. Which is good!

A Light Source Is Cutting Right Through A Wall!

If that's happening, it's almost certainly by design in terms of how the light works. See the section below on lighting performance for why some lights work like this.

But the short version is that I wanted to provide you with a very bright and dramatic light, and yet that usually is going to eat the GPU and CPU up in a very bad way. The compromise is to make the light not have shadows, which gives you that tool in your toolbox -- but means the light cuts through walls.

That then gives you a level design restriction in that those kinds of lights can't be placed too close to walls they would cut through without looking wrong: so watch for that, and don't do it. This is one of those cases where a technical restriction impacts the design choices you can make, unfortunately.

Rubble/Debris Is Misaligned On The Tile Grid!

This is by design! Hey, it's rubble. If it lined up nice and neatly, then it would look incredibly strange. Instead we have incorrect tile settings on all of them, which work wonderfully when you rotate them in various ways to get different effects. For example:

Rubble.JPG

And those normally-incorrect overlaps produce this nice effect:

Rubble2.JPG

Fixing Poor Level-Chunk Performance

The game tries to help prevent us from shooting ourselves in the foot performance-wise as we are creating level chunks, but it's still possible to do. Here are the main culprits:

Is your level chunk too large?

The game has to render everything in your level chunk the entire time the player is in it or right next to it. Optimal chunks are smallish in terms of what they have in them.

That said, physical size is irrelevant: a giant empty space takes next to no processing. So it's not really about the overall size, it's about the number of objects in there. A tiny space crammed with junk will perform worse than a huge space that has little in it. Overall it's good to aim for a happy medium.

Is your level filled with interactive stuff?

Walls and doorjambs and so forth are cheap. The game can batch those together, and your GPU eats those for breakfast. But things that might move are another matter: if you've filled your level chunk with things that can be broken or moved, like lights or breakable doors or furniture or little knicknacks or movable debris or boxes, then eventually it will start to chug. More than a couple of dozen of these in one level chunk is a bad idea.

Is your level filled too many different skins?

Remember how I said that walls are cheap? Well... that's mostly true. All walls that share the same skin are combined together, regardless of what the shape of the wall is. However, for each new skin you use for an additional color, that makes a separate batch. More than 2-3 skins each for walls, floors, and ceilings in a level chunk is not only overkill, it probably gets tacky fast.

Is your level filled too many lights?

These are by far the #1 culprit of performance drops. Particularly the huge spotlights that have shadows. Use those EXTREMELY sparingly. If the light is huge and bright, it costs a lot on the GPU. If it's huge and bright but doesn't have shadows enabled on it, you'll notice because it will cut right through walls and other obstacles as if they were not even there.

Those lights are more of a middle-ground in terms of expense, but you have to be careful where you place them or else you'll have really strange light bleed through walls.

The really small and dim lights that only affect a small area are ones that can be used more frequently, but even then it's good not to have too many of them. More than a dozen or so lights of any sort in a level chunk is likely to start causing performance issues, and it is better to use even fewer when all else is equal.

Are there are a lot of partially or fully see-through objects?

Those have to be rendered in forward mode and then blended into the deferred shading path, and that's costly to do. So while these are great to have around, they are definitely something to use sparingly.

Is it still chugging anyway?

In that case it's probably something you should send to Chris so that he can look and see if it's something in the definitions of some objects themselves, or some other optimization to the game itself that needs to be made. The above items are pretty much the main gotchas that an actual level-chunk-designer could run into performance-wise.

Release Raptor Main Page