Almost have a prototype done...
by Scott Coursey · 09/26/2006 (9:19 pm) · 6 comments
I'm currently working on a turn-based strategy game in TGB. I'm this close (in case you can't see me, I'm holding my fingers really close together) to having a functional multi-player mode. *yay!*!
I had the code working very well for a single-player mode, but when I put more networking stuff in for multi, I borked the single. Next, I'll have to get the single working again, and probably kill the multi. Go figure.
Anyway...
I only have two functional units right now. A soldier (
) and an archer (
). They work well and it's fun to move them around and attack.
I'm just not exactly sure how to continue with the server code... I'm not sure how much of a resource hog TGB would be without a GUI and I'd like to have multiple instances of it running. Besides, the machine that it'd be on is my only one... Hmm... Currently, the server is written in TCL which works excellently (I started writing this before the network code was put in the EA rev of T2D, then took a long break from it).
Well, it's late... Good night. When I get it functional, I'll be putting a demo version out. I'm currently developing most of it on my PowerBook and testing the multi-player functionality along with my wife's XP box. Sorry, no Linux for now. Possibly in the future if there's enough demand (Although I haven't changed anything in the engine - yet. I probably will when I get into the AI).
I had the code working very well for a single-player mode, but when I put more networking stuff in for multi, I borked the single. Next, I'll have to get the single working again, and probably kill the multi. Go figure.
Anyway...
I only have two functional units right now. A soldier (
) and an archer (). They work well and it's fun to move them around and attack.I'm just not exactly sure how to continue with the server code... I'm not sure how much of a resource hog TGB would be without a GUI and I'd like to have multiple instances of it running. Besides, the machine that it'd be on is my only one... Hmm... Currently, the server is written in TCL which works excellently (I started writing this before the network code was put in the EA rev of T2D, then took a long break from it).
Well, it's late... Good night. When I get it functional, I'll be putting a demo version out. I'm currently developing most of it on my PowerBook and testing the multi-player functionality along with my wife's XP box. Sorry, no Linux for now. Possibly in the future if there's enough demand (Although I haven't changed anything in the engine - yet. I probably will when I get into the AI).
About the author
#2
09/26/2006 (10:05 pm)
Cool art! Can't wait to see more!!
#4
I used TCL professionally for several years (as a scripting language for a middleware engine called Cloverleaf, used in healthcare data management and integration), and had a lot of enjoyment with it. Interestingly, after working with a typeless (everything in TCL is a string just like in TorqueScript) scripting language, it was very easy for me to transition to TorqueScript.
09/27/2006 (12:04 am)
I'd be interested in some more information on what you have your server doing, and especially how/why you chose TCL for the implementation.I used TCL professionally for several years (as a scripting language for a middleware engine called Cloverleaf, used in healthcare data management and integration), and had a lot of enjoyment with it. Interestingly, after working with a typeless (everything in TCL is a string just like in TorqueScript) scripting language, it was very easy for me to transition to TorqueScript.
#5
09/27/2006 (3:27 am)
Very nice sprites :) Good luck!
#6
@Stephen: I've used TCL professionally as well (I don't mind emailing you the server code if you want to see it). For me, I wrote a backend server wrapper around CVS for development checkin, branch locking, controlled forking, etc. I used PgTclsh for integration with PostgreSQL and Delphi for a client app for management to control the server's configuration.
My server is mostly doing message translation and broadcasting of the messages to the connected sockets, as well as simple password checking and denial of connections if there are enough players already joined. It also manages the "ready" state in the lobby.
I wrote it in TCL mostly because I'm very familiar with it. I could probably write it in TorqueScript, wrapping everything into a single object. That way, I could have a single server app controlling multiple games at once. I know the server, the way it's done now, will never peak my server's capabilities and I wanted to keep the overhead low. I've never done a dedicated server in Torque, so I don't know how much of my CPU would get taken. I didn't want to dedicate too much since the server is mostly spinning its cycles, waiting for reads on the sockets.
I figure that if I keep it written in TCL, then it's not plausible to distribute a standalone server, which doesn't bother me. It does include some problems with integrating the AI code, which should be done in TorqueScript so it'll run on the client machines in the standalone campaigns. That means I'd have to get an instance of Torque running on the server anyway, so I'll probably wind up porting the server to TorqueScript anyway.
09/27/2006 (4:43 am)
@Everyone else: Thanks for the comments on the sprites! I had fun drawing them. I used my Wacom 6x8" tablet with Alias Sketchbook Pro, with some tweaks in Photoshop. I'm planning on having golems, wizards, clerics, and some other fun character types. Once I get the basics down, it'll be pretty easy to move into more advanced units and working on the campaign.@Stephen: I've used TCL professionally as well (I don't mind emailing you the server code if you want to see it). For me, I wrote a backend server wrapper around CVS for development checkin, branch locking, controlled forking, etc. I used PgTclsh for integration with PostgreSQL and Delphi for a client app for management to control the server's configuration.
My server is mostly doing message translation and broadcasting of the messages to the connected sockets, as well as simple password checking and denial of connections if there are enough players already joined. It also manages the "ready" state in the lobby.
I wrote it in TCL mostly because I'm very familiar with it. I could probably write it in TorqueScript, wrapping everything into a single object. That way, I could have a single server app controlling multiple games at once. I know the server, the way it's done now, will never peak my server's capabilities and I wanted to keep the overhead low. I've never done a dedicated server in Torque, so I don't know how much of my CPU would get taken. I didn't want to dedicate too much since the server is mostly spinning its cycles, waiting for reads on the sockets.
I figure that if I keep it written in TCL, then it's not plausible to distribute a standalone server, which doesn't bother me. It does include some problems with integrating the AI code, which should be done in TorqueScript so it'll run on the client machines in the standalone campaigns. That means I'd have to get an instance of Torque running on the server anyway, so I'll probably wind up porting the server to TorqueScript anyway.
Torque Owner Corey Martin