Build map editor in to WZ

[aubergine]

There are already some basic features for map editing in WZ, as can be seen in the debug menu in WZ 3.1 (removed in 3.2).

If we could upgrade to QT5 in a future version of WZ, and expose UI API to JS, plus a few new JS API functions for doing stuff with the map, it would be possible to implement a map editor directly in the game, scripted in Javascript.

But first, I think we'd need a rethink on how tilesets are handled. Currently there are 3 standard tilesets: Arizona, Rockies, Urban. The graphics are all stored under the base/texpages/ folder, and basically it's just a big gallery of image files.

Currently, to make a new tileset, you have to replace (well, override via a mod usually) the files in one of those 3 standard tilesets. This seems particularly cumbersome.

What if there was a new tilesets folder (the old texpages folder would be kept for backwards compatibility). In the tilesets folder, there would be a subfolder for each tileset: Arizona, Urban, Rockies, Desert, Glacier, Paradise, etc. Adding new tilesets is a simple case of creating the folder, and putting relevant files in it, then bundling it as a .wz mod.

This would allow the game to have multiple tilesets. Rather than having to shove tilesets in to maps, they'd be centrally stored in the tilesets folders and thus be available to any map. Obviously, there would be some issues to overcome - eg. if a map is downloaded and you don't have the required tileset installed, it would probably need to default to a tileset thats bundled with the game - but that's do-able.

Each custom tileset would have an ini file that defines the closest visual match to a tileset bundled with the game. Like font declarations in CSS, it could be a comma separated list. For example the RainForest tileset could specify: similar = Paradise, Alaska, Rockies.

When a map is created using the custom tileset, it will store the "similar" property in <mapname>.ini, so should that map be used on a computer without the required tileset it would first try to find Paradise, and if not found Alaska, and if not found, the tileset bundled with the game: Rockies. There might be some aesthetic glitches, but the game would run fine despite not having the custom tileset installed, and a yellow console warning would be shown to the user to let them know which tileset they're missing. Maps would also be able to use tiles from any of the tilesets (which would probably require some mods to the map file format).

Now, on to the map editor...

A "Map Editor" menu would be added (again, this assumes that a UI overhaul has taken place and front-end menu system can be scripted via JS using exposed QT5 features). Options would include: Create new map, Edit existing map, Export map addon.

Create and Edit both have the same destination - the map editor - but take a slightly different route to get there. The Create option asks for a map size and what tileset to start with, possibly also with some auto-terrain options such as how hilly it should be, amount of water, and so on. It then creates a new map and you can start editing it. The Edit option lets you select an existing map and edit it.

When the editor window appears, you see the map just as you would in a normal game, because it's using the exact same rendering engine. The main difference is that there's no active players. The human player can place structures and units, move units, place features - much like they can do in an normal game or with the debug menu.

Additional tools would include:

* Brush size
* Raise / lower terrain
* Texture palette
* Player selector (eg. to place structures/droids for that player)
* Map settings (eg. to change default terrain, map size, filename, and options in <mapname>.ini)

Obviously, a number of new JS API features would be required - to change terrain altitude, set map width/height, and so on.

Because the bulk of the map editor is scripted in JS, modders could quickly extend the map editor with new features using existing functions. For example, someone could make a "Base Builder" tool that would use similar code to what you might find in an AI (but using addStructure() instead of orderDroidBuild() etc) to construct a base for the currently selected player. All the map author would need to do is select the desired player, click the Base Builder brush and click on the map where they want the base to be and >poof< a base appears. Alternatively the map author could instruct trucks to build the base in the same way they'd do it in a normal game!

This obviously won't happen overnight, in fact it's prolly a WZ4 timescale, but I thought I'd put up these initial ideas to start a discussion and see what people think. Just imagine some of our script-savvy map / mod authors, like NoQ, Felipe, ShadowWolf, Goth Z-T, raycast, etc., being able to mod the map editor... Once it exists, it wouldn't be too long before it's brimming with useful addons....

[Goth Zagog-Thou]

I'd also like to see some api functions that could deform or interact with the terrain via script -- for example, cliffs that could be "blasted away" (from the player's point of view) and likewise could be "grown" as needed.

It's a good idea all around, Aubergine.

[stiv]

A nice first step would be to document what the map format currently is. Preferably something that doesn't say "go read the source".

[vexed]

Qt5 is not a magic bullet that can fix the many things wrong in the codebase.
Lots of things would need to change to be more Qt friendly, and even then, things would be difficult at best.

It is far better to have a external editor written in Qt to deal with maps & campaign making.

[NoQ]

I wonder if it's possible to implement map editor in Ctrl+O cheat menu, since we already have cheat shortcuts for modifying heightmap etc.

[Per]

I wonder if it's possible to implement map editor in Ctrl+O cheat menu, since we already have cheat shortcuts for modifying heightmap etc.

There used to be an unfinished map editor in the ctrl+o menu, ever since the original code release. I tried to finish it, once upon a time, but ran into so many issues that I gave up on it. With time, all the code broke so badly that it made no sense to keep it around any more, and so I removed it all. Hence this thread.

[NoQ]

Lol: didn't read the first sentence of the thread before replying

[aubergine]

@Vexed, there are several (at least 4 that I am aware of) external editors already -- all of them are stalled. I imagine they need constant updates to keep up-to-date with the main game, and that gets difficult after a while.

[vexed]

@Vexed, there are several (at least 4 that I am aware of) external editors already -- all of them are stalled. I imagine they need constant updates to keep up-to-date with the main game, and that gets difficult after a while.

Nope, the same map format is still being used today.
You can take maps made from 1.0 and convert them (wdg->wz) (or just use the lnd file if you have it), and they will work in all versions of warzone we have released.

The reason those editors didn't get finished is people either ran out of time, lost interest, or it ended up being harder than they first thought.

The only person who had the dedication to finish a map editor is Flail. Since he did release the source, it wouldn't be that difficult to base a new editor written in Qt from the work he has done.

[Goth Zagog-Thou]

FlaME uses VB.Net and TK. I would LOOOOOVE for it to be in Python / QT instead. FAR more compatible on all platforms .. and let's be honest, .Net *anything* on Linux systems (using Mono) is dodgy and has performance issues.

I would do it myself but I don't know Python well enough to do a port.

[aubergine]

Nope, the same map format is still being used today.

You can take maps made from 1.0 and convert them (wdg->wz) (or just use the lnd file if you have it), and they will work in all versions of warzone we have released.

The reason those editors didn't get finished is people either ran out of time, lost interest, or it ended up being harder than they first thought.

The only person who had the dedication to finish a map editor is Flail. Since he did release the source, it wouldn't be that difficult to base a new editor written in Qt from the work he has done.

According to wiki, wdg -> map converter is no longer available; http://developer.wz2100.net/wiki/ConvertingOldMaps

Why would writing a new Qt app be any different to just writing the map editor in to WZ? WZ already has all the tools to render the map and objects upon it. And those will always be up-to-date. Via the debug menu, we can place structures and droids for any player. That deals with a large chunk of map editing. And, WZ is already compatible with all platforms it's compatible with

All that remains is the terrain - the ability to change height, choose what tiles are painted, etc. In WZ, when a building is placed the terrain height is sometimes adjusted, so there must be code to adjust terrain height already. We just need access to it from JS API. That would mean the biggest remaining hurdle would be the ability to draw buttons in the 3D view, for example making a terrain palette available.

If the functions could be provided, even in a 'hack' format (eg. like the recently added hackMarkTiles() and hackChangeMe() functions), a proof of concept could be built.

All I'm asking is the opportunity to test the feasibility of an in-game map editor. If someone could provide the following functions to JS API, I'll create a proof of concept:

* hackGetTileHeight(x,y) -- returns object or array defining z of each corner of a tile (or whatever it is that defines a tiles height on the map)
* hackSetTileHeight(x,y,heights) -- set the z of each corner (or whatever it actually is) of a tile at x,y
* hackGetMousePosition() -- return POSITION obj of tile that mouse pointer is over
* hackEventMouseDown() -- triggered when a mouse button pressed
* hackEventMouseUp() -- triggered when mouse button released
* hackEventMouseMove() -- triggered when mouse pointer enters a new tile

With that I'll be able to implement terrain deformations and a 'feature' paintbrush (eg. for painting forests). I can probably also implement a copy/paste for terrain heights and features too.

Because it's not possible to draw buttons or have custom key bindings, I'll use chat interface to change tools / brush sizes, etc.

It will be very rough round the edges, but it should be enough to show whether it's worth taking this idea further or not. Consider it a sprint, to check feasibility and work out what sort of extra features would be required to make a workable map editor.

If you're worried that I don't have time or might get bored or might find it too much of a challenge, just take a look at the wiki linked in my sig below: Several hundred pages created over the past few months with daily updates. I can see this through to the end.

[Emdek]

Ekhem...
https://github.com/Emdek/wz-map-editor
Need volunteers to keep it going.

vexed, the only way that would fix current issues (but most probably introduce new ) would be to rewrite game from scratch, reusing what could be reused. Whatever going Qt, external engine or any other combination.
If I would reach my goals for this map editor then it could be even used as proof of concept engine replacement.

[Per]

What I am looking at next for qtscript is control over at least some of the GUI widgets, and move some of their control logic into script land. Once I'm done with that, it may be easier to have another attempt at a built-in editor. I think without any GUI support it would be a pretty fruitless effort.

[Rman Virgil]

What I am looking at next for qtscript is control over at least some of the GUI widgets, and move some of their control logic into script land.....

.

[aubergine]

What I am looking at next for qtscript is control over at least some of the GUI widgets, and move some of their control logic into script land. Once I'm done with that, it may be easier to have another attempt at a built-in editor. I think without any GUI support it would be a pretty fruitless effort.

Yes, without GUI support, it would not really be usable. But, if we could get some of the functions for modding terrain exposed to JS API, we could at least start building a proof of concept. I think in particular it would be useful to know if using JS to do the bulk of the map editor scripting is a good or bad choice. Without testing it, we can't really say for sure.

The code triggered by chat commands can easily be triggered by GUI buttons at a later date once GUI stuff is exposed to JS API. That should give rise to a pleasing separation of GUI code and actions.

The other major advantage of building the map editor in to WZ itself, is the extensive list of JS API functions. For example, droidCanReach(), pickStructLocation(), etc. Already battle-tested (literally) by AI scripts such as NullBot, those functions are also incredibly useful in map development. For example, warnings could be given if an oil resource is placed in an unreachable location. Dynamic feedback can be added with things like playSound(), hackMarkTiles(), console(), etc. Over time, chunks of code could be written that would automatically add feature objects, like small towns or forests, even rivers, etc., with a click of a button.

I can see the benefit of developing an external editor as a good place to test ideas for complete new GUI and rendering engine, but that's quite a long term project and we could do with a more portable map editor for the existing engine in the interim.