Implement minimap

[franciscod]

Should we limit the world terrain size for this? What if the world grows? The minimap scale changes accordingly to accomodate the whole world?

attached screenshot for reference

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[lilezek]

Scaling minimap wouldn't be a nice feature in my opinion. I can think about two alternatives: · To center the minimap to the region you are. · To make the minimap able to zoom.

[franciscod]

In the game, the world has a defined size so it calculates the minimap scale on initialization. In our demo, the world can grow indefinitely. That's the main difference.

Should we fix the world to some size?

[hackathi]

It's against intentions to cut anything at any given arbitrary limit (at least in the engine - I actually think that fixed size maps have to be supported, but that does not affect the possibility to have an endless map). I'd go with a scrolling minimap, that shows reasonable sourrounding or the whole map if it is small enough.

[mic-e]

Fixed-size maps would obviously be supported, and the default mode for regular games, but maps with mincraft-like infinite terrain generation, or cylindrical/toroidal maps would also be incredibly cool...

I think for now we should just go with a minimap that scales down each time the map has grown (maybe in powers of two).

Monoterrain means we're able to draw just one single type of terrain. We're far beyond that at this point, but the building placement still doesn't work perfectly (think town center), so the milestone isn't finished yet.

[goto-bus-stop]

I think scaling it provides the most flexibility in standard, non-infinite-map games, as you can then have any predefined map size, and have the minimap fill its entire box.

Minimaps on infinite maps are a bit weird, you're almost definitely going to center it on your current viewport location, but at some predefined size or zoomable?

Maybe initially we can just have it scale, and not render non-generated chunks (& unexplored territory), and add something for infinite maps later?

[ghost]

Is anyone working on this at the moment? If not I would like to work on it.

[franciscod]

go on @jgelderloos !

[jfeo]

Are you still working on this @jgelderloos ? I've quickly put something together... judging by the temperature of my cpu when I run it, it's preeeeetty inefficient, but I could probably improve that ;-)

No units yet, and terrain colors are hardcoded to the terrain_id of the tile, and many other issues, but it looks alright at least :D

[ghost]

@jfeo , no not at the moment. I had a start on it but got distracted and have not worked on in a quite a while. What you have looks good. A few things to think about: The minimap probably does not need to update that often, maybe only once a second or so. Also, you may not want/need as much detail in it as you have. Especially if you want to support the goal of having very large maps you will need a way to compress the terrain data. So if there is a tiny lake in a large map, maybe it does not show up in the map. Anyways, good luck with it. Le me know if you make a PR of this and I will take a look at it.

[jfeo]

My idea for the minimap would be to make several layers, for terrain, units (and different kinds, such as military, civil, trade?). Mapping from minimap coordinates to real game coordinates (which is sort of needed anyway to make it at all).

A lot of the minimap computations happen each frame for now. Ideally at least the unit layer (when it is implemented) should update every frame, I think, as it will look weird otherwise. For the terrain, it would probably be better to only do an initial texture and then update it when the terrain changes (Some buildings change the terrain underneath them).

I haven't found any functionality yet that can trigger a minimap update when the terrain changes. Does anything like that exist?

Also the issues of how to choose a colour for each terrain_id... Initially I suppose it is okay to hard code, but it would be nice with a better solution - perhaps based on the terrain texture images themselves.

[fricklerhandwerk]

@jfeo On minimap terrain color: You could pre-compute an average color from each tile at compile time and save that somewhere in a file.

[mic-e]

@frickler01 you could, and it's a good idea (but it would happen at convert time), but then it wouldn't look like the original game...

[jfeo]

I thought about that. It would be nice, as it kind of suits the idea avoiding false limitations, and would enable additions to the tileset without messing up the minimap. Another idea would be to keep the terrain_id color mapping as some kind of metadata, although if it is not kept in the original game files it might end up a bit hacky, and I haven't been able to find it.

[mic-e]

@jfeo: Not sure whether the data is currently written to a .docx file, but in Advanced Genie Editor, you'll find the color for each terrain in the Terrains section.

Edit: It is not. In openage/convert/gamedata/terrain.py, you'll have to change READ to READ_EXPORT in (READ, "color", "uint8_t[3]"),.

You might want to split it into three fields, color_red, color_green and color_blue.

[etandel]

I think using an average color for the minimap could be dangerous, since white or light grey tiles would appear too similar to stone (and relics) on the minimap. There may be other such cases as well...

PS: I just found out about the project, and it looks awesome! Congratz, people! =D

[TheJJ]

@etandel come by in our IRC (#sfttech on freenode)!

This data value is what we want to use as color for terrain tiles. And for units, there's this enum.

[timo-42]

my thoughts: Every player should be able to choose how he perceive the other players.

Examples: no blue for naval maps, no gree for grass maps, no green and red for people with dyschromatopsia.

new Feature: different shades of color for buildings, infantry, mounted and siege units.

[fricklerhandwerk]

@timohaas This is going off topic, but in Company of Heroes they solved it more elegantly using different shapes for different unit types, which is clearer given a minimum shape size. Needs more work to implement though.

@TheJJ Maybe add a comment there so one doesn't have to know this thread later in time?

[TheJJ]

I like the different-shapes idea. I added a comment there, it will land upstream whenever my to-be-created datafile patch (with new intel on the dat file) is merged.

[jfeo]

Hey! Been busy with holidays, but I worked a bit more on the minimap. The code style is probably pretty horrible, but at least it gives some visual gratification

[jfeo]

I wonder if it would be possible for the minimap to be notified of changes in the terrain/units, so it would not have to either recalculate everything in each frame, or only update in some set interval?

[mic-e]

Looks pretty cool. What software did you use for recording?

[jfeo]

Thanks! Still a lot of work to go though. Need to use datafile values for terrain (and player?) colors. Eventually elavation as well. A lot of optimization as well... But at least it kind of looks like something.

I use SimpleScreenRecorder to record (it is, at least, in the arch linux community repository, perhaps also other distros?), and just found vid.me for uploading without having to sign up.

[mic-e]

The problem with notifications is that stuff will get out of sync if you forget notifying in one particular place (unit movements, unit selections, terrain drawing, terrain changed by building construction, I'm sure I forgot about some). For now, let's keep it simple; there's always room for optimization later.

[jfeo]

The terrain colors defined in the terrain files are a bit odd. Using them, I get the following:

A look into the 0000-terrains.docx it is clear that the values do match what is shown:

Grass,g_grs,15001,256,100,1,55,236,54,0,10,10
Water,g_wtr,15002,257,140,0,19,19,19,1,10,10
Beach,g_bch,15017,257,110,2,137,124,88,2,10,1

The color values being

55,236,54
19,19,19
137,124,88

Anyone got any idea why this is?

[TheJJ]

323 brings a lot of changes for the terrain section, maybe you can benefit from it once it's merged.

[mic-e]

Maybe those values are not actually RGB, but... uhm... three different lookup values in the color table, or something?

[jfeo]

I'm a bit at a loss in regards to it right now. Maybe the fragment shader is supposed to do some kind of magic on it? Lookup values would be kind of weird, as it seems the palette indices all refer to a color and not a color component (using an 8-bit number to refer to another 8-bit number would be weird anyway, I think)

[mic-e]

What I meant to say was: Maybe it's just pure chance that there are three values, and every one of them represents an entire color. I have clicked around in AGE and found no hint that they're supposed to represent color components (though the fact that there are exactly three of them does of course hint that they might). Even if they represent color components, they might represent something exotic like HSV, for some reason.

[jfeo]

For the water colors the CIELAB color representation seems to be very similar at least. It's the closest I've come to any match, including HSV, HSL, etc. Think I'll leave it for a bit, and return to it later.

[Enephst]

Just wanted to say that it looks great and good work!

[jfeo]

After getting a lot of help on the IRC channel, it is now clear that the color values are palette references (maybe for different colors for each terrain depending on elevation/sloping) to palette 50500. Converting and reading this gives the following:

[lilezek]

Shouldn't snow be rendered different? Except by that I think those are correct colors, good job.

[jfeo]

Actually, snow is normally rendered the same as grass, like you can see in this video for example https://www.youtube.com/watch?v=mxNWMToDQWI

[jfeo]

I made a WIP PR #344