Multiple "Views" in an RTS style game?
by Paul Mumby (old) · in Torque Game Engine · 05/27/2009 (9:00 am) · 6 replies
Hey, first post. New to Torque.
I'm working on getting to know the torque engine, in plans for a commercial Wii Game (we are planning on launching it at my work, but I am tasked with learning the engine before we make the purchase in a couple weeks, so I'm using the demo and working with scripting for now).
One of the features planned for our game is to have 2 "views" in the game (we are planning on an RTS type game, but more on a larger scale empire building kind of thing. with potentially very many players in a game at once. And games may last days, weeks, or even months, being persistent on the server)
The 2 views would be the "World" view where you see the main world map, where each player's "city" is represented by a single model which represents the size of the city. this keeps the larger world map with many players, much simpler. And then the smaller "City" view where you can click on your city, and it zooms into an essentially private instanced smaller map, where you can build your individual buildings and such.
Now that I'm getting my hands dirty in Torque, I'm getting a bit concerned this might not work well in the current model without some fairly extensive modification to the engine. Right now a server runs a single "game" which is a "world" so to speak, where all players co-exist.
The only way I could think to possibly do this with the current model would be to run seperate servers for each "instance" and fire them up as needed for players, but this could create several other problems.
Am I just misunderstanding how the engine works due to lack of experience? or are we going to have to rethink our model somewhat?
Any help, comments, or suggestions are much appreciated.
Thanks!
I'm working on getting to know the torque engine, in plans for a commercial Wii Game (we are planning on launching it at my work, but I am tasked with learning the engine before we make the purchase in a couple weeks, so I'm using the demo and working with scripting for now).
One of the features planned for our game is to have 2 "views" in the game (we are planning on an RTS type game, but more on a larger scale empire building kind of thing. with potentially very many players in a game at once. And games may last days, weeks, or even months, being persistent on the server)
The 2 views would be the "World" view where you see the main world map, where each player's "city" is represented by a single model which represents the size of the city. this keeps the larger world map with many players, much simpler. And then the smaller "City" view where you can click on your city, and it zooms into an essentially private instanced smaller map, where you can build your individual buildings and such.
Now that I'm getting my hands dirty in Torque, I'm getting a bit concerned this might not work well in the current model without some fairly extensive modification to the engine. Right now a server runs a single "game" which is a "world" so to speak, where all players co-exist.
The only way I could think to possibly do this with the current model would be to run seperate servers for each "instance" and fire them up as needed for players, but this could create several other problems.
Am I just misunderstanding how the engine works due to lack of experience? or are we going to have to rethink our model somewhat?
Any help, comments, or suggestions are much appreciated.
Thanks!
#2
From your post, I am envisaging something like a 'civilisation' large scale map, that can be zoomed in to a 'sim city' style smaller map.
I think your right that there will be extensive engine modifications needed to handle what you are talking about, you don't want everything scoped to all the clients when they are in the 'global' view, you just need to scope stuff in the 'zoomed' view.
The easiest approach might be to have the global view as a GUI screen that allows you to change between levels/servers when you zoom in. Other people will probably have better ideas.
It sounds like an interesting project though.
05/28/2009 (3:40 am)
No, the RTS kit doesn't cover what he is talking about.From your post, I am envisaging something like a 'civilisation' large scale map, that can be zoomed in to a 'sim city' style smaller map.
I think your right that there will be extensive engine modifications needed to handle what you are talking about, you don't want everything scoped to all the clients when they are in the 'global' view, you just need to scope stuff in the 'zoomed' view.
The easiest approach might be to have the global view as a GUI screen that allows you to change between levels/servers when you zoom in. Other people will probably have better ideas.
It sounds like an interesting project though.
#3
Hmm...
If anyone has any further suggestions they would definately be appreciated.
The idea of using the global "world map" as a gui view instead of a full 3d view is interesting. because in theory I don't need to give players the "zoomed in" view of other players towns, just general stats. So theoretically this would work and keep engine mods to a minimum. BUT that's still going to need extensive serverside mods to handle the hundreds of instances running at once.
What if I were to divide up the world into several "regions" and run each region in it's own server. Only allowing enough physical land in each region for enough buildings and such to keep within my poly budget? That way as players move around they hop from region to region (server to server) but each individual server is within sane limits...
This is going to require some major thought.
05/28/2009 (5:15 am)
Hmm... that's what I suspected... I am thinking it wouldn't be too hard to setup the server to auto-boot individual "instance" servers for each town as it's needed. But it's likely more involved than I'm thinking. In addition the lag time this would create for the players would be huge (not to mention the overhead of potentially running several hundred instances of the torque server at once lol)Hmm...
If anyone has any further suggestions they would definately be appreciated.
The idea of using the global "world map" as a gui view instead of a full 3d view is interesting. because in theory I don't need to give players the "zoomed in" view of other players towns, just general stats. So theoretically this would work and keep engine mods to a minimum. BUT that's still going to need extensive serverside mods to handle the hundreds of instances running at once.
What if I were to divide up the world into several "regions" and run each region in it's own server. Only allowing enough physical land in each region for enough buildings and such to keep within my poly budget? That way as players move around they hop from region to region (server to server) but each individual server is within sane limits...
This is going to require some major thought.
#4
Does that sound doable with minimal engine modifications?
05/28/2009 (6:56 pm)
What about running a local server on the client. (like in a singleplayer game) as well as the main central server for the larger world map view. And let the script hop between the 2 servers. Since enemy players will never see your city it's fine that it runs entirely locally. We can simply sync this info with a server via a secured web service to keep the data in-sync with a persistant database.Does that sound doable with minimal engine modifications?
#5
BTW, while I said that the RTS kit doesn't solve these problems for you, it is still really useful for an RTS game, as it has lots of networking type improvements that demonstrate a way to deal with the fact that Torque networking is based around each client having one player avatar in the world.
The main use of the RTS kit is to read the code changes and see what problems they are solving and how they solved them, then doing something similar in your own code.
Matt
05/29/2009 (4:21 am)
That sounds like a pretty interesting idea. My biggest concern would be trusting the 'server' that is running on the client machine, you would need to provide the main server with some way of checking what the city servers are telling it, and deciding if it is realistic.BTW, while I said that the RTS kit doesn't solve these problems for you, it is still really useful for an RTS game, as it has lots of networking type improvements that demonstrate a way to deal with the fact that Torque networking is based around each client having one player avatar in the world.
The main use of the RTS kit is to read the code changes and see what problems they are solving and how they solved them, then doing something similar in your own code.
Matt
#6
For example have the client fetch current data for the city as a single datablock every time the user switches to that view. Then have the client pre-check actions (such as creating a building or whatever) to allow for ghosting (red = nobuild, green = build for example) but then once the building is built, fire off a "build" command with the location of the building to the webservice. And have it do a check for validity and respond with "OK" in which case the building is safe to construct, or some other message, in which case it's an error to be displayed to the client. (such as QUIT CHEATING!) lol...
That might work. Basically the "city view" server is a 3d "browser" to the web service. and the client just renders what it's told to. That way no trust is actually placed on the clientside (avoiding any possibility of cheating)
Do you think the torque networking code would be able to handle for example a couple hundred users in a world map where each user has only a fairly simple "city" model representing their town (possibly 4-5 cities per player) and lets say only a quarter of the players have "troops" on the world map at once, and if so it's represented by 2-3 "armies" (which are a single animated model, with relatively low detail, representing a mob of people)
Or will I still need to heavily optimize the netcode to handle that kind of load?
Thanks again!
05/29/2009 (5:16 am)
Yes I agree. I would definately have to double/triple check everything the clientside server does... lolFor example have the client fetch current data for the city as a single datablock every time the user switches to that view. Then have the client pre-check actions (such as creating a building or whatever) to allow for ghosting (red = nobuild, green = build for example) but then once the building is built, fire off a "build" command with the location of the building to the webservice. And have it do a check for validity and respond with "OK" in which case the building is safe to construct, or some other message, in which case it's an error to be displayed to the client. (such as QUIT CHEATING!) lol...
That might work. Basically the "city view" server is a 3d "browser" to the web service. and the client just renders what it's told to. That way no trust is actually placed on the clientside (avoiding any possibility of cheating)
Do you think the torque networking code would be able to handle for example a couple hundred users in a world map where each user has only a fairly simple "city" model representing their town (possibly 4-5 cities per player) and lets say only a quarter of the players have "troops" on the world map at once, and if so it's represented by 2-3 "armies" (which are a single animated model, with relatively low detail, representing a mob of people)
Or will I still need to heavily optimize the netcode to handle that kind of load?
Thanks again!
Torque Owner Javier Canon