WorldEditor for game

Game Design
1

Good day!
There is the small (or not) question I have.
I need to make the editor for game resources like game objects, game global map and scenes. Like the map editor for strategy games, where you can draw terrains, add units etc… Important feature - non-code and player-friendly design. So:

  1. I think will be better, if I make it as the single program and don’t integrate in game. Like StarEdit, WarCraft 3 World Editor or TES Construction Set. Is it good way, or game-integrated level editor has a right to exists?
  2. If it will be as special program, I need to add them in the game folder and give them access to game units, contains game object classes? Is it practice safe and good? Another idea - make absolutely independent editor with own classes, because editor don’t need full list of “real” game objects. But it will still result in a partial repetition of the code.
  3. I think LCL will be enough for this project, moreover LCL components will be very helpful for editor interface designing. Or better to use game engine (maybe I overlook some important detail…)?

I understand that is questions about the own view to the design, but I am interested you opinions and experience. Thanks for attention!

2

Overall, it’s a broad question and likely various answers can be valid – depending on needs :slight_smile:

Let me share some of my thoughts:

  1. If I would decide to make my own game editor, I would definitely plan from start to share some code with the actual game. While surely there will be some things game-specific and editor-specific, in my experience there’s also a nice “common set” of things useful for both editor and game. You want single language, single data structures, single code for them, to save yourself some work.

    I recall here in-game editor I made for “Orcs and Volcanoes” , really really long time ago: Development: great API for 2D games and UI, our engine in Debian, on the road to OpenGL ES, Orcs and Volcanoes game screenshots | News | Castle Game Engine . It was part of the game, and it allowed to design and test maps really quickly.

  2. Connecting to the above, I would consider making such editor a “core” part of the game project. So that you can interrupt the “game mode” essentially at any moment and switch into “editor designinig mode” and then of course, once you edit some stuff, jump quickly into “play mode” again. This is the main advantage of making a home-grown, custom editor IMHO – you can make the experience really “seamless” for players and the editor becomes an essential game part.

    Because of this, I would probably go for making “editor mode” just something within one project, together with the game. I.e. one executable, both game and editor. Because it has mostly advantages: obvious code sharing, easier distribution (on desktop, on mobile, everywhere – you have 1 project, no need to distribute 2 projects).

    Note that, even if you decide to make “2 executables” anyway, then they could of course share some data / database / config. Remember that our “data” ( Data directory and castle-data:/ URL protocol | Manual | Castle Game Engine ) is supposed to be read-only, and to be really cross-platform you have to treat it like that (on Android it is really read-only, on Windows/Linux system-wide installation it may also be read-only). But you can establish and writeable directory shared by both projects anyway.

    Still, even if it’s possible with 2 executables, it’s certainly easier when you have just 1. Because then you just use ApplicationConfig for your project’s writeable space that is cross-platform. No need to deal e.g. with non-trivial problems “how on Android to share a writeable directory between 2 applications”.

  3. The above also implies that I would then try to make the whole editor just like the game, so using CGE UI classes ( User Interface | Manual | Castle Game Engine ), not LCL.

  4. Note: If I would not want to give end-players access to editor, I would consider instead making it:

    But I understand that CGE editor may be “too much” for novice players. I don’t know whether Tiled would be enough for your players. Both options imply an editor only on desktop, and separate from your game – so you don’t have advantages in AD 1 and AD 2 that I outlined. But in exchange, you have a mostly ready editor, where you only need to think how to add tweaks you need.

  5. I would go for LCL only if LCL has some specific ready control that I desperately need and I cannot make it easily in CGE :slight_smile:

    That is also why I chose LCL to make CGE editor, in the end. It’s a big gain (LCL has lots of difficult UI components, like “ready object inspector”) but also some loss (it is necessarily something separate from game, it’s only on desktop, though I have some ideas to connect them – using CASTLE_WINDOW_FORM, using IPC, or finally using CGE UI for whole editor, as per Roadmap | Manual | Castle Game Engine "Big Plan: The ultimate solution, that will allow to switch dark mode on/off on all platforms with exactly the same results, will come from reimplementing CGE editor using CGE user interface components. ")

I guess it all comes also into “what do you know” :slight_smile: For me surely the choice of “making all user interface using CGE components” would be nice, as even if something is missing in CGE – I would like to add it (like a TCastleTreeView, planned). But this is then something I would consider a gain (I’m doing a project, I’m also improving CGE), it may be different for you, I understand you should naturally choose something that you already know well, and you already know it satisfies all your requirements.

I hope this helps as food for thought! :slight_smile:

2 Likes
3

Thank you, the information is very useful!