MaruMari (NES Hombrew)

[snarfblam]

Now seemed like the right time for me to start another project I'll never finish, tentatively titled "MaruMari." It's a homebrew heavily inspired by Metroid. The name comes from the original name of the morph ball item: "maru mari".



Right now it's in its very early stages, so I'm very open to suggestions. The game-play will be like going down a very long vertical shaft in Metroid, but you're stuck in ball form and there will be forced scrolling (if you get pinched at the top, you'll lose). There will be power-ups similar to or inspired by Metroid games. I'm thinking maybe the focus should be on aiming for a high score, and the game may or may not be endless. I intend to have multiple levels, each with its own song, but that will all depend on how much I can fit in a 32 KB ROM.

Currently, I'm working on the basics of the engine. I've got player movement and scrolling down (that still leaves a lot of ground to be covered).

I've got a project outline for anybody strangely curious about the details.

[Yuki]

You should allow the player to customize their ball after they beat the game with different qualifiers, and unlock things like a dark samus morphball, and a dark suit morphball, phazon suit, PED, and so on.

[knuckles]

You should allow the player to customize their ball after they beat the game with different qualifiers, and unlock things like a dark samus morphball, and a dark suit morphball, phazon suit, PED, and so on.

Maybe a hard mode too? (you take more damage from enemies, spikes, etc.)

[Blarget2]

How about this as a variation of the floors?
                                   

[zephyrtronium]

Things that come to mind just reading the design document:

• An item that increases bomb capacity could be useful as well. This might be integrated with energy tanks, e.g. picking up one also increases bomb capacity by 1?
  
• Combining the two options you listed for springball would make sense as a third option, but only if they're frequent enough (or last long enough) that it matters.
  
• Springball and space jump have different applications, so it wouldn't necessarily make no sense not to require the former for the latter.
  
• Screw attack isn't very useful as listed. It depends upon springball or space jump, at least one of which is temporary. Perhaps a better idea would be to have a speed threshold controlling its activation? Another idea might be to grant permanent springball with it.
  
• Speed booster could be a candidate for invincibility item. Enemies are destroyed on contact, and movement is quicker, but the screen scrolls faster.
  
• Power bombs could work by making the background flash a few times and then destroying all onscreen enemies.
  

[Zhs2]

Spring Ball and Screw Ball should be powerups. Space Jump should be obsoleted entirely in favor of Spring Ball, unless perhaps turned into a Fly Ball what incorporates the effect of Spring Ball but allows you to jump multiple times instead of once. Perhaps also in the same vein, the ball should gain temporary shooty powerups for shooting things horizontally and vertically instead of relying upon bombs (Ball Turrets, lol.) I also like zephyrtronium's idea of a speed booster, which makes you temporarily invincible AND quicker. All of these powerups should be randomly generated and last for varying numbers of seconds each.

As for power bombs, they should be more like a panic button. Allow the player to carry a very limited number for use when trouble arises (perhaps select button, since A would be for jumping if you had the appropriate powerup and B for bombing. Start for pausing. Right?)

[snarfblam]

Oh, wow. Lots of good ideas.

Things like level design and extras are something I'll address when I've got the engine done-ish. I still need to code for level data compression, palettes, objects (enemies/items), etc...

Hard mode should be easy to include. I'm not sure how I want to deal with bomb capacity. An item that increases capacity might be a good idea. It'll be easier to say when I have things up and running and can toy around with the possibilities. Of course, that applies to a lot of the ideas. I love the speed booster idea. I'd like to work power bombs in too. Flashing the background was my first idea, but it struck me as sort of cheesy and cliche. Maybe it'll work if I throw in some screen shaking too. In fact, I think that would definitely be passable if power bombs were used as a panic item.

[zephyrtronium]

I assumed from the start you'd be randomly generating levels. There are lots of ways to do so: you can choose from a selection of pre-assembled segments and chain them together; you can generate a pattern for each row and use a pathfinding algorithm to make sure there's always a safe passage through; you can overlay big chunks of solid and air blocks and attach other things afterward. Just a few ideas.

[snarfblam]

I initially chose the non-random option for a couple of reasons. One is that it is just plain simpler, which drastically increases the odds of me finishing the game. The other reason is that I don't know if I could make randomly generated levels look as good.

Piecing together pre-assembled parts could be doable depending on how you go about it. I'm not sure exactly what you mean with the big chunks of solid and air blocks. NES is pretty restricted in terms of both memory and processing power, so something more elaborate would require much more ingenuity.

[snarfblam]

(excruciatingly slow) progress:

"Maru Mari" Homebrew Progress

I've got enemies! Well, just rippers, but most of the work was adding generic enemy code to the engine.

[snarfblam]

So the idea occurred to me today to center the screen on the player (horizontally). I'm wondering what other people think of this.

Also, sound! I used a ready-made sound engine (FamiTone), which is great, because sound programming is not my strong suit. Bombs aren't finished, HUD design is far from finalized, and pretty much everything (especially sound effects) is a placeholder/temporary while I chip away at the engine.

[spoiler=Fixed]http://www.youtube.com/watch?v=GzFovv403Zk[/spoiler]
[spoiler=Centered]http://www.youtube.com/watch?v=CXKZ4dTdNOs[/spoiler]

[Zero One]

Excuse me while I fail to contain my nerdgasm.

[spoiler]HNNNNNNNNNNNNNNNNNNNNNNNNGGGGGGGGGGGH[/spoiler]

Also, I think the 'fixed' scrolling would be best. I prefer the Kid Icarus feel whereas centred makes it seem a lot more complicated.

[squishy_ichigo]

Fixed looks a lot better imo, perhaps an option to choose?

[FullOfFail]

I prefer fixed too. Scrolling would be more for a exploration game, unless you want to combine that aspect of Metroid in aswell.

[Quietus]

Agree with the others.  Fixed.

[Zhs2]

Fixed has such a Super Mario Bros. 2 feel to it, though imagine all of those other games with a camera view centered on your character. Fixed gets my vote.

[snarfblam]

Well I guess it's unanimous.

perhaps an option to choose?

I could do this, but it's looking like there would be no point.

[zephyrtronium]

If you ask me, I think centered would look better were it not always centered. The first and last segments in the current map, where there's really only one way to go, make more sense with a fixed camera, but the middle segment, where in one or two places you must wrap around the screen in order to continue, would look better with a wrapping camera.

[snarfblam]

Things I've accomplished:

• Added energy tanks to hud
• Lava/Spikes
• Bombs bounce player and kill enemies
• Breakable blocks (vram updates were surprisingly difficult)

Maru Mari Progress

Things I want to do next:

• More items and enemies
• Randomize levels

I've come around to the decision that levels should probably be randomized. I have a vague idea of how I might do it. The levels could be constructed from pre-defined half-screen-sized sections, maybe with simple transformations applied to them (flipping and horizontal shifting).

[zephyrtronium]

My favorite part was the garbage dump.

For building levels from subsections, might I recommend a sort of Markov chain-based algorithm? Each subsection has a map of (accumulated relative probability)->(subsection ID), generate one random number, iterate through the map, and the next subsection corresponds to the first key greater than the random number. Map building in O(n) time, or even O(lg(n)) if you use binary search, although sorting the map first by relative weight descending and iterating linearly probably would have better performance. Plenty of ways to optimize and customize, too, like having the values of the map be jump pointers to the code that actually sets up that subsection. The only real drawbacks are that it would involve more work to set up than just "pick some random subsection and go" and it might be a bit heavy on space.

[passarbye]

nice progress snarfblam!

i like what i see. :)

[snarfblam]

For building levels from subsections, might I recommend a sort of Markov chain-based algorithm? Each subsection has a map of (accumulated relative probability)->(subsection ID), generate one random number, iterate through the map, and the next subsection corresponds to the first key greater than the random number. Map building in O(n) time, or even O(lg(n)) if you use binary search, although sorting the map first by relative weight descending and iterating linearly probably would have better performance. Plenty of ways to optimize and customize, too, like having the values of the map be jump pointers to the code that actually sets up that subsection. The only real drawbacks are that it would involve more work to set up than just "pick some random subsection and go" and it might be a bit heavy on space.

I'm not sure I understand 100%. If I've got the wrong idea, you might have to explain that to me like I am six.

Each level section has an associated map (i.e. dictionary) which identifies a set of possible sections to follow, with weighted probability as the key (represented as accumulated probabilities for easier mathing). Is this correct? And the goal is to... create more interesting or suitable random sequences? As in, sections that fit together more suitably are more likely to appear together? How would the maps be generated? Manually?

Edit - Also, if anybody has any suggestions for enemies, now's the time. Definites are zoomers, rippers, multiviolas, rinkas, and of course, metriods.

[zephyrtronium]

I think you've got it, but I'm bored, so I'll explain more thoroughly.

Say you've got five sections, A through E. The game picks A to start building the map, and it does its thing. When the time comes to choose the next section, the game looks at A's map, which might look something like [80 C0 E8 F0 F8 FE FF] - the important things are that M[n] > M[n-1] and M[n]-M[n-1] ≤ M[n-1]-M[n-2]. The algorithm takes a single random byte, then walks through the map from start to finish. The index of the first byte greater than or equal to the random value is found and used as the index into another table, either of jump counters to new subroutines specifically for setting up their respective rooms or of arguments to a global routine that takes care of everything. If we go with the latter, we might set it up so that each is a pointer to that section's data (including a pointer to its own map somewhere) and another byte giving a flip flag in its lsb and signed horizontal offset in the remaining bits. A's table might look like [[&B 00] [&A 01] [&C 00] [&C 40] [&C 01] [&D FC] [&E FD]]: 128/256 chance of going to B without changes, 64/256 chance of going to A flipped horizontally, 40/256 chance of going to C unchanged, 8/256 for C shifted right by 32 (whatever this might mean), 8/256 for C flipped, 7/256 for D shifted left by 1 (or really shifted right by -1), and 1/256 for E flipped and shifted left 1. It would be a good idea to keep flip and offset stored and make these changes relative to the existing ones to keep everything lined up.

This approach has a few nice properties: for one thing, the map always ends in FF, so it isn't necessary to store or predefine a length, and maps are only as long as they need to be; for another, if those conditions I mentioned by the example map are held, then the chance of actually having to walk through the entire map is inversely proportional to its length and therefore how much it actually matters. It also lets you define "sequence points" that have only one possible child and whose ancestors cannot be reached by its descendants. Such constructs allow you to define distinct "areas".

The problem is that, yeah, the maps all have to be constructed by hand. The process could be simplified a bit by checking via recursive flood fill or (preferably) pathfinding that you can always reach all the possible targets each section lists, but it most likely wouldn't be worth it to coax a computer to "guess" what structures would look good together.

[snarfblam]

So after a whole lot of inactivity on this project, I got around to adding a new enemy. Behold! Multiviola!



It's not much in terms of progress, but Maru Mari is back on my radar. I'll keep chipping away at it.