Outpost 2 Mapper

[leeor_net]

So I've been thinking (again) about the Outpost 2 mapper and how we can make this sort of thing better so we can see maps and levels generated by non-programmers.

I took a crack at migrating the original OP2 Mapper code from VB whatever to a modern version and... failed. Part of the problem I'm having with it is the drawing code. It's not easy to do in the Win32 API, VB.Net is a language I'm not very familiar with anymore and C# eludes me entirely (I just never took the time to learn the language and how to develop graphics programs with it)

Anyway, I have a basic grasp of OP2's level format but if this were to work I don't think I can do it by myself. Plus, there would need to be a way to allow users to script events and whatnot through the editor without the user having to compile some sort of source code. Basically, embed a script file of sorts in the level file and feed that into a custom mission DLL that interprets a script... or something to that end. There's also the problem of Outpost 2 reads the DLL mission file to get the name, game type, etc so how would that work in terms of using an embedded script interpreter?

Any thoughts on this? Or any desire to make this happen at all? Even without the above mentioned script editor a really good terrain editor would make developing new maps a lot easier. I am still very much in the middle of OutpostHD development so I've been almost entirely focused on that (and also why I'd need help to make this happen).

[Hooman]

I would be very interested in improving map editing capabilities. Eliminating the need for a compiler would be a huge plus. Another point of pain is filling in large areas with tiles of a certain terrain type, auto placing of tileset transition tiles, and auto placing ridge tiles.

The scripting part sounds like the biggest and most difficult change. We'd need to make changes to the file format, and associated loading code. We'd also need a way of interpreting and running the extra data at run time. A full scripting engine sounds complicated. There are many things that can be done at runtime, so there's quite a lot of functionality to implement. There's also security concerns, but I suppose no more so than passing around DLL files.

For auto tile placement, that's more of a meta data issue. We would need to add information about the tiles that allows them to be auto placed correctly. It's tedious, but it should be reasonably simple. At least it should be simple once you know how you need to classify the data.

Another meta data issue is classifying the tile groups. Some are like the doodads in Starcraft, meant to be pasted as a whole. For example, volcanoes. Some are collections of individual tiles, where a single tile from the group can be pasted, but you'd never want to paste the whole group. For example, a group of single tile meteor craters. Then there are some groups that can be pasted as a whole, or have individual tiles taken from them, such as groups of plain flat terrain. We should try to augment the existing group data with more meta data that allows for better automated processing.

[Vagabond]

Flashy has a working scenario that allows dynamic scripting through the Outpost 2 networking messaging. Basically, you just type messages into the game and the scenario DLL interprets them into commands like creating disasters or sending attack squads against your colony. Maybe worth checking out for the scripting portion.

http://forum.outpost2.net/index.php/topic,5480.0.html

I'm not sure how ambitious you are about the mapper, but it might be worth trying to insulate the scripting / mapping from the Outpost 2 code. Maybe create an in-between layer that translates the scripting into Outpost 2 specific. This way you could use modern programming practices in the Mapper and not tie it to Outpost 2 specifics. I guess this would make the project a lot more time though?

[leeor_net]

Another point of pain is filling in large areas with tiles of a certain terrain type, auto placing of tileset transition tiles, and auto placing ridge tiles.

This is what I found most lacking in the current version of the mapper. Hated it. But it's also fairly simple to implement. I've done in several times in a number of projects but I've never successfully pulled this off in a GUI application... I'm wondering how necessary a GUI application really is or if it would be perfectly fine to do it the way I have in the past like the following (see attachment).

For auto tile placement, that's more of a meta data issue. We would need to add information about the tiles that allows them to be auto placed correctly. It's tedious, but it should be reasonably simple. At least it should be simple once you know how you need to classify the data.

The scripting part sounds like the biggest and most difficult change.

This is the hardest part -- a terrain editor is one thing, integrating drag and drop scripting is a lot harder.
Part of my problem is I don't completely understand how this is set up. There seems to be a number of tile information flags but I didn't look to far into it. An autotiler should be simple enough to do once that's set up.

Another meta data issue is classifying the tile groups. Some are like the doodads in Starcraft, meant to be pasted as a whole. For example, volcanoes. Some are collections of individual tiles, where a single tile from the group can be pasted, but you'd never want to paste the whole group. For example, a group of single tile meteor craters.

I began to notice this as I was searching through the tile groups and tile information. It occurred to me that most of this doesn't need to be stored in the map files themselves, that this is better suited for a map editor to know.

[Arklon]

The scripting part sounds like the biggest and most difficult change. We'd need to make changes to the file format, and associated loading code. We'd also need a way of interpreting and running the extra data at run time. A full scripting engine sounds complicated. There are many things that can be done at runtime, so there's quite a lot of functionality to implement. There's also security concerns, but I suppose no more so than passing around DLL files.

There's that Python API project BlackBox was working on, which has been sitting at >90% completion for months now.

[leeor_net]

I personally really hate python but if it works, why not use it instead of reinventing the wheel?

Would be interested to see how it could be integrated with a project like this.

[Hooman]

There's that Python API project BlackBox was working on, which has been sitting at >90% completion for months now.

It's always that last 10%. 

Was there any plan to package the Python code with the map file, or just have it sit loose in the same folder? Was there a plan to have the game look for Python files to interpret, or would a dummy DLL still be needed that ran the Python code?

[Arklon]

I personally really hate python but if it works, why not use it instead of reinventing the wheel?

Would be interested to see how it could be integrated with a project like this.

Python and LUA are the easiest to generate C++ bindings for with SWIG, Python being the easier of the two. Between that, LUA's horrendous syntax, and what would be the easiest for newbies, that was why he went with Python.

Was there any plan to package the Python code with the map file, or just have it sit loose in the same folder? Was there a plan to have the game look for Python files to interpret, or would a dummy DLL still be needed that ran the Python code?

The Python extension DLL acted as both a mod DLL and mission DLL in one. The Python code would be independent of the map, but we talked about bundling together maps, code, custom tech files, and other mission-specific files together in their own vol or zip files at some point. The plan was to hook the colony game and MP map lists to list Python missions, but I don't think that was implemented yet. As it stands, it's very much usable, it just needs finishing touches, some urgent like the map list hooks, others would just be nice like making enumerators/etc. more "Pythonic".

[leeor_net]

Between that, LUA's horrendous syntax, and what would be the easiest for newbies, that was why he went with Python.

I always liked Lua, but I agree python is a lot easier to pick up so I'm all for it. Best tool for the job and so on, amiright?

As it stands, it's very much usable, it just needs finishing touches, some urgent like the map list hooks, others would just be nice like making enumerators/etc. more "Pythonic".

Going to recommend someone with better understanding take over that end of it, maybe even build tools to package everything together. I think my skillset would be better suited toward developing the terrain editor along with auto brush type deals. Not sure how to integrate everything so if we put our heads together I think we could bang out some specifications to make everything play nice.

It's 3am for me and I'm running on three hours of sleep, forgive me if I'm loopy.

[Arklon]

For auto brush, your best best is to just analyze the stock maps to determine the proper terrain type edge transition tiles. I remember BB and Hooman looked at it a lot in the past and there's no convenient patterns in the tilesets that anyone could see. They even asked an OP2 developer about it who unfortunately didn't know anything about it.

[leeor_net]

I figured that's what I'd do, see if there's some pattern I can discern and then go from there.

I think for now I'll dump the GUI version of the editor in VB.Net and go with the C++ option. The Landlord editor I built is a decent base to start from and is easy to modify.

Hooman mentioned the metadata, I figure that's something that ought to be embedded in the editor vs. the maps themselves. He helped me understand the binary encoding for it so I was able to pull it out of one of the stock maps to get the 'doodads' and tile patterns and sets out. It's a good start anyway.

[Arklon]

Keep in mind that, aside from tile groups, there is also tileset-related metadata embedded in the maps so that lava, tubes, bulldozing, etc. works correctly.

[Hooman]

Arklon brings up a good point about the tileset meta data that I had largely forgotten about.

Hooking the game lists to show a new set of custom maps is something I'd been meaning to look into. Perhaps I'll try to do some code analysis to that effect.

[leeor_net]

Keep in mind that, aside from tile groups, there is also tileset-related metadata embedded in the maps so that lava, tubes, bulldozing, etc. works correctly.

I did not know that. Definitely important information... though it reminds me more and more that Dynamics truly never intended anybody to modify the game.

[Arklon]

Keep in mind that, aside from tile groups, there is also tileset-related metadata embedded in the maps so that lava, tubes, bulldozing, etc. works correctly.

I did not know that. Definitely important information... though it reminds me more and more that Dynamics truly never intended anybody to modify the game.

BB's old Mapper is able to edit said metadata, which came in handy for the Greenworld tileset. It's a pretty easy feature to miss, though, it's not exactly prominent.