Jump to content
  • Advertisement
  • 08/03/17 12:34 PM

    Super Mario Bros 3 Level Design Lessons, Part 3

    Game Design and Theory

    jbadams

    For my second SMB 3 post, I took a look at worlds 2 through 8 and picked out 30 stages that exemplified clever level design. World 8 is the last standard zone in the game, but I decided to write one more article detailing SMB 3’s hubs.

    smb3piranhas.png

    The unique piranha nodes lead to stages filled with venus fly traps and an end-level treasure.

    Hubs are an old video game trope, but in SMB 3 they are much more involved than in previous incarnations.

    Each hub in the game has its own visual theme and unique layout, e.g., World 7 is a scrolling archipelago, while World 8 comprises multiple skull-filled maps. These areas are not only littered with standard level nodes, but also contain unique stage-icons such as quicksand pits, tanks, and piranha plants. Offsetting these challenges are shops and sporadic minigames that provide bonus rewards.

    All these elements — and plenty of additional ones — turn the overworlds into individual mini-levels that are also connected to the main gameplay stages. Here are 10 examples of how that’s done:

     

    1). Pipeline Shortcuts

    Super_Mario_All_Stars_3_11.pngSuper_Mario_All_Stars_3_12.png

    Super_Mario_All_Stars_3_13.pngSuper_Mario_All_Stars_3_14.png

    Entering pipes on the hub transports Mario to tiny, single-screen levels. These levels contain no enemies and simply serve to ferry Mario from one point on the overworld to another. The game could’ve simply teleported Mario on the hub and avoided this element altogether, but it accents the link between the hubs and the main gameplay stages. It also serves to cement an internal logic that pipes are gateways anywhere in Mario’s universe.

    In addition, pipe detours can facilitate alternate routes through the hubs, allowing the player to skip entire batches of levels. This approach of making stages optional is something that became more and more prevalent in each Mario sequel. The notable point here is that it allows the designers to isolate the more challenging levels so that fewer players ever get stuck.

     

    2). Wandering Enemies

    Super_Mario_All_Stars_3_21.pngSuper_Mario_All_Stars_3_22.png

    Adding a bit of life to the hubs are various types of Hammer Bros. that move around non-level nodes whenever the player exits a stage (by either completing it or dying). Stepping on a node occupied by Hammer Bros. teleports Mario to a single-screen arena where a battle ensues.

    Defeating the Hammer Bros. yields a random power up from a set different than that of the stores, e.g., the player can receive a Starman or a Hammer.

    The Music Box power up can also put all the Hammer Bros. to sleep, allowing the player to safely pass across the nodes they occupy.

     

    3). Fortress Destruction

    Super_Mario_All_Stars_3_31.pngSuper_Mario_All_Stars_3_32.png

    Beating the mini-boss Boom Boom releases a “?” Ball that, when touched, destroys his home. This is a nice connection to the hub itself as the fortress blows up when Mario exits the level, clearly linking the two events. This is the only way to get past a Fortress Node as it’s not possible to fly over it with Lakitu’s Cloud.

    This sort of hub-updating is common to completing non-standard levels, e.g., blocking doors are removed and bridges are lowered to allow passage.

     

    4). Hand Traps

    Super_Mario_All_Stars_3_41.pngSuper_Mario_All_Stars_3_42.png

    Hand Traps are special nodes located in just a single part of World 8. They can randomly drag the player into a level whenever he walks over them, adding variety to the overworld’s mechanics. This event is accompanied by an animation of a large hand pulling Mario down, further emphasizing the link between the hubs and the stages.

     

    5). Bonus Toad Houses

    Super_Mario_All_Stars_3_51.pngSuper_Mario_All_Stars_3_52.png

    Collecting all the coins in certain levels unlocks a special blue (white in the original) Toad House on the hub. Unlike the standard houses, these only contain a single chest that yields either a P-Wing or an Anchor.

    Aside from providing an optional challenge and an extra reward, the bonus houses are another great link between the core stages and the overworlds.

     

    6). Destructible Obstacles

    Super_Mario_All_Stars_3_61.pngSuper_Mario_All_Stars_3_62.png

    Various hubs contain rocks that the player can destroy using a hammer. These usually open up a path to an extra reward or serve as shortcuts that allow the player to skip some levels.

    This sort of interaction with the environment prevents the hubs from feeling static, and World 2 actually uses the mechanic to hide a secret!

    If the player uses the hammer in the top-right corner of the map, he’ll open up an additional path to a Hammer Bros. duo that drops a Warp Whistle. There’s no obvious hint of this secret as there are plenty of rocks in the level and the map doesn’t scroll to reveal the path until the rock is destroyed. Despite this, it’s a very satisfying secret to discover with an equally worthwhile reward.

     

    7). The Canoe

    Super_Mario_All_Stars_3_71.pngSuper_Mario_All_Stars_3_72.png

    Super_Mario_All_Stars_3_73.pngSuper_Mario_All_Stars_3_74.png

    World 3 allows Mario to hop in a canoe as an alternative mode of transportation. The canoe moves gradually instead of jumping from node to node, and it allows the player to visit an island filled with power-ups and mini-games.

    Aside from breaking the monotony of traversing hub-nodes on foot, the canoe can also be used to navigate to a second, secret island that holds another Toad House.

     

    8). Airships

    Super_Mario_All_Stars_3_81.pngSuper_Mario_All_Stars_3_82.png

    Each airship in the game represents the last levels of a world (except World 8). If the player fails to finish the level on his first try, the airship will randomly travel to another node on the hub. This effectively makes the player chase the last level, which is a novel and amusing conceit.

    This mechanic can also cause a few headaches as the ship can move to locations hidden behind Hammer Bros. or unfinished stages, but this can be avoided with the anchor power up.

    In either case, the airships add life to the hub and also have coin-filled counterparts that act as another fun reward.

     

    9). The Tower (of Babel?)

    Super_Mario_All_Stars_3_91.pngSuper_Mario_All_Stars_3_92.png

    World 5 is actually composed of two different hubs linked together by a rather clever gateway.

    The first hub is a typical grassland with a few clouds on its lower-right side and a spiral tower that takes Mario to a largely vertical level. Climbing the tower to the top and activating a Beanstalk deposits the player in the second hub: the cloudy sky. This hub turns out to be a large cloud-kingdom that contains even more levels and a miniature version of the previous hub in its top-left corner!

    It’s also possible to travel between the two hubs — and necessary if an airship moves from one to another — although the tower needs to be traversed each time going up.

    The visual link between the two hubs is a small, aesthetic touch, but it fits perfectly with the in-game logic and Mario’s penchant for cloud-platforming.

     

    10). World 9

    Super_Mario_All_Stars_3_01.pngSuper_Mario_All_Stars_3_02.png

    Finally, the warp zone itself is presented as a hub, World 9.

    The warp zone allows the player to skip entire worlds, but it’s not implemented as a custom piece of UI. Instead, it’s a meta-world of sorts, beyond the regular worlds yet connected to them. This anchors the warp zone to the in-game universe and utilizes an existing interface that’s familiar to the player.

     

    SMB 3’s hubs might not be the game’s most defining feature, but they help tie together its various components into a cohesive whole. Consequently, the hubs are much more than just abstract menus; they’re part of a larger, interconnected picture that’s fun to explore.

     

    Note: This article was originally published on the author's blog, and is republished here with kind permission.  Check out his work at Incubator Games.

    Full Series:
    Super Mario Bros 3 Design Lessons, Part 1
    Super Mario Bros 3 Design Lessons, Part 2
    Super Mario Bros 3 Design Lessons, Part 3



      Report Article


    User Feedback


    There are no comments to display.



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Advertisement
  • Advertisement
  • Latest Featured Articles

  • Featured Blogs

  • Advertisement
  • Popular Now

  • Similar Content

    • By jb-dev
      This is how loading screens will look like. I still have no idea whenever or not I could show things like tips or anything alike...
    • By Programmer One
      I'm currently writing a 2D game engine from scratch for Android. The first iteration of the engine is just going to use the Android Canvas view for drawing. At some point, I want to support OpenGL ES - but not until I finish this first project (which is a very simply game based on this engine). Right now, I'm dealing with Sprites and I've encountered a design challenge that I'm not entirely sure which direction I should go.
      For the sprite bitmaps, I've decided to go down the sprite atlas route (as opposed to individual image files). I'm using Texture Packer and I've written a custom JSON exporter. I didn't really want to limit myself too much, so I decided I'd support sprite rotation and trimming in order to save as much space I can in the atlas. I backed off from supporting polygon trimming for now. If you're unfamiliar with Texture Packer, it's essentially a tool that will allow you to import individual sprite frames, organize them into folders and then have the application generate a sprite map and corresponding coordinate data file. This application supports trimming any blank (alpha) space around the sprite images in order to pack them closer together. It also supports rotation if it makes the image fit better.
      What I'm trying to figure out now is how to deal with loading the sprite image data. Currently, I'm at the point where I can deserialize the JSON map data into "Sprite Frame" objects. These objects contain information about each frame. My format allows grouping of sprite frames in order to organize frames that correspond to the same animation. In essence, the sprite frame object has:
      The original (untrimmed) size of the sprite image. The original position of the sprite image within it's bounding box. The rect of where the image is in the sprite atlas. A flag indicating if it had been trimmed. A flag indicating if it has been rotated (CW). This will give me all the information I need to draw the image onto the Canvas. If I didn't support all the other fancy features I want (packed rotation, trimming) and pre-transformation (i.e. mirroring a sprite so I can reuse it for things like changing the walking animation without having to pack in more sprites), then drawing the image from the sprite atlas onto the canvas would be as simple as a simple Canvas.drawBitmap([Source Bitmap], [Destination Rect], [Source Rect]).
      But, since the image I'd be drawing MIGHT have been rotated, trimmed or otherwise transformed, I can't just simply blit it onto the Canvas. I'd first would need to apply some transformations in order to "undo" changes that were done during packing. This means I would need to either:
      Slice out the child image from the sprite atlas into a new bitmap, and apply the "unpacking" transformations (i.e. rotate back, realign, etc). Apply a transformation to the Canvas itself. (I don't think I want to go down this road since I've read that transforming the Canvas tends to be rather slow). So, I'm probably left with having to create smaller bitmaps from the sprite atlas and then keep those in memory for as long as I would need them. So, for a single sprite character, I'd be looking at around 36 sprite frames (9 different animations, each with 4 frames). What I'm concerned about is memory consumption. So now I'm thinking:
      I should read in all the sprite bitmaps from the sprite atlas and shove them into an LRU cache. This means all the sprite image data is now in memory, all ready to go for whatever animation sequence and frame I want. Once I'm done with the atlas, I dispose of it and just work with what I have in memory. I can perform this caching when I load levels and then clear items from the cache that I no longer need. I should just keep the sprite atlas, blit directly from that onto the canvas, and get rid of the fancy packing features so that I don't have to process any transformations. The only problem with this approach is that I will also have to shelve shearing and rotation on the sprite object itself. TL;DR: Am I being overly memory conscientious or having a couple frames of sprite data in memory not a super big deal?
       
    • By jb-dev
      Another version of the main menu. This one has a more complete skybox. I'm not sure if it'll be a good idea to use the same shade on the actual Levels skyboxes...
    • By JeremyAlessi
      Jean Simonet is an indie developer who moved away from the AAA space in 2013 after delivering Skyrim and realizing that Fallout 4 just had him doing more of the same. Jean challenged himself and succeeded. 
      In this talk, Jean runs a counterstrike on every piece of indie gaming advice you've ever been told.
       

      View full story
    • By JeremyAlessi
      Jean Simonet is an indie developer who moved away from the AAA space in 2013 after delivering Skyrim and realizing that Fallout 4 just had him doing more of the same. Jean challenged himself and succeeded. 
      In this talk, Jean runs a counterstrike on every piece of indie gaming advice you've ever been told.
       
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!