forum.webdiplomacy.net

webDip dev coordination forum / public access todo list
It is currently Thu Oct 19, 2017 1:55 am

All times are UTC




Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6
Author Message
 Post subject: Re: SVG Map
PostPosted: Mon Nov 02, 2009 7:09 pm 
Offline
Site Admin

Joined: Sat Jun 28, 2008 6:24 am
Posts: 892
Neat, these must be some impressive maps :o


Top
 Profile  
 
 Post subject: Re: SVG Map
PostPosted: Mon Nov 02, 2009 8:33 pm 
Offline

Joined: Wed Sep 09, 2009 2:37 pm
Posts: 156
The map has gotten so big that I have to basically put up a message saying "small map does not exist"

here's the current one I'm working on (World War IV by Tom Reinecker): http://careyj.com/dip/map/WWIV/initialMap-largemap.png

It's already to the point where it's playable (except for north/south coast points). I just need to code in special rules for it.


Top
 Profile  
 
 Post subject: Re: SVG Map
PostPosted: Sat Mar 20, 2010 4:04 am 
Offline
Site Admin

Joined: Sat Jun 28, 2008 6:24 am
Posts: 892
The recently released IE9 preview has SVG :mrgreen:


Top
 Profile  
 
 Post subject: Re: SVG Map
PostPosted: Sat May 29, 2010 6:36 pm 
Offline

Joined: Wed Oct 08, 2008 12:47 pm
Posts: 726
http://www.codedread.com/svg-support-table.html
The builds are progressing on SVG support.
I think I'm going to make this my #1 proirity over the summer. Exams finish on the 18th June, but I might be on posting for the two weeks after that. If not I want to hit it then, so thought I'd start talking about the framework in advance...

Javascript order generation etc: how do you want the map to plug into it?
The current code has its own database, but this could/should be merged into the existing js database each variant has. It contains border information, as well as a pixel-location unit-placement lookup, although this *could* be changed to be part of the map.
Currently the map has javascript to help calculate its possible moves on its own (unfinished), but really this should latch into the existing functions anyway. One rather intuitive way is the slight workaround to simply look at the option boxes! When they change, the other functions are triggered, which then update the options in the next box: all the map would have to do would be read this off. However, the map should be written such that it can be viewed fullscreen and free of the page. Also, this is quite consciously a workaround, and they should be avoided for as long as possible as it makes expansion more complex.
The map also has its own AJAX setup, but this is already quite modular, and could easily be modified to be totally so, and plug into a common framework. A note here on scope: as noted above ideally the amp would be able to run independantly of the page if requested, and thus any libraries used should be referenced within the file.

So, how's this going to work?


Top
 Profile  
 
 Post subject: Re: SVG Map
PostPosted: Sun May 30, 2010 6:03 pm 
Offline
Site Admin

Joined: Sat Jun 28, 2008 6:24 am
Posts: 892
Sweet, cant wait :mrgreen:

figlesquidge wrote:
http://www.codedread.com/svg-support-table.html
The builds are progressing on SVG support.
I think I'm going to make this my #1 proirity over the summer. Exams finish on the 18th June, but I might be on posting for the two weeks after that. If not I want to hit it then, so thought I'd start talking about the framework in advance...

Javascript order generation etc: how do you want the map to plug into it?
The current code has its own database, but this could/should be merged into the existing js database each variant has. It contains border information, as well as a pixel-location unit-placement lookup, although this *could* be changed to be part of the map.

I think it gets loaded into a territories array at the moment, and it should have everything needed. It isn't bundled with the map because keeping it static and reducing the map to the set of units and occupations etc means the map data can be cached

The territories array may well change in future, though Im not sure about the timeframe, but the changes won't be too bad and I'll probably be able to provide a compatibility layer if need be

Quote:
Currently the map has javascript to help calculate its possible moves on its own (unfinished), but really this should latch into the existing functions anyway. One rather intuitive way is the slight workaround to simply look at the option boxes! When they change, the other functions are triggered, which then update the options in the next box: all the map would have to do would be read this off. However, the map should be written such that it can be viewed fullscreen and free of the page. Also, this is quite consciously a workaround, and they should be avoided for as long as possible as it makes expansion more complex.

That is a neat approach, and you may be able add another onupdate handler to the order dropdowns to do it, but there are definitely drawbacks. I think as long as there's a bit of an interface layer between your internal code and the kludge you'll need to hook into the current system in the short-term you shouldn't need to redo anything much later though

Quote:
The map also has its own AJAX setup, but this is already quite modular, and could easily be modified to be totally so, and plug into a common framework. A note here on scope: as noted above ideally the amp would be able to run independantly of the page if requested, and thus any libraries used should be referenced within the file.

Sounds good, a common AJAX interface should definitely be used, and the actual server interface is pretty well-designed (though the AJAX code will need changes to be more abstract)


Really I think as long as you don't rely on actually taking and extending the existing code (which would be mad anyway) it'll come out okay. The two pieces of code's functionality overlap enough that they're bound to neatly fit onto the same base map-data-set/order-generation&update-library, no matter how they're designed, with little to no refactoring needed. If later richer interfaces are desired they should fit in without any worries, and any incompatibility issues will be no problem to work around in JavaScript
Definitely looking forward to it though, using some of that capability that hasn't been used yet


Top
 Profile  
 
 Post subject: Re: SVG Map
PostPosted: Sun May 30, 2010 7:11 pm 
Offline

Joined: Wed Oct 08, 2008 12:47 pm
Posts: 726
Indeed. I'll talk to you directly about it nearer the time then, to see how things are getting on by then.

kestasjk wrote:
I think it gets loaded into a territories array at the moment, and it should have everything needed. It isn't bundled with the map because keeping it static and reducing the map to the set of units and occupations etc means the map data can be cached

Don't quite get what you mean here, so I'll try rephrasing what I think you said:
There is a territories array, with border information [this would be extended to have the xy coordinates in it]. This is static.
There is also map data, loaded via JSON (I assume you chose JSON? If so I'll convert over-mine's in AJAX). This is variable

kestasjk wrote:
<on hacking in javascript hooks>
That is a neat approach, and you may be able add another onupdate handler to the order dropdowns to do it, but there are definitely drawbacks. I think as long as there's a bit of an interface layer between your internal code and the kludge you'll need to hook into the current system in the short-term you shouldn't need to redo anything much later though

Totally agree. Using onchange handlers really wouldn't be a nice way of doing things. If nothing else it would lock the map to the page.

kestasjk wrote:
<on AJAX>
Sounds good, a common AJAX interface should definitely be used, and the actual server interface is pretty well-designed (though the AJAX code will need changes to be more abstract)

Indeed. Well having thought about it a bit, I realised that actually the map doesn't need AJAX at all. As long as the map data includes territory ownership etc (which I'm guessing it currently doesn't?) then all the information should be in the map and territories globals (however they may be named)

In my mind, the final workings would be something along the lines of:
1) Page loads, including generic js (game,orders,map,clock) (all variants)
2) Game object loads variant array (cached per variant).
3) Game loads required current phase data (cached per game).
4) Game object sets up orders using this data
5) If variant has an SVG map, render it now
During usage, game would only need a couple of major methods -
getMapData(phase), which would return the map data for that phase [used for history]
getOrders(), saveOrders() - as currently used.
getMessages(NatID) - returns messages between player and other nation. Could easily use xml and merely append the fragment to the conversation
sendMessage(NatID,msg) - sends a message

Oh, and I think you've finally managed to turn me to OO. As you've probably noticed I've heavily resisted it over the years, and in my mind it still has big issues (especially in scripts) but as long as the naming scheme makes sense to you it sure it easy to follow.


Top
 Profile  
 
 Post subject: Re: SVG Map
PostPosted: Mon May 31, 2010 12:10 am 
Offline
Site Admin

Joined: Sat Jun 28, 2008 6:24 am
Posts: 892
figlesquidge wrote:
Don't quite get what you mean here, so I'll try rephrasing what I think you said:
There is a territories array, with border information [this would be extended to have the xy coordinates in it]. This is static.
There is also map data, loaded via JSON (I assume you chose JSON? If so I'll convert over-mine's in AJAX). This is variable

This is a variant specific map data file (misleadingly called territories.js):
http://webdiplomacy.net/variants/Classi ... itories.js
It does have xy coords etc in it, I did plan ahead ;)

The turn specific data (who owns which territories, where the units are) are all requested basically from map.php, or from the same place maps are cached per game per turn.
There is an XML map as well, which I think you were using for testing at some point. It follows the same sort of "draw arrow", "draw unit", etc convention that drawMap follows though; it lists the last turn/phase orders to be drawn unlike the JSON data, but I believe is less appropriate for something dynamic, and isn't used/interfaced with at all by any other code

Since JSON is used for submission of data, and it's just plain easier and easily flexible enough for this, I think going with JSON would be best (but at the moment only the XML lists the previous orders to be displayed; that is in the PNG map so it wasn't required in the JSON)

But in a nutshell yup there is static per-variant map data and variable per-game-per-turn unit/territory-owner data, all JSON

Quote:
Indeed. Well having thought about it a bit, I realised that actually the map doesn't need AJAX at all. As long as the map data includes territory ownership etc (which I'm guessing it currently doesn't?) then all the information should be in the map and territories globals (however they may be named)

True, it'd only need to have some ajax capability once there's a requirement to submit orders directly via the map; until then it just has to represent the data in the JSON files, and the orders being entered (the territory ownership is included as a static file which doesn't need AJAX to load also, making things a bit easier)

Quote:
In my mind, the final workings would be something along the lines of:
1) Page loads, including generic js (game,orders,map,clock) (all variants)
2) Game object loads variant array (cached per variant).
3) Game loads required current phase data (cached per game).
4) Game object sets up orders using this data
5) If variant has an SVG map, render it now

Sounds about right, but I'm not sure about the details of it, JavaScript is a bit funny about how it loads up

Quote:
During usage, game would only need a couple of major methods -
getMapData(phase), which would return the map data for that phase [used for history]
getOrders(), saveOrders() - as currently used.
getMessages(NatID) - returns messages between player and other nation. Could easily use xml and merely append the fragment to the conversation
sendMessage(NatID,msg) - sends a message

Again that sounds about right, but there are probably some details that need a bit more fleshing out (e.g. notifications of messages received/game updates, in a v efficient way, the error codes and/or exceptions thrown on access denied/refresh-required etc)

Quote:
Oh, and I think you've finally managed to turn me to OO. As you've probably noticed I've heavily resisted it over the years, and in my mind it still has big issues (especially in scripts) but as long as the naming scheme makes sense to you it sure it easy to follow.

Ah glad to hear that. :) I think it's not fundamentally different to procedural stuff, it's just another layer of abstraction on top of it; there's no sense in which you convert to OO imo, you just use it as you need (just don't learn OO from my terrible novice JavaScript, whatever you do :( )

Actually webDip wasn't OO until 0.5, and didn't do OO right until 0.8; it takes a while to figure it out and a lot of it is intuitive (which means how good you are is based on how many mistakes you've made in the past), but time spent you get back many times later imo


Top
 Profile  
 
 Post subject: Re: SVG Map
PostPosted: Mon May 31, 2010 1:23 am 
Offline

Joined: Wed Oct 08, 2008 12:47 pm
Posts: 726
re OO bit:
Didn't know it only started at 0.5, but I've been following since pre-0.8
I agree that there isn't much different, the only real issue (and I think Orathaic mentioned having this problem as well) is that just how one breaks up code can be a little subjective - there are lots of perfectly logical and rational ways of doing things. As a result, when hunting through someone else's code it can take quite some time to track down the actual function you wish to change.


Top
 Profile  
 
 Post subject: Re: SVG Map
PostPosted: Mon May 31, 2010 3:22 am 
Offline
Site Admin

Joined: Sat Jun 28, 2008 6:24 am
Posts: 892
That is true, but I think any layer of abstraction can be done differently and cause confusion, I wouldn't put that down to OO in particular. But it's a common complaint so probably valid


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group