No announcement yet.

UDK Procedural Generation prototype

  • Filter
  • Time
  • Show
Clear All
new posts

    UDK Procedural Generation prototype

    Hey guys, this school project has been sitting on my harddisk for a while now, and I finally got around to making the source code public. I've moved on to other projects by now, but I thought it'd be nice to share some of the UDK scripting I did a while back.

    The game is a top down shooter, where levels are pieced together procedurally at run-time. We pre-made each room separately and assemble them at the start of each level. The game itself is not terribly polish, but may serve as a reference for other people trying to accomplish something similar. The idea was inspired by games like Teleglitch.

    I'm not promising I'll check back frequently on this thread.. this was kinda just a post it and run kinda deal for me.. but I might respond to questions for a while...

    Anyways, thanks for checking this thread out!

    Source code:

    Cool, let us know if you have any pics...

    Did you solve any of the Pathing / Terrain / landscape limitations...?


      Originally posted by frankit View Post
      Cool, let us know if you have any pics...

      Did you solve any of the Pathing / Terrain / landscape limitations...?
      Hm.. we used no landscaping at all. All the levels were based on assets that could be instantiated as InterpActors.
      Pathing was fine though.. used dynamic pylons and the navmesh stuff.

      Here are some screenshots. First few are from the editor, you can see the rooms are completely isolated and modular. They are floating in space...
      Last couple screenshots are in game.. the lighting is not as nice since the level pieces moving around made texture baking impossible/hard?
      Here is a backup of the pictures in case link ever goes down...
      P.S. Sorry for first post attempt without even a screenshot. It was a bit half-hearted.

      The green bar you see in the next photo is just for debugging. It shows the "nodes" of each room, which are the points of connection to nodes of other rooms.


        nice stuff

        you say you made each room separately and then reassembled them. is this using prefabs or just one mesh per room?
        also how did you manage to save the navmesh for the rooms in order to have it spawn with the room later? I tried to do so but failed terribly


          Originally posted by Chosker View Post
          how did you manage to save the navmesh for the rooms in order to have it spawn with the room later? I tried to do so but failed terribly
          Its difficult to tell from the pics how complex the levels were. But I'd be very interested to know about your dynamic pathing solution too. Perhaps you got the NavMeshOstacle actor working? Also, did you use Bots or Crowd Agents?


            @Chosker - Rooms were created using multiple meshes, and each mesh was a separate InterpActor. The InterpActors belonging to a room were all connected (using the Actor base properties...) to the floor of that room, or some other "root" InterpActor. Navmesh was done with dynamic pylons which were connected to the bases of the rooms using Actor basing as well. Generation was then done as normal.. (just build and it works!)

            @frankit - Level complexity was not super high, but a decent amount of detail could be added in with this method. Just imagine trying to create a level with all static meshes, and no landscaping. Once that's done, just change them all into InterpActors at once.
            As for pathing... I really don't recall doing anything too special there... (it's possible that I did something uncommon I suppose.. but I can't recall). The Navmesh code can be found here...

            I believe bots were used, as I did not look into crowd agents.

            Oh, I guess about the pathing.. each room was kind of like an elevator. In the UDK samples there was a level with pathing that worked on a moving platform. My solution was pretty much based on that.


              thanks for the info, but I still don't quite get it
              the pathing done by the AI is easy enough, shouldn't be different from the navmesh pathing tutorials available on the web.

              but we get to the building of the rooms.
              so first question, do you "build" the layout of rooms at runtime or at editor time? I do this myself in the editor (I create prefabs in the editor, then I just spawn them at runtime), however I was never able to put the navmesh information into a prefab (you can save the pylon but the navmesh data gets lost).
              maybe I should've tried dynamic pylons, don't remember if I ever did. I do remember trying to manually create the navmeshes but then there was no way to connect them to a pylon at runtime

              and finally (kinda the same as above),
              Originally posted by canary40 View Post
              Navmesh was done with dynamic pylons which were connected to the bases of the rooms using Actor basing as well. Generation was then done as normal.. (just build and it works!)
              this is the part that eludes me completely. I'm sure you generate the navmesh off pylons at editor time (I'm sure you can't do it at runtime), so how do you save the navmesh?

              I guess it'd be good to backtrack a little. so just to be clear, do you spawn your room meshes, or are they actually just extra levels that you stream in?

              I just tried creating a Prefab with a DynamicPylon. the navmesh seems correctly saved into the Prefab (as opposed to using a regular Pylon). I'll run some tests in the evening, but if I can spawn this by code it will change (improve) many things in my code!


                ok I made some additional tests.
                I made a spawnable class that inherits DynamicPylon (bStatic and bNoDelete set to false) and tried spawning it, using the one in the prefab as Spawn Template (the same way I do with my spawnable static meshes and the like).
                the DynamicPylonSpawnable spawns but sadly it contains no path information. I even tried calling RebuildDynamicEdges() on it but that didn't do anything either.

                I also used a `log to see every actor that was contained in the prefab just in case the navmesh would have been saved as a separate entity from the pylon, but there was nothing more.
                somehow the prefab is able to store the navmesh information inside the pylon, but Spawning a new pylon from code using that pylon as template doesn't make it carry the navmesh over

                it remains a mystery to me how you're doing your navmeshes at runtime


                  The layout is determined at runtime, so each playthrough will produce a different level layout. The rooms are not spawned at run-time, simply moved. That's probably the key you're missing. By moving the rooms, effectively the problem can be solved using the methods listed at this link Just jump down to dynamic pylons..


                    So the levels aren't really procedural in the true sense.. Instead they're closer to a 'moving elevator'....
                    That's why Dynamic-Pylons are sufficient to generate a working Navmesh / pathing solution...
                    In effect, you're shuffling a deck a cards around, re-arranging the furniture, but not creating a 'new' procedural world every-time...
                    Unlike Rama's demo below...



                      yeah that seems to be part I was missing
                      all clear now, and from my latest experiments I'm more convinced that 'new' procedural levels (with varying and random elements) with Navmesh/Pathnodes is impossible in UDK
                      still good job

                      frankit: you seem quite interested in this as well. are you working on such a thing? I made my own dynamic pathfinding implementation, perhaps you're interested in the details?


                        Cheers Chosker! Definitely interested, especially in learning about the approach and the algorithm used. Also, whether it works best in open-worlds or close-quarters mazes.

                        Procedural is hugely interesting, because doing everything statically all of the time just takes too long if you don't have a large team.... There was big interest at E3 over 'No Man's Sky'. If you don't know it, 6 guys from the UK have produced a Triple-A title in record time... It may be hype, but at worst procedural should extend the life of existing work, and help create new worlds in fresh ways. Unfortunately UE4 has little to offer, and UDK nothing. So knowing this, is migrating to UE4 after UDK such as a wise choice? I don't know as Epic don't like fixing bugs... Having access to the source isn't the answer, as I want to make games, not get bogged down in C++ wires and circuits!

                        BTW: Your work is solid. I saw a clip a while back where a pawn with custom collision pushed other pawns out of the way. You've probably moved on a lot since then. But I'm sure people would follow your work if there was a work-in-progress thread like CobultUDK & Obhib have ...



                          I don't mean to hijack this thread, perhaps this talk could be better suited elsewhere.
                          thanks for the positive words, I used to have a thread much like CobaltUDK and Obhib but it didn't spark much interest. plus it's been quite a while that my progress has been mainly from the code side of things, so the updates aren't too interesting except from being technical (also the reason why I don't update my indieDB page)
                          but I could bring it back up and explain a little about my random stuff there

                          having used UE4 only a little but seeing what others do with it I have to say it has quite some to offer.
                          First is that navmeshes get rebuilt at runtime and change dynamically. I was able to prototype maze-solving bots quickly and I had this testcase where one of the walls was blocking everything but had rigidbody phsyics, and once I pushed it out of the way the paths were clear for them. this was a few hours of work vs. the many days I spent in my dynamic pathfinding for UDK.
                          there's also the great advantage that blueprints can actually execute their logic on the editor. with this I've seen some procedural stuff ranging from 'an actor that randomizes its mesh every time you move it in the editor' to 'meshes that adjust their size and shape based on what's below when you move them' and all the way to random building fa├žade generators (much like unfinished ProcBuildings feature of UDK) - all blueprints. personally I look forward to using UE4 for the procedural stuff I might achieve with it