Map browser (ohyes, another one)

DeletedUser

Guest
I've noticed occasionally that some cities have a black circle within the square, what does that mean?
 

DeletedUser20248

Guest
A blue circle actually. That indicates that city was conquered on that day.
You can see the blue circle in the point graphs as well, indicating the same thing.
 
Last edited by a moderator:

DeletedUser20248

Guest
Thank you :)
Unfortunately my ISP decided to do some cable maintenance in the neighbourhood a few days ago and since then my internet connection has been going in and out. So if you find the map site to be unreachable, feel free to try again a bit later. I certainly hope this will be fixed sooner rather than later.
 

DeletedUser

Guest
The map is amazing. I love how you can interact with it and see the pattern of players growth.
 

DeletedUser20248

Guest
I added a graph type selector, allowing you to choose town points, player attack / defend / total points and alliance attack / defend / total points.
The new graphs also include the conquer circles again. So in a player points graph, you can see all conquers (blue circles) and also all lost cities (red circles) of the player.
The same for alliance graphs, where you can see all conquer events of the alliance. This becomes a bit pointless for big alliances though, but it does allow you to see if an alliance is gaining more cities than losing them overall (more blue or more red circles).

Just refresh your browser for the new feature to appear!
 
Last edited by a moderator:

DeletedUser

Guest
May I suggest some improvements?

Currently only 5 of each type of display can be entered, Any chance of adding more?

Alternatively, could you add the ability to add a comma or semicolon separated list to the existing entries? This could be useful to see where all of your enemies/allies are under one colour.

Ability to change the colours.

Finally a bug report. The time increment using PGUP/PGDN doesn't seem to work on Chrome.
 

DeletedUser20248

Guest
I limited the amount of input fields to 5, because there will be a lot of people who enter loads of alliances and then wonder why the map doesn't work. Especially on the older worlds with giant alliances this is a real problem. One could say it's the user's own responsibility, but ... they'll do it anyway and then complain to me and/or start to think "this is crappy".

Colour changing .. is it really needed? There aren't really better colours you can select. The existing ones have been chosen to contrast well against the background. Again, it's all about not allowing the user to do silly things. Also if you could pick your own colours, I guess you'd also want those colours to be saved in the url. This will make the url start to become really long and I'd like to avoid that. There are many things that could still be done, but I chose not to, in order to keep things pretty simple. Only those features that give you really good information are added (and I could be pursuaded to add more of those). I'm afraid colour selection wasn't one of them.

I'll have a look at the bug soon.
EDIT - now fixed
 
Last edited by a moderator:

DeletedUser

Guest
Thanks for the reply Viccoh,

I do understand your reasoning in limiting the number of input fields, but it also prevents "what if" scenarios from being tested. For example - a number of small alliances that are at war with a larger aggressor could be included under one colour, and still not have so many cities displayed that it affects performance. The converse would be true if 3 very large alliances were included, therefore including thousands of cities. What about an "Advanced" feature that allows for more alliances, but comes with a warning about performance?

Colours are fine, and it was only suggested after trying another method of "what if" scenarios.

I'd like to confirm the time increments correctly under Chrome now. Thanks
 

DeletedUser20248

Guest
thought about it for a bit and decided the best i could do is just add some more inputs (8 now) and add a dynamically displayed alert icon for when you are about to enter 4 or more alliances in the search inputs.
The best would be of course to speed up the drawing process, but I can't think of any more optimisations :/ (that are actually worth the trouble)
 

DeletedUser

Guest
Thanks for your time on this Vic, it's most appreciated.

8 sounds like a good compromise, and should allow for most situations. It seems you're damned if you do, or you're damned if you don't on this matter.

[Edit] I've just been testing it, and I don't see much of a performance drop. I'm not displaying too many cities however, but It's exactly what I needed. Thanks again.
 
Last edited by a moderator:

DeletedUser

Guest
Thanks again for the update :)

When you get to thousands of cities you can notice the performance drop. I was loading the 5 biggest epsilon alliances and that took about 2 minutes to load then when I tried 8 alliances it took about 4 minutes. Even though it has slow loading time with those numbers it is still by far the best map program I've seen :)
 

DeletedUser

Guest
I've noticed a small buggette/misfeature.

The alliance and city names use a text match, and I'm assuming your draw method is using the same. This is fine as long as the names stay the same, but it breaks should anything change. Player names can sometimes change too, so the same applies across the board really.

The ID's are consistent throughout, so possibly would be a better reference when drawing?

For example:

The Assassins Guild have renamed themselves as The Lonely Assassins now. Both names point to the same ID, and the name has to be changed when stepping through history. This is the world you currently inhabit btw.
 
Last edited by a moderator:

DeletedUser20248

Guest
Yeah I know what you mean (except about playernames changing - is that allowed? Seriously?). Actually I didn't even know you could change alliance name. I only knew about town name changes and those make sense (to me).

Ugh I never dreamt that those name changes were possible. It complicates things a lot. I'd have to rewrite pretty much the whole search, storage and display methods and tbh, I don't feel like doing that.

I did add auto complete though, but I've yet to put it live. I will tonight, along with the addition of the new world en29.
EDIT - autocomplete is live. En29 opens tomorrow actually, so I'll add that then.
 
Last edited by a moderator:

DeletedUser20248

Guest
The ID's are consistent throughout, so possibly would be a better reference when drawing?

hmm, actually I"m not sure what you mean by this. I do get the ID part, but not the drawing part. Well maybe I see what you mean, but I think then we'd have to change the way we think about how to use the browser.
Because now it's "what you enter is what you see". But if I'd somehow implement history-walking-with-IDs, then it is no longer "what you enter is what you see", as names may start to be different in the inputs and towns display. Colour would then become much more important and the names would be secondary.
I am currently not sure if that would actually be better (read : not confusing).

Imagine doing a new search when you are displaying data from two weeks ago. Would searching for "The Lonely Assassins" still give a result then? (assuming they renamed within two weeks - I dunno)
And how will I know that there are no duplicate names when I do a search? I mean, before I know of any IDs, I first need to search by name. Do you see what I mean?

So to summarise, I do think history-walking-with-IDs would work, but then you can only do actual searches for townnames, alliancenames and playernames for "today". And then you'd use the returned IDs for those searched names to browse through the history.
It would however no longer allow for doing new searches for any given day in the past.

What I currently do, when I see town(s) disappear for no apparent reason, is pin the town as it's still visible, then go to the day where it isn't. Add the different player/town/alliance name (which you can see in the pinned town info) to the search, unpin the town and do the new search. It will then show the changes and it will indicate in red in the search inputs when which town/player/alliance name was found, for that day.
 
Last edited by a moderator:

DeletedUser

Guest
Yeah I know what you mean (except about playernames changing - is that allowed? Seriously?).
I believe the moderators have the power to do this in rare cases, but it is rare and player names can be dropped from this if it helps.

hmm, actually I"m not sure what you mean by this. I do get the ID part, but not the drawing part. Well maybe I see what you mean, but I think then we'd have to change the way we think about how to use the browser.
Because now it's "what you enter is what you see". But if I'd somehow implement history-walking-with-IDs, then it is no longer "what you enter is what you see", as names may start to be different in the inputs and towns display. Colour would then become much more important and the names would be secondary.
I am currently not sure if that would actually be better (read : not confusing).
I understand what you mean, and I envisage the following method:

The name is entered (with autocomplete) as we do now, but the datatbase key (ID) is matched. Any history walking is done using the key, and a callback to update the input field with the corresponding text data for that key is used.

Imagine doing a new search when you are displaying data from two weeks ago. Would searching for "The Lonely Assassins" still give a result then? (assuming they renamed within two weeks - I dunno)
The name match can be done as it is currently, but for the relevant time. IE The Lonely Assassins 7 days ago would match, and The Assassins Guild from 3 weeks ago would match. History walking for either of them would see a name change using the method above.
And how will I know that there are no duplicate names when I do a search? I mean, before I know of any IDs, I first need to search by name. Do you see what I mean?
Yes, but duplicate names cannot be made at any given time, so from above, the name would be valid at that time in history. People do start new alliances and name them after defunct ones, but they can never do this while the name is already in use. Town names don't come under this of course.
So to summarise, I do think history-walking-with-IDs would work, but then you can only do actual searches for townnames, alliancenames and playernames for "today". And then you'd use the returned IDs for those searched names to browse through the history.
It would however no longer allow for doing new searches for any given day in the past.
A text search would find a match in history, and the corresponding key (ID) can then be used to keep the input field updated.
What I currently do, when I see town(s) disappear for no apparent reason, is pin the town as it's still visible, then go to the day where it isn't. Add the different player/town/alliance name (which you can see in the pinned town info) to the search, unpin the town and do the new search. It will then show the changes and it will indicate in red in the search inputs when which town/player/alliance name was found, for that day.
That's exactly what I've been doing to get around this so far.
 

DeletedUser20248

Guest
well, let me run it through my head for a while. Maybe I'll envision the code changes clearly at some point and might have a go.
In fact, if it were just for alliances names, I think the changes would be minimal. But I'm getting confused when thinking about doing the same for towns.
An alliance name is unique, but a town name isn't. If you search for Rome for example, you'll get a whole load of results. I'd have to start tracking all those results by ID then, and that diverts completely from how the whole search and display mechanism works atm. Imagine this :

You search for Rome and get 20 results.
You set the history slider to 5 days ago.
Now one of these 20 Romes appears to be conquered that day and used to be named Athens before the conquer. That leaves us with a projected result set of 19 Romes and 1 Athens.
The original search term Rome is still valid, but according to your suggestion, the town name input should reflect the name change of that one town. Which for towns it obviously cannot, because there still are 19 Romes in the result set. Town names are not unique and that causes problems for this alternate mechanism.

So i think this could work only with alliances (and I guess playernames), because those are unique at any given time.
 
Top