Hello everyone,
Last year I started working on an ARPG item generation framework. I finished, but I felt that, ultimately, it wasn’t good enough to release (let alone ask money for). Taking what I learned I started again from scratch a few months ago, now with a much better implementation. I also decided to break the project up into a few different assets that would work together, but would be useful and powerful on their own.
A little while ago I released Selectionator, the weighted selection engine that will eventually be the RNG heart of the system, but is a useful asset for anyone that needs weighted random selections.
After that, I started working on a procedural item model generator. As I’ve been working on it, it’s expanded into a full-on procedural content generator. It integrates nicely into Unity’s component system, and can be dropped into existing projects really easily, or can support new projects from the ground up. I’ve been calling it Smithy and I think that’s the name I’m going to stick with.
It’s a bit involved, but to the end user there’s really not a lot to fiddle with (unless you want to, then there’s a bunch). Most of it happens in an adapter component:
(there has been basically no UI work done so far, so I apologize for how rough this looks, for now at least)
You throw it on a GameObject and drop it into edit mode. From here, you can define any number of nodes - plugs (fit into sockets) and sockets (accept nodes).
You then tag these nodes with any keywords that might be useful. “Branch”, “Gun Barrel”, “Arm”, “Hilt”, etc. You add any number of tags, and overlap node tags on the same object. On generation, nodes find keyword matches from your assets (or AssetDatabases, if provided) to connect to.
(You can see some of the first steps towards a not-godawful UI here)
If your GameObject has a mesh, it’ll let you snap nodes to points on the geometry (vertices, triangle centroids, edge midpoints, and also at a mouse position raycast)
These nodes have a fixed position relative to the object, and a facing direction (this is the angle it connects to something, or has something connect to it), as well as a percentage chance that the node will be filled (in the case of sockets) or selected (in the case of plugs) on generation.
There are a few options that allow for precise and quick adjustment, like movement snapping and connection angle overrides (default connections are set to the normal of the mesh they’re attached to, or world.up for objects without a mesh)
There are also jitter options. These will shift position, rotation, and scale on generation. This helps especially in making organic and greebly stuff look hand-made:
(size jitter only)
Nodes also have some QOL stuff built in - they can be arranged into layers that can be mass-adjusted. You can sort nodes into layers and set all their tags, weights, alignments, etc. all at once. Nodes and node layers can also be selectively hidden, and color and opacity options are in the works.
Nodes can also have a weighted list of materials, and on generation will choose and take (or push to their child):
The final node feature - and something I think is especially useful - is the inclusion of procedural materials. This was the last feature to get implemented, and so far it’s working pretty well.
Procedural materials consist of combinations of ShaderProperties and selection probabilities, and then choose from these combinations to fill out a newly-instanced material:
These nine spheres are all referencing a single procedural material asset, which holds a few texture and glossiness options.
Objects can be generated in-editor for testing, or for saving out to a unique own prefab. Nodes can be manually linked up or generated on the spot (single nodes or for the whole object). The greeble demonstration gif above is being generated and re-generated inside the editor. Generations here can also be saved into their own prefabs.
One of the more useful aspects of the editor assembler is that it’ll take and spit out seeds. You can feed this to the generator at any point so you can generate the exact same object under any conditions. Multiplayer games, for instance, can ensure the same item drops for all players by transmitting the seed.
Realtime generation happens through a factory class that can take parameters to further tweak the object that’s generated. There’s also a preloader script that can be dropped on objects already in the hierarchy to allow them to generate child hierarchies on Start(), which is useful for environmental/decorative stuff.
So I think it’s pretty evident that this could be a nice resource for designers, artists, and teams with limited art budgets. What’s really exciting to me, though, is that because this system just bolts on to GameObjects, there’s nothing to stop you from throwing logic nodes in.
One of the included demos that I’m working on is a simple FPS shooting range with randomly generated guns (like Borderlands). I tried a little proof of concept test and I was able to knock out a pretty robust weapon generator from scratch in a single morning. You could use this for pretty much anything though.
Anyway, it’s basically done and working now, but it’s still pretty rough around the edges. Here are my plans going forward:
-
Styling / QOL
This asset is pretty much feature complete for release one, but it’s still clunky in some parts and not at all user-friendly. I still need to do a first-pass refactor and optimization. I also need to make sure that the system is intuitive and easy to use, and it needs to look nice. I want to knock out at least a few more demos to do this, so I really start to get a feel for how it might be used in different pipelines, and what parts of the system need to be immediately at-hand. -
Read-only Asset and Bake To Read-Only (post-release?)
Asset artists should be able to use this as a resource to extend their work, and hopefully revitalize previously-released assets. I want asset artists to be able to incorporate Smithy, and release to every Asset Store consumer (not just my customers). I think what’s going to happen is that I’ll have a different release edition target specifically towards asset artists. This edition will be able to “bake” the Smithy adapter to a read-only version suitable for export.
Unity users who get these assets can also download a free, read-only version of Smithy. They’ll be able to instantiate the artist’s assets, but not modify node structures. -
Runtime Node Editor API (post-release?)
One of the things I think would be really useful is the addition of an API for node management at runtime, so developers could turn the tools towards their players. You’d be able to implement build-your-own systems (like Loadout or Scraps or Blacklight) really easily. This might involve rewriting some of serialization stuff, definitely a lot of extension and friendlier method writing, and absolutely require high-quality documentation, speaking of… -
Support is a huge thing for me, and especially when it comes to Unity assets: I’ve bought my share of poorly-documented stuff with no support to speak of. I am committed to being available to resolve issues as quickly as possible - but - I am a firm believer in ease of use and excellent documentation being better than the quickest support. I want to make sure the system is intuitive enough to not really need the docs, but having really thorough ones anyway. Walkthroughs, tutorials, and examples are going to be included as well.
Demos &c:
I have a little lowpoly tree generator that takes these meshes:
and does this:
I have this as a standalone demo for Windows, (available here if you want it, run it windowed) and I had wanted to get it out as a WebGL demo, but WebGL keeps acting up. I’ll hammer that out soon.
Still early for demos, but I’ll post them here as they happen. WIP stuff will be posted here or @evilwizards
I’ll keep adding to this thread as I work on the project (and answer any questions that might come up). I’m also at @evilwizards on twitter if you want to ask questions there (or do me a solid and retweet something!)
Date and price are still being worked out.
