Super Mario Bros 1 has all these little great touches which makes it feel... tactile. Hit a block and it immediately makes a sound and bounces. If it breaks, it scatters little pieces around. Giana Sisters didn't do this and feels a bit... muffled because of it.
I'm less than impressed by 3D platforming games. Basically, in a 3D game you mostly slide around a ground plane. Sure, you jump around a little but mostly it's to get to a different ground plane. So, you have two axises (X,Y) with the same behaviour and Z isn't used much. In a 2D side scroller you have different behaviour for the X and Y axis which makes it more interesting to me. You still to do most of the things you can in a 3D game, like going around enemies, colliding with stuff, etc. The basic game verbs are still there.
The main selling points of a Mario game for me is crushing blocks, jumping on enemies, kicking shells, making daring precision jumps. None of these work well in 3D Mario from what I've seen and experienced. You can't show off elaborate block crushing mazes graphically unless you put the player between glass (2.5D). It's very difficult to even hit the right spot when you jump, or jump under a block and hit it. Kicking a shell at an enemy would probably require some kind of homing routine, and you probably wouldn't have it bounce back at you. All this has been replaced by difficult to control sliding around with a fiddly analog knob, while collecting all of the stars, waving the cursor around screen to pick up the the plinky plonk.
Well, both formats have their advantages of course. Since we live in a 3D world it's natural for us to want to present games using a realistic setting in 3 dimensions. It looks nice too, and as I concept artist I can understand the strong compulsion to present the characters and environments in full 3D. Whatever, I want to do pixel art now. End rant.
Some of my favorite Mario enemies never really made it into the Super Mario setting, such as the Snap-jaws (DK.Jr) and Crabs (sidesteppers in MB). Other interesting designs are the Egg dino from DokiDoki, the robots and bomb shells from SML, the Wrecking Crew wrench bots and eggplant-suit thingie. My favorite SMB 3 enemy is probably the little white plants.
Below is a mockup. I'm working with a 4-5 color restriction (including transparency color). Unlike SMB1, I use a black, partially lost, line art style. The dark teal ground tile layer is supposed to foreshadow how the underground levels look. It felt a bit dull and flat to use 2 layers of plain brown tiles for the ground level (as in SMB1). The pipe is a nod to Giana Sisters (which had more greebly pipes).
Strange as it sounds, I'd like to do an anti-Mario game. Rather than splitting the game into linear levels, I'll just have one big level, like Exile. The player arrives to a place with a history to uncover, but will have to be very active and responsible in his/her omnidirectional progress. Well, that's how Exile played early on anyways. You really could paint yourself into a corner by wasting the grenades and dropping vital stuff. It made the game setting feel very tangible, almost the opposite of Mario games where nothing really matters, and story progress is simply pushed on the player.
The original SMB was limited to something like 6 on screen enemies. Nowadays, the whole game could probably be persistently simulated. In a sandbox type game, this means that eventually all enemies will be dead or stuck, unless they respawn. Respawning could happen with Zelda puffs (or Legacy of the Wizard eggs). Maybe a simple pattern recognition function could detect stuck enemies, and a wizard shows up and teleports them out. Also, enemies which crowd up might be relocated to somewhere else. Some enemies (like turtles/shellcreepers/koopa troopas) could also have more movement types, allowing them to get out of bad situations. I liked how SMW made the turtles more humanoid. It could be fun to make less evolved turtles which still move like the MB/SMB1 ones, and more evolved biped ones. Mine took inspiration from the Super Mario Land ones as well.
This is a first draft of how the world map might look. Doors like castle gates might have to teleport the player into a reserved indoor section (bottom left). The background hills could also exist as foreground objects. Thanks to my RLE-updated dynamic water I could probably handle large amounts of it in a section of the map.
Aside from the dynamic water and destructible terrain, I also want to do ecology (crops aka SMB2 style plants) powered by a weather system (fancy speak for dumb-ish cloud actors moving about dropping aforementioned dynamic water which is then absorbed by certain topsoil tiles with or without seeds). Water could be returned to a humidity buffer if it's somehow destroyed/released. Plants could store it temporarily.
The different regions of the map have different terrain and game themes (MB, SMB 123, SML, DKJr, WC). At this point I'm not sure what the different factions are up to, but the minions could have simple goals which together create some sort of functional structure (which can be crippled by the player).
I'll probably draw the map as a RAW image in Photoshop and just load that into the game as bytes, and edit over it. It might be possible to make a "smart" routine which figures out pipe-tiles and such so I won't have to diddle daddle with that. I've already got functions for randomizing tiles, recognizing top tiles, background shadow tiles, etc.
Perhaps the game takes place on another planet, or in another realm. There the player discovers a civilization of "Toads", perhaps fighting a losing battle against... some guys. Below the surface are ruins of... the Elder-Toads? Maybe some kind of resources. Maybe something the other factions are after. Power which destroyed the Elder-Toads.
Bowser variants based on the game cover and in-game sprite.
While I can enjoy the simple gameplay of SMB, I sometimes feel like I'm not accomplishing much in the game. Mario never accumulates anything. Well, there were some item collection in SMB3, but mostly it's picking up plinky plonk and temporary powers. It would be interesting to play around a bit with the Mario formula, heretical as that may be.
As of 2013 (this project was started in 2010) I'm thinking the game might be about Pauline, Mario's Fay-Wray in Donkey Kong. Perhaps they broke up because she was always out adventuring (not getting kidnapped as much anymore), turning Mario's attention to Peach. Anyways, below are the power-ups that I had in mind for Mario. Pauline has other stuff, like a hat, umbrella, and purse (while pink, it might actually be full of combat gear). Peach used an umbrella in her own adventure. The hat reminds me of Remilia/Flandre Scarlet's (wearing it give her bullet-hell abilities?). I'm thinking she might have a sort of bubble tommy gun otherwise.
Temporary powerups (Mario):
Then there's the regular abilities such as jumping, running, smashing. These could be enhanced by collecting coins and buying 'level ups' in stores. Items could also be used to enhance regular abilities. The player will need to both level up and collect items to max out abilities. For example, if Mario can only jump 2 blocks high in the beginning, he could gain an additional 2 by grinding for cash and 2 from items. Being able to jump higher or run faster is sometimes required to get past certain places.
Some special powers are enabled by a single unique item.
Also, some enemies may become friendly and open up a passage, e.g. the strangle vines becoming ladders rather than... something which tries to strangle you.
Style test for enemy art. I dunno.
NES restriction SMB1 sprites, 16 tall instead of 8. Need to jigsaw together for some overlap. Sprites are a bit stretched on a TV.
Hardhat honey, an original character which sprung forth.
Then this happened. Nokonoko and Kuppa-Hime. These two are up to no good.
Not as fancy as the other princesses, but a persistent hard worker... some would say stubborn...
Snifit/Shy-gal. Not sure if I showed these screens but I plopped her into SMB2 in 2013. The SMB2 ROM has a lot of duplicate tiles due to the bank switching techniques it uses so generously. To properly change all instances I need to write a tile id/search function so I can map all instances onto my sprite sheet which has a more friendly layout. It was too much work so I stopped at this toad swap.
Just a wild theory...
It might be difficult to figure this one out without the super-crown context.
Almost unrelated, but while I'm here... an update to me A64 concept. Would be an expensive due to coloured panels needing extra moulds/tools. There's also some fun switches, sliders and lights. Specs? The Commodore 65 specs are quite juicy now, but less so at the time (which was too late) (1991?).
In hindsight, I wonder what appropriate Commodore 128 specs would have been (1985). Perhaps something which would have been easy for C64 game devs to work with, without changing their product:
So no Z80, CP/M or 80-column chip+vram. This might actually have made it slightly cheaper and faster to engineer. I think "GPU" changes would run the risk of causing market division (developers might choose one machine over the other) and it appeared people were pleased with using the C128 as a regular C64. Also, in 1985 the graphically beefy Amiga 1000 was just around the corner (though in a completely different price bracket).
In 1985 home computers were just on the cusp of booting into desktop environments like GEOS, Workbench or GEM. Not realistic for the C128, but it did have a sprite editor in ROM. I think my last wish would've been for more programs in ROM. Fun and convenience on boot matters a lot. Loading is a significant threshold. Gfx editor, Tracker, Text editor, BASIC, Compiler. A memory inspector could've been quite neat for fooling around with C64 game data on a 128 kilobyte system. Almost like a file manager with a RAM-drive, opening up for all sorts of shenanigans. Of course, developing all this software for a prototype system would've been a challenge, but maybe with the C64 as a base.
A built-in MF2DD drive is probably not realistic. FDDs were fairly expensive at the time (1985). In 1988 an external one was more than the C128, but external ones need the housing, PSU and standalone driver circuitry of course.