Unlucky Adventurers [7DRL 2017]

[JonathanS]

Doing my first 7DRL this year.

For "Unlucky Adventurers" I'm focusing more on presentation than on gameplay.

Specifically in sprite processing (SDFs, voronoi splitting, normals, generalized coords, etc). Particularly interested in seeing what can be done with skeletonization and inferring morphology for idle/hit/attack animation of otherwise static sprite images, and blowing them up in a fashion that isn't "puzzle pieces."

Dungeons will consist of porting Metazelda over to C++, authoring "room" variations in GZDoomBuilder (dumping the UDMF to XML), and inserting "rooms" that satisfy the metazelda criteria (some herringbone wang-tiled composed). If time permits I'll fiddle with some more classic dungeon floor/cave generation for a few floors.

The game will be small-squad scale (multiple characters), map scale and MOB counts will really depend on how lethal everything ends up.

Existing code usage consists of an automatic STB_C_Lexer based reflection generator for C++, a few utility classes (BlockMap, Variant [like QVariant], and MathGeoLib). A stripped down version of Urho3D will be used for video/audio.

[JonathanS]

Progress abound.

• Gamedata/object system pretty much done
• CastleDB is used for data and Jzon is used to read it
• Game premise is closer to hammered out
• Metazelda fully ported over to C++ and partially tested
• Switched to bitmap based room tiles instead of using GZDoomBuilder and generating the meshes from that
• Process was too slow
• OpenCL physics simulation appears to work (for projectiles/particles)
• MapData -> Mesh is complete, now to start creating pretty tiles.
• Bitmap processing almost finished

Here's a piece of the bitmap processing work-flow.



Given a source image it is first converted into a boolean mask (that stage ommitted, as it's just alpha clipping) and a signed distance field is generated. The Red channel contains the negative distance (normalized against the greatest possible distance [32]), and the Green channel contains the positive distance (inside) in a 1.0 - NormalizedDistance form so it's easier to visually troubleshoot the image for "loose" pixels. The Blue channel is still a wild-card for effects, will probably end up containing a blend of RGB luminance and smoothed by a laplacian of the the RGB space distance. The positive side of the SDF is used for internal effects and the negative side is used mouse hover glowing.

Independently a Voronoi map is generated and works with the boolean mask to classify all valid pixels into voronoi cells. Using these cells it's easy to split an image into chunks which is how the chunks below were generated. Aside from a "1 by 1" approach an infinite line/plane could be provided to bisect the image based on cells whose centroids fall outside the bisecting segment and other radius tests, though for those a smaller voronoi frequency would be ideal.

The next step is to, with both the Voronoi map and the signed-distance field, run a Sobel-edge filter on the intersection of voronoi cell edges with positive signed distance field. That will get the pixels that would've been "cut" and the Sobel-edge results should just require a remapping to a red gradient to create a decent appearance of having been chopped off.

Aside from just exploding and bisecting there's other effects to fiddle around with for doing melts, dissolves, and carbonizing.

[jtolmar]

Very interested to see where you're going with all this bitmap processing.

I'm using a Voronoi-like process I call "competitive floodfill" in my level generator, and I think it might also be more appropriate for your pixel processing.

The pixel-processing version would be:
1. Put the (cell id, pixel) tuples you want for your cell centers into a low-first priority queue (they can all have priority 0).
2. Pop from the queue and check if that pixel has already been marked. If not, mark that pixel as being part of that cell, and queue its neighbors with higher priority (remember, low-first queue). You can use arbitrary priorities here, though strictly increasing is easier to reason about.
3. Repeat until the queue is empty.

The magic is in the priority increases in part 2. You could greatly increase it when trying to cross a transparent area so your slices bend around them, or bring in weights from your edge detector so it's more likely to try to cut things at outlines.

[JonathanS]

Isn't that less a Voronoi and more a weighted breadth first search in a constrained area?

> Very interested to see where you're going with all this bitmap processing.

Likewise, bummer that I'm realistically not going to make it in time. I should've spent some time ahead of time working on a basic map and data framework, I'm paying the cost for it now. It'll still be cool to just focus on generating effects from single images and OSS all of that at deadline, as I do think that roguelikes can use minimal art and still appeal to those like me that just can't wrap their heads around ASCII and must see "oh, that's an ooze being all oozzy."

It'll still be a fun project to see to the end though.

[jtolmar]

Isn't that less a Voronoi and more a weighted breadth first search in a constrained area?

Multi-seed breadth first search but yes. The result is a Voronoi diagram if you weight by euclidean distance from your seeds, which is how I got there. Also technically it's (usually) a Voronoi diagram in some sort of metric space .

It'll still be cool to just focus on generating effects from single images and OSS all of that at deadline

A seven day roguelike library, then? 7DRLL