Menu
▾
▴
sfbol-planning — Discussion for planning the StarBattles Online project
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(25) |
Oct
(4) |
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Charles G. <g_...@ho...> - 2002-04-28 18:44:06
|
<html><div style='background-color:'><DIV> <P><BR>just ofund the sight, and wanted to learn more about it so.. umm.. hey, and let me know if there is anything i can do. I would really want to see this thing get made and work well.</P> <P> </P> <P>~Chuck<BR></P></DIV></div><br clear=all><hr>Join the worlds largest e-mail service with MSN Hotmail. <a href='http://g.msn.com/1HM105401/47'>Click Here</a><br></html> |
|
From: Devlyn D. <de...@ya...> - 2001-11-15 00:17:19
|
This is related to an earlier post about the engine that was used for Delta V online. When I posted that note, I hadn't realized that the base engine was actually being opened up for further customization. Check here: http://www.vasl.org/vassal/ This is the VASSAL Engine. It it the engine that was originally made to allow playing of Advanced Squad Leader of the internet. The author, Rodney Kinney, has opened up the software to allow custom modules to be made to allow for a wide range of games. This is very close to the level of customization that I think we were looking for. It is client heavy, but it does already solve a lot of problems including interface, communication, logging, etc. It also allows expandability via custom Java classes within a module. Should we look into this further and maybe use this as the base engine and expend our energy making it work for SFB? This is posed as a question...I do not have the programming expertise to know if this is better/worse/indifferent to current plans. -Dev __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com |
|
From: Devlyn D. <de...@ya...> - 2001-11-07 18:10:23
|
Don't worry, I have faith man! :) Actually, this is the frustrating part for me, as a non-programmer, because there is really nothing tangible I can contribute right now and I basically come off as a lot of talk. I realize that all of the real work is being done by the programmers (i.e. you) and you should work at a pace you are comfortable with. Don't worry, I'm still here also and stand by to assist in whatever way I can. Eventually I see myself doing a lot of testing and documentation. If there is anything that would help in the interim, please let me know. -Dev --- sfb...@cy... wrote: > Just so you didn't worry, I wanted to let you know > that I am still here! I was beginning to wonder > myself ;-) My home pc has been hosed and work has > picked up, but I am still working. Check out > http://cyberlizard.org/projects/sfbol/index.php?location=usecaselist.html > I created a list of use cases, hopefully I've > covered the various actions that the various pieces > will do. I've also updated the vision doc and plan > doc on the site to reflect our desire to create a > modular server. Please let me know what you think. > I'm at a conference here in orlando this week, but > I'm able to check my mail. > > -- > "Great spirits have always found violent opposition > from mediocre minds" > Einstein > > > _______________________________________________ > sfbol-planning mailing list > sfb...@li... > https://lists.sourceforge.net/lists/listinfo/sfbol-planning ===== The facts, although interesting, are irrelevant. __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com |
|
From: <sfb...@cy...> - 2001-11-07 15:48:09
|
Just so you didn't worry, I wanted to let you know that I am still here! I was beginning to wonder myself ;-) My home pc has been hosed and work has picked up, but I am still working. Check out http://cyberlizard.org/projects/sfbol/index.php?location=usecaselist.html I created a list of use cases, hopefully I've covered the various actions that the various pieces will do. I've also updated the vision doc and plan doc on the site to reflect our desire to create a modular server. Please let me know what you think. I'm at a conference here in orlando this week, but I'm able to check my mail. -- "Great spirits have always found violent opposition from mediocre minds" Einstein |
|
From: <sfb...@cy...> - 2001-10-16 19:03:25
|
Unfortunately, the motherboard on my main work box at home decided to die. I haven't been able to do very much during the last week. I just wanted to let y'all know so you didn't think I'd forgotten about it. On a positive note, I just got in my possession my wife's old laptop, which I proptly installed Linux on, so I should be able to keep working here shortly. I've got a design laid out for a generic server, and a basic communications protocol figured out. I just need to revamp the existing code and we should be able to at least have an alpha test. I'll keep you updated. Aaron -- "Great spirits have always found violent opposition from mediocre minds" Einstein |
|
From: <sfb...@cy...> - 2001-10-10 14:21:48
|
On Tue, 9 Oct 2001, Devlyn Davis wrote: > I've been continuing to research other games to find > out what I like/don't like about the way they've > implemented the various parts of their systems. I've > listed a few in previous posts that I felt warranted > looking at, because for some reason or another I was > impressed with something they did. This is a great idea. It's always a good idea to not work in a vacuum. > > The next phase of my research will be to find an > online game that I can run on my own server. A few > examples of the games I've been looking at are Empire, > Stars! and World Conquest. There are others, and some > allow you to run your own server and others do not. > I'll find one I like and set it up within the next few > weeks or so. Most of these games are not really > analogous to SFB because they are not wargames, per > se. They are more like on-going strategy games. > However, I want to get a feel for how to set up the > software and maintain the games. I think this will > enable to to gain some insight into what works/doesn't > work with a client/server game. FreeCiv comes with most Linux distros. It is a client server game where you can run your own server. Quake III Arena also let's you run your own server. IIRC, FreeCiv is a strategy game, but I can't remember if it's turn-based or RTS. Quake, of course, is a FPS. > > By listing the games I've been looking into, I'm not > trying to push the development of SBOL in any > particular direction, I'm just trying to develop an > idea of what has already been done so I can discuss > /evaluate designs for SBOL more intelligently. I think this is terrific. Definitely a worthwhile pursuit. I tend to get caught up in the technical details. > > -Dev > > __________________________________________________ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com > > _______________________________________________ > sfbol-planning mailing list > sfb...@li... > https://lists.sourceforge.net/lists/listinfo/sfbol-planning > |
|
From: Devlyn D. <de...@ya...> - 2001-10-09 21:44:53
|
I've been continuing to research other games to find out what I like/don't like about the way they've implemented the various parts of their systems. I've listed a few in previous posts that I felt warranted looking at, because for some reason or another I was impressed with something they did. The next phase of my research will be to find an online game that I can run on my own server. A few examples of the games I've been looking at are Empire, Stars! and World Conquest. There are others, and some allow you to run your own server and others do not. I'll find one I like and set it up within the next few weeks or so. Most of these games are not really analogous to SFB because they are not wargames, per se. They are more like on-going strategy games. However, I want to get a feel for how to set up the software and maintain the games. I think this will enable to to gain some insight into what works/doesn't work with a client/server game. By listing the games I've been looking into, I'm not trying to push the development of SBOL in any particular direction, I'm just trying to develop an idea of what has already been done so I can discuss /evaluate designs for SBOL more intelligently. -Dev __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com |
|
From: Devlyn D. <de...@ya...> - 2001-10-04 21:30:21
|
This is an online version of RISK: http://test.dominategame.com/ I really like the chat/channel/login system. -Dev __________________________________________________ Do You Yahoo!? NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 |
|
From: Devlyn D. <de...@ya...> - 2001-09-26 20:56:34
|
Well, I think the original inspiration for this project was to port SFB (that is certainly what attracted my attention and participation :) So I think that whatever we do, we should keep the goal of porting SFB in mind. That being said, I think to get the most 'bang for our buck' we should build something that is well-defined for using with other systems. It might not be a bad idea to do as you suggest and break the system down into it's component pieces and see where the game flow is. I'm sure we'll find that SFB has many similarities to other wargames in terms of game flow. Also, my vote is for a strong server solution, if that is feasible. The reason being is that it would seem to be easier to maintain and it allows for a wider range of clients. I imagine our initial client will have a feel very similar to the pen and paper version. But I can also imagine a day when someone creates a really cool open-gl client with 3D ships for either SFB or another game. As long as we have a well-defined communication protocol we should be able to have many types of clients and in different languages. The request-reply system you mentioned for the server sounds reasonable. In fact, that sounds like it would work for other games as well. Let's face it, every game is going to have some sort of Sequence Of Play, it just happens that SFB has very extensive SOP. Maybe for the generic engine there should be a hook to load the game-specific SOP module. The server would then load the SOP module and get it's timing and request-reply system from the module. Whatever is in the SOP module will be the backbone for the game. -Dev --- sfb...@cy... wrote: > I just wanted to throw this out for discussion. > With this focus on an extendable game engine, should > we focus more on that aspect and not design the > sfbol portion until it's finished? Which should be > our primary goal? I totally agree that an > extensible framework would be the best way to go, > but maybe, for the first couple iterations, focus on > the sfbol gameplay, then revise the design of the > server side once we have a better grasp of the > general gameplay flow. On the other hand, there are > definite advantages to creating an extensible > framework first, completely defining the interfaces > to game modules, and building the sfbol portion to > fit that. I can see the benifits to both ideas. > This kind of relates to my next thought. > > One design issue that has been somewhat of a > stumbling block has been how to structure the > client-server relationship. For sfbol, it seems > like a request-reply type setup would work best, > with the game server requesting information from the > clients at the time required by the sequence of > play. chat would flow freely, of course. Would > this be the best setup for a generic game engine? > Or perhaps the server should be extremely thin, only > handling the setup of 'chat rooms' for games, and > forwarding any messages to the game modules, letting > the game modules do everything else. In that case, > the server could handle different types of games > with one instance. Should the 'bullpen' > environment, where people can see what games are > running and create and join them, be handled by the > server itself, or by game modules? > > One thought I had (and these are coming to me as I > type, so please bear with the rambling) was that > there could be a generic client that would connect > to the generic server providing a 'bullpen' > environment. When the user selects a game, or > creates a game, of a certain type, the generic > client would look for the appropriate jar's for the > game, and offer to download them if they are not > present. In a way, this is kinda like the MPlayer > service. Alternatively, there could be a separate > client for each type of game and the server would be > dedicated to that type of game. In that case, each > game module would be responsible for providing the > means to create and join games. > > I'll keep thinking. Maybe I'll do up some diagrams > to help visualize things. > > Aaron > > -- > "Great spirits have always found violent opposition > from mediocre minds" > Einstein > > > _______________________________________________ > sfbol-planning mailing list > sfb...@li... > http://lists.sourceforge.net/lists/listinfo/sfbol-planning __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com |
|
From: <sfb...@cy...> - 2001-09-26 18:47:21
|
I just wanted to throw this out for discussion. With this focus on an extendable game engine, should we focus more on that aspect and not design the sfbol portion until it's finished? Which should be our primary goal? I totally agree that an extensible framework would be the best way to go, but maybe, for the first couple iterations, focus on the sfbol gameplay, then revise the design of the server side once we have a better grasp of the general gameplay flow. On the other hand, there are definite advantages to creating an extensible framework first, completely defining the interfaces to game modules, and building the sfbol portion to fit that. I can see the benifits to both ideas. This kind of relates to my next thought. One design issue that has been somewhat of a stumbling block has been how to structure the client-server relationship. For sfbol, it seems like a request-reply type setup would work best, with the game server requesting information from the clients at the time required by the sequence of play. chat would flow freely, of course. Would this be the best setup for a generic game engine? Or perhaps the server should be extremely thin, only handling the setup of 'chat rooms' for games, and forwarding any messages to the game modules, letting the game modules do everything else. In that case, the server could handle different types of games with one instance. Should the 'bullpen' environment, where people can see what games are running and create and join them, be handled by the server itself, or by game modules? One thought I had (and these are coming to me as I type, so please bear with the rambling) was that there could be a generic client that would connect to the generic server providing a 'bullpen' environment. When the user selects a game, or creates a game, of a certain type, the generic client would look for the appropriate jar's for the game, and offer to download them if they are not present. In a way, this is kinda like the MPlayer service. Alternatively, there could be a separate client for each type of game and the server would be dedicated to that type of game. In that case, each game module would be responsible for providing the means to create and join games. I'll keep thinking. Maybe I'll do up some diagrams to help visualize things. Aaron -- "Great spirits have always found violent opposition from mediocre minds" Einstein |
|
From: <sfb...@cy...> - 2001-09-26 18:25:09
|
Thanks for all the info. I'll definitely look into it. My inet access has been limited at work the last few days due to our response to Nimda. That leaves just time at home, and for some reason, the wife doesn't respond positively when I spend 8 hours at work, then 8 hours in front of the computer ;-) I'm definitely working though. The demo I had hoped to get together is taking a bit longer than I anticipated. -- "Great spirits have always found violent opposition from mediocre minds" Einstein On Tue, 25 Sep 2001, Devlyn Davis wrote: > Continuing to do research on the different open source > strategy games out there... I guess I'm looking for > inspiration as well as places from which to borrow > code, if applicable :) > > > Xcong > http://sources.redhat.com/xconq/ > This project seems reasonably mature. It also appears > well documented. I'm impressed by the goals stated > for this project. Below are the stated goals for > Xconq's Game Design Language (GDL). > =================================================== > PORTABILITY > Xconq should be able to run on a wide variety of > machines. However, new versions need not restricted by > the limits of old systems. > > AI > It should be possible for a game AI to play any side > in any game. > > NETWORKING > It should be possible for any player on the net to > play any side. > > SCALE > Xconq should work well for games of strategic and > operational maneuver based on a 2D surface. It does > not need to work well for tactical games, adventure > games, space games, or anything requiring full 3D. > (This doesn't mean that it should be excluded from > those types of games, just that they are not required > to be possible.) Xconq should be able to handle very > large games. > > GAME DESIGN > The designer should be able to use GDL to build any > strategic-level game desired. There should be multiple > computational models available to the designer, such > as different algorithms combat resolution. > > GRAPHICS > It should be possible to use graphics of a high > quality, but it should not be required to produce a > playable game. The designer should be able to adjust > all aspects of a game's appearance. > > PLAY ACTION > It should be possible to design both turn-based and > real-time games, the choice being left to the game > designer. It should also be possible to design both > simple easy-to-play games and complex detailed games. > ================================================== > > I think going with the same basic idea, but with the > idea that it'll be client/server from the ground up > (and, of course, suitable for SFB :) would not be a > bad start. > > I'm going to play around with Xcong in the next week > or so, just to get a feel for it. Maybe some ideas > will come to me after playing around with it. > > Chaotic Domain > http://chaosrts.sourceforge.net/ > This is another real-time strategy game. I'm > impressed with the progress they've made. I like the > chat server they came up with, it seems to work pretty > well. They noted they they wrote their own networking > core, I don't know if there's anything to be learned > by snooping that. I also *think* I like the webstart > dealio. It seems like an easy way to distribute the > game, but since that was my only experience using it, > I'll reserve judgment. > > -Dev > > > > > __________________________________________________ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com > > _______________________________________________ > sfbol-planning mailing list > sfb...@li... > http://lists.sourceforge.net/lists/listinfo/sfbol-planning > |
|
From: Devlyn D. <de...@ya...> - 2001-09-26 06:00:55
|
Here are some pics of the next version of Star Fleet Battles Online, version 3. V3 is based off of GUB http://www.wanderinghorse.net/gub/gub.html and will be in Java. http://www.sfbonline.com/shot3.jpg http://www.sfbonline.com/shot4.jpg http://www.sfbonline.com/shot5.jpg http://www.sfbonline.com/shot6.jpg http://www.sfbonline.com/shot7.jpg http://www.sfbonline.com/shot8.jpg I'm not sure of the exact functionality yet. Although from posts on the ADB BBS, it does seem as though it will be multi-player (more than two players at once.) There will also, presumably, be some game logic (see shot 8) but I don't know if it will do any rule-enforcement. Some notes: It is not true client/server. Each client will have the full program. The server looks like it will only be a pass-through for authentication and connections. -Dev __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com |
|
From: Devlyn D. <de...@ya...> - 2001-09-26 05:46:45
|
Continuing to do research on the different open source strategy games out there... I guess I'm looking for inspiration as well as places from which to borrow code, if applicable :) Xcong http://sources.redhat.com/xconq/ This project seems reasonably mature. It also appears well documented. I'm impressed by the goals stated for this project. Below are the stated goals for Xconq's Game Design Language (GDL). =================================================== PORTABILITY Xconq should be able to run on a wide variety of machines. However, new versions need not restricted by the limits of old systems. AI It should be possible for a game AI to play any side in any game. NETWORKING It should be possible for any player on the net to play any side. SCALE Xconq should work well for games of strategic and operational maneuver based on a 2D surface. It does not need to work well for tactical games, adventure games, space games, or anything requiring full 3D. (This doesn't mean that it should be excluded from those types of games, just that they are not required to be possible.) Xconq should be able to handle very large games. GAME DESIGN The designer should be able to use GDL to build any strategic-level game desired. There should be multiple computational models available to the designer, such as different algorithms combat resolution. GRAPHICS It should be possible to use graphics of a high quality, but it should not be required to produce a playable game. The designer should be able to adjust all aspects of a game's appearance. PLAY ACTION It should be possible to design both turn-based and real-time games, the choice being left to the game designer. It should also be possible to design both simple easy-to-play games and complex detailed games. ================================================== I think going with the same basic idea, but with the idea that it'll be client/server from the ground up (and, of course, suitable for SFB :) would not be a bad start. I'm going to play around with Xcong in the next week or so, just to get a feel for it. Maybe some ideas will come to me after playing around with it. Chaotic Domain http://chaosrts.sourceforge.net/ This is another real-time strategy game. I'm impressed with the progress they've made. I like the chat server they came up with, it seems to work pretty well. They noted they they wrote their own networking core, I don't know if there's anything to be learned by snooping that. I also *think* I like the webstart dealio. It seems like an easy way to distribute the game, but since that was my only experience using it, I'll reserve judgment. -Dev __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com |
|
From: Devlyn D. <de...@ya...> - 2001-09-25 04:35:41
|
I have been doing some research trying to find projects with similar goals so we could see how they solved their problems and maybe recruit some help. Below are some of the projects I found (there was more, but many of them seem to have been abandoned.) http://civil.sourceforge.net/index.php This is a real time strategy game about the Civil War. Being a real-time game, it isn't quite in the same ball park as our project, but they seem to have a well defined client/server setup. They also have a very active mailing list going on at sourceforge. http://www.yagga.net Yagga is "A system and a language to design parallel , multiplayer gaming worlds," written in Java. Not sure what to make of this, but it seemed fairly well documented. Might be a good source for ideas. http://sourceforge.net/projects/osge/ This is the project page for The Open Source Game Engine. I don't know how far this project got, but it seems to have goals for an engine that coincide with ours. I sent an email to the project admin and he expressed interest in contributing to the project. -Dev __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com |
|
From: <sfb...@cy...> - 2001-09-24 15:23:48
|
On Sat, 22 Sep 2001, Devlyn Davis wrote: > I've been doing some research on other projects with > similar goals. Since I'm not a programmer, I cannot > comment on the specifics of how to do this stuff, but > the following seems to be good goals for the > extensibility of the engine: > > There seems to be three main areas where extensibility > (customization for a particular game) makes the most > sense. Create hooks in the code for: > > Extensibility to the engine itself > Extensibility via plugins > Extensibility via dat files > This is an off-the-cuff thought, but I can see a combination of plugins and a config file telling the server which plugins to load, similar to how apache does it, or Quake III. > I'm a non-programmer (read: dunce) so I don't know how > accurate the above assumptions are, but they seem > logical. I haven't seen evidence that you're a dunce (yet) ;-) > > -Dev > > > > __________________________________________________ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com > > _______________________________________________ > sfbol-planning mailing list > sfb...@li... > http://lists.sourceforge.net/lists/listinfo/sfbol-planning > |
|
From: Devlyn D. <de...@ya...> - 2001-09-22 20:39:44
|
I've been doing some research on other projects with similar goals. Since I'm not a programmer, I cannot comment on the specifics of how to do this stuff, but the following seems to be good goals for the extensibility of the engine: There seems to be three main areas where extensibility (customization for a particular game) makes the most sense. Create hooks in the code for: Extensibility to the engine itself Extensibility via plugins Extensibility via dat files I'm a non-programmer (read: dunce) so I don't know how accurate the above assumptions are, but they seem logical. -Dev __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger. http://im.yahoo.com |
|
From: Devlyn D. <de...@ya...> - 2001-09-21 18:17:36
|
Check out the following: http://www.vasl.org/ Apparently, the author of this software is working on modifying the code to create the VASL Engine. The end result would be an extensible online wargame engine. I'm not sure how far along they are, or how the license would work out, but I don't think they have plans for releasing the source for the engine. They would probably just publish the spec for creating modules. Also, check this out: http://www.vasl.org/DVOL this appears to be the first game that is being done with the modified engine. As a matter of fact, from what I understand, DVOL is the first game being made this way and a lot of what is being done to extend VASL to develop DVOL is going back into the VASL codebase. I've looked at the alpha client and it looks very promising. This is actually where I see us being able to take this project. By creating an engine from the very beginning with the idea that it would be extended and modified to specific needs (in our case SBOL), I think we would be creating something worthwhile. __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ |
|
From: <sfb...@cy...> - 2001-09-19 22:43:31
|
Hmmm. Interesting. That was kinda what I was talking about where a file literally tells the app how to draw it. Looking at the .pdf file in Vi, I noticed that it was generated with GNU Ghostscript. I'll have to look into that. Thanks for the info. I might just have to check with this guy. Aaron |
|
From: Devlyn D. <de...@ya...> - 2001-09-19 22:33:51
|
I do use Linux, but I'm no expert. I've been playing
with it off and on for several years. As a matter of
fact, I will be moving my web server to Linux soon.
It is currently running on a Win2K box (getting tired
of fending off CodeRed, Nimda, etc :)
During the previous project that was to attempt what
we are here, there was a guy by the name of David Lang
who came up with a system for coding ALL of the SSD
data into a text file. By all, I mean all of the
system data as well as data that was to be fed into a
program to generate a .ps or pdf image. Below is his
representation of the Cadet Cruiser:
======================================================
ship_outline {
/Ariel-Bold findfont boxsize 2 mul scalefont setfont
8.5 23 (FEDERATON) label
8.5 21 (CADET CRUISER) label
0.5 setlinewidth
3.5 boxes 1.5 boxes moveto 3 boxes 0 boxes rlineto 0
boxes 5.5 boxes rlineto -3 boxes 0 boxes rlineto 0
boxes -5.5 boxes rlineto closepath stroke
11.5 boxes 1.5 boxes moveto 3 boxes 0 boxes rlineto 0
boxes 5.5 boxes rlineto -3 boxes 0 boxes rlineto 0
boxes -5.5 boxes rlineto closepath stroke
7.5 boxes 10 boxes moveto 0 boxes -8.5 boxes rlineto 3
boxes 0 boxes rlineto 0 boxes 8.5 boxes rlineto 9
boxes 15 boxes 5 boxes -73 253 arc closepath stroke
10.5 boxes 4.5 boxes moveto 1 boxes 0 boxes rlineto 0
boxes .5 boxes rlineto -1 boxes 0 boxes rlineto 0
boxes -.5 boxes rlineto closepath stroke
6.5 boxes 4.5 boxes moveto 1 boxes 0 boxes rlineto 0
boxes .5 boxes rlineto -1 boxes 0 boxes rlineto 0
boxes -.5 boxes rlineto closepath stroke
} def
/ship_labels {
/Ariel findfont boxsize .62 mul scalefont setfont
8.5 14 (BRIDGE) label
15 3 (SEN) label
15 5 (SCAN) label
15 7 (DAM CON) label
6.5 14.5 (HULL) label
10.5 14.5 (HULL) label
8.5 5 (HULL) label
8.5 7 (BTTY) label
8.5 3 (SHTL) label
8.5 9 (APR) label
8.5 11.5 (IMPULSE) label
6.5 16.5 (TRAN) label
10.5 16.5 (LAB) label
8.5 16 (PH-1) label
7.5 15.5 (FA) label
4.5 15 (PH-1) label
12.5 15 (PH-1) label
4.5 13 (LS) label
12.5 13 (RS) label
4.5 6 (L WARP) label
12.5 6 (R WARP) label
1 4 (EX DAM) label
8.5 18 (PHOTON) label
} def
/bridge_hit {
8.5 13 bridge
} def
/flag_hit { } def
/sensor_hit {
15 2 (6) sensor
} def
/scanner_hit {
15 4 (0) scanner
} def
/aux_hit { } def
/emer_hit { } def
/chull_hit {
6.5 13.5 hull
6.5 12.5 hull
10.5 13.5 hull
10.5 12.5 hull
8 4 hull
9 4 hull
} def
/fhull_hit { } def
/ahull_hit { } def
/trac_hit { } def
/tran_hit {
6.5 15.5 tran
} def
/phaser_hit {
8.5 15 (1) (FA) phaser1
4.5 14 (2) (LS) phaser1
12.5 14 (3) (RS) phaser1
} def
/drone_hit { } def
/torp_hit {
8 17 (A) (FA) photon
9 17 (B) (FA) photon
} def
/shuttle_hit {
8 2 shuttle
9 2 shuttle
} def
/apr_hit {
8 8 apr
9 8 apr
} def
/impulse_hit {
8 10.5 impulse
9 10.5 impulse
} def
/lwarp_hit {
4 2 warp
5 2 warp
4 3 warp
5 3 warp
4 4 warp
5 4 warp
4 5 warp
5 5 warp
} def
/rwarp_hit {
12 2 warp
13 2 warp
12 3 warp
13 3 warp
12 4 warp
13 4 warp
12 5 warp
13 5 warp
} def
/cwarp_hit { } def
/btty_hit {
8 6 battery
9 6 battery
} def
/probe_hit { } def
/cargo_hit { } def
/lab_hit {
10.5 15.5 lab
} def
/exdam_hit {
1 1 exdam
1 2 exdam
1 3 exdam
} def
/damcon_hit {
15 6 (4) damcon
} def
======================================================
here is what it looked like when generated:
http://devsnet.no-ip.com/sfb/fed_cad.pdf
Now, I have NO idea how he worked this out. I believe
he did mention a way to represent damage to the ship,
but I'm not sure. Anyway, if this method is
appealing, David will have to be contacted for
guidance. I should make mention that I have not
contacted him about this particular project and am
posting this stuff without his knowledge. He may or
may not be willing to help, but from my experiences
with him, he seems like a decent guy.
--- sfb...@cy... wrote:
>
> On Wed, 19 Sep 2001, Devlyn Davis wrote:
>
> > I've been looking into the XML tools you
> mentioned.
> > Merlot seems to be the best choice because it is
> free
> > :) My editor of choice for Linux is Vi, and since
> ViM
> > seems to be a clone of Vi, that would seem to work
> > also. I do agree, however, that a graphical tool
> for
> > data entry would probably be the best bet.
>
> Do you use Linux alot? I don't run anything else at
> home.
>
> >
> > On a similar topic, is there any current thought
> on
> > how the SSD's will be displayed in the game. Will
> > they look like the paper SSD's? i.e., will there
> be a
> > graphical representation of the ship that shows
> all of
> > it's systems and shows which systems have been
> > destroyed? Also, will the charts that are on the
> > SSD's (weapon charts, movement charts, etc.) be
> > displayed? Part of the reason I'm asking is to
> find
> > out if the end result will have any bearing on how
> we
> > gather the data and how much data to gather from
> the
> > SSD's.
>
> I definitely think there should be a graphical
> representation. I don't know about the charts.
> Probably should, just for familiarity.
>
> 2 possibilites occurred to me for the graphic. One
> was to use SVG (scalable vector graphics, I believe.
> It's an XML derivitive). The description of how to
> draw the image is stored in a file and we would have
> a process to convert the SVG to a graphic format to
> display.
>
> The second would be to just have scanned in images
> and display them.
>
> The biggest issue with both is how to mark the boxes
> destroyed. Seems to me you'd need to know the x,y
> coords of the box and the size in order to color it
> on the scanned images. One advantage that the SVG
> has is that since it is rendered, it would be easy
> to modify the SVG file to tell it to render that box
> a different color. The disadvantage (and this seems
> like a big one to me) is that you'd have to have
> some way of creating the SVG file initially. I
> don't know what kind of tools are out there to
> translate a graphic into SVG format, or if someone
> would have to do it from scratch for each SSD.
>
> But for the scanned image, someone would have to
> find out the x,y coords and sizes of the boxes and
> their names.
>
> Any other ideas would be welcome. Dev, I believe
> you had mentioned something about a demo someone
> else had done that generated the SSD's. Maybe they
> had something workable.
>
> Aaron
>
>
> _______________________________________________
> sfbol-planning mailing list
> sfb...@li...
>
http://lists.sourceforge.net/lists/listinfo/sfbol-planning
__________________________________________________
Terrorist Attacks on U.S. - How can you help?
Donate cash, emergency relief information
http://dailynews.yahoo.com/fc/US/Emergency_Information/
|
|
From: <sfb...@cy...> - 2001-09-19 20:32:42
|
On Wed, 19 Sep 2001, Devlyn Davis wrote: > I've been looking into the XML tools you mentioned. > Merlot seems to be the best choice because it is free > :) My editor of choice for Linux is Vi, and since ViM > seems to be a clone of Vi, that would seem to work > also. I do agree, however, that a graphical tool for > data entry would probably be the best bet. Do you use Linux alot? I don't run anything else at home. > > On a similar topic, is there any current thought on > how the SSD's will be displayed in the game. Will > they look like the paper SSD's? i.e., will there be a > graphical representation of the ship that shows all of > it's systems and shows which systems have been > destroyed? Also, will the charts that are on the > SSD's (weapon charts, movement charts, etc.) be > displayed? Part of the reason I'm asking is to find > out if the end result will have any bearing on how we > gather the data and how much data to gather from the > SSD's. I definitely think there should be a graphical representation. I don't know about the charts. Probably should, just for familiarity. 2 possibilites occurred to me for the graphic. One was to use SVG (scalable vector graphics, I believe. It's an XML derivitive). The description of how to draw the image is stored in a file and we would have a process to convert the SVG to a graphic format to display. The second would be to just have scanned in images and display them. The biggest issue with both is how to mark the boxes destroyed. Seems to me you'd need to know the x,y coords of the box and the size in order to color it on the scanned images. One advantage that the SVG has is that since it is rendered, it would be easy to modify the SVG file to tell it to render that box a different color. The disadvantage (and this seems like a big one to me) is that you'd have to have some way of creating the SVG file initially. I don't know what kind of tools are out there to translate a graphic into SVG format, or if someone would have to do it from scratch for each SSD. But for the scanned image, someone would have to find out the x,y coords and sizes of the boxes and their names. Any other ideas would be welcome. Dev, I believe you had mentioned something about a demo someone else had done that generated the SSD's. Maybe they had something workable. Aaron |
|
From: Devlyn D. <de...@ya...> - 2001-09-19 19:59:04
|
I've been looking into the XML tools you mentioned. Merlot seems to be the best choice because it is free :) My editor of choice for Linux is Vi, and since ViM seems to be a clone of Vi, that would seem to work also. I do agree, however, that a graphical tool for data entry would probably be the best bet. On a similar topic, is there any current thought on how the SSD's will be displayed in the game. Will they look like the paper SSD's? i.e., will there be a graphical representation of the ship that shows all of it's systems and shows which systems have been destroyed? Also, will the charts that are on the SSD's (weapon charts, movement charts, etc.) be displayed? Part of the reason I'm asking is to find out if the end result will have any bearing on how we gather the data and how much data to gather from the SSD's. -Dev --- sfb...@cy... wrote: > > On Mon, 17 Sep 2001, Devlyn Davis wrote: > > > re: XML. I, of course, defer to the opinion of > the > > programmer(s) on the best form for the data to > take. > > Also, I've coded a few web pages in HTML via > notepad > > and such so I don't think XML will be entirely > foreign > > to me. > > > > In terms of the tools you mentioned for > manipulating > > XML, were you referring to tools to help encode > the > > data into XML? Or were you referring to > manipulating > > the XML code after the data has been entered? Or > > maybe both? ;) > > I've attached an example of an SSD done in xml. If > you've got IE 5.0, you can open it with that to get > an expandable tree view of the document. The tools > I was referring to are things like XMLSpy or Merlot > that can take a document type definition and provide > a graphical interface for data entry through dialogs > and the like. Then it outputs the completed xml > document. I figured that a graphical interface > might be easier for people to deal with than a > plain-text file with a ton of tags. I personally > use ViM. I've gotten some scripts for ViM that > complete tags, wrap tags around highlighted text, > etc. > > I personally think that xml would be the best way to > store the SSD's, tables, turn-mode charts, etc. > They are easiliy modifiable and extremely easy to > convert to any other format. We can use them to get > a first iteration up and running. And if we need to > input the data into a database, it's cake to suck in > the xml and populate tables. Depending on the > database, no coding would even be required to do it. > > Aaron > > <?xml version="1.0"?> > <!-- $Id: fedcassd.xml,v 1.1.1.1 2001/09/17 20:02:31 > cyberlizard Exp $ --> > <!-- <!DOCTYPE starship PUBLIC "-//ADB//SSD//EN" > SYSTEM > "http://cyberlizard.org/projects/sbol/DTD/SSD.dtd"> > --> > > <starship> > <race>Federation</race> > <class>CA</class> > <pointValue>125</pointValue> > <sizeClass>3</sizeClass> > <turnMode>D</turnMode> > <crewUnits>43</crewUnits> > <boardingParties>10</boardingParties> > > <systemCosts> > <shieldMin>1</shieldMin> > <shieldFull>1</shieldFull> > <lifeSupport>1</lifeSupport> > </systemCosts> > > <systems> > <sensors> > <sensor id="sensor1">6</sensor> > <sensor id="sensor2">6</sensor> > <sensor id="sensor3">5</sensor> > <sensor id="sensor4">3</sensor> > <sensor id="sensor5">1</sensor> > <sensor id="sensor6">0</sensor> > </sensors> > <scanners> > <scanner id="scanner1">0</scanner> > <scanner id="scanner2">0</scanner> > <scanner id="scanner3">1</scanner> > <scanner id="scanner4">3</scanner> > <scanner id="scanner5">5</scanner> > <scanner id="scanner6">9</scanner> > </scanners> > <damageControl> > <dcLevel id="dc1">4</dcLevel> > <dcLevel id="dc2">4</dcLevel> > <dcLevel id="dc3">2</dcLevel> > <dcLevel id="dc4">2</dcLevel> > <dcLevel id="dc5">2</dcLevel> > <dcLevel id="dc6">0</dcLevel> > </damageControl> > <excessDamage>6</excessDamage> > <probes>5</probes> > <transporters>3</transporters> > <tractors>2</tractors> > <labs>8</labs> > </systems> > > <shuttles> > <shuttle id="shuttle1"/> > <shuttle id="shuttle2"/> > <shuttle id="shuttle3"/> > <shuttle id="shuttle4"/> > </shuttles> > > <shields> > <shield id="shield1">30</shield> > <shield id="shield2">25</shield> > <shield id="shield3">25</shield> > <shield id="shield4">25</shield> > <shield id="shield5">25</shield> > <shield id="shield6">25</shield> > </shields> > > <weapons> > <weapon id="PT-A" class="heavy" type="photon" > fa="FH"/> > <weapon id="PT-B" class="heavy" type="photon" > fa="FH"/> > <weapon id="PT-C" class="heavy" type="photon" > fa="FH"/> > <weapon id="PT-D" class="heavy" type="photon" > fa="FH"/> > <weapon id="P1" class="direct" type="PH-1" > fa="FH" /> > <weapon id="P2" class="direct" type="PH-1" > fa="FH" /> > <weapon id="P3" class="direct" type="PH-1" > fa="LF|L" /> > <weapon id="P4" class="direct" type="PH-1" > fa="LF|L" /> > <weapon id="P5" class="direct" type="PH-1" > fa="RF|R" /> > <weapon id="P6" class="direct" type="PH-1" > fa="RF|R" /> > <weapon id="P7" class="direct" type="PH-1" > fa="AH" /> > <weapon id="P8" class="direct" type="PH-1" > fa="AH" /> > <weapon id="P9" class="direct" type="PH-3" > fa="A" /> > <weapon id="P10" class="direct" type="PH-3" > fa="A" /> > </weapons> > > <engines> > <engine id="rightWarp" loc="R" > type="warp">15</engine> > <engine id="leftWarp" loc="L" > type="warp">15</engine> > <engine id="impulse" loc="C" > type="impulse">4</engine> > <engine id="auxWarp" loc="C" > type="warp">2</engine> > </engines> > > <batteries>3</batteries> > > <controls> > <bridge>2</bridge> > <emergencyBridge>2</emergencyBridge> > <auxControl>2</auxControl> > </controls> > > <hulls> > <hull id="forwardHull" loc="F">12</hull> > <hull id="aftHull" loc="A">4</hull> > </hulls> > > </starship> > __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ |
|
From: <sfb...@cy...> - 2001-09-17 20:23:49
|
This is a good idea. My thought had been to allow for the saving of games so that users could pick them back up, but asynchronous play sounds like a better solution. Aaron On Mon, 17 Sep 2001, Devlyn Davis wrote: > I know it's a little early to be discussing feature > requests, but this is something that was brought up > amongst other SIB players and it sounds like a good > idea. > > Allowing asynchronous play. Basically, the system > would become a sort of PBEM mediator for the players, > although it wouldn't really be PBEM, the user's would > just send their turn data to the server for > processing. The reason that this sounds appealing is > that SFB can sometimes take a few hours (or more) to > play a scenario. There's a lot of folks that don't > have that amount of time to spend online at once. > Asynchronous play would allow two or more players to > play out a scenario over the course of a day or two, > playing their turns when they have a few minutes > available to spend online. > > There should be limits placed on the system such as > how long to allow a user to make his next move and how > long a game could stretch out, but I think this opens > up the system to a wider audience. > > Just having fun with the possibilities... > > __________________________________________________ > Terrorist Attacks on U.S. - How can you help? > Donate cash, emergency relief information > http://dailynews.yahoo.com/fc/US/Emergency_Information/ > > _______________________________________________ > sfbol-planning mailing list > sfb...@li... > http://lists.sourceforge.net/lists/listinfo/sfbol-planning > |
|
From: <sfb...@cy...> - 2001-09-17 20:21:37
|
I had a thought this weekend. I had noticed that the current SFBonline uses an IRC server to handle the communications. Why couldn't we find an existing IRC server and just modify the code to include our game modules? This has the advantages of using a well-documented protocol, the code is already there to handle multiple users and games, using IRC channels. I'm sure we could find plenty of IRC client source code to base the client on. All we would need to do is modify the server to plug into our game modules that process the rules. There is also the added advantage that the modified IRC server could be used to handle any different game modules. Just a thought. I'll check out the feasibility of this. Aaron -- "Great spirits have always found violent opposition from mediocre minds" Einstein |
|
From: <sfb...@cy...> - 2001-09-17 20:14:19
|
On Mon, 17 Sep 2001, Devlyn Davis wrote: > re: XML. I, of course, defer to the opinion of the > programmer(s) on the best form for the data to take. > Also, I've coded a few web pages in HTML via notepad > and such so I don't think XML will be entirely foreign > to me. > > In terms of the tools you mentioned for manipulating > XML, were you referring to tools to help encode the > data into XML? Or were you referring to manipulating > the XML code after the data has been entered? Or > maybe both? ;) I've attached an example of an SSD done in xml. If you've got IE 5.0, you can open it with that to get an expandable tree view of the document. The tools I was referring to are things like XMLSpy or Merlot that can take a document type definition and provide a graphical interface for data entry through dialogs and the like. Then it outputs the completed xml document. I figured that a graphical interface might be easier for people to deal with than a plain-text file with a ton of tags. I personally use ViM. I've gotten some scripts for ViM that complete tags, wrap tags around highlighted text, etc. I personally think that xml would be the best way to store the SSD's, tables, turn-mode charts, etc. They are easiliy modifiable and extremely easy to convert to any other format. We can use them to get a first iteration up and running. And if we need to input the data into a database, it's cake to suck in the xml and populate tables. Depending on the database, no coding would even be required to do it. Aaron |
|
From: Devlyn D. <de...@ya...> - 2001-09-17 20:08:45
|
I know it's a little early to be discussing feature requests, but this is something that was brought up amongst other SIB players and it sounds like a good idea. Allowing asynchronous play. Basically, the system would become a sort of PBEM mediator for the players, although it wouldn't really be PBEM, the user's would just send their turn data to the server for processing. The reason that this sounds appealing is that SFB can sometimes take a few hours (or more) to play a scenario. There's a lot of folks that don't have that amount of time to spend online at once. Asynchronous play would allow two or more players to play out a scenario over the course of a day or two, playing their turns when they have a few minutes available to spend online. There should be limits placed on the system such as how long to allow a user to make his next move and how long a game could stretch out, but I think this opens up the system to a wider audience. Just having fun with the possibilities... __________________________________________________ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ |
