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...

Completing the World of Super C

Taxonomy of Virtual Spaces Part II

I completed adding environmental geometry and gameplay functionality into my recreation of Area 1, Fort Firestorm from Super C (Konami, 1988).

Ramps

The biggest hurdle to recreating this world was the existence of ramps. The platformer character controller script I wrote was based on the controls for Super Mario Bros. That game has no sloped surfaces that the player can walk on at all. All surfaces are sheer walls, floors, and ceilings. When I first tried to use my character controller on a sloped surface, my character just slid uncontrollably down the slope.

The SMB team did plan to incorporate sloped surfaces, just like in Donkey Kong [source: Satoru Iwata looks over some early SMB development documents and says, "Looking at these specs, it says, 'Add refinements focusing on Donkey Kong's slopes, lifts, conveyor belts and ladders...'" Of that list, only lifts made it into the final SMB game. (Nintendo, 2010, "Volume 5: Original Super Mario Bros. Developers," Iwata Asks: Super Mario Bros. 25th Anniversary, https://iwataasks.nintendo.com/interviews/wii/mario25th/4/2/)]. The team decided to simplify things by making the game worlds out of rectangular blocks instead. Slopes were not introduced to the SMB game series until Super Mario Bros. 3 (JP: 1988, US: 1990).

Debug images show the character's velocity vector as a cyan-colored line

My platformer character controller needed to be modified so that the avatar could run up or down a slope without it affecting their running speed or their ability to jump. In short, I added a new "ground" collision layer named "ramp." When standing on flat ground, they may run directly to the left or right. When standing on a ramp, all of their movement vectors are rotated to be relative to the ground plane of said ramp. Running left or right moves the player parallel to the ramp's surface. When the player jumps, the surface of the ramp is ignored and all movement is calculated just as if the player character stood on flat ground.

Background Towers

Several different types of towers are seen in the near background of the level. Note the graphic difference between the large towers in the original game and the ones in my project. These buildings serve to showcase two aspects of my research:

- Multiplanar Space

The towers are in the background of the player's plane of action and cannot be used by the player for navigation (the player avatar cannot jump onto the towers and cannot enter the doorways). However, enemy characters can use the towers and as vantage points and spawn points, as seen in the image above. Implied enemy soldiers even throw grenades from behind some towers (not shown).

The player avatar can indirectly affect this background layer by shooting. Bullets strike any target within the plane of projection, whether they are in the primary plane of action or in the background layer. The player avatar can collide with and be shot by background enemies as well.

In actuality, the enemy characters are always on the same plane of action as the player avatar. The background towers and walls serve as parts of the environment that only enemies can stand on. These rules, combined with the way the towers are drawn on the screen, create the illusion of a multiplanar environment.

- Hybrid Visuo-Spatial Projections

The towers serve as a good example of the hybrid nature of digital game graphics. This is a subject I've written about many times and it serves as a core feature of my Taxonomy of Virtual Spaces system.

Digital games, like all digital media, are hybrid in nature. Various symbols appear on the screen, sometimes using different means of projection or perspective, yet the player views all the disparate objects as part of a cohesive whole. (Source)

All video game imagery is a hybrid collection of smaller images displayed and moved around a screen in order to generate a complete picture of the agents and environment of a virtual world. Those hybrid images may be "seen" from different angles from each other, yet we still understand the image as projecting a single, virtual space. (Source)

The two different towers shown in the image are projected by different methods. The smaller, boxy towers use the same cabinet oblique projection as much of the rest of the environment. This is a paraline projection where receding lines are all in parallel (see the yellow lines in the image). The larger towers on girders use a naive perspective projection that is similar to 1-point perspective, but the receding lines do not quite converge on the same vanishing point (see the cyan lines in the image). The roof is approximately in 1-point perspective, but the floor uses an oblique projection. The two combine into a naive perspective with opposite oblique projections that approximate receding lines that converge in the distance. This is why the larger towers look strange in my project when rendered in cabinet oblique projection.

Dream of the Palace (Giotto di Bondone, 1297-1300)

Naive perspective is often seen in western art before Alberti published Della Pittura (1435), detailing the methods of linear perspective developed by Brunelleschi during the Italian Renaissance. Artists like Giotto painted buildings with roughly converging receding lines (or orthogonals) to approximate a perspectival view.

Art and Representation (Willats, John, 1997, pg. 64)

As seen in John Willats' analysis above, there is a sense of a horizon line near the center of Giotto's palace, where the receding lines are horizontal on the picture plane. Each floor of the palace is painted at an oblique angle tilted toward that horizon line. These receding lines do not converge and do not form a linear perspective.

Level End and Beyond

The end of the level leads into a large building through what appears to be a breeched garage door. This serves as a transition to Area 2, First Base in which the view becomes planometric naive perspective (with a bird's eye view looking down at the floor). Area 3, Jungle changes again with an elevation vertical oblique projection. Area 4, Inner Base starts with elevation cabinet oblique right projection followed by elevation naive perspective. Area 5, The Cliff starts at elevation vertical oblique projection, then switches to elevation cabinet oblique right projection (note that Area 1 is left projection). All of the first five levels of this game use different projection methods for their environment art assets.

A question that may be asked here is why? There are several possible reasons. One may be a desire for visual variety. This makes sense with the variety of navigational gameplay in different levels (horizontal side scrolling elevation view, vertical scrolling elevation view, vertical scrolling planometric view). Another possibility is that different artists worked on different levels (although I think that Setsu Muraki was the only artist for game graphics).

Framing the World

Taxonomy of Virtual Spaces Part II

An important aspect of my "Taxonomy of Virtual Spaces" (Rowe, unpublished) system for analyzing digital environment aesthetics is in defining how the world is framed by the screen. As I detailed in a previous blog post, the concept of the screen as a framing device or "window" through which a player observes a virtual world is one formalized by Clara Fernández-Vara, José Pablo Zagal, and Michael Mateas. In paper published through DiGRA, they state that “The screen is the basic unit of space in videogames, since it frames the interface” (Fernández-Vara et al., "Evolution of Spatial Configurations In Videogames," 2005). The screen can act as a yardstick by which we can measure the virtual space, one screen at a time, at least in most 2-D games.

The screen's parameters and motions are often described in camera terms, like a tracking shot following the player character or zooming in on a target. I argue that 2-D games do not have a concept of a game camera, which would imply a view from a fixed station point (the oculus). 2-D use paraline projections instead of perspectival views and there is no station point. The Unity game engine still uses an allegorical "orthographic camera" object to act as framing device for 2-D games, but does not construct an image of the world the way a camera or an eyeball would.

Virtual Worlds of the NES

BG Planning Sheet used in developing Super Mario Bros.

Nintendo's Famicom/NES game console was capable of displaying a 256 x 240 pixel image on a standard definition, 480i resolution screen with a 4 x 3 aspect ratio. These pixels are slightly wider than they are tall due to the fact that 256:240 is not exactly a 4:3 ratio, so they are stretched horizontally. Game backgrounds are typically divided into 16 x 16 pixel tiles (in truth, 16 x 16 metatiles created from four 8 x 8 tiles), so one screen is 16 tiles wide and 15 tiles high.

Blank BG Planning Sheet from Nintendo

Game developers at Nintendo used an internal form called a BG (background) Planning Sheet when devising the graphics for their games. This form includes a grid 16 tiles wide and 15 tiles high to represent the graphics that can fit on one screen. A CRT television would often have a bezel around the screen that would obscure part of the image, so important objects and data could only be shown on the TV's "tile-safe area" away from the edge of the display. You can see plus signs (+) marking the corners of this area on the sheet above.

Converting to 16 x 9

Mega Man (1987, Capcom) and Shovel Knight (2014, Yacht Club Games)

Yacht Club Games wanted to emulate the look and feel of NES platformer games like Mega Man in their own Shovel Knight. They faced the same problem: how to convert the graphics designed for a 240 pixel tall 4:3 display to a high definition 1080 pixel tall 16:9 display? They solved this by a method they call "breaking the NES." Each "pixel" of graphics in the game is displayed at 4.5 x 4.5 pixels. 1080/4.5=240, giving a effective vertical resolution of 240 pixels. Keeping the same vertical resolution of the NES gives them a 400 x 240 widescreen display area. Screens are still designed to be 15 tiles tall, but can extend further left and right than NES games. See the image above to see Shovel Knight side-by-side with original NES graphics. Yacht Club Games doesn't have to worry so much about a TV's tile-safe area, so they can display text much closer to the edge of the screen than NES developers could.

Super Mario Bros. and my project

This is the approach I've taken with my project as well. I am not trying to emulate pixel graphics as that is not the focus of my research, but I am copying the same vertical screen heights of objects (characters, obstacles, blocks) as seen in NES era platformer games. This preserves the size of objects on the screen, even when displaying on a 16 x 9 monitor.

Adding Implied Details of Depth

Taxonomy of Virtual Spaces Part II

I continue to work on my platformer game expansion to my interactive Taxonomy of Virtual Spaces project. This overall project is being created to explore the aesthetics of primary geometry methods used when virtual spaces are projected onto a game screen in different visuo-spatial configurations.

World 1-1 in 3-D doesn't look that different from 2-D

The initial geometry I created for my platformer world was equal to World 1-1 of Super Mario Bros., but it all looked highly artificial from a perspectival view. I made several simple changes to the level objects to convey the implied dimensionality of the objects in the game based on how they are rendered.

This page references several original Super Mario Bros. design document images that have been shared by Nintendo through the Super Mario Bros. 30th Anniversary Special Interview, Iwata Asks Bonus 1: Ancient Documents from 1985, and an Asahi Shimbun article. These files have been preserved by Gaming Alexandria.

The path "width"

It seems odd to see the character running on a one-block wide pathway. Judging by the early SMB design document shown above, the "ground" layer might have had some visible depth, with receding lines drawn vertically on the screen in a vertical oblique projection (see this previous post for more analysis and comparison to other NES games). There is a sense that there is some foreground space in front of and some background space behind the character on the ground surface.

To mimic this look, I changed the ground elements to be 2 blocks deeps. Floating blocks in the image above do not have the same sort of receding lines, giving the impression that they are not as deep as the ground surface. I left those elements at 1 block deep.

The Warp Pipes

The green warp pipes are clearly intended to be cylinders, as they mimic both sewer pipes (a direct reference to the original Mario Bros.) and planter pots (with piranha plants growing out of them). All of the pipes are 2 blocks wide on the screen and thus, presumably, 2 blocks deep as well. The dithered shading and highlights imply a metal pipe painted green with a shiny paint. The direction of the highlight signifies that the light source is to the left of and behind the "camera."

My pipes are all now 2 block wide cylinders of varying heights. In perspectival view, the circular tops of the cylinders look unusual, but I have found that this is often the case when drawing a circle in 1-point perspective. This is little more than Unity's default perspective camera so far; I still need to add capabilities for other projection methods.

Stairblocks

These blocks are commonly used to make "staircase" patterns in SMB, such as a staircase leading to a platform at the end of a level, just before the flagpole. Unlike bricks and other blocks, stairblocks (so named in the official strategy guide How to Win at Super Mario Bros. (Nintendo, 1987)) appear to have beveled edges, with strong highlights on the upper and left edges and shadows on the lower and right edges.

To match this, I beveled the edges of the stairblocks in my world. The lighting also roughly matches the implied lighting of the original game.

Castle

World 1-1 ends with a two-section castle, over which fireworks may explode if the last digit of your timer is a 1, 3, or 6. The wider base of the castle appears to be a gatehouse with battlements across the top of the wall. Behind the gatehouse there appears to be a narrower and taller tower keep, also with battlements across the top of the wall.

The front face of this castle wall appears to be flat (like a brick wall) as opposed to round (like the warp pipes). The battlements on the far left and right side give the impression that the castle walls are 1/4 block thick. I created a roughly square gatehouse and a smaller, similar keep.

Conclusion

As far as gameplay goes, none of these changes have made any difference in the environment. All of the invisible colliders are exactly the same. In 2-D orthographic projection, the only differences are in lighting and shading: all of the shapes are exactly the same size on the screen. In 3-D perspectival view, this begins to feel more like a fleshed out world, even though many detail elements are missing (such as bushes, hills, and clouds).

Shifting Dimensions in Platformer Spaces

Taxonomy of Virtual Spaces Part II

I continue to work on my platformer game expansion to my interactive Taxonomy of Virtual Spaces project. This overall project is being created to explore the aesthetics of primary geometry methods used when virtual spaces are projected onto a game screen in different visuo-spatial configurations. 

3D Nintendo Mario by Justin Buovino (2009)

In other words, what is the experience of playing a video game using a different projection method? Artist Justin Buonvino uses Bryce software to create renders of NES game environments as if the games could be played with 3-D perspectival projection (linear perspective) methods. This shows a dimension of depth to the 2-D characters and environment, something that may be closer to the player's mental model of the game even if it isn't expressly shown on the screen.

3D SEN by Geod Studio

3D SEN by Geod Studio is an impressive piece of NES emulator software that can "3Dify" NES games, making them literally playable in a perspectival projection. Developer Tran Vu Truc has painstakingly set screen depth and model data for game objects in many NES games so that Mario's warp pipes are rendered as cylinders, for example. The program even allows users to play their NES games in VR.

Flipping between two views of the same space in Super Paper Mario (Nintendo, 2007)

Even Nintendo toys with this concept as a gameplay feature in the Paper Mario series of games. The titular character can "flip" between dimensions, shifting to a 3-D perspective to overcome obstacles that are a challenge in 2-D perspective.

My project in orthographic projection

My project in 1-point perspective

To start, I've created a replica of World 1-1 from Super Mario Bros. as a default environment for now. I can shift between two different projections at the moment and the controls feel fluid and snappy. The camera settings are set so that the virtual world is framed at the same scale as the original game, as in the screen frames a 15 block high view of the environment (like in SMB). The 16x9 window is obviously much wider than the NES 4x3 aspect ratio, so I change colors on the ground surface every 16 blocks, which would be one screen width on the NES.

Testing the Numbers for Platformer Player Controls

Taxonomy of Virtual Spaces Part II

As detailed in my last post, I used Excel to create formulas to translate Super Mario Bros. physics values (measured in pixels and frames) into metric values (meters and seconds) so that I can use them with my character controller in Unity. It didn't take long to realize that something was wrong.

These make for VERY slow acceleration!

For the acceleration values, I multiplied the calculated distance values by 60 when I meant to multiply them by 60^2 (3600). No wonder my character seemed to get up to speed slowly: I was off by a factor of 60! Once I made that change, the character felt much snappier.

When comparing directly to SMB, my run speed seems slightly fast. In SMB, it takes Mario about 3 seconds to cross one screen width (16 blocks) from a standstill when walking and about 2 seconds when running. My character is covering that distance (16 meters) in a little less time (about 2.6 and 1.6 seconds, respectively), but it is close enough that I can move on and concern myself with other aspects of the controller.

Implementing Player Platformer Controls

Taxonomy of Virtual Spaces Part II

After determining the formulas to use to design a player avatar controller for 2-D platformer style gameplay, I need to actually create the code and determine what values to use. How fast should the avatar run? How high should they jump? How far can they jump? What about double-jumping, jump-dash, or other types of movement?

This project is focused on game spatiality, so the character controller is really just a means to an end. The controls should be intuitive, familiar, uncomplicated, and even archetypal. As a start, the obvious choice would be to emulate Super Mario Bros.

Start with Super Mario Physics

A Complete Guide to SMB's Physics Engine by Jdaster64 (link to archive.org)

How fast does Super Mario run? How high does he jump? How far does he jump? This information was collected by Jonathan Aldrich, a.k.a. Jdaster64. Aldrich has spent years meticulously compiling mathematical data about how many Nintendo games function. His A Complete Guide to SMB's Physics Engine document, linked above, gives information on how Super Mario and Luigi move in Super Mario Bros. and the Japanese version of Super Mario Bros. 2 (known in the USA as Super Mario Bros.: The Lost Levels).

I don't know about Aldrich's methodology for acquiring his data and it would be prohibitively difficult to verify every value he's posted. However, I only need a controller that feels authentic to the player, not an emulation with pixel-perfect accuracy. At a cursory examination, his numbers make sense, and I will certainly know from testing if the results are accurate.

Aldrich's distance values are measured using screen units that make sense from the structure of the NES game console. Each different unit of measure is 1/16 the size of the previous unit and each is recorded using a hexadecimal value. One "Block" is 16 pixels across (using the basic 16 x 16 tile size of the NES). One "Pixel" is about 1/240th of the height of the screen and 1/256th of the width of the screen (the NES displays this to fit in the 4:3 aspect ratio of a standard definition television, so the pixels are slightly wider than they are tall).

SMB also tracked fractions of pixels of distance, which allowed for very precise values for acceleration and speed. There are also "Subpixels" (1/16 of a pixel), "Sub-subpixels" (1/256 of a pixel), and even "Sub-sub-subpixels" (1/4096 of a pixel).

Velocity is measured as distance moved per frame, or in 1/60 of a second. Acceleration is the amount of velocity change in 1/60 of a second.

How Many Pixels per Meter?

Converting Aldrich's values to metric

Virtual spaces in the Unity engine are measure in meters, which are typically equal to our own real-world metric system. I reckon that one block should be equal to one meter. In SMB, Mario grows from about 1 block high to about 2 blocks high when becoming Super Mario. 1-meter and 2-meter are both height values within the realm of real-world human possibilities. In addition, it makes things easier to build a world environment where each block is one meter across.

I used Excel to convert blocks and pixels to meters and convert frames to seconds. Now I have the number values to set my velocities, distances, and acceleration values. Now I need a script to give everything structure.

Ultimate 2D Platformer Controller

Ultimate 2D Platformer Controller by Sasquatch B Studios

Fortunately, I found a tutorial video (linked above) for a character controller that uses Unity's new Input System (which is a learning objective for me in this project) and is built using the same formulas I wrote about in my last post. The scripts seem well designed and the results are good so far. The jump values can easily be edited and include options like coyote time and hang time. There is a fair amount of extra functionality I will still need to add (such as different jump heights for walking and running), but this seems like the perfect structure to start with.

UPDATE:

If you follow the Ultimate 2D Platformer Controller tutorial linked above, be sure to watch part 2 of the tutorial here. The first part of the video cleans up and fixes a few bugs from the original video and, if you are interested, shows how to add wall slides, wall jumps, and mid-air dashes.

Designing Platformer Player Controls

Taxonomy of Virtual Spaces Part II

One of the first steps in this project is to code a player avatar controller for 2-D platformer style gameplay, to allow the user to comfortably navigate the virtual environment. This also gives me a chance to use Unity's new Input System for the first time, as I've always used the Input Manager in previous projects.

Now, where to begin? Although I've created a few platformers in my time (like the experimental Super Mario Love (Rowe, 2019)), I've never created one professionally or for broader release. I've studied the game genre extensively and know enough to give my students advice on developing camera systems or how to adjust gravity to not feel "floaty," but this will be a new endeavor for me.

Building a Better Jump

Math for Game Programmers: Building a Better Jump (J. Kyle Pittman, 2016, GDC)

Building a Better Jump by J. Kyle Pittman is a lecture on using physics formulas to plan and design a platformer game controller, part of the "Math for Game Programmers" series of tutorials at the Game Developers Conference.

A common way to create a platformer game is to open the Unity editor, create a player character game object with a rigidbody, and write a script that applies a force on the object in an upward vector when the player presses the space bar. Then, through trial and error, the developer tunes the force value until the object can "jump" to the desired height. This tends to feel floaty, require a lot of iteration, and using Unity's default physics values tends to make it feel like every other Unity game out there.

How high?

Formulas for initial velocity and gravity

Pittman's approach is to remember your college physics formulas! By using the projectile motion vs. gravity formula f(t) = 1/2 gt^2 + v0t + p0 (Blogger is not great for writing formulas!), he shows that the initial velocity (v0)and gravity (g) values can be calculated based on how high you want the character to jump at the apex (h) and how much time you want the character to reach that apex (t). For example, if I want a character to jump 5 meters straight up and take 0.5 seconds to get there, then I should use a jump velocity of 20 m/s and a gravity value of 40 m/s^2 (or about 4 times our Earth's gravity).

How far?

Pittman uses more formulas to determine what lateral velocity (running speed) is needed to clear a certain jump distance. Remember calculating for how far a cannonball can fly before it impacts with the ground? No need to worry about launch angles here. Pittman shows how to calculate what x velocity is needed using time, height, and lateral distance requirements.

Break the Rules

Increase gravity at apex of jump to give the character a sense of weight

The formulas so far create a jump that is a perfect parabola, which unfortunately feels "floaty" and doesn't feel good to play. Here, Pittman quotes Game Feel (Swink, 2008), stating that in Super Mario Bros., the force of gravity triples at the apex of Mario's jump. (Swink: "At the apex of the jump, when velocity reaches 0, gravity is raised artificially by a factor of three, pulling Mario back to the ground with a much greater force than the one he overcame to get airborne in the first place" (2008, pg. 211). This "fast fall" technique makes the player feel "weighty" instead of "floaty." This is a simple technique that I've been teaching to my students for years.

Other modifications

Double jumping

Fast fall, double jumping, and variable-height jumps are all calculated using the same basic methods: use multiple parabolas or partial parabolas to determine the values needed. Pittman's methods give a great foundation for designing a platformer character controller from the ground up by the game's navigational requirements rather than fumbling around by trial and error.

There are still other important aspects of designing a platformer controller that are outside of scope of this lecture, such as coyote time, jump buffering, and hang time. Most of these involve setting timers and allowing the player to input a jump command when their character is not currently "grounded."