Posted May 20, 2020 by Zed Hanok
#design #proc-gen #random generation
Note: Random generation is just what it sounds like: some things are picked randomly. Procedural generation is a bit more involved: it is programmatically generated content. Even so, the two terms are often used interchangeably.
Okay, I used the last couple weeks to learn JS and make a library of JS code for Conway’s Game of Life, which I’m going to experiment with.
Also, I’ve made a simpler test game in Twine and JS for trying out some sophisticated stuff (space game like FTL but text, it randomly generates planetary systems in the simplest and crudest fashion, has some graphics, manages some stats, almost has a basic combat system…).
Most game development needs to focus on two different projects for now:
Working on the sci-fi Twine game demo (which needs a name! any suggestions?) also can be incorporated into a game jam.
Speaking of the game jam, I have a tried to streamline stuff to make progress on the Sleuth Project (such as picking a game jam that will help, not hinder), but I have a few things that will continue to slow me down:
It is here that I can try procedural generation of dialogue and plot. I will probably just throw in some arbitrary conversations as the ship hails other vessels; I may need some placeholder graphics for the other ship captains. Heck, I need better placeholder graphics for the game, in general. Maybe I can use the Asset Jam to make those and get two things done at once?
This is an important series of experiments. Generating realistic clusters of rooms requires two – probably three – passes of procedural generation. It may simplify things dramatically to not worry about the rooms fitting together right away and just generate a tree where the “rooms” are just HTML tags or JSON.
This is where my Game of Life library comes in handy.
You see, in Conway’s Game of Life, some super-simple cellular automatons live if they have 2-3 living neighbours. Too few and they die of underpopulation; too many and they die of overcrowding. If they have exactly 3 neighbours, they reproduce. This usually occurs with at least one other neighbour also reproducing, and then somebody in the middle of the group dies from overcrowding, splitting the group into two groups, which both grow and split, and so forth. If I “walk” through the groups of “living cells” and build a tree of the clusters, I can convert each living cell to an HTML SPAN tag or a JSON object or something and print out the whole thing.
I can randomly set the clusters of cells as clusters of rooms. I already know which types of rooms belong together in a cluster, so it would be easy to randomly assign the cell as a room from the options.
For instance, in the front of a mansion, there is a Main Hall with some or all of the following rooms clustered at the very front:
(And you probably need one restroom and a closet per cluster of rooms…)
Thus, each cluster of living cells becomes 3-4 rooms, plus a restroom and hall closet.
At least, that is how I think it will work. I need to try the system in a demo game. Different algorithms for making the rooms – and positioning them – may work better or worse.
Really, it’s more like “Project One” and “Project Two”. Anyway…
At this stage I can make a small version of Sleuth – “Sleuth1”. It will have procedurally generated rooms, a random generation of murder victim (and maybe random character names), and procedurally generated conversations (or mini-plots or something).
I hope that this stage – “Sleuth2” – will be a game with a fully random plot that makes sense. Each time you play, the entire nature of the murder mystery is like a whole different visual novel!
It may be necessary to have a “Step 2.5” that experiments at making such procedurally-generated plot-lines (and maybe whole proc-gen story scripts?).