support for creating next-generation maps - Page 2

support for creating next-generation maps

Requests for features in the spring code.

Moderator: Moderators

Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: support for creating next-generation maps

Post by Master-Athmos »

When hearing the term "custom-geometry-maps" I still think it would be great if we'd divide a map in like 16x16 zones where each zone gets a random, premade tile applied to so we could have random maps. Has the SM3 format any potential for making this happen...

So in other words the map pretty much would be generated on runtime by welding premade parts togehter. Piece of cake for e.g. the new heightmap but textures most certainly are an issue (especially if one wants detailmaps etc.)...
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: support for creating next-generation maps

Post by smoth »

V1ntage wrote:So we have World Builder, an editor ...
worldbuild is a feature placement tool. Do not let the name deceive you.
User avatar
Neddie
Community Lead
Posts: 9406
Joined: 10 Apr 2006, 05:05

Re: support for creating next-generation maps

Post by Neddie »

Well, the support would be nice, but it would be largely useless until somebody provided a large tileset, and there are only a handful of people capable of delivering the requisite tiles. If you had a program to stitch them correctly...

I believe you could, with the present map format, deliver something similar to a tile mapping system with a few changes. You need a graphical map editor capable of stitching, a tile loader, and composite tiles. This would thus be a serious undertaking. You would not be able to create geometry you could not already create in the present map format, though with a good enough tileset including custom features you could cheat it. Support for transparency, reflectivity, refraction and translucency in the map texture would help greatly, but baby steps, baby steps.

Essentially you would...
1. Create a tileset manually.
A tileset would consistent of composite tiles with multiple layers to reflect each "map" used in map generation, or with individual bitmaps. 16x16 is far too small to work with, though, 256x256 textures with corresponding height/metal/feature map tiles would be more reasonable. The tileset itself would have a script which defines which images are being called for which capacity on a list of tiles - it would also define wet/dry characteristics, height deviation defined in tile heightmap and whether or not the tiles are economic or featured. These tags would be read by the graphical map editor so when you select a tile you know what height, facing, metal, and features you're getting.
2. Load the graphical map editor.
Nurrr. See every Blizzard release. You'd probably like to provide the same level of map generation tools, possibly a program to build new tilesets from source images, and ditch all of the mission building elements, at least for the time being. When you load you select a map size, this will construct the grid for you to drop your tiles into.
3. Build your map.
Take your tiles, place them. Switch between views to make sure your geometry is coherent and you have enough metal/features/height variation. You would probably edit as an flat plane, like you do manually at present - however somebody could implement a three dimensional heightmap renderer, complete with voids for missing tiles. I would note that voids themselves will not render, a tileset could have a void option but that would have to be added as a tile. When your map is constructed, then you load your skybox. If all the constraints are met you can then build your map, probably direct to .sdz or .sd7, with a field for adding documentation. The program would stitch the maps from your tiles, dump the features from tileset to map directory, save documentation/license as text, and package the map. Ideally then you would have a direct test button that launches Spring with the map and a neutral/basic test game with a unit placer so you can test movement with general movement types.

However, this is a manual version. An automatic generator would have to be run host side and transmitted, which means all the clients would have to wait. With a comprehensive composite tile set, and a program that takes a few randomly generated numbers to handle variance you could have it generate usable maps but they would be choppy. Some sort of framework would have to be built to check the map for reasonable height coherence, to rebuild sections until they make sense, and to place resources reasonably. This logic would be the stumbling block for implementing random map generation, though with enough work, a host would just...

1. Set Size (Tiny 4x4 1v1 to Enormous 42x42 8v8)
2. Set Tileset/Tilesets (Mars, Pluto, Dead Terrain Set Collection...)
3. Set Economic (Low to Ultra High Resources, Low to Ultra High Features)
4. Set Moisture (Dry to Aquatic)
5. Set Variance (Flat to Choppy)
6. ???
7. PROFIT

Anyway, after the above system was working you could add a secondary feature system, to add features that aren't pre-packaged with a tile - this would involve having a feature collection with predefined facing and in-tile placement, sort of like the little map embellishments you could add with the Blizzard tiles. Lua support in the map editor could come after, but I would just offer a map compile to directory option so people could add their lua manually in the meantime.

I would like to note that I know of only a handful of people with the artistic skills to create semi-realistic tiles of this sort, even fewer with the discipline to finish a full tileset. The project you would see using this sort of method first would probably be something which doesn't require realism, something which generally uses flat surfaces to begin with. Making the first full tileset would be a real pain, for various reasons I don't have the time to get into.
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: support for creating next-generation maps

Post by Master-Athmos »

Well to my understanding the only hurdle to just have something that "works" technically is about pathfinding as this should be the only thing that would totally break anything. There still would be graphical problems to solve but from my understanding the decisive part really is about getting something into Spring it can process its pathfinding upon despite how the outcome will actually look like...

Afaik this is pretty much just about the heightmap. So with a tileset you'd just need to put some square bitmaps next to each other and save that as a new image und use it as the heightmap. You might want to do a blur or something on the edges to counter any unwanted steps there. To my understanding you also could do this technique for the other textures although here you of course have a huge disadvantage as e.g. a resulting 2048x2048 texture for the entire map will not look good. Still it technically shoud be possible...

So in the end we'd need either a technique for handling terrain areas chunked (in terms of rendering) or we just need a way to sort of having a texture for each tile around and than get the respective polygon's UV-space applied to them. I have no well thought out solution or suggestion towards this though...

I'm also no real pro when it's about the SM3 format but from what I read about it it seemed to work very much like what you'd call a terrain in general 3D engine slang...

EDIT:
The initial idea also isn't really about using tiles for creating small map areas although this in the end would be a very nice feature. In the first place it was about having a rather small number of tiles making up the entire map in order to provide something that plays new every time as a map pretty much never would be the same and you couldn't apply like the very same tactics you always use on a specific map...

This imo would be fun. Afaik it already once was suggested but at that time the SM3 format wasn't more than unusable junk. Now with it getting at least some treatment I'd like to know if this would be possible now without reinventing the wheel of everything...
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: support for creating next-generation maps

Post by smoth »

This would be an IMMENSE amount of work. I am not trying to be a downer but seriously, IMMENSE.
User avatar
Neddie
Community Lead
Posts: 9406
Joined: 10 Apr 2006, 05:05

Re: support for creating next-generation maps

Post by Neddie »

smoth wrote:This would be an IMMENSE amount of work. I am not trying to be a downer but seriously, IMMENSE.
If I changed my whole post to a smaller font because I, as a long-winded bastard, thought it was too long, and I didn't discuss the technical details at all, obviously it is an immense amount of work. :P
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: support for creating next-generation maps

Post by smoth »

Most of the engines that have mesh additions to the terrain also support mesh based collision along said objects. Something spring does not do.

So you guys are putting the cart before the horse with no horse in the first place.
User avatar
Neddie
Community Lead
Posts: 9406
Joined: 10 Apr 2006, 05:05

Re: support for creating next-generation maps

Post by Neddie »

My post was entirely working within the current constraints of the format. We can stitch manually, for instance.

But yes, if we want the maps with "modern" features, not just a tile based mapping program, we definitely need a score of advancements and, as usual, a new bloody format.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: support for creating next-generation maps

Post by smoth »

I think just getting the ability to have some sort of mesh based collision on map features and allowing for movement across and onto objects would be a big advancement enough to make most of this exceptionally feasible.

who is going to add that though?
Master-Athmos
Posts: 916
Joined: 27 Jun 2009, 01:32

Re: support for creating next-generation maps

Post by Master-Athmos »

I'd say for the random map generation we just need to have sort of a UV-space for certain parts of a map. Generating the entire map's heightmap is no problem - giving it any good texture is not as e.g. putting an entire map's texture in a 2048x2048 texture would be way too low-res imo and not look good on any not tiny maps. So we'd need to have certain polygons of a map getting their texture from an individual "bitmap" so that every tile would have like a 1024x1024 texture of its own...

But apart from that - here's a hackish idea I just had. Let's assume we'd create a heightmap by placing the respective tiles next to each other and save that as the new heightmap bitmap. Then we assign something totally unimportant as a texture. Unimportant for the reason that we now are going to disable the terrain rendering (-> Lua gadget , is possible already afaik). Would there now be a way to place some s3o objects representing the terrain tiles as sort of a fake?

So we'd have an invisible terrain responsible for unit movement, pathfinding and so on. What you see are just going to be some s3o objects though which all have a texture of their own providing the desired texture detail. As long as one would play with non-deformable terrain this might actually work...

The next question probably would be if there's a way to get access to a s3o's vertice position so you could adapt their position to that of the invisible terrain...

Any opinions on this hackish method actually being realistic?
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: support for creating next-generation maps

Post by smoth »

well there is a constant shift of focus in the thread so I would say there is no realistic possibility.
Post Reply

Return to “Feature Requests”