Announcement

Collapse
No announcement yet.

Is it feasible to use UDK to build a homeworld like RTS?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Is it feasible to use UDK to build a homeworld like RTS?

    Path finding is a major component in standard RTS but in a 3d space based rts all is needed is collisions and a way to slip by stuff. So simple rounded bounding volumes around rocks and stations is all that is needed.

    For networking all the UT3 stuff needs to be thrown out and everything needs to rely on TCPLink. FPS games rely on the server for almost everything, can the existing server be thrown out without much hassle?

    Most RTS use lock step simulation and networking mechanism. Lock step would require two representations - a logical representation and a graphical representation. The Logical representation is updated deterministically at agreed upon interval (say 4 times a second) while the graphical representation should be smoothing over the logical one.

    Is it possible to set logical ghost actors to be smoothly followed by the real graphical actors? And more importantly can the logical ghost actors be made 100% deterministic. Are ue3 collisions deterministic? So that with exact same input the exact same output is reached on all of the clients (assuming they run same architecture - the PC)? Is the general ue3 math deterministic? Are there any math optimizations that could lead to different outcomes?

    I hope that for a 3d spaced based RTS some of the UT3 graphical optimizations still could be used. This is not a top down rts, you still generally float among the ships. But are there any problems form this front?

    Have any solid RTSes been done with ue3? Is there any one on here who is planning an RTS we could sync up with?

    #2
    Path finding is a major component in standard RTS but in a 3d space based rts all is needed is collisions and a way to slip by stuff. So simple rounded bounding volumes around rocks and stations is all that is needed.
    I would propose that path finding is still important because otherwise you would get units doing stupid things such as trying to fly into other enemies, enemy zones and so forth.

    For networking all the UT3 stuff needs to be thrown out and everything needs to rely on TCPLink. FPS games rely on the server for almost everything, can the existing server be thrown out without much hassle?
    I disagree.

    Is it possible to set logical ghost actors to be smoothly followed by the real graphical actors? And more importantly can the logical ghost actors be made 100% deterministic. Are ue3 collisions deterministic? So that with exact same input the exact same output is reached on all of the clients (assuming they run same architecture - the PC)? Is the general ue3 math deterministic? Are there any math optimizations that could lead to different outcomes?
    Yes, it is possible.

    Have any solid RTSes been done with ue3? Is there any one on here who is planning an RTS we could sync up with?
    The last time I made an RTS was with Unreal Engine 2 (the USkaarj project), and we solved a lot of problems then which are probably solvable now. I plan to write a kitset for UDK which allows developers to focus on creating the RTS game and not so much the RTS mechanics. This will be a commercial module for UDK as well.

    Comment


      #3
      I disagree.
      Solid Snake, so you think using the ue3 actor replication based model and running the simulation also on the server and only syncing the important stuff is the best appraoch?

      I would propose that path finding is still important because otherwise you would get units doing stupid things such as trying to fly into other enemies, enemy zones and so forth.
      Can the UT3 path finding (either old way points or new nav mesh/pylons) be used in rts?

      The last time I made an RTS was with Unreal Engine 2 (the USkaarj project), and we solved a lot of problems then which are probably solvable now. I plan to write a kitset for UDK which allows developers to focus on creating the RTS game and not so much the RTS mechanics. This will be a commercial module for UDK as well.
      What would be the features of such Kit?
      What is the time frame of its release?

      What worries me is that USkaarj was the only visible RTS project for UE2.

      Comment


        #4
        Solid Snake, so you think using the ue3 actor replication based model and running the simulation also on the server and only syncing the important stuff is the best appraoch?
        A lot of RTS games now a days are moving to a client server model as well, but given that it's still possible to make Unreal Engine have client authority anyways. But the main point of disagreement I have is that TCPLink itself is quite slow as compared to the main form of communication in Unreal Engine which will more likely be UDP.

        Can the UT3 path finding (either old way points or new nav mesh/pylons) be used in rts?
        Very much so as it still uses either A* or Dijikstra's algorithm to calculate weighted paths.

        At this moment I can't quite confirm the exact features of the RTS Kitset, but what I would like is that it'll be a kit set which you can put on top of UDK and it'll be pretty much an RTS that you can start playing (albeit a very simple one). With something already working, the developer could then start modifying it to suit the RTS game they have in mind.

        USkaarj was the only real RTS project but a few others experimented with RTS like game play.

        Comment


          #5
          To use TCP for games (or most real time applications) one needs to disable Nagle's algorithm ( http://en.wikipedia.org/wiki/Nagle%27s_algorithm ) Nagle's is great for web traffic though, I bet that is what TCPLink is because most of the examples are HTTP related. Even if not C++ code is faster then script code. I will play with the replication model (it might have some other benefits like server side fog of war).

          I was fine using TCP for my game (without Nagle) because my RTS focuses more on tactics then button mashing. So having update once a second and taking orders 1 second to register is fine. As long as it looks seamless.

          Was source for USkaarj ever released? I cant download it, the links are broken, even if I had UT2004.

          Solid Snake, you been great help thanks!

          Comment


            #6
            Originally posted by treeform View Post
            For networking all the UT3 stuff needs to be thrown out and everything needs to rely on TCPLink. FPS games rely on the server for almost everything, can the existing server be thrown out without much hassle?
            You may simply not use the UDK networking, but then you're on your own. You may want to use the TCPLink just to communicate with your custom local proxy server, in which you will have full control over the networking details.

            As far as 100% determinism goes, I don't think so, unless you will do the physics yourself on CPU/GPU and handle the determinism issues of floating point calculations.

            I believe PhysX in UDK uses variable timestep, so unless there's an exposed option to kick it into constant mode, that's plain not deterministic. Still, as long as framerate doesn't fluctuate too much, physics should be pretty consistent.

            There's the FIXEDFPS option for running at constant framerate, put in with movie recording in mind. That would be desperate but it's interesting enough to mention.

            I've been toying with an 3D space RTS idea but just as exercise for myself, not as something for people to play with. The key point was making it as large scale as possible (1000+ units) while keeping it low-bandwidth.

            Comment


              #7
              The determinism is a must if one wants to implement a lock step model RTS.

              But looking more at the UDK networking spec it might be possible to construct an RTS using that which is not a lock step system. Benefits of that are a true server side fog of war, true random numbers on the server and fantastic optimizations that Epic put in.

              Comment


                #8
                Originally posted by Solid Snake View Post
                A lot of RTS games now a days are moving to a client server model as well, but given that it's still possible to make Unreal Engine have client authority anyways. But the main point of disagreement I have is that TCPLink itself is quite slow as compared to the main form of communication in Unreal Engine which will more likely be UDP.

                Very much so as it still uses either A* or Dijikstra's algorithm to calculate weighted paths.

                At this moment I can't quite confirm the exact features of the RTS Kitset, but what I would like is that it'll be a kit set which you can put on top of UDK and it'll be pretty much an RTS that you can start playing (albeit a very simple one). With something already working, the developer could then start modifying it to suit the RTS game they have in mind.

                USkaarj was the only real RTS project but a few others experimented with RTS like game play.
                Would you mind just sketching the basic outline of what you did with USkaarj? I know most of it might not be applicable to UDK in the specifics, but surely not everything has changed. I'm poking around looking for where to start on an RTS-type game and I'm really lost. The only concrete ideas I have now is to turn the UTPawn into some sort of constrained-view spectator with a pile of units attached to his object.

                Comment


                  #9
                  Just an FYI, Tom Clancy's EndWar used the UE3 and it is basically an RTS (I think)

                  Comment


                    #10
                    I did not think USkaarj was done that well it had all sorts of horrible issues with syncing and such. You would need to turn Unreal into a LockStep game which is how RTS games work... this is possible through the Unreal replication model. I think the way USkaarj implemented it was well sloppy and barely worked.

                    Comment


                      #11
                      micahpharoh, thanks about EndWar did not know that!

                      Comment

                      Working...
                      X