Level editor for another engine made with Unity

Unity Editor
1

Hi All,
Not sure where to post this question, so I hope General section is OK.

I’d like to create a level editor for some old-school game engine using a BSP geometry, brushes etc… There’s a couple options I consider like writing it from scratch in C# and .NET, but that means a lot of low level things to implement - basically re-inventing the wheels.
Another option is to use Unity for that. However, I still have two options here and I would like to ask you which approach is better:

  1. extending the Unity editor itself, so people would create their missions/levels directly with the Unity editor plus the tools I give them.
  2. making a run-time editor in Unity with full UI and mission loading/saving capabilities. Apart from the splash screen, people wouldn’t know that this was made with Unity and the UI would be completely different to the Unity itself (simpler as well).

Now, the editor would be targeted at hobbysts, rather than professional level designers, so option 1) even if it’s probably easier, looks a bit overwhelming to me. I know that a lot of potential users would find the Unity’s learning curve too steep to dive into it. And then the confusion of dealing with features which they don’t need\shouldn’t could be another layer of complexity that might put them off.

Option 2) would give me a full control over the feature set and the UI, so I could make it a bit similar to existing tools they have. However I’m not sure if this is even a feasible idea. I’m thinking about a typical 3D editor with customizable viewport layouts (2x2, 3+1, 1 fullscreen etc…), dockable panels (optional), ability to generate level geometry from brushes, baking light using ideally Unity’s baking tools (can this be done at runtime?), a regular menu bar and a number of toolbars, floating dialogs etc… Oh, and I like to add scripting abilities to this editor as well - either C# or Python, so people could automate things like brush and object creation with scripts.

Actually this project looks a bit like what I’m looking for:
http://postimg.org/image/ep40tw9gr/

However I’m just not sure what kind of effort is involved and would that make sense from the performance point of view?

Thanks in advance for your opinions.

2

Why would you want to do this?

The way you phrase it it seems like this is just something you want to do for yourself. And it sounds like a very ambitious project that could take many years to complete. How are you going to motivate yourself to complete it? If it was me it would be essential that I enjoyed myself while I made this editor and I would choose the option that appealed the most to me, not to get the end result that I’m after, but to keep me entertained while I work on it.

No matter what option you end up going with it sounds like a massive undertaking to me.

3

If it’s BSP why not look at one of the old BSP editors. WorldCraft/Hammer, Quark and Radiant and it’s variants like QtRadiant and GtkRadiant.

If you are using a old BSP engine I would assume it is based on the old idTech 2 or 3 source. That is what gtkRadient was made to work with.

2 Likes
4

@TwiiK
The reason why I’d like to do it is because the existing level editor for that engine is very primitive and buggy and it takes at least months and usually a year or a number of years for people to complete anything semi-complex. If there’s an editor that is more intuitive and more efficient, then we could expect an increased number of fan made levels, which is ultimately what the community wants. And have more life outside of modding and level editing too! :slight_smile:

There is also my own internal motivation. I just would like to undertake such a project as way of learning things. I’m into 3D, game development and tool making. I understand it’s a long term dedication, but that’s OK. As long as I learn new things. So, yeah, your point on enjoying it seems like a good point. Personally I would do it either from scratch (although that will take even longer, to learn all the low-level stuff) or do it as a run-time editor with Unity.

@passerbycmc
These editors operate on an additive CSG. The game engine I want to target is predominantly subtractive, which really appeals to me. Beside, they’re already fully fledged editors, so we’d have the same issue of conflicting and irrelevant features, which would cause at least a confusion.

1 Like
5

What game are you talking about?

6

I’m talking about the Dark Engine or to be precise, its updated (by fans) version called New Dark. The games made with it are Thief 1 and 2 and System Shock 2. The current level editor is called Dromed.

7

In that case I would drop option 1 right away. Like you say it has a lot of disadvantages and in my opinion they are huge. As a front-end designer myself I hate interfaces with features that are unrelated to the process and your editor would be flooded with them if you went this route. And you would be at the mercy of Unity in terms of where they want to take Unity in the upcoming years.

In regards to option 2 I think you’re giving to much credit to certain features. Multiple viewports, dockable panels and the whole UI bit would be fairly trivial to implement in my opinion. I have no idea about the ability to use the light baking features during run-time, but if you were to make your own editor from scratch you wouldn’t even have light baking unless you wrote it yourself so I would consider this a bonus if it works and something you just ignore it if it doesn’t.

When it comes to the BSP stuff I would think it wouldn’t matter much if you made it from scratch or as a run-time editor made with Unity because Unity has no such thing and you would have to make it from scratch anyway.

In regards to “option 3”, i.e. making this from scratch, what “wheels” would you have to reinvent? I remember that when I was working with XNA I made a level editor for my game in Visual Studio. It was so long ago I don’t remember how, but I assume since XNA was C# that I made it using C# and .NET. I remember that it was very easy and I made a fully fledged level editor. My game was a 2D tile based one and my level editor was similar to Tiled. I imagine 3D would be a lot harder, but there’s probably a lot out there you can base yourself on and I imagine that because you’re considering this project it means you know a lot more about 3D rendering than I do. :stuck_out_tongue: The editor wrappings with the UI, file saving/loading and dockable panels and all that would be the same.

I’d say go for option 3 if you feel like you have a firm grasp of 3D rendering, matrices and all that jazz. Otherwise go with Unity, or any other 3D engine that’s potentially more suited for what you want to do, and let it handle the rendering part for you.

8

Yep, I’m aware of the BSP needed to be built from scratch. Dark Engine uses very specific approach anyway - it has 3 types of media: solid, air and water and a couple of boolean like operations on them, that I don’t think even any of the existing Unity Assets would be a good fit for that.

Lightmap baking, from what I can read is not really a run-time solution, which would be probably a big pro of the option 1). However again - Dark Engine needs light maps on a per light basis (for some of them, so they can go off in extinguished), so probably a generic solutions won’t work here. This is going to be another big thing to implement.

As for the “wheels to re-invent” - I meant all the low level stuff like rendering the scene, getting mouse events working in the viewport, basic particle systems etc… All the things that are already there, when you work with a certain 3D application.

I am familiar with certain 3D rendering aspects, but I’m not strong about it at all. It’s the thing I’d need to learn and I’m trying to estimate which way would get me quickest to my goal.

But is there anything that you think may be impossible or fairly limiting with the Unity run-time approach (apart from the above mentioned Unity’s light maps baking)?

9

Unity does not have built in support for bsps. There’s a SabreCSG that provides something similar, though, so you could (try to) extend that.

I don’t see much point in writing a level editor from scratch, unless you think it is an incredibly fun thing to do.

You could use unity editor to design levels for another game if you wanted, then write some scripts to export level data from unity into another engine. However… unity editor abilities do not particularly shine, so you could also, say, extend blender to do the same thing.

Writing a level editor that will work as a unity game sounds like a waste of time to me. Level editors are usually ui heavy, and while unity ui functionality kinda sorta works for game purposes, it is not something I’d use for a GUI heavy application.

It’ll take a few months, regardless of your selected approach. I think that utilizing existing bsp editor (like hammer, or whatever else is available out here) would be a better idea.
If I were writing this, I’d go with C++/Qt application instead of .NET, because Qt gui framework offers more power. However, if you don’t already know C++, you won’t greatly benefit from going this route.

You may be able to repurpose portions of SabreCSG which went opensource and is available on github.

It’ll still require quite a bit of work. Implementing booleans is painful.

The bottom line is I definitely wouldn’t try to make a “runtime editor in unity”. I just don’t think it sis a very good fit for this kind of project. Extending Unity or extending some other editor or even writing this from scratch is roughly the same, but if you’re not very experienced with programming, you should avoid “write it from scratch” idea.

I think the best approach in your situation would be to try to repurpose some of the existing bsp editors.

10

I spent a lot of time in DromEd during Thief 1 & 2’s day, made several full campaign levels.

In my opinion this is way more trouble than it is worth. You’re basically better off just remaking the game in Unity, then making a level editor for that game.

11

Remaking a game is gonna take longer than remaking its level editor. IMO.

12

He’s making a game anyway, so he might as well.

1 Like
13

I’ve never looked for any options to gtkRadient when it comes to level designing (atleast regarding idTech powered games) so I can’t say for sure but I can atleast say that I wouldn’t be amazed if there were atleast some open-source level editors for bsp, if you haven’t checked already go ahead and do so 'cause in my opinion it would be a better approach, as you could then just build upon an existing base and add features you feel are missing, instead of starting from scratch.

(Again, I’ve never looked around so I’m not sure if any open-source alternatives are available…)

14

Yes, I agree with that. Recreating level geometry would be the easiest thing to do. Having all the game mechanics worked identically is just impossible. There’s a tons of hacks, shortcuts, unfinished features in Dark Engine. Getting the timing of events right etc… It just won’t work. There was an attempt to do just that in the past and it’s on hold for years now. (OPDE)

Not sure what you mean. I’m not making a game - I plan on to make an editor only, which will output a dark engine compatible .MIS file (mission). The good thing about this approach is, that all the CSG brushwork can be stripped for the playable version, so in the custom editor we can introduce a broader set of CSG primitives and just output the portalized geometry (processed CSG brushes). I could also improve the light map baking to include some AO/indirect light, soft shadows, alpha mapped shadows etc… But the final result will still be a file readable by the old engine.

1 Like
15

Initially I wanted to do just that for 3dsmax, but since it’s a commercial software, it’s going to be rejected by the community. Blender could be an option, apart from the fact I don’t feel like learning it. I’m not going to use this knowledge in the future.

I’m familiar with Qt framework to a certain extent, since I use PySide for Maya on a daily basis. There’s a Qt# binding for C#, but it’s not fully completed yet. But it’s good to hear an opinion on Qt vs .NET.

Yep, I do look around for existing solutions, which I could adapt and there are some available out there.
For example this one - I only came across it today, so I didn’t have time to check it out:
https://3deditor.codeplex.com/
It looks very bare bones, but it might be better than nothing.

As of the existing BSP editors - they’re all additive BSP. Still, I could use the brush creation code and just mess around with the actual BSP operations. But then, I might find myself seriously limited by somebody’s else solution, which had been done with a completely different philosophy in mind. I’d be better off probably with using some lower level Math library for doing things like planes intersection detection etc…

16

Hmm…

In this case, I’d recommend to check out sabrecsg. It has additive/subtractive brushes, though those are not strictly “hierarchial”… and only try writing your own solution from scratch if sabrecsg doesn’t work for you.

17

I don’t know enough about more technical topics in Unity to answer that, I’m afraid. I found this through a quick Google search, which I assume means you’ve seen it as well: https://www.assetstore.unity3d.com/en/#!/content/64806

It at least looks like a working editor made inside of Unity.

From my point of view I can’t see why making an application in Unity should be different from making a game, but I can see that the end result could end up being a bit crummy when making an application. I expect an application to function quite a bit differently from a game. I personally dislike applications that have their own interfaces rather than native OS interfaces, and I imagine the former would be the result if you were to use Unity to make this editor.

I also don’t know how window resizing, minimizing, maximizing etc. would work for you when making an application. If you know you’re going to choose one of the two approaches I would personally just try to create a barebones application frame in Unity before I did anything else just to see if that was possible at all. And I would not even bother taking that approach any further unless I was able to get something that felt native or as good as native. But you may not be as picky as me. :stuck_out_tongue:

Discord, Spotify and Slack, even though they are all great applications that I use everyday on both OS X and Windows, all feel a bit slow and crummy to me because of the fact that they don’t feel like native applications. I at least wouldn’t settle for anything less than those if I were to try and make an application in Unity. :stuck_out_tongue:

18

I actually downloaded SabreCSG some time ago and while it has some functionality, it’s far from the feature set needed. (it operates on cubes only). But since it’s open source now, I can have a look at the code and maybe borrow some ideas…

@TwiiK - speaking of UI. If I was to for a Qt, GTK or .NET frameworks, I would get that native UI look, which is probably always good and people are familiar with. On another hand, I kind of like the Lumion’s interface - it’s more based on icons - very little of text - and it’s kind of bespoke to whatever you do, whatever mode you’re in etc. instead of all menus and dialogs being just clones of the same visual templates. I’m a bit torn here - need to decide on the direction pretty early in the process, I guess! :slight_smile:
Thanks for the link to that Unity asset - I haven’t seen that before, but if I was to use Unity, it would be a good starting point to get all those selection gizmos and other basic stuff going from the start.

19

Imho much comes down to personal preference and context. I’d imagine the modding/level design communities for thief 1, 2 and system shock 2 are tiny. If those are the ones you want to make a tool for, you should ask them. Maybe some of them prefer to keep using Dromed or have very specific ideas of what they would like to work with instead?
For a “professional application” I like interfaces not to be too different from what I’m used to (Photoshop, Reaper, Blender, Substance Painter, Unity etc. - afaik none of those use 100% OS UI), but for a level editor I’d be most concerned with usabilty, workflow speed and most importantly iteration speed. I don’t know what Dromed offers, but if you made your editor in Unity, use a GPU based GI solution like SEGI and add baking to it, and include a “play mode” to playtest stuff in editor, I could see that being a big advantage that might be harder to get with a QT application because unity already offers a better base for it to be “playable”. I don’t mean elaborate playback of scripts etc., just walking around, jumping and climbing, to get an as accurate as possible “feel” for dimensions. It is a long time since I played around with level editors, but that was pretty much the feature I wished for the most.
In terms of icons vs text buttons, I prefer text personally (just a matter of taste), but imho good hotkeys are what’s really more important. If in the end it’s not a lot faster and more convenient to author content with your editor instead of the native editor, then who would want to use your solution? A new tool represents a significant time investment for users, so it needs to promise a big boost in productivity and quality to be worth giving it a try. That’s a factor I’d not underestimate.

Thief 1, 2 and System Shock 2 are some of my favourite games ever. While I never looked beyond the original content and don’t really have a big interest in 3rd party levels for the games, I think it’s cool to see that people still care enough about these games to consider investing a lot of time into making tools for them!

20

No, it doesn’t. You can drag individual vertices, faces, make ladders, prisms, etc.
http://sabrecsg.com/learn/reference/brush-tools/

No, you wouldn’t. At least in case of Qt.
http://doc.qt.io/qt-5/style-reference.html

Widgets are style aware and you can specify what kind of look you want or create your own style.
http://doc.qt.io/qt-5/gallery.html
http://blog.qt.io/blog/2012/10/30/cleaning-up-styles-in-qt5-and-adding-fusion/