fbf3bc No.33749
Since the /v/ threads also advertise vidya modding (and /vm/ is basically a dead board), I thought I'd just post my current project here.
So when I learned that randomizers were a thing a few years ago, I found it to be a very novel concept. Earlier this year, I remembered that shit, Super Metroid is fucking popular and it already has a number of item randomizers made for it. I played them and enjoyed the way it spiced up the experience.
My current project is to make a randomizer, but in such a way that not just the items, but the entire game is changed up (much like Roguelite).
____________________________
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33750
I don't have much progress to show off quite yet, but I've been working on this for around a month or so. One milestone I've reached was that I was able to take a good chunk of level data, and inject the tiles into the screen of my choice (I did this with a Brinstar room and a Maridia room). Right now, I'm working on a way to manipulate array data in a variety of ways (shift, rotate, flip, etc).
http://wiki.metroidconstruction.com/doku.php?id=super_metroid
http://patrickjohnston.org/bank/index.html
What I want to do is make a little programming framework that has a number of objects that mimic the game objects (eg tile data, room data and headers) and in a way that is both easy to manipulate as a human, and easy to write down back to the game data. There's a few layers of abstraction going on here...
As for the level generation, I'm going to take a node-based approach to it. For example, each node could track it's general position and size, and can be grouped by area, room, or screen. Connections between nodes indicate obstacles that need abilities to traverse, so I could manage a graph that knows whether getting a certain item is possible. Once the level nodes are figured out, I have an idea for terrain brushes, about how different graphics and such will applied.
As for game difficulty, I want to limit the player to Charge and a single beam at a time. I can use ASM to remap the "item cancel" button to become a beam cycle so you can swap between them on the fly, kinda like Prime. This way, I can give the occasional enemy resistance to certain beam types. Missiles and tanks would be very limited (eg +2 Missiles, +1 Super) to make them feel special. One last thing would be to make bosses immune to charge beams, so you have to either stock up or play well to defeat them, in addition to varied arenas.
Like most other /agdg/ projects, I feel this is very grand in scope, but I am okay with that. If I can make a simple, but novel proof of concept and release the source code, I know the SM community could do something with it, too.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
a50c7c No.33771
>>33750
My only concern is that this may end up with locations or items that are inaccessible and prevents the game from being finished, or that it may suffer from Minecraft prefab syndrome where the random chunk generation spawns your prefab objects (like a hallway, a door that is meant to lead to a boss, Mother Brain's chamber) inside a bunch of walls or other tiles. How would you prevent these issues?
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33773
>>33771
The game has a hardcoded limit of 5 or so zones (Crateria through Tourian), with a set of boss flags and such to track progress. Each zone has a number of player recognized subzones (eg Blue or Pink Brinstar, Kraids area) but to the game these are discreet and just kind of exist.
When running the generator, my thought was to start with 5 zone nodes, and expand each into 2-4 of these "subzones". It would also generate a "canonical" upgrade path/tree, and each core upgrade will either appear in the current subzone, or an adjacent subzone reachable from the current one, to encourage some backtracking, but not have it be excessive.
In an ideal situation, it would generate two different paths, so you aren't forced to play the same route through the same seed. I will flag it so that certain upgrades need others (eg morphball->bombs->power bomb) so you don't end up with useless things. The first two or so missile, super, and power bomb tanks can follow this tree, while the capacity upgrades can just be salted throughout all the other regions
In regards to the actual tile placement, I haven't ironed that out yet, as I'm still writing some API stuff that'll make my life easier down the road. I imagine I would abuse floodfill and pathfinding to ensure each feature and door is traversible. As a bonus for using the node-based approach, I can even use nodes down to individual room features and subregions within each room. I have at the very least measured some of Samus' jump width/height with certain abilities so I have a general idea how far you can move with those abilities. And of course, with nodes, I can tag connectors, so I can say "Going from Node A->B needs Hi Jump Boots, but going from B->A needs Bombs" and attempt to use that as a metric when placing room features
Each screen is a 16x16 tile region (of 16x16 tiles), with the top and bottom 2 rows offscreen, usually. Doors are always centered in the middle, with a 6 tile buffer above and below.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33796
Went through the game data and extracted the vanilla ROM's room dimensions for each each area, so I could get a sense of how large everything should be
Polite sage for a non content-related post to my project
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33803
Spent about 8-12 hours today casually muddling around and thinking of ways to design this. Basically what I wanted to do with break each area up into "nodes" and then have each node connect to different nodes and areas randomly, and then build up around them.
If you take a quick look at the game's existing map structure, you can most easily see what I mean in Brinstar. It has several recognizeable areas, such as the Morph Ball area, Kraids Lair, the first part before Spore Spawn, etc. If you cut off the optional upgrades, the path becomes very small, linear, and you can see what upgrades are actually needed to ''progress'. That's the same approach I want to take here.
If you count the original game's number of area transitions between major areas (and some are optional) there are 13. Using this algorithm I designed, you will get at most, 12 (and we can always increase that by having more green links). But my point is that this is a very good approximation, allows for weird "islands" like the Crateria spot past the Wrecked Ship, and hopefully has a nonlinear, but sensible structure to it.
From here, the next step would be to actually implement it, but also to add additional things, like items. The way I'd handle item placement is to design a "canonical" order of appearance, using Pic 5. Items are grouped by the user and can also have a requirement that other items MUST be found first, so that you don't get nonsense things, like Bombs before Morph Ball, or Super Missiles before Missiles. I arbitrarily had Space Jump and Screw Attack found last (because they're "powerful" and trivialize a lot of stuff), but everything else is freeform. Expansion tanks are placed last; but note that "hotbar" tanks are the first occurrence you'd find each one, so we again have control over when things start to appear (hopefully).
The cool thing about the items is that later. we can use them as flags on node connections; for example, going from Area A Node A->Area B Node C might require powerbombs, and the level builder will see that flag and then create a yellow door, or what have you. Like I said earlier, there's going to be a lot of pathfinding abuse to make sure things are sane.
This is all probably still weeks away, but hopefully I can keep up with my progress.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33805
Generated a few nodes and gave them a hierarchy. Linking them comes next
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33820
Good progress today. I refactored my Nodes to be a little more verbose in what they contain, which allowed me to kill off a ton of subtypes at the cost of just holding a little more data. Worth it, in terms of clarity.
I also started a basic renderer in SFML, just to see my output. This won't be included in the final version of the generator, however. The red dot is the root node, named "Zebes". There are 6 green nodes, which represent areas ("Crateria, etc"). Each area has 2-6 child nodes (blue) which are regions (eg room groups) within that area. I still need to connect the green nodes together, and implement the full linkage algorithm (islands and "bonus" links, and propagate area links downward).
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33823
>>33820
Finished the algorithm, going to tidy up a bunch of code before moving onto other things.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33824
Mockup for a potential approach to roomgen.
>Determine room size (8x4)
>Block out any overlapping parts of the map (black regions)
>Any valid tiles automatically receive a 2-tile buffer on the sides, 3-tiles on the the top and bottom (green stripe)
Good so far
>Draw a number (how many?) of random rectangles, such that each 16x16 region in the room intersects at least one rectangle
>Fill any "intersecting" bounds (purple region, second image) between each rectangle (how?)
>Remove any burrs and weird things that still show up (not done, see random pillar near top right)
After this step, it would round corners, smooth edges, vary the ground slightly, then place objects etc
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33836
Thought about how I'd generate room shapes.
Once I have my regions and connections determined, I'd expand each region node into 2-4 "room groups". Each of these is an important keystone to the game's route. They would each be connected by 0-3 additional filler rooms, depending.
As for the shapes of those rooms, my first thought was to draw a rectangle and then query it for overlaps, but that's silly. The better approach seems to be flagging each tile with a room ID, then determining the bounds of the room. Any overlap is then considered an empty screen, and a rectangle is drawn. Pic related.
tldr: Working backwards made a lot of sense this time.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33871
Today was a day where I refactored and tidied up code. I also worked on indexing things in memory. While the memory maps are largely known, certain things in editors aren't displayed, so I worked on finding exactly the data locations I'm looking for.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33873
Rejoined the Metroid community discord for modding. Turns out at least 2-3 people have attempted this sort of project before.
Saw this neat algorithm, might use it for when I'm beautifying my terrain
https://robertheaton.com/2018/12/17/wavefunction-collapse-algorithm/
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33904
Spend about a week or two trying to figure out a good approach for converting a bunch of room nodes into room shapes. Basically, if each room knows the doors it connects to, then I can block out already claimed rooms/screens, find the midpoint of the doors the room is to connect to, then run a drunken walker to each door, ensuring it doesn't grow the room too large.
This is all a mockup, and I'll actually bump the thread when I have something tangible. The bottom three pictures show the result and how I'd expand from there - the room skeleton, naive shapes on the middle of walls and tops of cliffs to rough it up, and then an analysis of how far you can reach from each platform, and placing additional platforms for mobility - this third stage is probably where I'd start looking at node traversal between doors and seeing what abilities are needed
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33953
Haven't had much free time. Still thinking of the best way to construct rooms. What I posted >>33904 is suitable for hubs, but not feature rooms.
Once I break an area into regions, each region is broken into 2-4 major rooms that act as hubs/main rooms through that region. These will branch off into separate, linear paths to each feature room. A feature room contains things like save points, major items, etc. Once feature rooms are placed, additional hallways connect them to hub rooms.
My difficulty right now is generating a desireable shape for feature rooms. Hubs can use a combination of walkers, A*, or whatever to rough up the shape, and hallways can use roguelike HVH or VHV lines to assemble a minimum spanning tree between each key feature.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.33954
Also, most doors are for horizontal traversal, rather than vertical. I quickly counted the number of doors in the game, and got through about 3/4s of it and had something like 7 or 8 vertical doors to 120 horizontal ones. So this needs to be a factor in design as well.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
fbf3bc No.34058
Kinda dropped this project for the moment.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
e2654e No.34271
Picked this back up and worked on a few things here and there. Just had a week or two of free time off work (unrelated to Coronavirus).
Pic related was made programmatically (and viewed in an existing editor, SMILE). I'm using a Grid<T> class I implemented in another small utility framework I made, which lets me take an array of data and interpret and change it in terms of rectangular values (eg, flip, shift, blit). I am currently working on "tile brushes" so I can draw features in a layer stack and then compile them to rom.
This particular room was hardcoded, but it features two Grid.Fill() operations to generate the room's frame, and then a brush to place the blocks and the door. I keep trying to decide between a dedicated Tile struct (easier to work with, but more cumbersome to code things with) or just using a ushort so I can take advantage of bit logic (slightly faster, which won't matter, but feels elegant).
Brushes also need to have XY flip and a few other things.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
e2654e No.34275
>>34271
Right now I am still trying little things with my framework, tidying it up, and making it more general purpose. This is mostly for me to test how to block fill and work with room data a little easier. Still a bit of ways to go.
As for the actual generation, what I've done here is give each tile a random "enabled" value. This determines whether its open space or a closed square. For each screen, I test whether the screens to the right, bottom, and diagonal bottom are also enabled. If so, it sets a direction flag that says to merge it. Then, it iterates each screen and sets appropriate flags for diagonals, and upleft and such (done this way for lazy bounds checking).
In production, it would check the diagonal flags so you don't have block islands in clear space, and it would also reinforce screen edges (sides of screen like normal rooms would). In addition, directions are forced, and some rooms could very well have sub tunnels.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
e2654e No.34282
>Made a small, lightweight framework to build other projects on top of / aggregation of general code I've written
>Making a second framework specifically for Metroid romhacking which contains specific utility and functionality
>Third code project is the randomizer/content generator
>Try to test some of the code by randomizing the palettes
>For each color in the palette, randomly swap the R/G/B values around to get a new color, then randomly lerp between the source color and target color
But then I realized I need more control than that, so I started working on layer/color blending mode implementation that PS uses, to an accuracy of +/- 1 on each RGB channel. After I get this made (and pushed to my first framework), I'll start working on a more robust way to color enemies and rooms, which uses ramps and such.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
e2654e No.34283
First pic is with an implemented "Overlay" layer effect, to basically make darks darker and lights lighter.
Second pic is actually done in game, but with arbitrary hardcoded palettes, it's not dynamic or anything, everything looks that way all the time. This was done with a greyscale and inverse filter.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
e2654e No.34290
I'm using a certain community doc to reference the addresses of everything. Using that (link related https://pastebin.com/raw/G1FtKFwR), I then made a hacky script that reads each enemy header, and for each header, reads the correct palette for that enemy, then uses SFML to output it to a file.
If you look at the palettes, you can see many of them have a 1/4/4/4/3 pattern for the ramps (first color is always transparent), which means I can then take chunks of the palette and selectively recolor them or what have you.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
e2654e No.34296
I've been working on adding a few container classes for things like enemy headers, palettes, weaknesses, and drop items that sort of stuff.
Also set up a public repo (everything is GPLv3) if anyone using C# is keen to mess around with stuff https://bitbucket.org/JackalsoftGames/metroidtools/
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
e2654e No.34297
Think I solved a major bottleneck for creating the room's shape.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.