Hi all,
Possibly a final update on this one...
So I shelved my graph-based experiment... I think it could be taken further but it is not "blossoming" the way I hoped. I hoping it would trigger further ideas and I might guide development by what made those ideas easy to implement. Instead it was progressing only very slowly past a basic level and it began to feel like a bit of a drag.
I think I get a couple of positive results from it:
1) that incrementally building a graph and relaxing its representation (2D, but that's not required) as you go can work. Obviously the relaxation gets more expensive as the graph grows and an approach that was able to move whole blocks around without needing to optimize their inside might be more efficient...
OR... my current approach can add new content anywhere, but if the approach was able to grow into empty space, say by growing North, then the previously completed Southern parts could be treated as fixed context not requiring further oprimisation.
2) that creating 2D maps via union + subtract geometry representations can generate quite rich geometry. (I don't know of a general term for this, it is like CSG but in 2D, "Constructive Flat Geometry" (CFG)?) The limitations here, however, were:
- depending on what geometry you feed into it, you may get numerical precision problems. I wasn't _plagued_ with those, but there were various tolerances built into the CFG algorithms (like "all verts within 0.1mm of each other are the same vert) and those made me nervous every time I looked at them. On the whole they behaved, but I did wonder if they were a problem that would strike later... I did at several points rework bits to make them more stable in the face of such things (like making them not care if a vert they were trying to introduce had to merge into an existing one) but I'd say that was only 99% there...
- depending on the exact nature of the inputs, you might need care in composing them because there is nothing topological about the CFG logic. Thus if something cuts right through something that should be impenetrable, that will make hole you don't want...
Negative results:
3) as discussed before I started, graph layout of geometry (as opposed to graph generation of plot/logical structure) isn't the most natural fit...
4) it is very hard to construct PCG in the absence of an actual game to inform the process. e.g. I put red/blue bits in my prototype thinking "that might be fire/water" but without an actual need/reason for fire/water in the levels, it is impossible to evaluate whether that is really working... similarly I didn't get as far as doors and keys, in part, again, because without a narrative reason for them it is really hard to imagine what the right rules for positioning them would be. I thought that the emerging levels would inspire me as to what the game should be (and thus get two way feedback) but so far it all remains very sterile and abstract :-(
Thus I am tentatively looking into a different approach...
Which I will describe in a separate message.
Regards,
Ian