Announcement

Collapse
No announcement yet.

UDK and 4x space games

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

    UDK and 4x space games

    I'm currently toying with the thought of finally going ahead to make a 4x turnbased spacegame, right now i'm at the stage of how i can actually do it.

    I'm going to try and prototype it in GameMaker first - I'm not exactly a programmer, though i do want to learn, so i need to be able to see the core mechanics at work before i commit to anything more graphically intensive.

    My first thought was to use Unity, since Endless Space seems to have gotten some things right (Unity seems to be able to do procedural textures pretty nicely). However, from what i have learned i'd need several software suites and addons to make it work the way i want, let alone a pro license, something for which i just don't have the money for. Even with that in hand i don't know whether my plans would be possible in Unity (zooming from a colony view all the way up to multiple galaxies for example, not necessarily seamless of course, though Mass Effect managed something similar).

    So i started thinking of UDK again, which is also more capable of doing certain other graphics i'd like, though the downside is getting UDK to work when making anything but a shooter-type game (which is reputedly much more difficult to do than with Unity). I'm also not sure whether the turn-based calculations are doable in UDK, thinking of end-game situations where you're controlling multiple galaxies and opponent moves have to be calculated. "Simple" things like research trees or similar also seem more difficult in UDK. Still, it'd seem cool to try and make such a game with an engine "which isn't mean for such things". I do have experience with the UT editor itself, though that's rather outdated (some ut99 levels and ut2k4 fooling around).

    I have very limited experience with Java and C++ (not much further than hello word and basic if/then stuff), so i think of myself as a beginner as far as programming/scripting is concerned. This is something i'd have to learn during the project. Currently i'm alone, so i'd mostly be busy with laying the groundwork and using only rudimentary graphics/sounds (if applicable).

    What would be the difficulties in getting a 4x spacegame to work in UDK, aside from the above concerns? I already found an older thread (2+ years old, see here) about a similar subject, though it's rather out of date and doesn't touch upon some of the other issues i mentioned. I was thinking of "solving" the floating point accuracy problem with a grid-on-grid approach (zooming simply switches to a different scale grid rather than trying to use 1 grid for all zoomstages, not talking about the UDK editor grid!).

    I do need to somehow make a Spore-size galaxy work - Possibly smaller though, incrementing game mechanics from planet -> system -> constellation -> region rahter than persisting on planet size all game long, possibly expanding to galaxy with multiple available galaxies. This is mainly a graphics issue though i believe, if i can get the incremental mechanics to work correctly, though this raises the question whether something like that is even doable in UDK.

    Are there any UDK projects like this released, regardless of scale (or any turn-based strategy games at all)? Would i be better off trying this in Unity after all? Any thoughts would be appreciated!

    #2
    udk can handle turn based games just fine.
    the only problem i see you having (apart from the coding in Unreal Script btw) is the max world size.
    if you think you can fit multiple galaxies in a 10km cube or have an alternative approach then go fot it.

    Comment


      #3
      Originally posted by tegleg View Post
      udk can handle turn based games just fine.
      the only problem i see you having (apart from the coding in Unreal Script btw) is the max world size.
      if you think you can fit multiple galaxies in a 10km cube or have an alternative approach then go fot it.
      This would be an issue in any other engine aswell due to floating point precision, as far as i can tell from the previous thread on this aswell as other sources. This is why space games in general are hard to do.

      I had an idea to try something grid-on-grid - meaning that you don't actually use the same grid for every location and zoom level. When zooming in a level you switch to a smaller grid to have accurate positions for all objects within direct range, objects outside of this (if displayed at all) usually don't need a precise position so they are translated into far out positions on the new grid. They're usually far enough away so that a precise position or even shape is not necessary (as you'd only see a spot of light most likely).

      This process would be repeated for each zoom level, with objects being resized, repositioned or removed/added entirely depending on need, if you get what i mean. A problem with this would be calculating positions and distances for game mechanic purposes, though this could be solved with a 'database' like approach where those values would not be determined by visual positions but values in a seperate file, if that makes sense.

      Comment


        #4
        The scale issue is not impossible, but it would require very careful design and engineering, and is not something to approach on a whim. You'll need to be a competent programmer and have some experience with the API to pull it off.

        I don't know what the Spore scale is like, but I do have a working prototype space game (EVE style) that exceeds UDK's map limit by several light years so it is doable.

        Comment


          #5
          Originally posted by ChromeBallz View Post
          This process would be repeated for each zoom level, with objects being resized, repositioned or removed/added entirely depending on need, if you get what i mean. A problem with this would be calculating positions and distances for game mechanic purposes, though this could be solved with a 'database' like approach where those values would not be determined by visual positions but values in a seperate file, if that makes sense.

          Another issue you'll encounter is managing large amounts of data/entities in script, which is slower than native C++. You could fake a lot of this with procedural and deterministic algorithms. But that's another can of worms that I could ramble on forever about it...

          Comment


            #6
            Well, the scale issue is something i'd have to work with regardless of engine, so the approach to 'fix it' would have to be applied to whatever i'd work with.

            Maybe i can actually just get away with making objects pretty small, as i don't have to emulate the exact astronomical distances, it just has to be immersive enough (it's a strategy concept, not a spacefighter/explorer after all). This would eliminate the problem of scale at least? Up to the point where i can get objects small enough for them to look good (think: zooming up to a planet so it fills roughly 30% of the screen). Zooming /down to the surface/ would actually be done with a transition of some kind into a 'normal' sized map (can this be done by streaming, possibly?).

            The data/script thing still worries me though, but that's something i'd have to do regardless of engine anyway again. Depends on the amount of data i can reasonably get away with.

            Comment

            Working...
            X