Menu
▾
▴
rails-devel
|
From: Brett L. <wak...@ea...> - 2005-10-11 18:25:42
|
> Does this plan fit with what you want in rails? I hadn't really thought of making anything printable for various copyright reasons. My initial reaction is that I'd rather not allow users to leverage this game to bootleg their own copies of any 18xx game. I suppose we can provide support for other forms of output on a per game basis, and just enable it as we get permission from each game's copyright holder. With that in mind, the primary implementation that we use would probably need to be specifically for drawing in Swing/AWT to a user's screen. Bridging the gap between generic output and Swing/AWT objects will take a bit of doing, but many examples of drawing already exist in our own hex drawing code, which gives us a good starting point. I don't think that changes the way you are talking about developing the classes, so yes I think that plan will fit just fine. ---Brett. |
|
From: Brett L. <wak...@ea...> - 2005-10-11 20:56:08
|
>Well, if you are going to display it on the screen you can't stop them >from printing it anyway. Besides that, there are plenty of sources for >tiles to print if they want to go about it, including my own website >which allows them to download EPS for the tile. Agreed. At the same time, I'd like to be careful of the games we're cloning that are still in print and/or have large corporate copyright holders that won't take too kindly to any efforts to republish an out of print game. I'm less worried about the games that have been published by various members of the 18xx community. So, at this point, I don't want to change any implementation plans. I just want to note that, in the future, we may need to have a mechanism to segregate out certain games for certain features. We'll cross that bridge if we come to it. > Right, but implementing the drawing primitives shouldn't be hard. It has > been a while since I did anything fancy in Swing but clipping is the only > one that might be an issue. Exactly. Java.awt.Graphics and Graphics2D has everything we need for drawing. I think the biggest conversion will be that the java API doesn't use polar coordinates, AFAIK. > Another output that might be of interest would be SVG or an image > (although that is probably better served by taking the PS output and > generating a bitmap from it) for web display, as a sort of status update > on a PBeM game. Definitely. You may want to take a look at the server-based UI that Erik has been maintaining. It's the GameTestServlet in the /test directory. I'm not certain how current it is, but it's an example of a server-based implementation using the same underlying engine. It's probably a good candidate for using the tile parsing classes out to SVG. ---Brett. |
|
From: John A. T. <ja...@ja...> - 2005-10-11 21:24:11
|
On Tue, 11 Oct 2005, Brett Lentz wrote:
> Java.awt.Graphics and Graphics2D has everything we need for drawing.
>
> I think the biggest conversion will be that the java API doesn't use
> polar coordinates, AFAIK.
Neither does Postscript or SVG, so it will be converted. Since there is
some common code, it may be better to make Tile.Output an abstract class
rather than an interface so the common methods can be implemented there.
> You may want to take a look at the server-based UI that Erik has been
> maintaining. It's the GameTestServlet in the /test directory. I'm not
> certain how current it is, but it's an example of a server-based
> implementation using the same underlying engine.
Ok.
> It's probably a good candidate for using the tile parsing classes out to
> SVG.
I'm not sure I understand what you mean here -- SVG would just be an
output method for rendered tiles, not an interchange or storage format.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
|
From: John D. G. <jd...@di...> - 2005-10-11 23:32:29
|
> John A. Tamplin wrote: >> Well, if you are going to display it on the screen you can't stop them >> from printing it anyway. Besides that, there are plenty of sources for >> tiles to print if they want to go about it, including my own website >> which allows them to download EPS for the tile. Brett Lentz wrote: > Agreed. At the same time, I'd like to be careful of the games we're > cloning that are still in print and/or have large corporate copyright > holders that won't take too kindly to any efforts to republish an out of > print game. I don't see this as a problem. If the details of each game live in the config file(s) and not the program itself, just make sure that the site where the app resides contains only config files for hobby-publishers' own games. People who own the commercial 18xx games can make and trade config files for those easily enough. |
|
From: John A. T. <ja...@ja...> - 2005-10-11 23:50:10
|
On Tue, 11 Oct 2005, John David Galt wrote:
> I don't see this as a problem. If the details of each game live in the
> config file(s) and not the program itself, just make sure that the site
> where the app resides contains only config files for hobby-publishers'
> own games. People who own the commercial 18xx games can make and trade
> config files for those easily enough.
It is likely consent would be given -- there are plenty of electronic
implementations of games freely available that do not require the
boardgame to play, all with the blessing of the owner (some produced and
distrbuted by the owner). In any event, my personal feeling is that the
tiles themselves do not constitute protectable content, and that is why I
have no problem putting tile images up on my site. I would argue that
being able to print an in-progress map is far less of an issue than simply
being able to play the game without requiring the original.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
|
From: Brett L. <wak...@ea...> - 2005-10-11 21:57:26
|
>> It's probably a good candidate for using the tile parsing classes out to >> SVG. >I'm not sure I understand what you mean here -- SVG would just be an >output method for rendered tiles, not an interchange or storage format. I know. I was meaning that because it's a web-based application, it would be a good candidate for using SVG-based tile graphics being that there are SVG viewer plugins for most browsers. The server can deliver the SVG directly to the client without needing to render or store the image locally on the server first. ---Brett. |
|
From: John A. T. <ja...@ja...> - 2005-10-11 22:01:32
|
On Tue, 11 Oct 2005, Brett Lentz wrote:
> I know. I was meaning that because it's a web-based application, it
> would be a good candidate for using SVG-based tile graphics being that
> there are SVG viewer plugins for most browsers.
>
> The server can deliver the SVG directly to the client without needing to
> render or store the image locally on the server first.
Since the Java client is going to be running there anyway, it isn't clear
that using SVG for display in a browser would work very well. It would
certainly be difficult to manage the display with part of it being
rendered in an applet and part in an SVG viewer plugin.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
|
From: Brett L. <wak...@ea...> - 2005-10-11 22:28:47
|
>> I know. I was meaning that because it's a web-based application, it >> would be a good candidate for using SVG-based tile graphics being that >> there are SVG viewer plugins for most browsers. >> >> The server can deliver the SVG directly to the client without needing to >> render or store the image locally on the server first. >Since the Java client is going to be running there anyway, it isn't clear >that using SVG for display in a browser would work very well. It would >certainly be difficult to manage the display with part of it being >rendered in an applet and part in an SVG viewer plugin. I think you're misunderstanding. The GameTestServlet is meant to run server-side as a game server UI (think CGI-style server-side processing). To allow playing games through a web-page. The servlet serves up standard HTML pages. The Swing-based UI is meant to be a stand-alone application. These are two completely separate interfaces that don't run together and are more or less completely incompatible. The intention is to allow two totally different ways of playing a game that uses the same underlying engine (and further secures model/view separation). So, when I say that the Servlet can use SVG, I mean that in the process of serving out an HTML page to the client, it could do so using SVG as the content-type of the tile/map images. ---Brett. |
|
From: John A. T. <ja...@ja...> - 2005-10-11 23:47:07
|
On Tue, 11 Oct 2005, Brett Lentz wrote:
> I think you're misunderstanding.
>
> The GameTestServlet is meant to run server-side as a game server UI
> (think CGI-style server-side processing). To allow playing games through
> a web-page. The servlet serves up standard HTML pages.
Ok, so it is actually a client to the main server, right?
> The Swing-based UI is meant to be a stand-alone application.
It is trivial to write standalone applications that can be run as applets
in a browser as well (although you have to sign the jar files if you want
to do some things), so that could be an option.
For that matter, the client could be written in whatever language people
want as long as the wire protocol was cleanly defined rather than just
exchanging serialized Java objects via RMI, Beans or something similar.
> These are two completely separate interfaces that don't run together and
> are more or less completely incompatible. The intention is to allow two
> totally different ways of playing a game that uses the same underlying
> engine (and further secures model/view separation).
>
> So, when I say that the Servlet can use SVG, I mean that in the process
> of serving out an HTML page to the client, it could do so using SVG as
> the content-type of the tile/map images.
Ok.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
|
From: Brett L. <wak...@ea...> - 2005-10-12 00:03:10
|
>> The GameTestServlet is meant to run server-side as a game server UI >> (think CGI-style server-side processing). To allow playing games through >> a web-page. The servlet serves up standard HTML pages. >Ok, so it is actually a client to the main server, right? No, the servlet files are placed on a webserver that utilizes something akin to Apache + Tomcat for running the JVM. Then, it's accessed similar to a CGI or ASP or PHP script, where the web server does all the processing and returns result output in the form of a webpage (HTML). It is somewhat similar to the interface being used over at fwtwr.com, but is a better interface IMO. ;-) By contrast, the Swing UI is intended to be more along the lines of Colossus, the Java clone of Titan ( http://colossus.sourceforge.net ). ---Brett. |
|
From: John A. T. <ja...@ja...> - 2005-10-12 00:59:40
|
On Tue, 11 Oct 2005, Brett Lentz wrote: > No, the servlet files are placed on a webserver that utilizes something > akin to Apache + Tomcat for running the JVM. Then, it's accessed similar > to a CGI or ASP or PHP script, where the web server does all the > processing and returns result output in the form of a webpage (HTML). > > It is somewhat similar to the interface being used over at fwtwr.com, > but is a better interface IMO. ;-) > > By contrast, the Swing UI is intended to be more along the lines of > Colossus, the Java clone of Titan ( http://colossus.sourceforge.net ). What I am saying is that in the final configuration, there is a server process that handles connections from multiple clients and moderates a game. Some clients may have multiple players on the same connection (ie, a hotseat game or one where the server is just being the moderator for a FTF game). These clients may be accessed over the web or a standalone client, or perhaps AI players. In that environment, a web interface running under Tomcat is just another client. The model I am thinking of is more like ICS (Internet Chess Server), OK-Bridge, or even Battle.net -- users run their favorite client and connect to the server and play the game, whether it is an extended FTF gaming session, PBeM, or whatever. The client simply handles interaction with the user, and all of the game data, rules enforcement (perhaps even rules knowledge depending on how you want to partition the client), etc reside on the server. Individual users could run their own server for private games (probably necessary until/unless someone can host a centralized server) but that doesn't change the model at all. I realize that the current monolithic architecture does not support such a thing, but hopefully that can be fixed down the road (as that is a major goal of mine). -- John A. Tamplin ja...@ja... 770/436-5387 HOME 4116 Manson Ave Smyrna, GA 30082-3723 |
|
From: Brett L. <wak...@ea...> - 2005-10-12 01:31:52
|
> I realize that the current monolithic architecture does not support such a > thing, but hopefully that can be fixed down the road (as that is a major >goal of mine). Got it. Ok, now I think we're on the same page. :-) It definitely looks like our goals are very similar. I want to see many of the things you listed. I don't think the game classes will need to be changed much, if at all, to support network play. ---Brett. |
|
From: Erik V. <eri...@hc...> - 2005-10-14 13:44:05
|
Back from vacation, I'm finding some interesting discussions have started in the meantime! > You may want to take a look at the server-based UI that Erik > has been maintaining. It's the GameTestServlet in the /test > directory. I'm not certain how current it is, but it's an > example of a server-based implementation using the same > underlying engine. I started becemong productive in this project by creating a pure browser/servlet based UI, only because I was familiar with that technology (unlike Swing). I had originally planned to keep it up to date, but have in fact not done so (yet) - currently the GameTestServlet class does not even compile. If there is interest in reviving it, I can do that, but it seems there is more urgent stuff to be done. I had not really thought about how to display the map in that UI. It would probably have become a Swing-based applet anyway. Erik. |
|
From: John A. T. <ja...@ja...> - 2005-10-11 19:53:01
|
On Tue, 11 Oct 2005, Brett Lentz wrote:
> > Does this plan fit with what you want in rails?
>
> I hadn't really thought of making anything printable for various
> copyright reasons. My initial reaction is that I'd rather not allow
> users to leverage this game to bootleg their own copies of any 18xx
> game. I suppose we can provide support for other forms of output on a
> per game basis, and just enable it as we get permission from each game's
> copyright holder.
Well, if you are going to display it on the screen you can't stop them
from printing it anyway. Besides that, there are plenty of sources for
tiles to print if they want to go about it, including my own website
which allows them to download EPS for the tile.
> With that in mind, the primary implementation that we use would probably
> need to be specifically for drawing in Swing/AWT to a user's screen.
Right, but implementing the drawing primitives shouldn't be hard. It has
been a while since I did anything fancy in Swing but clipping is the only
one that might be an issue.
Another output that might be of interest would be SVG or an image
(although that is probably better served by taking the PS output and
generating a bitmap from it) for web display, as a sort of status update
on a PBeM game.
--
John A. Tamplin ja...@ja...
770/436-5387 HOME 4116 Manson Ave
Smyrna, GA 30082-3723
|
|
From: Jeffrey B. M. <mc...@br...> - 2005-10-11 20:04:47
|
On Tue, Oct 11, 2005 at 03:52:37PM -0400, John A. Tamplin wrote: > Another output that might be of interest would be SVG or an image=20 > (although that is probably better served by taking the PS output and=20 > generating a bitmap from it) for web display, as a sort of status update= =20 > on a PBeM game. SVG is always of interest. There are some of us working on SVG support for VASSAL, and other programs. Especially for something like the rail tiles that can be precisely definted. Jeff --=20 ---------------------------------------------------------------------------- Computer Science is as much about computers as astronomy is about telescopes -- Edsger Wybe Dijkstra (1930-2002) ---------------------------------------------------------------------------- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X