|
|
Post by alandau on Jul 7, 2015 22:44:21 GMT -8
I see that Stanford games are now using a JavaScript-based visualization system: gamemaster.stanford.edu/gamemaster/games/breakthrough/breakthrough.jsAre there any plans to turn this into a well-defined standard? I know Sam was interested in JavaScript-based visualization as a replacement for XSLT (which I agree is a pain to work with). I've already played around with getting JS-based visualizations in the Server app in GGP-Base. It can be done in Java 8 without bringing in an external library; Java 8 includes the JavaFX library, which includes an HTML5- and JS-compatible browser that can be embedded in Swing applications. (This would require moving GGP-Base to require Java 8, but Java 7 is reaching the end of its supported life anyway.) |
|
|
|
Post by bertrand on Jul 8, 2015 21:37:46 GMT -8
So, I am inclined to say "yes", in the sense "I have heard it once a while ago". The main problem being : what would the standard be? The whole point of GGP is to make games as extravagant as we can.
On the other hand, I agree that we tend to play on boards that tend to have squares (sometimes hexagons, sometimes triangles). Do you have ideas?
|
|
|
|
Post by alandau on Jul 9, 2015 21:37:56 GMT -8
By "standard" I mean make it explicit how a visualization should be written in JavaScript: what a display method should be called, what the type of output should be, how it can read the state of the game, and perhaps how they should handle shared JS libraries. This isn't limiting it to any particular type of visualization, it just makes it possible to write visualizations and display code that don't end up contradicting each other (like how the XSLT visualizations on the Stanford and Dresden sides wound up being totally incompatible).
|
|
|
|
Post by Lars Ericson on Jul 12, 2015 11:18:50 GMT -8
Note GGP base as it stands doesn't work on Java 8, or at least didn't work for me when I downloaded it the other day.
Also graphing packages which might be of interest such as GEPHI failed for me with Java 8 installed and worked on Java 7.
We probably need to get to Java 9 or 10 before most applications migrate to Java 8 properly.
|
|
|
|
Post by Steve Draper on Jul 12, 2015 11:32:03 GMT -8
ggp-base is working fine on Java 8 for me. What problems do you see? Are you sure it's Java8 not your Eclipse version or some other ancillary thing?
|
|
|
|
Post by alandau on Jul 12, 2015 11:52:28 GMT -8
Java version upgrades tend to have very few backwards-compatibility issues; mostly they're in code that use com.sun classes that aren't supposed to be used outside of the JDK. Alloy uses Java 8 and is based on GGP-Base, and I haven't seen any problems there.
|
|
|
|
Post by alandau on Nov 23, 2015 23:26:08 GMT -8
I just thought to look for libraries that could deal with the potential issue of malicious code in user-submitted JavaScript stylesheets. (Not that there aren't issues with user-submitted XSLT; but with a JS function that manipulates a canvas you could make this part of the system's design.) Ideally you'd expose specific objects representing the canvas and the game state, and nothing else. There are a couple that seem relevant off the bat: developers.google.com/caja/www.adsafe.org/ |
|
