Please feel free to use "Feature Requests" in the project tracker to record anything that you would like added to the project. Tracker provides an important record of desired functionality.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-04-09
Hi Olaf,
Thanks for the opportunity to make a feature request for Regcom. I first saw Regcom a few years ago and kept it the back of my mind. I thought, "hey, a hex/turn based project that isn't already specialized for a certain type of game play!
In have two requests for your consideration:
1) Keep a branch as generic as possible--it would be nice if game developers could create their own type of game be it fantasy, WWII, etc. Xconq does a good job of this.
1a. Easy to parse map and unit files--reason: make it easy to import GIS data
2) Text-based interface--this makes computer-assisted tabletop play (via sphinx speech recognition/synthesizing) possible
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
all credits go to Randi for coming up with the code, he is the only one able to code on a professional level.
I don´t know where this project will go, for a while nothing has happened.
I totally agree with you that any engine must be flexible enough to accommodate different themes, and have
interfaces toward importing all kinds of data. I´ve recently looked at the wolfpack empire server which is
probably a good example (speaking for myself here), of how this kind of thing can be done.
For a hex based game the "world" will have to be torus which will probably pose a problem for a straight forward import of GIS data. Please have a look at http://vickijoel.org/hexplanet/ for a in depth look at the problem.
To incorporate something like sphinx would certainly be thrilling and new, since its a free python module it can be done.
To compete against the massive amount of MMOs popping up everywhere, we would need some unique features.
well you've given me some homework...
btw. when, and how did I contact you ?
Greets Olaf
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-04-11
I should have posted the second "script" link as follows:
Hey, I'm back. I really like the look of the hexplanet stuff. Too bad you get those stray pentagons. If they are just at the poles, it might be worth taking a closer look. If we don't take wrapping into account, torus or whatever, then we end up with people backed up against the edge of the map for protection. Fractals terrains would be a snap, just disturb the points during tesselation.
I have been adding gui functionality, edit boxes in particular. Still trying to connect a graphical client to a server. I also added a placeholder "main menu" screen to the client.
Randi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
with the hexplanet model you will always have one single pentagon, since a sphere must have an odd number of triangles. I believe its a perfect model for a space exploration game, where you could place the "stargate" in the pentagon. I suggest to use the Torus model, since its much easier to handle, and.. its already been done.
Olaf
PS: -Randi, If I can help you in any way with your connection problem, let me know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-04-11
Hi Olaf,
Thanks for your reply. I've taken the time to post some example work for you; I'll first reply in kind.
It looks like the RegCom project has flexibility in mind from the beginning--from RegCom's web page, "Regimental Command is a generic armored combat system..." :) Text based file formats for maps, units, etc. that make sense are important. I'm now wondering if we couldn't just take a queue from the GRASS GIS system itself for a 1-to-1 export/import system. Here's the landcover file format linked below; the format will make sense as I link the associated GUI:
I read the hexplanet paper (very cool) and understand in basic terms what's going on when you're creating a sphere.
Finally, modified a copy of Xconq to respond to voice commands via sphynx and Perlbox. It was tedious entering in all the possible commands but I must say that voice control for movement, etc. worked really well.
Voice control is cool enough. What happens, then, when we take this basic engine using GIS data and use it with a real tabletop: a kind of hex version of this:
You hadn't contacted me btw; I browsed the forums, etc. I didn't want to pester Randi about this like I'd just invented fire. I contacted you first based on your posts--I thought you might be interested.
Best,
Cooper
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
File formats will most likely be xml. Just normal xml, no fancy schema stuff. Right now, the client-server protocol is in xml, i.e. <login username="foo" password="bar" />. I use xml on a regular basis for file storage and it generally works very well. You do run into problems with large files. Binary data can also be awkward to handle.
I like the GIS stuff. Part of the plan was to use fractal seeds to reduce bandwith but we really need to be able to handle raw map data, whether converted GIS or output from some kind of map editor. Maybe use GIS for coarse data and fractals to fill in the rest.
If you would like, I can add you as a developer. We are still at the "back from the dead" stage and starting to throw ideas around again.
Randi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please feel free to use "Feature Requests" in the project tracker to record anything that you would like added to the project. Tracker provides an important record of desired functionality.
Hi Olaf,
Thanks for the opportunity to make a feature request for Regcom. I first saw Regcom a few years ago and kept it the back of my mind. I thought, "hey, a hex/turn based project that isn't already specialized for a certain type of game play!
In have two requests for your consideration:
1) Keep a branch as generic as possible--it would be nice if game developers could create their own type of game be it fantasy, WWII, etc. Xconq does a good job of this.
1a. Easy to parse map and unit files--reason: make it easy to import GIS data
2) Text-based interface--this makes computer-assisted tabletop play (via sphinx speech recognition/synthesizing) possible
Thanks
Hello Cooper,
all credits go to Randi for coming up with the code, he is the only one able to code on a professional level.
I don´t know where this project will go, for a while nothing has happened.
I totally agree with you that any engine must be flexible enough to accommodate different themes, and have
interfaces toward importing all kinds of data. I´ve recently looked at the wolfpack empire server which is
probably a good example (speaking for myself here), of how this kind of thing can be done.
For a hex based game the "world" will have to be torus which will probably pose a problem for a straight forward import of GIS data. Please have a look at http://vickijoel.org/hexplanet/ for a in depth look at the problem.
To incorporate something like sphinx would certainly be thrilling and new, since its a free python module it can be done.
To compete against the massive amount of MMOs popping up everywhere, we would need some unique features.
well you've given me some homework...
btw. when, and how did I contact you ?
Greets Olaf
I should have posted the second "script" link as follows:
http://www.ajass.com/node/293
Best,
Cooper
All -
Hey, I'm back. I really like the look of the hexplanet stuff. Too bad you get those stray pentagons. If they are just at the poles, it might be worth taking a closer look. If we don't take wrapping into account, torus or whatever, then we end up with people backed up against the edge of the map for protection. Fractals terrains would be a snap, just disturb the points during tesselation.
I have been adding gui functionality, edit boxes in particular. Still trying to connect a graphical client to a server. I also added a placeholder "main menu" screen to the client.
Hi All,
with the hexplanet model you will always have one single pentagon, since a sphere must have an odd number of triangles. I believe its a perfect model for a space exploration game, where you could place the "stargate" in the pentagon. I suggest to use the Torus model, since its much easier to handle, and.. its already been done.
Olaf
PS: -Randi, If I can help you in any way with your connection problem, let me know.
Hi Olaf,
Thanks for your reply. I've taken the time to post some example work for you; I'll first reply in kind.
It looks like the RegCom project has flexibility in mind from the beginning--from RegCom's web page, "Regimental Command is a generic armored combat system..." :) Text based file formats for maps, units, etc. that make sense are important. I'm now wondering if we couldn't just take a queue from the GRASS GIS system itself for a 1-to-1 export/import system. Here's the landcover file format linked below; the format will make sense as I link the associated GUI:
http://www.ajass.com/node/294
Here's the result:
http://www.ajass.com/image/tid/18
Even if the file format is unique you can write a script to convert GIS ASCII export to the engine's import file format:
http://www.ajass.com/image/tid/18
I read the hexplanet paper (very cool) and understand in basic terms what's going on when you're creating a sphere.
Finally, modified a copy of Xconq to respond to voice commands via sphynx and Perlbox. It was tedious entering in all the possible commands but I must say that voice control for movement, etc. worked really well.
Voice control is cool enough. What happens, then, when we take this basic engine using GIS data and use it with a real tabletop: a kind of hex version of this:
http://www.ajass.com/node/297
You hadn't contacted me btw; I browsed the forums, etc. I didn't want to pester Randi about this like I'd just invented fire. I contacted you first based on your posts--I thought you might be interested.
Best,
Cooper
Cooper -
File formats will most likely be xml. Just normal xml, no fancy schema stuff. Right now, the client-server protocol is in xml, i.e. <login username="foo" password="bar" />. I use xml on a regular basis for file storage and it generally works very well. You do run into problems with large files. Binary data can also be awkward to handle.
I like the GIS stuff. Part of the plan was to use fractal seeds to reduce bandwith but we really need to be able to handle raw map data, whether converted GIS or output from some kind of map editor. Maybe use GIS for coarse data and fractals to fill in the rest.
If you would like, I can add you as a developer. We are still at the "back from the dead" stage and starting to throw ideas around again.