A better way to edit portals

[Blastfrog]

Engine-side, portals do exactly what they should and there should be no changes. Functionally, the existing implementation of portals is already fine, it's just a major pain in the ass to edit.

 

I once had the idea of having a fourth 'integer' spacial dimension, different "zones" or layers, wherein it'd be multiple self-contained maps yet act as one, sharing sector and line tags, with the ability to travel through them, but this idea sucks for several reasons. It would be such a refactoring of the very way the engine handles space/collision/etc, so nontrivial it'd effectively be a rewrite of the engine. It's a heavyhanded and unnecessary approach to solving the problem that would get nowhere fast, even if some engine did implement it (it's not like other port authors would be keen on following suit).

 

The above paragraph is largely irrelevant and useless, I simply mention it because I want to note that I've considered other ways of addressing the problem and concluded that strictly editor-side improvements are the way to go, after weighing the pros and cons. The 4D idea sucks so bad that it wasn't a difficult conclusion to come to.

 

Ahem. Digression aside, the idea would be that editors could allow for editing the levels as you would layers in Photoshop. The editor first automatically identifies and internally numbers "clusters" of sectors, any self-contained space not physically connected to other such self-contained spaces. These would be the equivalent of "zones" as I described in my ill-thought concept detailed above.

 

These layers would be given automatic offsets, and would "lie" to the user about where the geometry really is. The way Eternity handles stitching the layers together in the automap is what I had in mind. The whole purpose is so that one can actually line things up easily and work quickly when dealing with portal-connected layers. Doing it all manually, by hand, is tedious, cumbersome, slows development, and discourages making full use of what the portal feature is functionally capable of because the mapper would rather not deal with the hassle.

[Mordeth]

I'm using the 'layers' approach. The entire map geometry is divided into stacking horizontal slices, from a basement layer to ground level to first floor etc. Those layers are usually between 128 to 320 units high, depending on need. Often an indoor part of a room within such a layer can get its own separate private layer. Detailing stuff (with anchored or edge portals) is used on the fly without a pre-determined plan.

 

Each layer has a dummy sector 'anchor' in the same relative position, which you then use to position new geometry in the right places in the adjacent layers. This is important, since every layer has to be precisely positioned to avoid errors.  A sector that needs extension into a different layer gets copied there, using the anchor for correct positioning, then adjusted for height.

 

It's not the technique or (lack of) tools itself that makes modding with portals cumbersome. It's the fact that an adjustment in a room might very well affect the geometry of the stuff in the different layer above/below this room and would need adjusting too. Once you put something down, it's that much harder to adjust later. Want to make this room's ceiling higher because it looks better? Too bad, there's already geometry above it that you find very hard to change accordingly. Like, instead of checkers you're now playing 3D chess. Not to mention that you can't preview your new room, if that room depends on another portal area (or two... or three...) to be complete.

 

There's more to 3D then just having nice architecture. There's gameplay that ought to be elevated to 3D as well, both in flow as in combat. And I've found that is the hardest part to get right.

[printz]

 

8 hours ago, Mordeth said:

 

I'm using the 'layers' approach. The entire map geometry is divided into stacking horizontal slices, from a basement layer to ground level to first floor etc. Those layers are usually between 128 to 320 units high, depending on need. Often an indoor part of a room within such a layer can get its own separate private layer. Detailing stuff (with anchored or edge portals) is used on the fly without a pre-determined plan.

 

Or you can have a semi-random twining of areas, where for example both the highest and lowest belong to the same layer (because they were the first you designed in the editor), and you later add a middle layer accessed through portals. It becomes too unwieldy to "refactor" the map into orderly layers, so you just make do with this. I think edge portals make it easier.

[kb1]

 

On 5/22/2017 at 8:34 AM, Blastfrog said:

Engine-side, portals do exactly what they should and there should be no changes. Functionally, the existing implementation of portals is already fine, it's just a major pain in the ass to edit. ...

What if the two "overlay" portions were side-by-side as usual, but the editor showed a "greyed-out" image of the lower side, under the workspace of the upper-side, as if you were tracing an image by laying a thin piece of paper over the source image? It would be as if you built all of the lower level, took a screenshot, and then used that picture as the background of the editor's workspace. Would that get the job done?

[Blastfrog]

5 hours ago, kb1 said:

It would be as if you built all of the lower level, took a screenshot, and then used that picture as the background of the editor's workspace...as if you were tracing an image by laying a thin piece of paper over the source image

Yep, onionskinning. Your idea differs slightly in implementation, but it's pretty much exactly what I had in mind.

 

In fact, your version is probably better than mine. I thought to have all the layers "synchronized" on the x,y axes, and select which one you edited and which ones showed as onion skins. Your idea is instead to keep stuff where it is in the view, just bring over a reference overlay when and where it's needed.

 

5 hours ago, kb1 said:

Would that get the job done?

Absolutely. It would make anyone's lives a thousand times easier when dealing with portals.

 

I don't want to have to meticulously plan every single detail of my room before I build it, having to constantly check if I have the portals (even single vertexes) at their correct relative positions every time I make a small change. It slows development to such a crawl that it really damages the practical usefulness of the feature.