Game Genres, pt. 16: Facet Analysis of Video Game Genres

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.

Today's post returns to actual game genres with a look at "Facet Analysis of Video Game Genres," a thorough study of different systems found on game websites and in scholarly publications that are used to categorize digital games by genre. This may include gameplay genres (platformer, racing game, shooter) and thematic genres (fantasy, crime, food). This informed the researchers' work to recategorize the various systems into one overarching system of game genres defined by 12 different facets.

"Facet Analysis of Video Game Genres" by Jin Ha Lee, Natascha Karlova, Rachel Ivy Clarke, Katherine Thornton, and Andrew Perti (2014)

The study was performed mostly by researchers at the University of Washington's GAMER Game Research Group and presented as part of the University of Illinois Urbana-Champaign's iConference 2014. GAMER was formerly the GAme MEtadata Research Group, and supporting researchers and archivists with tools for cataloguing and organizing digital games as cultural artifacts is one of the group's primary goals.

Facets and Foci

The thorough system outlined in the paper is based around 12 different facets or aspects by which one can differentiate a game. Within each facet, a game may fall under one or more foci that accurately describe the game:

Table 1: Video Game Genre Facets with Examples of Genre Labels Representing Each Facet

The above table, adapted from the paper, shows only a handful of possible examples of foci defined in this system. The facet of Style alone has 100 different variations. This is a robust system for defining and categorizing all manner of digital games with a singular system. Additionally, game can easily be organized using only the facets that a researcher is most interested in.

For my research, how well does this system categorize the spatial aesthetic qualities of digital games?

Facet Analysis and Spatiality

The concept of spatiality was not a primary concern for the GAMER Group researchers. Their work is based on existing methods for categorizing game genres, which do not tend to focus on spatiality. However, the facet of Presentation encompasses some of the graphic techniques used to project a virtual space to the screen and provides the best comparison.

Presentation and its related foci are described in the paper exactly as follows:

Presentation is defined as “the manner or style of game display” containing the following ten foci:

• 2D: Representation of space in two dimensions. (e.g., A Boy and His Blob, Odin Sphere)
• 3D: Representation of space in three dimensions. (e.g., God of War, Uncharted)
• Isometric: Games that use isometric projection to render three-dimensional objects in two dimensions. (e.g., Final Fantasy Tactics, Age of Empires)
• Static background: Games with a background display that does not move or change. (e.g., Peggle, Princess Maker)
• Vertical scrolling: Games with a display that scrolls vertically where characters typically move from bottom to top. (e.g., 1942, Raiden)
• Side scrolling: Games with a display that scrolls horizontally where characters typically move from left to right. (e.g., Muramasa, Castlevania: Symphony of the Night)
• Grid-based: Games featuring a display that is made up of a series of intersecting vertical and horizontal axes. (e.g., Bejeweled, Tetris)
• Video backdrop: Games based on interacting with a motion-video backdrop, either as scenery or an enemy (modified from mobygames.com). (e.g., Area 51, EyeToy Groove)
• Text-based: Games that use text as the main display method.
• Perspective manipulation: Games where characters are able to switch between multiple display methods (e.g., 2D to 3D or vice versa). (e.g., Super Paper Mario, Perspective)

Defining this facet presented another challenge: what is the nature of the relationship between the Presentation and Artistic style (see below) facets? After lengthy discussion and examination of extant terms and screenshots of game displays, we determined that it would be useful to separate the technical aspects from the artistic or aesthetic aspects of game display. Thus two different facets in our scheme describe the visual aspects of video games.

This is a mix of terms that can describe the spatiality of the gameworld (2D, 3D), frame mobility (scrolling, static background), and even a non-project method of spatiality (text-based). I'll show how each focus aligns with terminology in my taxonomy.

Comparing Presentation to Taxonomy of Virtual Spaces

• 2D: Aligns with Gameworld Spatiality: Continuous, 2-D. There is not delineation in the Facet Analysis system between continuous and discrete (individual nodes in a network, like a chessboard) spatiality.
• 3D: Aligns with Gameworld Spatiality: Continuous, 3-D. 
• Isometric: The researchers' definition of this term, according to what is in the paper, is unclear. The examples given above (Final Fantasy Tactics, Age of Empires) are generally described as "isometric" (what my Taxonomy defines as an Axonometric Projection (further defined as dimetric in these cases)). However, the paper also refers to Mortal Kombat 3 as "isometric." Do the researchers define any 3-D objects rendered in a 2-D gameworld as "isometric?" In the case of MK3, the characters are based on photographs, the environment is rendered in 1-point perspective, and the background is multiple flat layers rendered in parallax to give an impression of depth. 
• Static Background: Aligns with Frame Mobility: Fixed.
• Vertical Scrolling: Aligns with Frame Mobility: Non-Fixed, Smooth-Scroll, Vertical Axis. There is no delineation between normal scrolling (like Ikari Warriors) and Auto-Scrolling (like Raiden).
• Horizontal Scrolling: Aligns with Frame Mobility: Non-Fixed, Smooth-Scroll, Horizontal Axis.
• Grid-Based: No real equivalency. 
• Video Backdrop: No real equivalency. Defined with the Taxonomy by the projection method used in the video backdrop.
• Text-Based: Aligns with the Non-Projection Method: Text Description.
• Perspective Manipulation: Such games are defined by the different possible perspectives as options in my Taxonomy.

Comparing Artistic Style to Taxonomy of Virtual Spaces

The Artistic Style facet compare the graphics used in a game to other forms of visual media (like manga or watercolors) and most don't really align with the concept of spatiality. The Artistic Style focus of Abstract would seem to align with my Taxonomy Non-Projection Method: Ambiguous, but the two concepts are different.

The Abstract examples include Lumines and Dyad. While both games may commonly be referred to as "abstract," everything in the game is strictly representational. A square of light in Lumines is still recognizable as a square of light that aligns to the game's 2-D plane. A spinning cylinder of fog in Dyad is still recognizable as a cylinder rendered in a 3-D perspective. These may not represent anything found in the real world, but they are unambiguous and project specific objects that exist in the space of the gameworld.

Ambiguous means that part of the game image is strictly non-representational: the player is not supposed to have a clear sense of space in this case. An example that I've referred to before is in the battle screens of Earthbound.

EarthBound (Ape Inc., 1995 (originally Mother 2 in Japan, 1994))

The background is completely ambigous: an ever-morphing, undulating fog of squiggly shapes with no sense of space. The Starman Jr. enemy is clearly rendered and represented, but the player has no sense of where they are in the gameworld. We don't know how far that "fog" goes behind the enemy, or if this is all just an effect meant to convey the mind-altering aspects of psychic combat. It is left as a mystery, which makes it ambiguous.

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