Agrul's Procedural Dungeon / Creature Creators

Discussion in 'TZT GameDev' started by Agrul, Jul 4, 2014.

  1. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    Separating this from the general voxel thread, tired of scrolling past the links to other peoples' voxel engines. Current links:

    VoxelDungeon_OSX_with_BasicSwimming

    (randomly generated cave-dungeon, 10000-"rooms" large)

    (11/11/2014)

    Creature Creator (v. Basic Motion) Webplayer
    (just creates randomized torso and legs right now, gonna work on IK and procedural locomotion next)

    Recent Changes: added basic (though still ugly looking) motion to the creature creator, made the critters in it small (hides some of the ugliness in the movement, heh).
     
  2. Chemosh

    Chemosh TZT Addict

    Post Count:
    4,349
    Sounds fun
     
  3. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    Thanks pal. I actually have bones and basic bone-weighting of vertices in, but am trying to decide how to proceed from there. Right now I have the most straightforward 'mob chases you' system set up, but I am not sure I like it. And its legs don't move.
     
  4. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    Updated OP.
     
  5. Chemosh

    Chemosh TZT Addict

    Post Count:
    4,349
    This looks really fun. I mean like really fun. Expecially if you scaled this down a bit or something and made it so we could all play, had a few weapons laying around and could beat each other up. I'd like to see some random torches around to help with lighting as it's hard to see, but I think that's what makes part of it that creepy not sure what's coming up feeling
     
  6. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    Thanks dude, creepy is definitely what I was going for. Scaling it down is really easy; it's designed so I can specify the dimensions of the level, and the number of chunks that compose it, as well as the dimensions of the individual chunks (though not the voxels---they're fixed at unit by unit by unit cubes).

    I was planning to add some extra light sources for sure, once I get to populating the dungeon; been trying to get the creature creator to a point where I'm happy prototyping with it first, so that I can infest the dungeon with weird procedurally generated critters. My dissertation defense is coming up in like a month, though, and I owe my committee most of the doc's for that in ~2 weeks-ish, so I've been pretty tied up with that. As a result the creature creator modification has proceeded pretty slowly.

    I hadn't thought about throwing some trolls in it and some Photon code for multiplayer, but once things settle down here maybe I'll do that as a side project. My primary goal for this right now is to get it really rolling as a single-player first-person RPG-ish thing, but I'd definitely like to get multiplayer rolling with it too.
     
  7. Chemosh

    Chemosh TZT Addict

    Post Count:
    4,349
    Yeah like Diablo fps. Beat a dungeon crawl to the next. Have a town with your items
     
  8. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    That's kind of the atmosphere I want, exactly! In terms of mechanics, though, I want it to be a lot more open-ended and flexible than the Diablo series; the world will be heavily malleable (e.g. players can alter the terrain with spells/axes/shovels/etc), the spell system will feature effectively infinite variety and emphasize the player learning about the possibilities by experimenting with different combinations of materials and types of magic, the creatures will be largely procedurally generated, and physical combat will be both based on hit-boxes (so that you can chop off or lose various, particular parts of your body, and this will have ramifications for your/enemies' combat abilities) and on real-time interactions between different moves (e.g. if you block high but they swing low, you'll get hit).

    That's the plan, anyway.
     
  9. Chemosh

    Chemosh TZT Addict

    Post Count:
    4,349
    Let me know how I can help
     
  10. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    if you wanted to help with the procedural stuff, the basic code snippet around which i've built most of the current project is this scrawk blog project: http://scrawkblog.com/2013/05/05/simple-voxel-terrain-generator/ . if you can play with that and understand how it works (you'd also need to look up the MarchingCubes algorithm and read about it), that should be enough of a basis for helping build some more procedural stuff. a key issue i'd like to start working on implementing is 'infinite' terrain, which requires saving the currently visibile dungeon layout to a file and, whenever we're in danger of leaving the visible dungeon area, unloading unnecessary bits of the dungeon and loading in data for new parts of it. from what i've seen elsewhere i think this will require significant use of multithreading for it not to slow the game down a lot

    if you'd rather work on something else --- hmm. i could use decorations for the dungeon, like torches and chests and shit; i'm not sure if it would be better to directly model those in blender and instantiate them as prefabs in unity, or if it would be more efficient to procedurally render them, too. i think maybe prefabs would be workable, so long as some kind of basic culling occlusion can be used to stop them from generating lots of draw calls/triangles on screen at once

    there are some other things i'd like to explore, like how to procedurally generate interesting, novel textures from combinations of preexisting textures, the details of interactions between different kinds of magic, monster AI, and architecting a general plot and overarching geography for the world etc etc, but they're not really immediate concerns

    i'm hoping this project'll eventually be good enough to sell for $5 or $10 a pop. dunno if it'll ever get to that point, but that's part of the end game
     
  11. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    Getting back into this. Haven't updated the thread link, but I added some water to the dungeon generator and fixed a few errors I apparently never caught before. Generates all manner of weird cave systems now, pretty happy w/ it.

    Also did a little work figuring out how to get Unity to call chatbots created in an external Python script. Chatbot dreams r a go.
     
  12. Sear

    Sear TZT Neckbeard Lord

    Post Count:
    34,655
    lmk if you upload it to web again

    forgive my tangential engineer barf in ur thread here, but I've actually wanted someplace to ramble about my challenges with procedural generation

    My game will not utilize true procedural generation, but a more controlled and restricted method. The worlds are composed of interconnected screens (like a Zelda dungeon room except not top-down perspective). Elements inside them are only somewhat random (enemies, some platforms, some props and art, etc) within specific constraints (e.g., spawn 2-4 enemies here from a pool of 5 different enemy types based on some rarity %). I've already done a lot of that.

    I could piece together these screens and call it done, but I want this level to be partially procedurally generated too. Which is going to be harder. If a given screen has 3 different exit paths (say top left and right), my algorithm needs to not only know this and add the necessary screens, but also make sure these conditions are met:

    • New screens can't overlap previous ones (e.g., an L-shaped screen on a left sided exit).
    • New screens need to properly dead-end after there are enough of them populating the world (if there's 50 already in a given world and I want no more than 55, then any remaining exit paths need to tie off into screens with no additional paths).
    • Art/tileset conditions should be checked at some point (e.g., I have a castle but want 50% of it to be dark dungeon tile and 50% to be gothic interior)
    • World conditions should be checked at some point (e.g., I want at least 2 miniboss rooms, a secret room, and a boss room in every world).

    So that's a lot of shit, but I'm pretty sure I can figure that out + am actually kinda looking forward to coding it.

    Beyond that, though, what's really giving me hell is nailing down the architecture. I will most likely make the individual screens prefabs. I'll be able to conveniently edit some of it within Unity that way, too. I don't think I can prefab the worlds though and it doesn't really make sense to nest it that way. So this will have to be done 100% via script. I dislike Unity's multiple scene architecture, but I may use scenes for each world. I'm not sure how I'm going to handle screen population from a performance standpoint. The easy method is to populate my worlds upon load and then crutch on Unity's occlusion rendering. Potential problem with this is if I have a world that's 50 screens big, even if they are inactive and not eating up active threads, they are still stored in the memory. Since I'm making a 2.5D game with relatively modest demands, this may not even be an issue even on low-end PC hardware, but I don't know this for sure. I guess I can't know until I actually test out a full world and look at the memory footprint.
     
  13. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    i've been wanting to re-upload for a few days now, but can't because my main pc (which is where i have unity and all my unity projects) has been running a computation-bound algorithm on its GPU for me for the past few days, and everything else on it runs slow as molasses while it's doing that. was hoping i could offload some of that work to the laptop but i keep getting a weird error from the laptop's GPU that the desktop's GPU doesn't complain about and i despite a bunch of hours of beating at it still have no idea what the issue is, so i think i'm stuck just waiting to get my desktop back. pretty sure even opening unity would take 10+ minutes. ;o/ will probably be able to re-upload sometime this weekend though, and implement swimming just before i do, hopefully

    i like engineering barf in my threads, vomit away pal. i shall do the same, helps me get reinvigorated about all of this. right now i'm trying to learn more about writing my own shaders and about unity's syntax for accessing vertex-level data from scripts, to kind of round out the knowledge base i need for the various procedural projects i'm trying to finish and bring together

    my current approach to procedural generation relies heavily on the translation the scrawk's blog guy did of the standard marching cubes algorithm to unity. i'm really not using it as well as i could be right now, either, in the sense that the surface my world is constituted of is a tad 'blocky' in appearance (though still nothing like minecraft; sinuous pillars appear in my caves quite frequently, oddly shaped stalagmites/tites, etc), but if you generate the underlying surface that marching cubes is approximating in suitably smooth way, the resulting landscapes can be very smooth (as in scrawk's original demo code, which builds a small world of smooth sand dunes and warped, largely non-intersecting passages into them). my code generates its cave system by A) separating the world into a finite number of cubic chunks, B) assuming the world is 'filled' with rock, C) choosing a chunk to start with & emptying it of rock, then randomly picking one its adjacent chunks to empty and continue the process. eventually D) the random walk tries to go outside the finite size i've allowed the dungeon-world to occupy, and the process randomly chooses a room to begin another 'emptying' random-walk in. this ensures that the dungeon is fully connected, and tends to generate a cool, kind've chaotic intertwining-passages feeling; the process terminates when a preset number of 'empty chunks' have been hollowed out to form the dungeon. a post-processing run then goes back over all the empty chunks and 'fills in' random spots on the floor and ceiling to give the dungeon some rough, rocky variation in the form of stalagtites/mites

    there are a minor-major extensions i'm planning to pursue eventually:

    - boundless world (requires saving dungeon chunk info into external file and loading / unloading chunks from the renderer at run-time; i think this may also have to be done on the GPU -- through shaders -- for it not to lag a lot)

    - allowing the random walk to proceed in an arbitrary direction (i.e., randomly pick a point along a sphere and move in that direction for a prespecified distance, then randomly pick a new direction and do the same, etc), and to smoothly hollow out the rock around it within a smoothly-but-randomly varying radius around the passage's current direction of hollowing. this should fully correct the 'blocky' problem

    - voxel water. right now i've got normal, unity prefab water, and a really simple shader/transparent quad trick to simulate that you're underwater, but because it's a single prefab and not voxelized, simulating water flow between uneven passages and allowing the player to alter the water's volume and shape with magic are out of the question. i'd like to eventually fix this by voxelizing much / all of my water sources; i know it's possible to do, as i've seen a few examples of it (and have a copy of several GPU Gems chapters that discuss simulations of this kind in a little detail---they're a great resource), but because it involves voxel computations over time, i'm pretty sure it's going to be very challenging to implement it without slowing stuff way the fuck down

    for now though i'm just hitting low-hanging fruit - like the prefab water - to make the cave system more interesting. will probably install a simple level changing device soon that transports you from one cave dungeon to a new procedurally generated one, and start adding some basic artifacts, items, light sources, stationary critters and the like to the caves.

    once the caves have a reasonable amount of stuff in them to observe, comment on, and discuss, i want to try using some of the chatbot stuff (using nltk and pyStatparser mostly, which is why i needed to figure out how to call external python files from inside unity) i've been working with to create an NPC(s) (probably without a model at first---just like a floating sphere or something) that wanders around on its own and views/hears/smells/touches whatever it runs into, then incorporates that into its knowledge bank for discussion whenever the PC talks to the NPC. unfortunately there are licensing restrictions on commercial use of the syntax-tree libraries used to train the currently available statistical parsers that're used for generating/identifying the syntactic structure (id'ing sentence subjects, prepositional phrases, blah blah) of english sentences, including pyStatParser, so this could never be for commercial use without a ton of re-making of the wheel or settling for a much less satisfactory chatbot, but it will be cool to even just see how well i can do while taking advantage of these commercially restricted chatbots. the primary challenge will be building another grammar of my own for representing knowledge about the game world, i think, since as far as i can tell there aren't (m)any commonly used semantic grammars of this kind made freely available. i guess probably that's because the way you want to represent knowledge varies so dramatically depending on the application, and encoding a single grammar to encompass 'all' knowledge in a domain-independent way is harder than people are currently aiming for. anyway it will be really cool to see if this works even a little bit for making NPCs more interesting to interact with

    i've also got a few other projects i need to incorporate into the dungeon. my creature creator is semi-functional but the creatures look really dumb and are still not very free-form; it mostly makes a bunch of different kinds of multi-legged spiders with a centralized torso and no head. it procedurally animates them to follow the player, too, but the procedural motion needs a ton of work, the bugs run in kind've weird patterns right now, and their legs don't move very naturally. i can at least use it to get random bug models that just sit there for now, though

    the other two projects i need to incorporate are:

    - my world-modification project. i've got a modified version of scrawk's sand dunes world where the player can create or destroy terrain around them with a click, and can use this to, e.g., build columns or stairs up to higher levels in the world. this one should actually be pretty easy to incorporate into the current cave generator, so i'm excited to connect them together soon

    - my magic system project, which is still very much in its infancy, but at least has the first bit working: you click on nearby textured objects (or voxels) and 'drain' the texture from them to refill your mana with that texture, then recombine textures to create other textures, with each texture having unique magic properties. only the 'draining' part works right now, but it should be easy to hook that up to the world-modification system, so that you have a finite amount of 'earth' mana to spend in modifying the caves system, and have to restore your mana by sucking up more from nearby earth

    those last two systems are also a big part of why i'd eventually like to have voxelized water; right now the terrain-modification system won't work on water 'coz it's all one big prefab, while it's designed to work on voxel-objects created from and modifiable by the marching cubes algorithm
     
  14. Yogr

    Yogr Meatball Sub Pro

    Post Count:
    1,214
    If you know the exits of each screen, could you not buffer only the immediate exits?

    Alternatively, if the screens could be built with shared assets (particularly the assets which would take up the bulk of loading time), then you would only need to load the non-shared stuff to build each room which may be instant even on weak processors.

    Ahh, that precious balance between memory and speed.

    I'm not an expert on procedural generation, but what if you saved the seeds used to generate each chunk instead of the chunk data itself? This would save on memory but increase run-time processing.

    I dunno, I guess this all depends on complexity and size of the save data vs. complexity of generation algorithm at run-time. What do you think?
     
  15. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    that'd certainly work, yah. it's hard to know which side i need to trade-off against without actually giving it a shot, though, and i'm kind've putting that part of the project off a bit. for now i'm just lazily tying levels together through level-loading screens to keep things simple.

    working out the swimming code now, turns out my laptop actually can handle unity just fine, although it forces me to edit code in something other than Monodevelop
     
  16. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    Tinkering with the character motor scripts is takin' me quite a bit, hah. Guess that's what I get for mod'ing Unity's fancy pre-written ones instead of writing my own.

    Still, got basic water working, although it's tough as shit to get onto land, and the 'tranparent quad' technique for simulating water has a lot of visual drawbacks (though I think a lot of them can be ameliorated with further work):

    VoxelDungeon_OSX_with_BasicSwimming

    Will take a while to load; 10000 rooms, 30 x 30 x 20 chunks map.

    Next time I mess with it, think I might make the character do a small jump as he exits the water so that small ledges can be leapt onto. Right now gravity reactivates and your jumping is disabled so it keeps trying to drown you.

    Also gonna add the first talking, mobile sphere next, and some artifacts for it to talk about.
     
  17. Yogr

    Yogr Meatball Sub Pro

    Post Count:
    1,214
    So, you're at like Everquest circa 2000 swimming code?

    You have gotten better at Swimming(4)!

    Right now I'm working on a phone app and some algorithm work right now, in lieu of finding artwork or making a pink-box UE4 game.

    I like things that have very little art requirements.

    I plan to make some somewhat frequent updates on my phone app pretty soon. Going Android for first release and then I'll convert all the code into Objective-C for iPhone users.
     
  18. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    haha yeah around that level. I haven't found any great tutorials on writing up swimming code (although the bergzerg tutorial has an example of how to do swimming on the surface of the water; that's not general enough for my purposes, but maybe I should check it out to see if there's anything useful in it), and the Unity pre-supplied script doesn't handle swimming, so I'm just hacking at it until it does what I want. I could write my own movement script from scratch, but the Unity one is really nice for land motion.

    I'm not really all that worried about polish though, EQ1 movement would really be fine for me. I just want the basics of player motion in place so that I can do the stuff I'm really interested in around it
     
  19. Yogr

    Yogr Meatball Sub Pro

    Post Count:
    1,214
    I've never written swimming code either.

    and I don't know how much control you have over your physics engine.

    But you should check out real physics equations like for Terminal velocity (wikipedia always a good resource).

    You can switch out the acceleration force of gravity and replace it with your own acceleration calculations for forward movement, and then figure out the drag coefficient and density for your water.

    Shit usually works really well and is a better way to limit your max/min velocity than trying to set hard limits.

    It's fun to mess with in any case.

    And you can easily throw in other variables like drag coefficient while on ice or in mud if you want to get crazy in the future.
     
  20. Agrul

    Agrul TZT Neckbeard Lord

    Post Count:
    48,117
    implementing a full kinematics-in-water solution is my goal yeah (& i've got a page w/ water's drag coefficient coefficient up on my desktop at home right now, actually). that's essentially what unity does now, but their solution is a great deal more complicated than you'd have hoped at first because it also gracefully handles changes to velocity (magnitude & direction) on slopes, when colliding with angular objects, etc, and has additional code for handling moving platforms