MiniMap

[StefanP.MUC]

I don't know how much you already cared about the minimap, but I just found a minimap tutorial for Ogre/CEGUI:
http://www.gamedboy.com/tiki-index.php? ... ap%20CEGUI

In my GUI design I will put a StaticImage element that later can hold the minimap.

[svenskmand]

Nice The game will look very complete once we get this

[StefanP.MUC]

In the current gui design I uploaded (see GUI thread), the minimap is a StaticImage called "Root/MiniMap" and has a size of 150x150 pixel.

According to the tutorial, the coding part shouldn't take to long with Ogre. I think at the latest with 0.4.8 we'll have a Minimap.

[andrewbuck]

I had a quick glance a the tutorial and it didn't look too bad. I will try to look into the map soon here. I had been thinking about this for a while and now that you posted a good example of how to do it I should be able to make that work fairly easily.

-Buck

[StefanP.MUC]

I just got the minimap working.

However, I won't push it until I have sorted it into the right code place and adjusted the cameras, parameters and everything.

[TheAncientGoat]

Awesome news, got some screenies?

But boo for SVN-type SCM practises Commit, commit, commit then merge to the main branch, instead of everyone waiting for perfect commits to one repo...

[StefanP.MUC]

Screenshot. MiniMap is in the top right corner. Camera position is currently set to the starting camera position (autocalculation is on todo list).

I push when I think it's time to be pushed. So, please don't push me. It's on git now, so 0.4.8 will have the minimap included.

[svenskmand]

Awesome Stefan When you get it sorted out we should try to make it round, that will look better But nice work

But boo for SVN-type SCM practises Commit, commit, commit then merge to the main branch, instead of everyone waiting for perfect commits to one repo...

What?

[StefanP.MUC]

Yes, round frame should be better. But this is purely a matter how the CEGUI element is defined in the gui XMLs (and of course the frame needs to be drawn roundly in the PNG). Fiddly work - so this is for 0.4.9, I'd say.

SCM: http://en.wikipedia.org/wiki/Supply_chain_management
I see no reason in commiting non-compiling code (unfinished but working code is something else, of course).

[oln]

Yeah, if it's just a matter of waiting a few hours to finish a feature, I don't see the big need for a branch. If there was a feature that would take a long time, say a matter of weeks, and you don't want in the main tree until it's ready, then branching makes more sense.

[svenskmand]

Did you break this again? The mini-map is just black on the latest development version

[StefanP.MUC]

Yes, all it was doing was showing the field of a regular camera. But this isn't what we want (don't know why all tutorials I found do it this way).

What we really need is to iterate over all tiles and get their owner (color) and type (wall, room, water ...) and other infos (has it a creature on it for example) and display some pixelmap showing all this with good colors.
I already found some ways of doing this with Ogre. I will have to see what is the best of them.

[svenskmand]

Yes yes, I just wanted to try it out that is all

But nice that your already working in making the improvement

[StefanP.MUC]

I have now decided for a system. I create an Ogre Texture and directly access it's pixel buffer. This way I can access the pixel I want to change directly. Then I pass the texture to CEGUI.

What needs to be decided now are the colors. Of course, the buildings will simply have the player color. But what about creatures, walls, water, unclaimed terrain, fog of war, etc?

By the way, I didn't took a look into how the game handles the colors until now, but it seems that colors are stored as an integer. How does the game get the actual color from this integer?

[oln]

I think the game currently uses an array/vector with the possible team colours, and the integer describes which of these colours the team has.

[svenskmand]

I can try and make a example map using all the different colors, and then we can discuss which colors are best. If you list all the different types of tiles you need then I will make a mock up map with each type of tile/creature and give them some colors so we can discuss it.

[StefanP.MUC]

I think we need these tiles to appear in the minimap (including suggestions):

• water (light blue)
• lava (light or dark red)
• neutral wall diggable (dark brown)
• neutral wall non-diggable (dark grey)
• unclaimed ground (light brown)
• claimed ground (team colors)
• claimed and hardened walls (team colors darkened)
• rooms/traps (team colors lightened)
• creatures (somehow coupled to the team colors, but different from hardened walls and rooms/traps)

[TheAncientGoat]

Hmm, tiny icons for each creature could be rather useful, come to think of it.. Should we put out a media request for it?

[svenskmand]

Hmm, tiny icons for each creature could be rather useful, come to think of it.. Should we put out a media request for it?

Not in the minimap, that will mess it up too much, or the icons would have to be so small that there is no point in having them there any way. But we need icons for the creature panel at some point.

[MCMic]

Points are sufficient for creatures on the minimap.

[svenskmand]

Points are sufficient for creatures on the minimap.

Exactly

[StefanP.MUC]

Basically there are three ways of doing a minimap:
1) each tile is represented by a single colored pixel
- pro: "real" minimap (like you expect it to be)
- contra: if there's multiple objects on a tile only one can be displayed, example: creature from Player A fighting creature from Player B on territory from Player C

2) a "satellite" camera (a far away "tv screen" of the original game)
- pro: probably the most easy one to realize code-wise
- contra: what is it good for? just zoom out the regular camera and you have the "minimap" on the whole screen

3) a complex map (each tile is represented by an area of pixels, movable icon overlays are displayed on top)
- pro: most informative, most fancy one
- contra: extremly hard to code, needs alot of new artwork, probably strongly CPU consuming (as long as we don't manage to solve the current performance issues, we shouldn't introduce new ones)

I vote for 1) and optionally 3) for whoever feels doing it in the far future (I won't do this hard task, at least not now ).

[svenskmand]

The one in DK and DK2 is a mix of 1 and 3. Put why is there much difference in complexity between 1 and 3? I mean 1 in you only move pixels around, in 3 you move images around. And are you sure you cannot do it in a smarter way than painting each pixel yourself? E.g. use some functionality of ogre or cegui?

Can you not use something like overlays in ogre? Or have you looked into that?

[oln]

I think we should go with 1 first, as it's quite simple. Then 3 could be tested later. Alternatively, creatures could be small dots or something meanwhile if that would be simple to code.

[StefanP.MUC]

For the pixelmap I already use the most fancy way of Ogre already (it's basically a for-loop iterating over all pixels/tiles and setting the colors). CEGUI doesn't support this (I heard, 0.8 will have at least some functionality in this direction that could maybe, maybe not help us).

Everything that goes beyond pixels needs a lot more coding effort. If we are hard-working we could target a more complex minimap for 0.4.9 or 0.4.10. But for 0.4.8 I don't want to have more work (or the version will never be release-ready because it will have all this non-working stuff).