Why Do 2D Games Usually Go to the Right?

Taxonomy of Virtual Spaces

ROMchip Journal vol. 7 no. 1 includes a rare treat - a development essay by a Japanese developer that has been translated into English.

Author Hiromasa Iwasaki started in the game industry back at Hudson Soft in 1988 working on games for the PC Engine (TurboGrafx-16 here in the US). He served as director on the Turbo CD game Ys I & II (1989) and the Bomberman series game Atomic Punk (1990) for Game Boy, along with many other games that were never localized into English.

Lately, Iwasaki has been participating writing for dōjinshi publications, which are similar to amateur press publications. Dōjin circles are groups of creators who tend to publish together, usually around a particular theme or fandom, similar to amateur press associations. Japan's copyright laws make it easier for fans to create their own derviative small-press works based on popular characters from video games, comics, and animation and sell them in small quantities at dōjinshi conventions like Comiket (short for Comic Market). Most dōjin works are magazines and novels, but there is also a fair number of computer games (dōjin soft), board games, and card games as well.

On a side note, on my other blog, I have been researching about how some amateur dōjin circles became professional game design studios for board game and RPG publishers during the simulation game boom in Japan in the early 1980s. You can read about the Keio HQ Simulation Game Club in my translation discussion of Star Trek: The Invasion of Klingon Empire. You can also read the bio I wrote about Atsutoshi Okada, founder of the THQ dōjin circle and one of the most prolific simulation game designers of the era.

Legend Volume 7

Legend Volume 7 cover image (illustration by Hiroshi Aizawa)

Iwasaki has been writing for the Legend series of dōjin books. Volume 7 (shown above) features Iwasaki's essay about how and why early 2D games tend to have characters that move to the right, notably in "side-scrolling" games such as Moon Patrol and many others. This deals with the concept of Frame Mobility, how the screen appears to move (or not move) to show the player different parts of the gameworld.

Moon Patrol (1982, Irem)

Legend Volume 7 was available through booth.pm, a global dōjin marketplace, but is currently sold out. It was also sold through Comiket and other dōjinshi outlets in Japan, but is nearly impossible to access from the US... until now!

ROMchip logo

The game histories journal ROMchip funded a translation of Iwasaki's work into English and made arrangements to publish it in the vol. 7 no. 1 issue (July 2025). I recommend clicking over to that page to read it. Iwasaki writes on a number of subjects about game development, some of which is also published on his Colorful Pieces of Game blog.

Why Do 2D Games Usually Go to the Right?

My main interest is in his essay on early 2-D "side-scrolling" games and their tendency to have characters that appear to move toward the right side of the screen. The conventional wisdom is that this is a cultural norm for the English-speaking world. We read from left to right, therefore it feels natural to move from left to right. Others claim that the convention comes from old Western films, where the heroic gunfighter is shown on the left side of the screen so that his right hand is visible. Others claim that arcade game layouts often had a joystick on the left, therefore it was natural to start the player character on the left side of the screen. Still others claim it is a hard-wired part of our brain that left-to-right movement feels more "natural." Other claim that Super Mario Bros. did it, therefore it became standard. These arguments are echoed on The Escapist, Reddit, StackExchange, Resetera, and a study by Dr. Peter Walker of Lancaster University.

Few of these arguments question if there may be technical reasons why left-to-right motion became so prevalent.

Let's Standardize Terminology

Early on in Iwasaki's article, he has a quote that could sum up a lot of what my research means to accomplish.

Recently, I’ve had a few opportunities to talk about the history and technical aspects of games with university professors and graduate students, and I realized that if we don’t standardize terminology from the beginning, it can lead to confusion.

My Taxonomy of Virtual Spaces is an attempt to standardize the language we use to talk about virtual spaces. Instead of throwing around terms like "2.5-D," "top-down," or "isometric," let's agree upon and define what our terminology actually terms.

Iwasaki defines games in which the character moves left to right as Left Scrolling games. Conversely, characters move right to left in Right Scrolling games.

"Left Scrolling" sample image from the article

This makes sense in from the point of view of the graphics projected to the screen. What on the screen is "scrolling?" The background and environment, literally moving by much like unrolling a paper scroll. The environment and background movesto the left, giving the impression that the player character is moving to the right.

Iwasaki doesn't mention it, but this is a technique called induced movement.

Here is an example of induced movement that I use with my students. In the image above, we see the brave aviator Porco Rosso flying through the air in his seaplane. The plane is gently bobbing up and down and we see some secondary motion as the engine vibrates and Porco Rosso's scarf blows in the breeze. However, he doesn't seem to be going anywhere. There is no sense of motion and the aircraft feels static.

The addition of moving clouds provides induced movement to the aircraft. The stationary object appears to move right to left, in the opposite direction as the moving objects in the background. The plane is still smack in the middle of the image, but our brains read it as flying through the sky. This is the same way that side-scrolling games work.

Iwasaki also defines most vertically scrolling games as down scrolling (environment scrolls down the screen). I presume he would call a game like Downwell and up scrolling game.

Iwasaki admits that it is intuitive to think that a right scrolling should mean a game where the player character moves to the right as the environment scrolls. This make sense as we are used to thinking about games from the point of view of our avatar (the "self" in the logical interface between player and gameworld (adapted from terminology in "Nature and Origins of Virtual Environments: A Bibliographical Essay," 1991, Ellis)). Iwasaki had to change his thinking to focus on the thing that is actually scrolling: the environment.

Side-Scrolling Games

Iwasaki's discussion of side-scrolling games starts with the near-simultaneous arcade game developments of Scramble (Jan 1981, Konami) in Japan and Defender (Feb/Mar 1981, Williams) in the US. Scramble's Frame Mobility uses Auto-Scrolling in One Direction on the Horizontal Axis. The player's ship appears to be on an unstoppable march from left to right through the terrain. Defender's Frame Mobility uses Smooth-Scrolling in Two Directions on the Horizontal Axis (with a Mini-Map of the entire level). These innovations allowed players to explore expansive virtual worlds that were much larger than what a single screen could contain.

(Iwasaki also makes a brief mention of Sega's Bomber (1977) as a side-scrolling predecessor, but there is very little information about the game and it is unclear how impactful that title was. Coincidentally, I briefly mentioned Bomber in my last blog post and I haven't found out much about it either.) 

Star Blazer (1982, Broderbund)

Iwasaki quickly moves away from video arcade games with their powerful custom hardware and expensive price tags. Instead, he looks at how side-scrolling games were created on personal computers in the early 1980s. These computers needed to be general purpose, programmable, and affordable in the home and could not match the graphics seen in some arcade game hits. These would include games like Tony Suzuki's Star Blazer (see above), a Scramble-like left scrolling shooter that I put a lot of time into on my school's Apple ][ during lunch breaks. Your ship seems to speed left to right across a landscape filled with vital targets to destroy as enemy aircraft move right to left to attack.

"General Screen Coordinate System of a 2D Game Machine" image from the article

One issue that Iwasaki cites is the standard coordinate system used for placing sprites on the screen (interestingly, he has an aside about how Atari invented sprites, then called "motion objects," for Tank 8 and Sprint 2. According to Iwasaki, it was Texas Instruments that coined the term "sprite" when developing the TI-99 computer). As seen in Iwasaki's image above, the coordinates start at (0,0) in the upper left hand corner. The sprites also use this same coordinate system, where the (0,0) point on the sprite is in the upper left corner of the image.

As shown, sprites can easily be placed in the screen image as long as the upper left corner of the sprite is somewhere on the screen. It is simple to draw a sprite partially off the right edge of the screen and have it move left onto the screen in later frames (left scrolling). Problems come up if you try to draw a sprite off the left edge of the screen (right scrolling) as that would mean placing it into a negative coordinate. These values were often stored as unsigned integers with no ability to be placed in a negative position without special handling.

Technology and techniques evolved and it was possible to right scroll if needed (like in ˆJungle Hunt). But, it was inherently easier to left scroll rather than right scroll.

So, it is simple to draw sprites emerging from the right side of the screen and move left until they hit the left edge of the screen and disappear. The opposite is not as easy to accomplish. For a deep dive into this issue and other fun stories about early game development in Japan, read through the article at the link above.

(Not) Game Genres, pt. 15: Graphical/Spatial Game Characteristics from Understanding Video Games

Taxonomy of Virtual Spaces

This is a continuation of my long-running series examining game spatiality systems that may be related to but are distinctly different from game genres.

This post covers the system of graphical/spatial game characteristics defining the geography and representation in a gamespace presented in the book Understanding Video Games.

Understanding Video Games, 4th edition (Egenfeldt-Nielsen, Smith, and Tosca, 2020)

The authors of this text are Simon Egenfeldt-Nielsen (CEO of Serious Games Interactive and dibl), Jonas Heide Smith (head of digital communication at the Statens Museum for Kunst), and Susana Pajares Tosca (Associate Professor and co-founder of Game Studies journal). The book is intended as a textbook to introduce students to game studies and the concepts of of analyzing game history, game aesthetics, games as culture, games as narrative, and serious games.

Video Game Aesthetics

The chapter on video game aesthetics opens by exploring the concept of a gamespace, defined as "the entire space (or world, or universe) presented by a game." This is similar to my definition of a gameworld, although a game may contain numerous gameworlds which may have different visuo-spatial configurations (see my link for an example of different gameworlds in Contra).

A gamespace is defined in part by its physical laws (pg. 126) (what I've described as the underlying dynamics that determine the rules of action of a virtual environment), perspective (how the player perceives the gamespace), dimensions (2-D or 3-D), space type (what I call gameworld topology), off-screen space (can off-screen elements affect the on-screen player?), scroll (what I call frame mobility), and exploration (can player explore gamespace at their own pace?).

Graphical/Spatial Game Characteristics 

Basic Graphical/Spatial Game Characteristics (adapted from pg. 131)

According to the authors, aspects of gameworlds, except for physical laws, may be defined using the graphical/spatial game characteristics in the chart above. The following compares this system to my own Taxonomy of Virtual Spaces.

• Perspective (1st person/3rd person) - My work does not focus on a game's ocularization. This section does refer to "isometric perspective" and describes "top-down perspective" and "bird's-eye perspective" as the same thing (pg. 131). My own work uses Projection Angles and defines a top-down camera angle as about 60° and bird's-eye camera angle as 90° (keeping in line with the Game FAVR system). I find estimated camera angles are less ambiguous than terms like "top-down."
• Dimensions (two/three) - The authors account for 3-D gamespaces that are "faked" with 2-D methods. Examples include Wolfenstein 3D with its 3-D world populated by 2-D sprite enemies, Sim City 2000 creating a sense of depth with isometric projection, and Moon Patrol using parallax scrolling to create a sense of a deep and distant background behind the gameplay. My system differentiates continuous spatial systems (of two or three dimensions) and discrete spaces of nodal networks (like a game of chess).
• Space Type (torus/abstract/free) - This aligns with what I call gameworld topology. The authors use Torus to describe both topologies that I define as toroidal and cylindrical (games with wraparound screens). It is unclear what is meant by Abstract and Free in the chart above, as these terms do not seem to be extrapolated on in the book's text. In fact, it describes torus space as "abstract" (pg. 136). The text does describe different types of multiscreen games (going beyond early single-screen games like Pong), mirroring my characteristics of Frame Mobility that define the Framing Device. Unconnected Levels include games where new game screens are not necessarily connected to the previous screen, like Bomb Jack and Pac-Man. I define these as Fixed Frame or single-screen games. I argue that games like Donkey Kong imply that the game levels are connected as a single building that Mario must climb (Donkey Kong is seen climbing out of the screen to the next level). Zone-Based Multiscreen Spaces fall under what I call Discrete (or Page Flip) Frame Mobility. This includes games like Atari's Adventure. Seamless Multiscreen Spaces fall under what I call Smooth Scroll Frame Mobility.
• Off-Screen Space (Dynamic/Static/None) - None would include single-screen games with no off-screen space. Static means that off-screen space is "passive" and cannot affect the player. Dynamic means that off-screen space is "active" and can affect the player, such as in a strategy game with fog of war.
• Scroll (Vertical/Horizontal/Free/None) - The text claims that "horizontal scroll was common in many arcade games of the 1970s and 1980s" (pg. 139). I'd argue that horizontal scrolling was extremely rare in the 1970s, with few examples like Sega's Bomber (1977). The text does not offer any examples games that date from the 1970s. The characteristics for this category are similar to my terms defining Frame Mobility Direction of the Framing Device. Vertical and Horizontal match my characteristics of the same names. Free is what I call Any Direction. None matches what I call Fixed Frame.
• Exploration (Forced/Free/None) - This is a concept I don't specifically explore in my taxonomy. My concept of auto-scroll frame mobility is an example of Forced Exploration, but so is any game level with a time limit.

Conclusion

I should add this system to my post about Comparing Visuospatial Configurations and Terminologies. The system expressed here covers much of the same ground as the Evolution of Spatial Configurations in Video Games by Clara Fernández-Vara, José Pablo Zagal, and Michael Mateas (the same system that I analyzed earlier in this series). The authors of this book chose terminology that is generally more common than the terms used in the earlier Evolution of Spatial Configurations system (gamespace instead of gameworld, dimensions instead of spatial representation, scroll instead of spatial configuration). The book cites other works by Fernández-Vara in the bibliography, but not this paper.

I am surprised by the aforementioned errors found in the book (horizontal scrolling common in the 1970s, no explanation of abstract and free space types), especially since I have the 4th edition of this book. However, my biggest issue with this system is that it cannot easily account for the inherently hybrid nature of digital games. There is mention of "faked" 3-D gamespaces inhabited by 2-D characters, but no accounting for a gamespace that features multiple different types of visuo-spatial configurations in one game (like my example from Contra). I don't know what they'd do with a game like Wario Ware.

A "Cartoony" Spatial Paradigm? pt. 7 (Platformer character analysis)

Taxonomy of Virtual Spaces

This post continues my exploration toward evaluating a spatial paradigm of "cartoony" digital games, which evolved through the early 1980s. Part one analyzed two important early titles, namely Cutie Q and Pac-Man. Part two looked at some Pac-Man clones and Frogger. Part three analyzed some "maze shooters" and "maze looters." Part four explores how maze games evolved into platform games. Part five examined "maze tunneler" games where the player digs their own mazes as they explore. Part six looks at games that use a mix of elevation projections.

This post analyzes the development of character designs in early platformer arcade games from 1980-1984, when "cartoony" games were particularly popular. Unlike the typical connection of platfomers with jumping, most of these games were "climbing" or "ladder" games where the player cannot jump (Space Panic, Bagman, BurgerTime, Monster Bash, Popeye, Kangaroo, Elevator Action, Mr. Do's Castle, Mappy, Mr. Do's Wild Ride). Following this is an analysis of Monster Bash, a 

Early Platformer Game Characters

Early arcade platformer game characters 1980-1984

• Space Panic - Side view. See my analysis of this game here and details on the transition from maze games to platformer games. The "Spaceman" is simply and orthographically illustrated with little more definition than a stick figure. The character is limited to a three color palette (2 bits per pixel of color data (allows for palette of 3 colors + transparency) times 256 pixels (16 rows x 16 columns) equals 512 bits or 64 8-bit bytes per frame of sprite information).
• Donkey Kong - Side view. See my analysis here. Mario is far more detailed than the Spaceman protagonist of Space Panic. Both characters are limited to a three color palette and the same sprite size, but Mario has far more detail that would be recognized as cartoon-like. Still, his projection reads as orthographic.
• Bagman - Side view. This game's character graphics are closely adapted from Donkey Kong. The legs are shaped the same as Mario's, along with the convict's sideburns and the guard's hair and hat.
• BurgerTime - Side view. See my analysis here. Peter Pepper's sprites have around 7 different colors and so probably use 3 bits per pixel for color data.
• Donkey Kong Jr. - Side view head, 3/4 view body. DK Jr.'s sprite is 32 pixels wide, twice as wide as Mario and most other sprites shown here. This allows for more horizontal character details and pixels for illustrating a 3/4 view for Junior, though it makes for an awkward platformer character shape.
• Monster Bash - Side view. See below for further analysis. 
  
• Popeye - 3/4 view. See my analysis here. It is easy to see just how huge the characters in Popeye seemed in comparison to most other arcade games of the era. Popeye is about twice as wide and four times as tall as the typical 16 x 16 pixel sprite and the Brutus sprite is even bigger. It is well-known now that Donkey Kong started out as a Popeye-licensed design, but changed before the game was completed. According to research by Kate Willaert, one reason was because it was difficult to create a recognizable Popeye illustration in a 16 x 16 image. One year later, Ikegami Tsushinki developed some innovative arcade hardware capable of displaying very large sprites for Nintendo with Popeye. 
• Kangaroo - Side view. A female protagonist, a rarity at the time. "Mama Roo" is a mother kangaroo fighting and climbing to rescue her "Baby Roo" from monkey kidnappers. The large image size and wide color palette allow for a lot of details, though Mama Roo is still illustrated only in a side view.
• Mario Bros. - Side view head, 3/4 view body. Mario grows up, with 16 x 32 (or maybe 16 x 24?) sprites and a 7 color palette (3 bits per pixel).
• Elevator Action - Side view. Agent 17 has tall 16 x 24 sprites and a 7 color palette with effective animations, though his standing image is flatly illustrated.
• Mr. Do's Castle - Side view. See my analysis here.
• Mappy - 3/4 view. Hiroshi "Mr. Dotman" Ono's pixel art skills are on display here with his illustration for the titular mouse police officer working to defeat a gang of cat thieves. Appears to be a 7 color palette.
• Arabian - Side view.
• Flicky - Side view. Small birds in the Sonic the Hedgehog series of games would take the name of "flicky" from this game.
• Bomb Jack - Side view head, 3/4 view body. The character's body is at a slight 3/4 view with two "buttons" visible on the front of his costume.
• Mr. Do's Wild Ride - Side view. Mr. Do returns in another platformer, this time with an outline drawn around his sprite.
• Pac-Land - 3/4 view. The 32 x 32 image gives Namco's artists plenty of room to add details to Pac-Man in his in a platformer. This game's character models were modified from Namco's original designs when imported to the United States to better match Hanna Barbera's Pac-Man animated TV series that debuted in 1982. The original Pac-Man design had different eyes and sported a jaunty Tyrolean hat, making him look like a Bavarian hiker. 

Aesthetically speaking, Nintendo and Namco the best-looking "cartoony" sprites of this group. In the few short years examined here, sprites became more colorful as 7-color palettes replaced earlier 3-color palettes. Larger sprites could certainly catch one's attention, but the 16 x 16 standard remained a viable character size for many games through the 1980s.

Analysis of Monster Bash

This curious 1982 platformer game from Sega has the hero climbing ladders and fighting against classic monsters from films like Dracula and Frankenstein. The game is a good example of the transitional period from maze games to platformers as the game has both platforming and maze game levels with no change in character graphics or movement.

Monster Bash intro screen

The intro screen serves as a map of the three different levels in the game. Dracula House and Frankenstein Castle are both illustrated in orthographic, elevation projection with a front view. Chameleon Man Graveyard is illustrated in oblique, plan projection in with a bird's-eye view. This makes the map look disjointed, but each projection matches the method used in each different level.

Monster Bash "Dracula House"

"Lil' Red" the hero must face off against Dracula in his house, lighting candles and touching a sword to power up a zapper weapon to defeat the vampire. Lil' Red and the bat enemies are illustrated in orthographic side and front/back views. The larger Dracula sprite is illustrated in 3/4 view. They all explore the environment illustrated in front elevation projection.

Monster Bash "Frankenstein Castle"

This level has the same visuo-spatial configuration as Dracula House, above.

Monster Bash "Chameleon Man Graveyard"

In the Chameleon Man Graveyard, gameplay shifts to that of a maze game with an overhead view, although there is no change to character graphics or movement controls. The relatively small Chameleon Man "boss" character is illustrated in the same orthographic side and front/back views as Lil' Red. The environment is completely different from the other levels, with a plan oblique projection.

This game further supports the theory that early platformer games, especially "ladder" games, evolved from and are derivations of maze games. 

A "Cartoony" Spatial Paradigm? pt. 6 (Mixed elevation projections)

Taxonomy of Virtual Spaces

This post continues my exploration toward evaluating a spatial paradigm of "cartoony" digital games, which evolved through the early 1980s. Part one analyzed two important early titles, namely Cutie Q and Pac-Man. Part two looked at some Pac-Man clones and Frogger. Part three analyzed some "maze shooters" and "maze looters." Part four explores how maze games evolved into platform games. Part five examined "maze tunneler" games where the player digs their own mazes as they explore.

This post examines the "facing" of cartoony sprite characters drawn to game screens using elevation projections (side-facing or front-facing). Pac-Man and Super Mario Bros. both use a mix of front and side views with characters sharing the same game space. Mario's sprites evolved through different projections over several games until settling into a 3/4 view: side-facing but slightly twisted to show detail on the front of the character. This matches the acting method of "cheating out," where actors in profile will turn slightly toward the camera or audience to be seen better.

Back to Pac-Man

Pac-Man level 256 glitch

I wrote up a visuo-spatial analysis of Pac-Man way back in part one of this series, copied here:

Pac-Man Visuo-Spatial Analysis: The game screen emulates an orthographic plan view of a maze (not unlike a hedge maze) seen from overhead. It could be argued that the maze is seen from the side, but the lack of gravity that pulls to the bottom of the screen (this is not a platformer) and similarity to overhead driving games like Head On support a view from above. The character images are shown in orthographic front and side elevation views, much like in Cutie Q. This creates an incongruity between characters and their environment, one that I wrote about before (see the Orthographic Projection section). The game has a sense of continuous 2-D game space limited to a single screen (fixed frame) with a cylindrical topology (characters may move directly from one edge of the maze to the other by using the side tunnels).

Pac-Man characters

The characters of Pac-Man are illustrated in two different types of elevation projections. The ghost monsters look around toward the direction they are moving, but they read as front-facing because both eyes are visible to the player. Pac-Man is seen as side-facing, clearly showing his opening mouth in profile. The characters are drawn as if facing in different directions, yet they still read as if they are sharing the same space.

The Front-Facing Goomba

Super Mario Bros. Goomba, Koopa Troopa, and Super Mario

In Super Mario Bros., most enemy characters are drawn in a side-facing projection with two frames of animation, like the Koopa Troopa above. When such a character moves in the opposite direction, the frames of animation are flipped to face the other way. The Goomba is unusual in that it is a front-facing character with only one sprite frame that is mirrored left and right to give the illusion of a walking animation.

Blooper and Toad are the only other front-facing characters in SMB 1. Lakitu and Cheep-Cheep are drawn in 3/4 view. All other characters are side-facing.

As revealed by designer Takashi Tezuka in an Iwata Asks interview, The Goomba was the last character designed for the game and there were very few bytes available for additional graphics in the game cartridge's CHR-ROM chip. The team only had room for one 32 x 32 sprite that could be "animated" by flipping the image. They settled on a front-facing character that would look fine walking either left or right.

Early Incarnations of Mario

The Australian author and pixel artist known as NFGMan analyzed several different eras or generations of early Mario sprite designs. These sprites are organized by shared qualities in visual style rather than being strictly organized by year. This shows how different artistic styles may overlap in time and a single art style may transcend hardware devices.

"Mario 1.0" sprites, image from NFG Games The Evolution of Mario

Standing Mario sprites in the first image:

• Donkey Kong (1981, arcade)
• Donkey Kong Jr. (1982, arcade) (as the villain)
• Mario Bros. (1983, arcade)
• Wrecking Crew (1985, NES)
• Super Mario Bros. (1985, NES) (with Super Mario sprite)
• Super Mario Land (1989, Game Boy) (with Super Mario sprite).

Each of these early Mario sprites features a side-facing head seen in profile. Each Mario head shares distinctive features, with one visible eye, a crooked nose, sideburns, and bushy long hair.

The sprite bodies are drawn in different facings. The Donkey Kong sprite is close to a side view with one foot in front of the other, ready to move forward. The Donkey Kong Jr., Mario Bros., and Wrecking Crew bodies are drawn in more of a 3/4 view, with the front of Mario's overalls visible. Note that Mario's feet are pointed in both directions, ready to turn on a dime and start running. The Super game sprites all have front-facing bodies with body weight balanced in both the left and right directions.

"2nd Gen Mario" sprites, image from NFG Games The Evolution of Mario

Standing Mario sprites in the second image:

• Super Mario Bros. 2 (1988, NES) (with Super Mario sprite)
• Super Mario Bros. 3 (1990, NES) (with Super Mario sprite)
• Donkey Kong (1994, Game Boy)

This era of Mario sprites is notable for their dark outlines that help the character stand out from many different types of backgrounds.

Mario's hat has undergone a change, now looking more like a newsboy or fisherman's cap than the previous baseball cap appearance. The SMB 2 head is turned in a 3/4 view, with both eyes and both sides of Mario's mustache visible, but the other two games return to a side view profile. SMB 2 and SMB 3 give Mario a cartoonishly round nose while DK '94 gives Mario back his crooked, original nose.

The SMB 2 and SMB 3 bodies are at a slight 3/4 view, with both of Mario's overall buttons visible in his Super incarnations.

The DK '94 design, with its side view profile, crooked nose, and long hair, is intentionally anachronistic to harken back to Mario's arcade Donkey Kong roots. However, he does retain the big eyes and updated cap.

"The Mario Renaissance" sprites, image from NFG Games The Evolution of Mario

Standing Mario sprites in the third image:

• Super Mario World (1991, SNES) (with Super Mario sprite)
• Super Mario All-Stars (1993, SNES) (SMB 1 design, with Super Mario sprite)
• Super Mario All-Stars (1993, SNES) (SMB 2 design, with Super Mario sprite)
• Super Mario Land 2 (1992, Game Boy) (with Super Mario sprite)

Mario's design did not change much in the transition from the NES to the SNES, but the 16-bit system did allow the characters to be drawn with more colors. Super Mario All-Stars rereleased the original three Super Mario Bros. games with updated art on the SNES.

Super Mario World and Super Mario Land 2 designs closely follow the 3/4 view, round nose, and big eyes seen in the original SMB 2 design. The Super Mario All-Stars designs mostly follow the original games, with the exception that the All-Star SMB 1 uses graphics nearly identical to SMB 3 (not shown). 

Over 12 years of development (not counting DK '94), Mario's design evolved from a flat profile view to a full-body 3/4 view, giving an enhanced sense of dimensionality to the character and conveying more facial details.

To be continued...

Sluggo the Virtual Puppet: Part 4

Continued from Part 3.

Winter 2025 Review: Sluggo the Virtual Puppet

Sluggo says "hello"

This is a continuing journal of my project to design and build "Sluggo," a physical hand puppet that I digitized, rigged, and developed with hand gesture controls in Unity.

Bringing Sluggo to Life

The model was rigged with a skeleton and the skin was bound with weight paint. The final model was ready to bring into Unity for hand tracking control.

Step 1: Import to Unity

Sluggo in Unity

I exported the model from Maya to fbx format and imported it to Unity 2022.3.37f1. I used the same project that I had done some Mediapipe experimentation in earlier and already had many of the hand tracking control elements elements ready to go.

I had a moment of panic when I tested Sluggo's skeleton and found none of the joints would move any part of his body. Returning to Maya, I found that the "Animation" option was turned off in my export settings, which included skin weights. I re-exported with the option turned on and the mesh operated flawlessly in Unity.

Step 2: Test the Limits

Sluggo out of his "default" pose

I rotated each of Sluggo's joints that I wanted to control to determine the limits of motion and axis of rotation for each. For example, the lower lip joint could move about 75 degrees to close his mouth and each of the spine joints can bend about 30 degrees so that Sluggo can comfortably face the camera or look down.

Step 3: Hand Tracking

Courtesy of Mediapipe

I used the Unity plugin for Mediapipe for hand tracking. This system tracks one or two hands from a visual input like a webcam. The hand is tracked as a list of "landmarks," each representing a specific position on the hand in the 2D visual input. The developer can take those positions and use some math to determine the angle and gesture of each individual finger. For example, I can take the vector between landmarks 17 and 20 to determine the angle of the pinky finger. Once I know that, I can use that data to control the rotation of one of the eyestalk joints.

Step 4: Visual Scripting

My visual script to control Sluggo

I also took this project as an opportunity to try Unity's relatively new visual scripting platform. I am well acquainted with using C# with Unity and I've used Unreal's Kismet and Blueprint visual scripting, but I hadn't tried this one yet.

On initialization, the script tracks and stores the default rotation values of any joints that are controlled by hand tracking (this is all tucked away into a subgraph triggered by On Start). On every frame, the script analyzes the positions of certain hand landmarks (the lower right hand part of the graph) and sets the "bend" value for certain joints accordingly. Also on every frame, the script adjusts the rotation values of the controlled joints according to its current "bend" value (the unlabeled section just above the center of the graph). Each joint processes a subgraph I labeled "MySetRotation" that takes in the game object reference, the default rotation vector, the maximum rotation in degrees, and the bend value as arguments.

Mediapipe also generates a square to track where the hand is in the image, how large it is on the image, and what rotation it is on the image plane. I use this information to set Sluggo's position, rotation (perpendicular to the image plane), and proximity to the game camera. I also track the vector between landmarks 17 and 5 to how much the wrist is rotated and use that data to pivot Sluggo left or right.

Step 5: Completion

Sluggo the Virtual Puppet: Part 3

Continued from Part 2.

Winter 2025 Review: Sluggo the Virtual Puppet

Virtual Sluggo giving you the side eye

This is a continuing journal of my project to design and build "Sluggo," a physical hand puppet that I digitized, rigged, and developed with hand gesture controls in Unity.

Rigging Sluggo

The model was cleaned up and retopologized. Next, it needed a skeleton and skin binding so that the static mesh could be controlled dynamically through animation.

Step 1: Create the Skeleton

Sluggo in the X-ray machine

Most rigging tools are designed to create a skeleton for a humanoid bipedal character. Sluggo has a very different body from a human, so I needed to create a custom rig.

Starting at the root, Sluggo's has a few spine joints to the base of his head, which also serves as the pivot point for his jaw. One joint controls the lower lip, which should flap open and closed when talking, controlled by my thumb. The upper lip is controlled by two different joints, controlled by my middle and ring fingers, which should allow me to manipulate them individually to "scrunch up" his upper face. This effect is used to express frustration in Muppets like Kermit and Elmo.

The two joints from the top of the head from the bases of the eyestalks will remain static. The eyestalks are controlled by my index and pinky fingers.

Step 2: Paint the Weights

The influence of Sluggo's lower lip

Next, I painted the amount of influence each joint has on how the mesh deforms when it moves. Maya automatically set weight paints when the skin was bound to the skeleton, but these were not very good. I ended up flooding all influence weight to the root, then painstakingly hand-painted weights for each joint.

This section of the report only has two steps, but weight painting a deforming, cloth model took some time with tuning and refining to look good in different poses.

Next Step: Controlling in Unity

"Haven't I been through enough?"

Sluggo the Virtual Puppet: Part 2

Continued from Part 1.

Winter 2025 Review: Sluggo the Virtual Puppet

Sluggo in the digital realm

This is a continuing journal of my project to design and build "Sluggo," a physical hand puppet that I digitized, rigged, and developed with hand gesture controls in Unity.

Digitizing Sluggo

The first step in this multimedia project was to design and produce a physical hand puppet, affectionately named "Sluggo."

Step 1: Scanning

The scanning process

The physical puppet was set on a table atop a water bottle to hold it motionless during the scanning process. A hand scanner was used to digitize the puppet from every angle.

Sluggo the point cloud

The scanning process produced a cloud of colored points. The scan did a good job of capturing the details of the folds in the felt, the points where the pieces were sewn together, and the general color of the puppet. The point cloud needed to be converted to a triangular mesh with a material before further work could be performed.

Sluggo in Maya with 122K+ triangles

The 3D model is highly detailed with more than 122,000 triangles. I felt that performance would be improved in my planned real-time environment if I didn't have such a high-poly mesh to work with. Additionally, I could work more easily to edit the mesh if it was retopologized and quadrangulated (I can triangulate it for use in Unity later). I attempted to reduce the polygon count in Maya, but the command would either fail or produce an unsatisfactory result. 

Step 2: Correcting Errors in the Model with Meshmixer

Sluggo in Meshmixer

Autodesk Meshmixer is a relatively easy-to-use tool designed for use with 3D printing, but it can be repurposed for many types of 3D models. I sculpted the mesh to remove the few errors and aberrations from the scanning process, mostly around the base of the puppet (the end of the "sleeve") and to build up structure that was lost on the eyeballs. Unfortunately, this added a lot of polygonal detail in the areas where I was sculpting, mostly notably in the eyeballs.

Step 3: Retopologizing in Instant Meshes

Sluggo getting a new topology in Instant Meshes

Instant Meshes is a tool used for creating Instant Field-Aligned Meshes, based on a paper published by ACM. This tool helps create a topology that aligns well with the shape of a mesh, with the user able to paint direction lined directly ono the mesh, "combing" the lines of topology in specific directions. This quadrangulated the mesh and reduced to the polygon count, but unfortunately, it also destroyed the work I had done to fix the eyeballs. The ends of Sluggo's eyestalks became thin and pointy.

Step 4: Clean up in Mudbox

Sluggo in MudBox

Autodesk Mudbox is a sculpting tool that allowed me to "puff up" Sluggo's eyeballs and give them back the structure lost in the previous step of the process. I then corrected any errors in the texture material by using the stamp tool directly on the model, which works a lot like the stamp tool in Photoshop. I also flattened out the half circles that comprise Sluggo's mouth and refined other parts of the model.

Step 5: Back to Maya

Sluggo in Maya down to 77K+ triangles

The mesh now has a quad topology and is reduced to 77,000+ triangles. That is still a higher polygon count than I think I'll need, but I know that I want extra detail in the mesh so that it can nicely deform as it animates.

Next Step: Riggging