minimap - have some sort of minimap

shirishag75 commented 11 years ago

hi all, it would be nice to have some sort of minimap - maybe something which can be turned on and off with some keyboard combo. There could be one or more kinda minimaps.

a. A minimap which shows where you are located in the map/dungeon currently playing.

b. An overall map which shows how much of the overall game you have discovered with possibly marking of save points (as supposedly they would be rare.)

As of now only Bertram is working on the game, so he should be thinking about it. As I'm no coder I dunno when is the best time to start thinking about it, just putting it out on the open, so maybe it can be roadmap whenever Bertram thinks fit.

Bertram25 commented 11 years ago

While it's an interesting idea, I won't work on it for the first two releases. So I'll add this in the new 'later' category for now.

NemesisDD commented 11 years ago

I don't know exactly if I already made some comment on this before (if not, I definitely wanted to but forgot...). While you are right - it can wait -, I definitely agree on the MUST of having minimaps. ;)

Bertram25 commented 11 years ago

Ah, people are so much assisted nowadays. ;P Well, alright, but I think you both will understand, I should make the battle status effects working, and focus on content. :)

NemesisDD commented 11 years ago

Definitely. But I really hope to start coding in next days. So maybe I can take some work off your shoulders... starting with the main menu stuff.

Bertram25 commented 11 years ago

Good to hear :) I'll then focus on removing the tabs asap. And set the new 4 spaces indentation rule on. ;)

IkarusDowned commented 11 years ago

pokes head in just curious if anyone looked into some ideas for how to do this?

shirishag75 commented 11 years ago

Actually a very simplified way of doing it would be :-

a. Let's assume all the places are in a x, y grid for simplification. Let's say an arbitrary assumptive grid of 20,20 in x, y format. b. So at any place at any time you would be in some place in x,y in some place. This is good as it can be easily shared in walkthroughs such as go to 'Layna Forest cave, 15,15' and you will meet so and so or have something. c. This info. could also be shared with the player by means of a toggle switch/checkbox in the menu somewhere. d. The minimap looking wise should be an approximation of the map with the usual fog of war thing for places not gone yet .

As and when we have minimap there are number of possibilities which can happen (esp. with cheat codes). We can use it show number of enemies/hostiles on any given map, places which have some nice treasure and all kinds of secrets.

I am sure there is a secret area/easter egg or two that Bertram25 has hidden in the game somewhere for people to find. If any of our beloved devs., gamers anybody knows where please send me a mail at SHIRISHAG75 AT gmail dot com (all in small letters please) .

Looking forward to play the separation/judaai (hindi word meaning the same thing) of the yet to be lovebirds.

I'm sure other people would have more better and more elegant solutions to share.

Till l8er.

Bertram25 commented 11 years ago

Hi,

This is how I see it, while I'm not completely sure of myself yet:

The menu part:

A tab in the menu mode could show the place you currently in and the more general place you're at in the currently known world map.
Setting the currently focused map/ world map (that will change while the characters are advancing in the game) should be feasible at the script level, and very simple. Just set an image.
Setting the current character placement will be done on the script level because the placement will always be vague in this menu. I will never/ever show treasure/character/enemy coords and all within the game since it's not Zelda. And this will be the job of the ones making walkthrough ;) Just set pixel coords relative to the top left border of one of the two maps.

Within the map mode: (optional IMHO) A very light as in not gui cluttering minimap could be shown within the map mode. I'm not actually convinced it will be quite useful, at least for now, yet this one could show characters, monsters but not treasure chests. It would be an easy spoiler, since all the treasures in game are boxes.

The minimap shouldn't not have gui borders, have no flashy colors as for the background, and be very transparent. At the final point, the minimap shouldn't be too big, and hidden per default.

IkarusDowned commented 11 years ago

do you intend to pre-generate the minimap from say, the map editor? or should that be procedurally generated upon world entry? both are possible and will generally follow the same generation algorithm, but its a matter of cost at map-creation vs transparency and auto-creation during play time.

A tab in the menu mode could show the place you currently in and the more general place you're at in the currently > known world map.

can you provide a quick mock-up picture of what you are envisioning? For some reason i'm having trouble following and a visual aid might help

Bertram25 commented 11 years ago

I think I'll pregenerate it and display a part of it based on the sprite position, something like that. I'll probably need to hack the game to put out a minimap image generator in place, though.

can you provide a quick mock-up picture of what you are envisioning? For some reason i'm having trouble following and a visual aid might help

Sure. I didn't think anybody would touch this one any time soon but if you're interested, here is what I had in mind: maps-mock-up

(The 'world' part)

As for the region part, it's simply another map, maybe a little more precise and indicating the different places around.

shirishag75 commented 11 years ago

Just can say wow as in looking but for playing purposes doesn't make much sense.

Has anybody seen the maps done in virtual villagers as an inspiration or ideation.

See for instance :-

http://www.casualgameguides.com/games/includes/Virtual-Villagers-5-New-Believers/images/map.jpg

as well as :-

http://4.bp.blogspot.com/_YR-qCJXphXU/TUgfPKPDWZI/AAAAAAAAAYI/mtHbqrjwgaE/s1600/Virtual_Villagers_5_New_Believe+2011-01-23+01-23-09-64.jpg

As FOW (Fog of War) lifts the map should map places and things, would make it more fun for people.

Comments welcome.

Bertram25 commented 11 years ago

Yep, the world map shouldn't be shown by default but rather if selected.

The 'Region' map should indicate the different places, indeed, as I said above. Note that 'Region' is a temporary name until something better is found.

IkarusDowned commented 11 years ago

looks like the world map @Bertram25 has in mind is like the old FF style world maps. In this case, locations names should appear on the map as the scripts "trigger" them to be shown. We can deal with implementation deals later.

The mini-map doesn't neccesarily need to be a hack; I have a general algorithm rolling around in my head which could, in threory, auto-generate a mini map. I would say we could split this task into 2 -- one ticket for the world map, one ticket for the minimap. While they seem like the same thing, there is a distinct difference in the concept and implementation details IMO

shirishag75 commented 11 years ago

@IkarusDowned you are right on the money. I had the same idea about having two maps, the world map and the minimap which goes in more detail about a specific 'region'. The rest is upto you guys.

Bertram25 commented 11 years ago

In this case, locations names should appear on the map as the scripts "trigger" them to be shown.

Yeah, something like that.

While they seem like the same thing, there is a distinct difference in the concept and implementation details IMO

completely agree, starting by the world sound easier to me as a first go.

IkarusDowned commented 11 years ago

I'm a little unsure about the "region" map. that seems kinda unnecessary to me, but maybe I just don't understand yet.

Bertram25 commented 11 years ago

Let's forget about the region one for now. Maps are representing quite some work anyway, and you're right, it might just be a zoom of the world one and be unnecessary.

IkarusDowned commented 11 years ago

I'll start some work on the world map, then. Let me know if there are any stock images you can provide me with for the map, the pointer and things such as that. Any particular LUA interface preferences? I'm imagining, much like the quest log, have a table for the different locations you want shown, and their x,y location on the grid. I like the re-use of the location information in the bottom window, but i think we should remove the Time and Drunes and stuck with the name and image-banner. This will also probably be added to the table.

from the scripting side, i imagine a ShowWorldLocation(string_id) / HideWorldLocation(string_id) sort of thing?

Bertram25 commented 11 years ago

Hi @IkarusDowned, :)

You pretty much sum it up. Apart from the fact that I'd like to be able to reset the world map shown any time by giving an image filename.

something like: SetWorldMap(string), with SetWorldMap("") hidding it. I assume all the world locations should be set back to hidden when changing the world map.

You can use the default cursor or the hand pointing down if you want: https://github.com/Bertram25/ValyriaTear/blob/master/img/menus/hand_down.png

As for the map, I must admit that I have nothing fit to be seen ;) Yet, the image I used comes from here: http://opengameart.org/content/fantasy-world-map

Maybe, maybe one day, we'll use this to actually travel the world, btw: :) http://opengameart.org/content/worldmapoverworld-tileset

Thanks a lot for taking of such nice features and when thinking about the quest log, I can even say it was pretty quick! I can hardly follow with content to honour the features you add. ;D

IkarusDowned commented 11 years ago

haha, don't worry about trying to keep up with the changes -- you're the content master and there's way more content than features. We'll just make sure the features are there when you are ready for them

IkarusDowned commented 11 years ago

Hi all, haven't had a lot of updates recently, so I thought I share what I have done so far. Real Life is taking a chunk of time at the moment, so you may not see as much progress from me as you did in the past until mid-feburary

that being said, here's some basic working code for the map from the menu. world_map

so hang in there, its comming along :)

Bertram25 commented 11 years ago

Woohoo! It's coming along nicely already. :) Take your time :)

IkarusDowned commented 11 years ago

OK! yet another screen shot for everyone to look at. worldmap

thats right! world map locations and a pointer! the world map location is set by lua script, meaning that yes, we have scriptable locations. the pointer moves locations view left / right press. cancel returns to the main menu.

todo:

adding the pointing to location info in the bottom screen
either provide a "SetCurrentGlobalLocation" function in global, so the initial pointer location is determined by the script, OR make the code determine, on entry, where it is. This is a design decision -- for now it just defaults to the top of the location list.
save / load the current map and the current view able locations

@Bertram25 as you can see, the location marker is the "eye." Is there a "flashing diamond" sprite or maybe just a circle StillImage available for use? I couldn't find one.

IkarusDowned commented 11 years ago

actually looking at the current code, the easiest thing to do for bullet 2 is:

add a function to global called SetCurrentLocation(locaiton_id)

and use that to default to when opening the map menu. This is because, it looks like the location banner and name are not stored globally, but instead set thru a ModeManager:Push call, which takes a MenuMode instance with the location name and image set. It seems that unless we make major code changes there, its easier to just have the "location name" and "image filename" also in the location information on startup.

rootslinux commented 11 years ago

Is the location name/image not stored in the GlobalManager? I thought for sure that it would be. But yes, I was looking at the MenuMode code yesterday and noticed that you have to provide it with a location name/graphic filename in the constructor. I thought it was because the MenuMode code is so old that it hadn't used the calls that were added to GlobalManager.

But anyway, I agree with you. GlobalManager should store the current location name and filename, and there should be Get/Set accessor methods for this data. Then any game mode will have access to this data easily.

IkarusDowned commented 11 years ago

The only problem with that is that we would need to make some serious changes to the currnet MenuMode push / poping...it looks like all that is set in the constructors and pushed on the game mode stack at the moment. If we mad eit quereable, we would need to rework that I think. Not saying we should do it, but that might be a different task altogether.

On Sat, Jan 12, 2013 at 12:35 PM, Tyler Olsen notifications@github.comwrote:

Is the location name/image not stored in the GlobalManager? I thought for sure that it would be. But yes, I was looking at the MenuMode code yesterday and noticed that you have to provide it with a location name/graphic filename in the constructor. I thought it was because the MenuMode code is so old that it hadn't used the calls that were added to GlobalManager.

But anyway, I agree with you. GlobalManager should store the current location name and filename, and there should be Get/Set accessor methods for this data. Then any game mode will have access to this data easily.

— Reply to this email directly or view it on GitHubhttps://github.com/Bertram25/ValyriaTear/issues/23#issuecomment-12172908.

IkarusDowned commented 11 years ago

@rootslinux I'm not seeing any globally held "current_location" information, but its possible i'm looking in the wrong place. i was looking in global.hpp?

rootslinux commented 11 years ago

Yes, it should be in global.hpp if it's anywhere at all. I think that you are correct that this information is not currently a part of the GlobalManager, but it should be. I'm going to be adding it in to the Allacrost code tonight and make the adjustments to MenuMode so that it no longer requires this information to be passed via the class constructor. I need this to be added anyway to get MenuMode tests working properly with my new testing interface that I talked about in another recent issue here.

IkarusDowned commented 11 years ago

Ok, well, for now i'm going to proceed with having the location name and image be in the location data. It should be pretty trivial to take that and change it to an id and do an id lookup at a later date

IkarusDowned commented 11 years ago

check pull request #115 for the current World Map implementation! still waiting for a couple changes, but its mostly in :). We're mostly waiting on a location indicator graphic. right now its still the "eye"

Bertram25 commented 11 years ago

Hi, thanks for the hard work! :) I've added a animated location marker and a made a few small fixes cleanups here and there. :)

As for the location name being part of the global manager. Hmm, why not, indeed :) I'll handle it.

rootslinux commented 11 years ago

I just opened up the GameGlobal class (aka GlobalManager) and I found that the location stuff was already in there:

/** \brief Sets the name and graphic for the current location
*** \param location_name The ustring that contains the name of the current map
*** \param location_graphic_filename The filename of the graphic image that represents this location
**/
void SetLocation(const hoa_utils::ustring& location_name, const std::string& location_graphic_filename);

/** \brief Set the location
*** \param this is really only used when starting a new game, as we don't know the what the location graphic is yet
*** the location graphic filename is loaded during map loading.
**/
void SetLocation(const hoa_utils::ustring& location_name)
    { _location_name = location_name; }

/** \brief Sets the location
*** \param location_name The string that contains the name of the current map
**/
void SetLocation(const std::string& location_name)
    { _location_name = hoa_utils::MakeUnicodeString(location_name); }

hoa_utils::ustring& GetLocationName()
    { return _location_name; }

hoa_video::StillImage& GetLocationGraphic()
    { return _location_graphic; }

I'm almost positive that VT should have this in it's code as well. Maybe we were talking about two different things and did not realize it?

Bertram25 commented 11 years ago

Yep, this is true, and I fixed it last night: https://github.com/Bertram25/ValyriaTear/commit/e95b50ec31b140ae62e0e13b588f5cabf5e9a931

IkarusDowned commented 11 years ago

whops, sorry. i guess I didn't notice that. apologies and thanks for checking for me

On Sun, Jan 13, 2013 at 7:04 PM, Yohann Ferreira notifications@github.comwrote:

Yep, this is true, and I fixed it last night: e95b50ehttps://github.com/Bertram25/ValyriaTear/commit/e95b50ec31b140ae62e0e13b588f5cabf5e9a931

— Reply to this email directly or view it on GitHubhttps://github.com/Bertram25/ValyriaTear/issues/23#issuecomment-12191723.

IkarusDowned commented 11 years ago

ok, just looked at the code, I was imagining something a littler different. i was hoping that the location name + image would be a "set", tagged with some ID in a config file or something. so when you SetMap() it would be SetMap(locaiton_id), and internally the tag would associate to the correct location. So that would mean that there would be some map of id - to - location name + location image in GlobalManager. Not suggesting this change is neccesary -- just a misconception on my part

Since the name and imag eis still controlled by the script, I suggest that we keep the current world_locations.lua the way it is -- that is, we set the filename and location name inside there, instead of a location_id key.

In this case, because there is a chance that the location name set in SetMap can differ from what is set in world_locations, I suggest that we keep the SetCurrentLocationId() function as well, and that way it can be controlled through the script. thoughts?

Bertram25 commented 11 years ago

Hi @IkarusDowned

All in all, I let it as is, indeed. I 'd like to keep the ability to set the exact sentence, and the image I want for a given location. Because, one can imagine a map location, but with different world locations names, or "sub-locations", for instance. The use of it will prove the right way to use it, yet I do think it's straight forward, simple and okay like it is for now.

Regards, :)

IkarusDowned commented 11 years ago

aaaalll right. Looks like its time for step 2! introducing a mini map during "map" gameplay. This is actually not too bad, but it does require a couple things:

1) In order to maintain a "fixed size" minimap, we will need to have some absolute max / min guidelines for the regular map. @Bertram25 can we guarantee a world not being more than X by Y ( ore better yet, X by X) number of tiles? Keep in mind this doesn't mean ALL maps must be X by Y, just that there is a max bound to them. 2) Each "screen" on the map will essentially act as a single "location" on the minimap. There are two ways to generate this smaller image: a) draw the entire map to a separate buffer and scale it waaaay down, such that each each screen represents a "square" on the minimap. b) pre-generated "scaled" images per-screen which we can use a heursitic to determine which to pick for the given screen. Either one is OK with me, but both depend on (1).

We could also have the minimap itself pre-generated as an image, and then just calculate offsets into the image to show location and such.

IkarusDowned commented 11 years ago

slight correction, looks like we need to create a parent "map" script which explains the relationship in some sort of grid-fashion, all the "maps" of a given region. This may take some changes to the map editor also, if we want to do "region" based minimaps...

Bertram25 commented 11 years ago

We could also have the minimap itself pre-generated as an image, and then just calculate offsets into the image to show location and such.

That's it, permitting us not to be forced to have a max tile size for the maps

The minimap could also, now or later, be pre generated by the editor, the game using a parameter, or a custom tool out made out of a portion of the game code. I would rather prefer have the minimap option as a debug parameter of the game (disabled at release builds) as it would permit to only maintain one codebase for it.

Bertram25 commented 11 years ago

slight correction, looks like we need to create a parent "map" script which explains the relationship in some sort of grid-fashion, all the "maps" of a given region. This may take some changes to the map editor also, if we want to do "region" based minimaps...

The region map would be a subset of a location map (a table of sub-locations in the map locations config script), that's all. No need to go further, that would already be just perfect :) I would use a custom image for region maps also. As for the API, showing/hiding the sub-locations should be possible with the same rules than the mother map.

Thus, when you confirm on a location which has sublocations, it would change the world map to the region map and display just another map with other location marks. I guess we'll want to use different location markers (just crystal animations of different colors)

And in dungeons only, the mini-map would be available in a second 'Map' sub-menu, next to 'world map', displaying only the parts where you did go roughly. (I don't know how to code that, yet :S)

Fine with it? :)

IkarusDowned commented 11 years ago

I was thinking that you could just have it on the main play window, and leave the menu as is. that seems more intuitive to me. So, above the "sprint" bar

Bertram25 commented 11 years ago

Ah, right :) That, too, and in the first place. Yes, this is the very first need.

The minimap displayed in the menu mode would be the kind you see in Zelda when in a dungeon and looking for the overall picture of the current dungeon map, but it can wait for much later.

IkarusDowned commented 11 years ago

Ok, I think we might be branching again, so lets split this once more into pieces: "Location" map and "mini" map. Lets focus on the location map first. If my understanding is correct, the "location map" would be:

given a certain map, for example "layna_forest_entrance.lua", the location map would draw the general "bounds" of the map, along with any (a) discovered special points like saves and (b) exits / entrances.
each "location map" is considered independent from the other. IE, layna_forest_entrance.lua would not care about layna_forest_north_east.lua
the visibility of each location map would be scriptable, along with any sort of (c) fog of war and other map effects
as the player moves around a map, their position would be updated on the location map
location map is viewable through the menu.

(a) is a feature we can add later, it does not necessarily need to be in the first-iteration. (b) seems like a must. at the very least, the location map should have some way of saying "this is not a wall, it leads somewhere else." (c) also seems like it is needed.

Does this sound correct?

Bertram25 commented 11 years ago

Hi Everything you wrote sounds pretty relevant to me. :-)

shirishag75 commented 11 years ago

A very simplistic view of the minimap could also be seen in freedink. www.freedink.org.

IkarusDowned commented 11 years ago

@rootslinux is there any way to draw to a texture through the video engine? IE, off-screen rendering? The reason I ask is that I'd like to generate the "minimap" on map load, and simply render it during the draw calls. In order to do that programmatically, I need some sort of way to render off-screen.

Bertram25 commented 11 years ago

@IkarusDowned You mean, not render it on the screen surface, but rather on a created client-side memory texture?

This is called procedural images, IIRC. I think you're after the ImageMemory class. src/engine/video/image_base.cpp file at the beginning. But this class might lack a few functions to be able to put pixels values on the relevant memory place before putting the whole pixel map onto the GPU as a texture.

I do think this could be solved by looking at how the engine does to apply pixel values to a textures at image loading, though. Not an easy one :S

IkarusDowned commented 11 years ago

not quite Bertram. The ImageMemory class is for taking pre-existing images (textures, pictures, screenshots, etc) and doing manipulation on them. But I think I can utilize that. I guess If i created the texture array and manually manipulated the data, that would certainly work. What i was really hoping for was something like this: http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-14-render-to-texture/

The idea is that I could continue to use the current rendering engine archicture, but all the calls would be drawn to a texture instead of to the screen buffer. This way, we increase the useability of the VideoManager by allowing off-screen rendering for generated data, and then we just blit / ImageMemory the data as a texture image and use it.

If I'm thinking about this all wrong, or if its far too much effort to implement, do let me know! I don't mind writting it in as neccesary, but I just want to make sure I'm not duplicating work or missing something obvious

Bertram25 commented 11 years ago

Ah indeed, this is the exact other way around. :)

Note also that I somehow may have concerns about manipulating textures on the GPU memory as a question of syncing and performance, that's why I rather thought you would want to create and manipulate them in the main memory, at first. But let's give it a strong try if possible.

Using a separate framebuffer is a good idea, while you should take a good care if, for instance, you would use only one framebuffer accessible from the videomanager, data blit on screen might become mangled when we later that feature more aggressively. We'd then need to add support to create an arbitrary number of framebuffers, use them, and get rid of them on the go.

This might be simpler or more complicated than I think, depending on how the texture manager existing code will help / get in the way. As you surely know, when pushing Ctrl+T, one can see the different textures used, and I do think most of the code is already there to create and manipulate data onto a texture.

Thus, adding support for such a thing would be just awesome!

IkarusDowned commented 11 years ago

I'm studying back up on my OGL now, and based on whats written in that ogl tutorial, it shouldnt be that much different. we mostly need some way to specify the target, and then push / pop or at least save the previous target so we can restore it.

Alternatively, the minimap can be created as such:

pre-generated images that are associated to each location "tile" on the map. These are specified much like the layers themselves, in a "minimap_tiles" table or something. This would be used to essentially do location-lookup for changing the player location on the map, as well as linearaly traversing it for the basica minimap rendering.
use the player location and lookups to draw a "dot" as to where the player is

the benefit of this method is that we don't to do much (if anything) to the rendering engine. The downside is that

need to modify the map editor to allow for a "generate minimap" option
potentially slow to render. Since it will need to do more function calls (as opposed to just drawing a texture)

ValyriaTear / ValyriaTear

minimap - have some sort of minimap #23