Announcement

Collapse
No announcement yet.

How suited would UDK be for a 4X game?

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

    #16
    Originally posted by UnspoiledWalnut View Post
    Not the way he is doing it, I thought he wanted to make it something like Spore or something where it would have a geocentric system when walking on planets.
    Given that the entire game will probably want to be scripted from the base up using only the core most engine classes, that probably want be much of a problem. The whole project is incredibly daunting as it is.

    Originally posted by UnspoiledWalnut View Post
    He shouldn't need to, it's an FPS.
    I'm not sure you understand what a 4X game is; they're more like strategy games played over a vast area and usually additionally include strong emphasis of resource management, politics and exploration at an 'Empire' level.

    Comment


      #17
      I'm not sure you understand what a 4X game is; they're more like strategy games played over a vast area and usually additionally include strong emphasis of resource management, politics and exploration at an 'Empire' level.
      I know, I was responding to leveling down the player size since there isn't really a player walking around, just units.

      Comment


        #18
        I'm not sure you should even be using the unreal concept of a map for this. Traditional maps are for bsp, static meshes, and laying out gameplay events. In a 4x space game everything on screen should be a dynamically spawned actor, or even more likely a UIScene/HUD. So really you've just got a single completely empty "map" and you're spawning various things into it where ever they need to be.

        You might also want to look into offloading some of the end of turn and AI calculations through DllBind into something a bit closer to the silicon.

        Comment


          #19
          If you're going to be just doing that though, you might as well throw out UDK anyway - it's an awful waste of a package to be doing almost everything in the HuD/UI.

          Comment


            #20
            Originally posted by Makaze View Post
            You might also want to look into offloading some of the end of turn and AI calculations through DllBind into something a bit closer to the silicon.
            Using native code would probably speed things up dramaticaly. I didnt knew that UDK had dll bindings

            Comment


              #21
              Originally posted by ambershee View Post
              If you're going to be just doing that though, you might as well throw out UDK anyway - it's an awful waste of a package to be doing almost everything in the HuD/UI.
              The strategic gameplay would play out like that, the tactical gameplay would however be realtime and more 'action' oriented

              Comment


                #22
                Originally posted by UnspoiledWalnut View Post
                But, I think instead if you just scaled everything down to whatever amount so that it would give the illusion of having a much much larger area, it would also work if you used LOD effectively. But this way it would let you not worry about backing in and out all the time to switch between the systems, but I don't know just HOW small or large you can really scale objects before distorting them. This is the way I would personally do it, but you would need to work on the perspective systems so that when you back out really far it won't need to render EVERYTHING that has been loaded.
                Ive given this some tought, and it seems like it would be hard to use a scaled unrealunits becouse it would require different scales for different map sizes, and it would require the camera speed to scale as well depending on 'zoom' level. Its upside is that it provides a more seamless tranition.


                Using multiple layers seems like its easier to implement and would make the model tranitions for the different map layers easier (a single ship would be visible in orbital view, in solar view it would be replaced by an icon, in galactiv single ships arent visible, only fleets are visible as icons) since lod doesnt make it easier to understand what an object is. The downside is that I expect a certain jump when I zoom closer to an object.


                Anyway, these are issues that I can dwell on for quite some time, I'm currently spending my time learning uscript by making custom game modes and experimenting as I go.

                Comment


                  #23
                  You could just code everything so that it scales them automatically I suppose, based on the size of the map. Either way you're going to be having some trouble getting it to work right.

                  Comment


                    #24
                    My biggest concern as of now is speed, specifically the speed of unrealscript. According to this site unrealscript is of a significant magnitude slower than good old native c++. This is by far the biggest Achilles heel that needs to be solved before I can move forward with the project, the solution seems to hide in one of the options discussed below.

                    As far as I've seen by the documentation available, you can tag classes and methods as native and the engine will look for them in a dll file provided, but it seems like this is only available to licensees since it apparently requires a recompile of the engine.

                    Dll bindings seems to be the option left, the documentation I've seen on this is scarce tough and it feels like passing anything other than primitive data types would be hard.

                    Ive also seen the option of using TCP Link to access SQL database (like MySQL or SQlite ), depending on how fast unrealscript can communicate over the TCP Link this could solve a lot of problems.

                    Since it is a turn based game I could also compress all the database changes at the start of every turn and send it as one single large package, eliminating a lot of waiting. The key seems to make the system work asynchronously.

                    Comment


                      #25
                      I don't personally think the execution speed of Unrealscript would be too much of a hindrance. DLLBinding to some sort of database manager is a distinct possibility for managing certain data.

                      Native classes are integrated into the binary file - so yes, this is a licensee feature

                      Comment


                        #26
                        Originally posted by ambershee View Post
                        I don't personally think the execution speed of Unrealscript would be too much of a hindrance. DLLBinding to some sort of database manager is a distinct possibility for managing certain data.

                        Native classes are integrated into the binary file - so yes, this is a licensee feature
                        Given that the bulk of script calls is related to the turn based portion of the game I suppose that cuts me some slack regarding speed

                        Comment


                          #27
                          TCPLink is not good for anything requiring a great deal of speed - the underlying thread has low priority.

                          Comment


                            #28
                            Now that we have DllBind the trick of using TCPLink to talk to a local resource doesn't seem worth the trouble. Marshalling stuff across the DllBind does seem a bit tricky but it should only be a pain to setup once.

                            Also I'd say a SQL DB is gross overkill for any game. Realistically your game, even a big expansive complicated 4x game is not going to have enough data to justify the memory overhead of a SQL DB. Not even to mention the requirements of installing it and having it run in the background of your game. So just have your dll write things out to a temp file and read them back in, incorporate this turns changes, and process the lot, and write back out to a new temp file. That also gives you a built in autosave as each temp file could be the complete game state.

                            One of the biggest things that will help you long term, at least from when I did something similar (though not with unreal) is to make an app that manages your enums. I made a little C# program that opened csv files of enum info, allowed you to edit them, and then exported a file for my main app and one for my embedded one that used a different language. That way my enums were always in sync and the two pieces were always talking to each other about the same thing. We decided to go that route after an enum change on just one side resulted in a bug that took us forever to track down.

                            Comment


                              #29
                              Originally posted by Makaze View Post
                              Now that we have DllBind the trick of using TCPLink to talk to a local resource doesn't seem worth the trouble. Marshalling stuff across the DllBind does seem a bit tricky but it should only be a pain to setup once.

                              Also I'd say a SQL DB is gross overkill for any game. Realistically your game, even a big expansive complicated 4x game is not going to have enough data to justify the memory overhead of a SQL DB. Not even to mention the requirements of installing it and having it run in the background of your game. So just have your dll write things out to a temp file and read them back in, incorporate this turns changes, and process the lot, and write back out to a new temp file. That also gives you a built in autosave as each temp file could be the complete game state.

                              One of the biggest things that will help you long term, at least from when I did something similar (though not with unreal) is to make an app that manages your enums. I made a little C# program that opened csv files of enum info, allowed you to edit them, and then exported a file for my main app and one for my embedded one that used a different language. That way my enums were always in sync and the two pieces were always talking to each other about the same thing. We decided to go that route after an enum change on just one side resulted in a bug that took us forever to track down.
                              Hands down some solid advices there

                              Using DLL bind is probably the way to go, even if I cannot export complex objects, a toString function could encrypt all that I need to replicate the object on the other side as a String. In order to do that I need to keep two separate lists on each side of the applications and writing a custom tool for syncing those lists seems like a very very good idea.

                              Making a big file for each round is probably faster than making thousands of DLL Bind calls, once again a very good advice. Individual changes and queries could be done later directly trough DLL Bind.

                              I can see that a real database might be a bit overkill, its not really hard to make a datastructure that will cover my needs.

                              Comment

                              Working...
                              X