I've been tossing around a few ideas for a StarTrek type game, and would appreciate any thoughts about complexity, or appropriate technique in coding...here are my ideas:
- a top-down version of ST:Armada, where players control a starship to battle against others or work in teams against a common foe (NetTrek is an existing popular example for *nix machines, coded in C/C++)...
- using the interior floorplan of a ship to allow characters to roam about the vessel, where they perform what ever duties they are responsible for while on-board (engineering, science, helm, medical, etc.) ...now here is where it gets a bit complex: this starship 'A' runs on dedicated BYOND daemon - a self-contained world so-to-speak... starship 'B' also runs on its own daemon with its own crew, ship layout, etc... in fact every ship that plays is running on its own server daemon, using server-to-server communications to handle combat between ships, transferring of characters to other ships ('beaming' them over), communications, etc... I suppose you could extend the daemon concept to include worlds for the ships to visit as well. And lastly, a map-server daemon that tracks where all the ships/planets are, and deals with certain universe physics such as travel time from point to point for ships and communications between ships.
Personnally I find the second idea challenging and certainly more dynamic - but could become really complex. I chose the daemon method because I think that would perform better load-balancing, as some ships may be more active than others... I suppose an object-based ship would work too, but I forsee tracking/manipulating multiple individual ships would be harder for a single application to perform at a reasonable speed (as close to real-time as possible)...
Thoughts? Critisisms? Comments?
ID:154327
 Jan 2 2002, 9:50 pm
|
|
Spuzzum wrote:
I like the server-hosting idea a LOT. That's the first time I've heard of anything this unique and nifty with regards to BYOND's functionality. We'll have to ask Dantom about this. My thinking is to run each daemon on a seperate port, running multiple daemons (even multiple dreamseekers possibly) on a single machine (preferrably Linux). A P2-200Mhz box with lots of memory ought to handle atleast 4-5 daemons in realtime, if the ship-code is tight. Won't know until I, or anyone else, tries... Another thought (scary, eh?) is to just have everyone download their own copy of ship code (a 'ship client'?) to run on their own box that communicates with a central 'galaxy map' daemon (probably one of my servers that is up all the time). This would/should work for those who want to run an entire crew themselves, and put a lot of the internal processing on the client side. Communications, position, and combat data can be relayed to the central daemon. But this leaves out teams who want to work on one ship... Be careful, though. This method is bound to bring you many headaches -- I'd suggest starting a little smaller. Possibly. I think I may start with a simple ship client and galaxy daemon...if I can get that to work, multiple ships would be the next logical step... Thanks for your input Spuzzum! | |
You overlook a possibility... if I have the ship module running on my computer, my "shipmates" could still log into it... so having one team all play on the same ship would still be possible.
| |
Lesbian Assassin wrote:
You overlook a possibility... if I have the ship module running on my computer, my "shipmates" could still log into it... so having one team all play on the same ship would still be possible. Interesting point...hadn't thought of that one before. | |
Lesbian Assassin wrote:
if I have the ship module running on my computer, my "shipmates" could still log into it... so having one team all play on the same ship would still be possible. I *did* think about that after my last post, but if the ship module is running on a low end computer, or worse a low connection speed (say 48-56K modem), then that "ship" could grind to a slow crawl if too many "crew members" are trying to run around on it...optimization of code for speed would rise to cutting out some features if that were the case... Again, we won't know until we try... What info is available on server-to-server communication? Or must I wait on my copy of the BlueBook to swim to Germany? :) | |
digitalmouse wrote:
What info is available on server-to-server communication? Or must I wait on my copy of the BlueBook to swim to Germany? :) Check out this demo if you haven't already: byond://Deadron.ClientServer It doesn't cover the server talking back to the client, but I think I have some code around to do that also. | |
What info is available on server-to-server communication? Or must I wait on my copy of the BlueBook to swim to Germany? :) I think it's air-mail, actually, but with airport security in the States, who knows what might have happened to it now. ;-P | |
Deadron wrote:
Lesbian Assassin wrote: But we have thought of the basic "ship-as-client" idea before! At one time, Deadron had a nice little forum system set up for DDT, and that was one of the ideas we tossed around. Anyway, I think the idea would be very workable in BYOND, and even on a 56K connection I think it would be feasible for a ship to have several people in the crew. | |
Gughunter wrote:
But we have thought of the basic "ship-as-client" idea before! At one time, Deadron had a nice little forum system set up for DDT, and that was one of the ideas we tossed around. Anyway, I think the idea would be very workable in BYOND, and even on a 56K connection I think it would be feasible for a ship to have several people in the crew. I'm not sure the client-server connections would be ideal, but you could imagine an interesting game where people get together on a "ship" which is running on one computer and prowl the universe looking for other ships to take on... Would perhaps be even more interesting if it was cooperative play against the evil computer forces. | |
Deadron wrote:
Would perhaps be even more interesting if it was cooperative play against the evil computer forces. Maybe, but I think it would be more interesting to play against evil human(player) forces! :) But a few simple AI Borg (or whatever) would be nice for target practice and team coordination and training... I think playing against other 'teams' would be the best for overall game play, especially if the team members work well together...'fleet'-based team play should be good too (for the single player/single ship idea). But first some work on a client that interacts with a galactic map daemon... In regards to your Client-Server code, I've looked at it already, and that is what started me on the server-to-server communications idea. And Spuzzum, I know the book is coming by airmail - I was just using creative metaphors... :) | |
I've always wanted to make and/or play a game like this... in fact, I was planning on making a 3D MMORPG that did just that -- players join the game in command of a starship (standing inside the ship, mind you), or simply as an engineer or civilian, and then they can fly around space doing whatever they want, even design their own ships room by room, deck by deck, then build them and fly them -- after the eventual point where I decide to start programming for a living.
Right now, though, I'm young and happy, and I'm sticking to my easy roots. =)
I like the server-hosting idea a LOT. That's the first time I've heard of anything this unique and nifty with regards to BYOND's functionality.
The only problem is that the communication would become difficult to track, due to the fact that BYOND is designed to have everyone run on a single server, and then players can hop onto different servers from that server or whatever.
True... divvying up the workload (something many successful games do nowadays) is a very good way to go. Fortunately with BYOND, you can't create a decompiler very easily, so your client programs are likely to be very safe (unlike other multiplayer online games, which are prone to hacking).
Be careful, though. This method is bound to bring you many headaches -- I'd suggest starting a little smaller.