Creating a map editor for RTS. Can I ask the player to use Unity or is that a bad idea?

Unity Engine
1

I’m thinking about creating an RTS map editor available to the public but I would really like to avoid a maximum amount of work and it seems to me that the easiest way would be to ask the player to download unity and work with my scripts and build his map in Unity.

I would hide most of the core logic and only provide the scripts that allow you to make a map. I believe this is possible using DLL’s but let me know if that is actually foolproof.

If there is nothing from the Asset Store I provide to the user would it still pose any legal problems?

My questions are probably vague but even thoughts on if this a good idea or not are welcome.

2

This is almost always a bad idea. Granted, I don’t know the details of what you’re map making process is, but if you want them to use Unity, then it seems like you are thinking about having them make scene files that you’d load later. If you also allow them to distribute those files to other players through your system, you can easily be used as an attack vector for malicious software. It’s better to have your own map making editor that you can control.

2 Likes
3

The closest thing I can think of having been done like this is Kerbal Space Program, which required mod creators to use Unity to create new parts, plugins, etc. A level editor is not at all the same as that, and I do think it’s too much to ask of players, who have since the 80s and 90s been accustomed to level editors that they don’t need to learn new tools and skills to use.

I’m curious what you’re proposing could happen here? If the “level editor project file” exports an asset bundle, those don’t contain new code that didn’t exist in the main executable, so what would be the attack vector here? (I’m not necessarily disagreeing, I just don’t see how that would work)

4

In normal usage, that’s true, but it is possible to distribute dlls through asset bundles even though that isn’t officially supported. In this case, I’m thinking about a maliciously designed scene bundle that contains code in an unexpected way. I’ll concede that I haven’t tried doing this, though. The process seems very similar to other injection projects I’ve worked on (that was for a good reason!).

5

Even if you manage to include a DLL, wouldn’t something in the main executable need to explicitly search for and call a method in the DLL in order to run code in it? (Also haven’t tried doing this, so I’m very much stabbing in the dark)

Though one thing I’ll certainly agree to is that it’s more likely that someone would find a way to execute malicious code from an asset bundle (in some way that we may not be expert enough to be aware of) than a file created by an inbuilt level editor. And even if that weren’t true, having your level editor be Unity is still a pretty bad idea for other reasons.

1 Like
6

Yeah, sorry those were two different ideas I didn’t clearly break apart. You’d have to load the dll too, which is an extra problem. I was thinking of having a scene file that also contains code (by manually editing the file) and is crafted to specifically hijack the bundle loading process to execute code. I don’t think the asset bundle system is designed with security in mind, so I’m speculating that it should be pretty easy to do (as far as reverse engineering goes).

7

I don’t see much useful in search results for “AssetBundle security” - mostly the results for that are people concerned about users extracting and repurposing the contents of the asset bundle, not being concerned about malicious stuff being inserted into them. If nothing else, I think that if an attack like this was possible, then Apple would be the first to bring down the banhammer on iOS apps using AssetBundles, so I’m going to take Apple permitting Unity apps to use AssetBundles as fairly strong assurance that arbitrary code execution through them is not possible (or at least that blackhats haven’t figured out how to do it).

8

I don’t think you have any legal issues. I think it is a bad idea though. From the user perspective, Unity is very complicated software with lots of functionality put right in front of the user which is unrelated to level editing. You have to assume level editors are not experienced developers.

A level editor should be simple, and try to restrict things which would break the level, but Unity is the opposite of that.

2 Likes
9

I would design the level editor as a separate application and only import and use assets through specific channels. Letting your users use Unity directly is not a good idea, for the reasons mentioned.

If you need the user to be able to make logic beyond the scope of selecting preset options and drag and dropping things around in the UI, try using a language like LUA or Python and import and execute those instead, as LUA interpreters are a pretty common sight in Unity dev these days. You can control what parts of the application can be managed through a language like LUA pretty easily, so it’s much safer than compiling and executing arbitrary C# (though this is also technically possible).

It’s also possible to include a specific version of the Unity Editor in your game’s build, or in a separate download as the “Level Creator” (because it’s quite massive really, so including it with the main game is probably not a great idea). This wouldn’t be to have the user open and run it directly, but rather to run it yourself through the Level Creator application using command-line arguments, to dynamically create asset bundles and store simple assets like textures, audio, and models in a format that Unity can actually import and understand. We’ve managed to get it working through Docker on a Linux server and run commands against it through a web API for this purpose, generating Asset Bundles that are then downloaded and used by our games automatically as updates without needing to re-build them.

Things to pay attention to and understand here are asset bundles (Addressables even, if you’re keeping up on preview features), Streaming Assets, command line arguments like -nographics, -quit, and -batchmode. Unity Editor for Linux is also available now I’ve heard- though frankly, using Docker/containerization to run it in a completely controlled environment is even better IMHO, if you’re going that route.

Just some things to think about.

10

Is it possible to include certain tools from Unity in a custom map editor, like the terrain tools, …? Just curious.

The kind of RTS games I take inspiration from use their own custom engine and it’s really not something I want to do. It would take too much time to create: We are only 3 people in our team. Maybe it’s too hopeful to provide a map editor with such a small team.

Here’s the kind of RTS map editor I’m thinking about (They are billions):

https://www.youtube.com/watch?v=USzcxdSZt2c

11

Not really. Including the UnityEditor in your build will enable you to run command-line arguments, but it’s not really something you can directly communicate with and control externally- if anything, it’s a modified startup and execution procedure. In other words, you can have several static functions that each do different things depending on the parameters fed in with the command-line. The Editor will run/open, execute the selected function with the parameters given, save the results in some way, and then usually quit. This can be useful for building things like AssetBundles remotely with a single detailed command, or feeding it instructions from an XML/YAML options file or something. Start, execute function, store useful results somewhere, quit. Then your other application/s, or the game you’ve built, whatever, can use that file with the stored results.

In order to manage functionality that requires a lot of back-and-forth, you’ll need to set it up as a server to receive TCP/UDP connections, probably using sockets- making it similar to a multiplayer server. You can check out any tutorials on multiplayer with Unity, and most will have helpful information with this usage if you really want to go in that direction.

It still won’t really let you use things like the terrain tools in built games though- those tools really requite the scene view interactions to use, and at that point it’s the same as just telling users to use Unity directly. It’s not viable there.

That said, I’m a bit confused. The video you posted has nothing to do with terrain tools- it’s completely flat, and painting textures on top can/should be done using overlays (much like decals). It uses a grid system, and the Unity terrain doesn’t natively have support for that kind of thing. Your “terrain” wouldn’t really be Unity terrain anyways- it’d all just be built on top of Unity terrain at best, or just using a quad instead if you don’t need the heightmap information.

If I were you, I’d drop the notion of using Unity Editor tools directly in your level creator- you need to use/make tools that are usable at runtime instead. Modifying heightmap data for terrains is perfectly possible at runtime, and there are no doubt plenty of tools around to help with that if you need it. If you do things like the video though, you don’t even need that- there’s no heightmap data, and so no need to use Unity terrain to begin with, much less the Unity editor.

12

Ok, no unity tools then.

Are there any RTS games that have been made with Unity? I can’t seem to find one.

I would use a height map like Starcraft2’s editor for the terrains:

https://www.youtube.com/watch?v=KBdRkF29GQk

13

Desp[ite what many people says here, that’s very good idea I think. In the past all games with map editors exposed the editors to the public, so you can create some project template and presets of tools and assets for your game. Let players build map asset bundles and teach your game to load maps from bundles.

Unity have easy learning curve so many people will do.

You don’t need to include unity editor in your build, just write a paper and maybe cut a video tutorial for modders on where to get unity and how to mod your game.

1 Like