I’ve made more progress in sealing up road connections, adding more variety and, most of all, creating 4-lane roads! I’ve still got to work on seeding out the highway before the map is built, so we have a big thoroughfare in there. Pretty soon I should be far enough to start getting Fog of War back in (which was ditched when I made the move from 2D to 3D back in May).
Also, Unity has had some nice sales lately and I stumbled onto this, which I jumped on. At first glance the pack seems to be selling a bunch of muzzle flash VFX and so on, but it also includes this sweet modular turret system which includes a bunch of different weapons that can be separated from their turret bases. How cool is that?
I was starting to make plans towards learning some basic 3D modeling so that I could make weapons like this… typically they are attached to the side of a vehicle or something.
In my case I want the player to be able to see the weapons in their inventory, and then place them out on a grid. So, while I will still need to find or create some of the more unusual models (what does a smoke screen sprayer look like?), I can get pretty far with these guys.
I managed to carve a good chunk of time working on city generation over the 4-day Thanksgiving, but I wish I were done. My core accomplishments was in creating single-wide alleys, more crafted patches for both 2-lane and alley roads, and most importantly: Allowing patches to be rotated when placed.
This allows me to create more variety, not just because things look different when rotated, but also because I can spend my time on crafting unique areas without having the create four direction rotations of them. It’s getting there…
The biggest problems beyond variety is playability. The most interesting maps should have some interesting tactical spaces, and more importantly enough loops that give the players a better sense of exploration as well as not punishing them as much for getting some speed going (which dead ends can completely wreck). Typical Roguelikes (Dungeonmans included) introduce at least a few loops so that exploring the map doesn’t force endless backtracking.
A whole bunch more work is needed, including:
Make additional large patches with interesting tactical features such as open areas, wide runways and so on. This will help keep the game from just being a bunch of corridors.
Create an evenlarger 4-lane road type and seed the map with a couple of large roads. This should present some neat places to build up some speed.
Checking patches before they are laid down to make sure that they are not blocking off an adjacent road (this leads to a series of roads that lead to nowhere).
When the map has been expanded as far as it can be (usually a set value, such as 1000 attempts at placing a patch), make sure that all the “unexplored” road tiles are capped with dead ends or are connected up to their neighbors. (Again, this avoids road connections that terminate abruptly.
Add some “overlay” rules and tagging that allows for “optional” entrances into a block. This way if I try to lay down a block next to another block, I can more easily “bust a hole” between the blocks as needed. This will be huge for generating loops.
Create a few rules to evaluate a “good” map, including if there is enough space to explore and that there are areas suitably deep in the city where boss areas can be placed… and if those criteria are not met, throw the whole map out and start over.
I basically need to take this as far as needed until it’s fun, and then step away from it and worry about making it perfect later. Something like this could take all of my time for many months if I let it. Over time I’ll try to add new models, streetlights, textures, buildings and so on, but I need to work towards something I can play again.
Once the map generates well (hopefully in another week), I’ll need to properly populate it with encounters, and create a boss area fairly far from the entrance that players need to play towards. Once I’ve got that I’ll be back to having a game loop and can push to sharing a build out. That’s something I really want to get done before the holidays.
Another big gap between the last update and this one. Part of it was a good thing (two-week vacation to Japan) and part of it was a bad thing (two weeks of airport-spawned sickness after going to Japan). Then for the last month I continued to purge that damn technical debt.
It turns out there were a lot of things that the game generated (including things I wrote this summer when creating the overworld) that was mired in sub-awesome way of storing things. I can’t say things are perfect now, but my Perforce tree is starting to fill up with all the datafiles I can now create, search and copy to my heart’s content.
The datafile system (again, inspired by the one used in Dungeonmans) allows me to use tables to reference other tables, as well as arbitraily roll dice for whatever I want. I still have entities to squeeze into the system but I think everything else is in a pretty good state. Now I just have to train Notepad++ to parse them just a hair better and I’ll be in a great place for editing.
One thing I won’t be converting into text files is the Patch System I wrote for my initial attempt to create cities. I wrote that system to integrate well into the entity editor, and I can drop in a bunch of tiles into an object and then drag the object right into an info panel to bake it out. I’m not great at tools but I’m pretty happy with that one. I’ve only just started to fill out variety with it but I think it can produce some really crafted setpieces in the midst of the pile of procgen that a Roguelike generally has.
Coming back to working on the generation of a quality city, I decided to double down on the value of Patches and try a generation system that capitalizes on it. We colloquially call it the “Crown Royal bag” method, once again inspired by Dungeonmans (Jim mentioned in his talk at last year’s international Roguelike conference). It was actually first written about by Mike Anderson on RogueBasin. The idea is to keep a list of all your legal walls that can hold doors in a list and draw randomly. Pick one of those walls and consider busting a door into the side. Then pull a precrafted “room” from your virtual Crown Royal bag at random and see if it fits onto that particular doorway. If it doesn’t fit, throw it out and start over. For hundreds of draws you might only place 40-50.
There are number of issues using this for a city. First of all, as you can see here, my tiles are created with entrances and exits built in… I had to create an entrance and exit tagging system to figure out what tiles were valid connections to each exit. That wasn’t too hard luckily, although I have to create connections now for single-lane roads and just plain asphalt and dirt, which are more interesting alleys and short cuts than the core big, two-lane roads.
Second, the technique basically creates a tree rather than a nice, playable dungeon with loops. I’ve got a ton of ugly dead ends and roads that lead up to other roads but don’t connect. It’s important for the proper feel that intersections look right and create nice setpieces with crosswalks and driveways and stop signs and such. To accommodate this I need a more sophisticated system, in particular a way to overlay roads onto other roads and have them convert to intersections. That actually means that I’d be heading into creating a road link system instead of relying on handcrafted patches, but I think I can integrate some smart tagging on my tiles to handle this.
The battle continues… Trust it’ll look better soon.
Yes, Technical Debt is still rearing its ugly head. One of the things that any procedurally-generated Roguelike has is a ton of different files that hold profiles that define how to generate cities, landscapes and enemy encounters. And tables, so many randomized tables!
During the 7DRL I found an expedient solution that worked for the challenge and a fair amount of time afterwards. I baked data right into each Unity scene that I saved out, imagining that I could just make a scene for each type of scenario or terrain profile I wanted. I could bake in components that had all the predefined information I needed and just load them as needed. I could even drag-n-drop the appropriate prefabs for everything I wanted to spawn. How simple. Sure, it nagged at me that it wasn’t super extensible, but scenes were cheap to make and I was interested in how far it could get me.
Wellll, it turned out it was pretty far, but eventually it started to haunt me. The more scenes there were, the harder they all were to maintain, even if all the common information was kept in Unity prefabs. Oh god, the prefabs… they are great sometimes, but they also can puke all over themselves if I moved files around or a metafile got invalidated somehow. Also, any time I wanted to choose something randomly, it felt like I was writing new code to deal with it each time.
I also used the serializer for a number of structures, but there was always a desire to have more flexibility when reading data.
Anyway, I knew I needed to up my datafile game. My friend Jim’s amazing RL Dungeonmans has something like 500+ datafiles holding anything from name generation to encounters to tile definitions, with weighted randomization tables and tables that reference other tables. How slick! He spent many years refining his data methods and he encouraged us to reuse his approach in our own games.
So last weekend I finally bit the bullet and built a datafile system around some of the same concepts and in the end my format is virtually the same as Dmans. This way I can build a sector with a pretty flexible format:
And these tables have some handy reference capabilities (recursing through each table referenced) and weighting for randomized results:
"The [t1] of [t2]" 10
"The [t3] [t1]" 10
"The [t1] of [t3] [t2]" 10
…and bingo, my world generation becomes 10x more flexible and powerful. I’m dyin’ to get back to the drive-shoot stuff, but this was so worth it.
The Unity Asset Store is a great temptation at all times, cleverly one click from my development environment. When you’re stuck in the dregs of some less-than-glamorous code snarl, it becomes the devil. An Asset Store 24-hour sale are basically late-night Ronco TV ads for game developers. Just 10 bucks for the next 2 days! 30% off! But hey, this might be just the thing your game needs to be awesome…
Recently I bought a Volumetric Clouds package, hoping that I could get some cool, turbulent cloud cover with shadows over my landscape as the player wanders around. Looks pretty good, but my poor frame rate just couldn’t handle it, especially at high resolutions.
The solution involves a sweet technique of rendering many layers of a noise texture so it piles into a volumetric shape. It seems to run pretty well for ground scenes looking up at the sky, but for my particular situation it didn’t quite fit. Maybe I can’t use it for Auto Fire, but it’s a clever enough solution that looks great in a lot of cases, so I don’t feel too bad supporting the creator.
I don’t want to obscure the map features anyway, so just shadows would probably do the trick. I might be able to do an extremely cheap version of the shadows with some some screen space projection instead… but there are a hundred other things to do first.
I stumbled on another Unity sale recently that dangled a plugin called Beautify in front of me. “Add a pro look! Punch up your colors! See the detail!” I couldn’t help but bite, because I’m always wondering what I can do to eliminate the muddiness that I sometimes get with Unity, especially when I shrink assets that are intended to be experienced at realistic sizes.
A good chunk of what Beautify does is apply a sharpen post-process, along with some LUT’s to enhance some coloring. I must admit there’s an appeal to seeing those shrunken assets appear sharper against the terrain or ground surfaces. (You’ll probably have to click to see the difference).
It punches everything up and everything gets a nice feel in comparison. However, it uses a sharpen filter, so I have to balance its use versus all the work built-in antialiasing does. So, while it helps eliminate some of the muddy appearance (something I equate with unpolished products), it adds a lot of shimmer and harsh pixels (something I equate with unpolished engines). In the end I probably just need some lighting help from a real artist. 🙂
Anyway, I can turn down the sharpen or nix it if I want, which is good because I like the results Beautify gives me with color. It’s also got sweet bonus night vision and thermal views.
Nonetheless, I’m still looking for the right combination of lighting and filters to attain the pro look I’m after. The quest continues… and my wallet fears the night.
I’ve had some pretty great results so far with generating my terrain and dynamically placing road decals as needed. The Easy Decal 3D solution ended up being pretty great. The folk at &u Assets were super-helpful, and with clever use of their baking and decal combine features my roads went from 20 fps to 200 fps. So, basically solved, and it’s worked out pretty well for putting interesting terrain features when staring down at splat-mapped Unity terrain starts to get tiresome.
I feel pretty good about the look and feel of my overworld, as well as the scale (which was a concern since it’s extremely exaggerated, even though I wanted a gritty feel). I still have a ways to go before I can finish up my core loop and release a build, but things have leveled up a fair amount.
I know it’s been a while since I’ve updated, but there hasn’t been a lot going on that’s particularly showable. My Perforce checkins show that in the past few months I have…
Used a landscape generation tool called Gaia to generate custom baked landscapes that I can use for specific locales or pre-constructed sections of the overworld.
Created a home base area for the player to start in.
Project movement grid information on the ground to help navigate some areas. I’ll still work on making sure that they are clearly traversable.
Added characters from Fuse in there, using some of the pretty good tools to grab some animations and basic clothing setups.
Enlisted the help of my wife Sandra to help get some characters together! Nice being able to construct characters as easily as you would in a game like Skyrim. And so far it’s free (knock on wood).
I’m still considering how I want to show characters in general. I liked having them when I had a 2D game because it was easy to see what everybody was, but by going 3D I’m going to have some trouble with parseability. I’m already scaling things up larger-than-life, but even more might be needed for humans.
Got together some basic quest granting, as well as a main stats screen for players to track the quests they’re on.
I also realized that I probably didn’t want a traditional quest system… I’m not out to make Wasteland 3 or anything. So, I’ve got the system but I’ll be working on evolving it to work even better with generated content.
Started thinking harder about the overworld experience. There’s a lot of back and forth that happened here… very briefly I thought about creating only one overworld zone and generating only content within. However, performance considerations, as well as the interesting gameplay that can happen in the overworld, I decided to break it into sectors that include both generated and prebuilt areas.
Started to move towards the exaggerated scale I want to hit with chunky buildings and roads, but areas on the map with interesting states to deal with.
Experimented with a number of ways to put roads on a generated terrain mesh, and so far have settled on Easy Decal 3D, which is a bit quirky but that’s pretty standard with Unity asset bundles. I think it has a good set of features and make it run performant, if I can just work around some of the funky bits.
I’m hoping this approach will work. It is the most dynamic, and would hold up best for generated terrain, but it’s also eaten a good chunk out of my frame rate and needs optimization.
This is all on top of investigation, data loading/saving, performance, and other things. Hmm. So yeah, I guess I was actually pretty busy over July. Still hoping to get back to working on city combat stuff soon.
This past week I’ve been polishing a new feature for procedural generation, patches. This allows me to hand-create a collection of assets (both single-tile and multi-tile) that gets placed down in a singular area by the terrain/city generator. It can be a solid square or only fill some of the squares within. I can import any patch by dragging in a group of objects from a sample scene. The tile system already converts the patches into the tileset currently in use by that map, and mixes in variants as they are available to the tileset.
The patch system has a lot of additional features yet to do. For example, allowing the definition of patches in a nine-slice style where I can scale them to an arbitrary size with consistent edges. This would allow me to create arbitrary-sized plazas, but more importantly, I can create a road patch that has signs, lights and various elements on it, that scales according to the length (and width if desired) of the road.
I also want to put in randomized prop points: object stubs that will randomly place a specific prop in that spot, anything from a trashcan to a stain to an ambient effect. It also allows me to place variants of an existing entity, such as a destroyed version. This will be important so that my generated city doesn’t look all pristine the way it does above.
I didn’t expect to get dragged into city decor so early in AutoFire’s development. It’s certainly a topic of interest to me, but the push in that direction really came from trying to find props for the game. My 7DRL city was fine, it was basically a dungeon. A dungeon can be a twisty maze of passages and hallways don’t necessarily need a specific direction of travel defined. However, it felt like 90% of modern-day props required placement with some thought… You can’t just sprinkle in mailboxes, street lights and stop signs via Random.Range(0, size)… There needs to be established clusters and strips of materials. I can construct hand-built areas anyway, but to extend everything into procedural town I’m pushing the limit of my limited home-grown tools.
Rolling from all this, I’ve also discovered as my game’s scale gets better established that I’m reaching a point where my single-square building assets are looking weirder and weirder… I want the cars to be big and bold, and characters in the world to be larger than life also, but right now they are about two stories tall. I was okay with something more abstract and representational when I was in 2D, but working in 3D makes that scale a bit more important. Aaaaaand the only way to get my building “walls” closer to the “correct” size is to come up with a system for merging building squares into larger structures. That will take a whole new post-process that… I’m going to wait on.
I’m quite aware that I’m running the risk of entering a bottomless pit of effort… Making a city look like a city is hard, and many games make that their only thing, whereas I have
so much more to do. So, I’m going to finish up this patch functionality and pull back to environments that are a bit easier to generate, such as frontiers, shanty towns, junkyards, and so on. This way I can push back into mission generation and create some assassination missions and encounters. This will finally lead me back to the promised land: the refinement of driving mechanics, combat and its associated UI.