From last week: fireballs, global collision detection, redesigned bits, and shiny cartridges. Fireballs come with the Firepuss Hoodie (which I haven’t animated just yet). They bounce off of horizontal surfaces and disappear in a puff when they hit enemies or vertical surfaces.
I was never satisfied with the previous bit design. The rotating cubes felt too generic. Much happier with this new two face bit design and the subtle cart animation.
The beginnings of 2-bit mini Mimeo using the Narwhelp hoodie’s lightning strike ability. Not shown: mini-bolts that spark up from the ground to power abandoned machinery/knock off enemies.
Demoing bricks, chests and hidden blocks with a cameo by a lone resolution dependent block that hints at the presence of a hidden block (while initially preventing its discovery). Bricks bump when hit by 2-bit Mimeo but break in higher resolutions. Chests can contain bits, carts (currently lacking behavior) and 1ups (not shown) or as many bits as you can collect in 5 seconds. Chests can be hidden (invisible) or disguised as bricks (not shown). Still lacking sound effects for everything other than bit collection.
The ideal platformer camera should:
- minimize vertical motion
- lead in the direction the player is facing
- remain motionless during horizontal micro-adjustments
The secret to achieving all three is (what I call) the trap. The trap is an invisible rectangle (made visible for this demo), roughly twice as wide and tall as the player sprite, with the same starting coordinates. Rather than follow the player sprite directly the camera follows the trap. When the player moves within the trap, the camera does not move. The trap only moves when the player pushes against one of its edges.
This video includes a visual representation of the Mimeo trap and features three distinct camera behaviors discussed previously: free-moving, zero-lock and platform-snap; each tied to specific regions of the map.
Following yesterday’s analysis of Super Mario Bros. 3, today I spent some time with the camera behavior in Super Mario World. The Free-moving behavior gains some new sub-behaviors, including locking vertical camera movement to the top of the map and locking vertical camera movement relative to Mario’s last standing position on a platform (fixed or moving) or water exit point. Smart.
Just completed a playthrough of Super Mario Bros. 3. The goal this time was to document the camera/viewport behavior. A surface examination might suggest that the camera logic is extremely complex with many unique conditionals and biased objects attracting the camera but after a thorough playthrough a simpler logic (coupled with informed level design) reveals itself.
There are essentially two types of camera behaviors in SMB3: Free-moving, in which the camera follows Mario, keeping him in the center of the screen (vertically and horizontally) except when doing so would place part of the viewport outside of the map; and Auto-scrolling, in which the camera moves automatically along a predefined path at a predetermined speed (first just horizontally with more complex paths introduced later). The left edge of the screen pushes Mario along, the right edge prevents progress and the bottom edge becomes a bottomless pit (instant death).
This post is only concerned with the first behavior.
There are very few truly Free-moving levels. Those levels are usually two or more screens tall with lots of 30 and 45 degree ramps, one screen-wide vertical shafts, or those where the action takes place entirely underwater.
The remaining Free-moving levels start with the camera locked in a fixed vertical position aligned to the bottom of the level. Mario can jump up and off-screen in certain places (even though there may be platforms somewhere above).
There appear to be two triggers that can release the camera: filling the P-meter (required for flight with Racoon or Tanooki Mario) or climbing a vine. Either can release the camera from its vertically locked position allowing it to follow the player. Once unlocked the camera remains Free-moving until Mario returns to an elevation that allows the camera to lock back onto the bottom of the map.
Some levels ignore these triggers (the most notable example is the secret door to the warp whistle in the first mini-fortress). There are also a few levels that contain multiple rooms, stacked and connected by pipes (the mid-World 5 tower for example). In these rooms, instead of snapping to the bottom of the entire map there are independent, rectangular camera regions that the camera smoothly transitions between when Mario enters a pipe.
Most of the level design in SMB3 is horizontal and only two screens high. Most of the action occurs in the bottom half of each level with the camera locked vertically in place until Mario takes flight or climbs a vine. Because the levels are carefully crafted with these simple rules in mind the camera behavior appears to be much more complex than it actually is.
This demo features the rewritten collision detection system (which is also more forgiving when jumping up against isolated/edge blocks), a more vertical level (with basic camera controls), and a very noticeable reflection of a developer in need of a haircut. Wonder who that could be.
As I continue to refine the gameplay systems these videos may become less and less distinguishable from one another. That will be remedied once I start building proper levels so bear with me.
Another (really) quick one of Mimeo interacting with the new ramps and resolution-dependent blocks. Detection of these new elements is still pretty spotty (hence the short video). Next up: rewriting the physics engine so that these new, more complex rules are applied to all physical entities and not just Mimeo.
(In the earlier demos, Grimps are limited to platforms because they were operating with a simplified physics engine unique to them and if placed on the ground they would walk through the walls instead of turning around and heading in the other direction.)
A quick update on in-game map rendering additions (including resolution-dependent blocks). Xcode had its way with me yesterday; you can hear it in my voice.
This ground tileset will never be seen in-game. It will only be used by Mapt to plot the physical dimensions of the levels Mimeo will be tromping through.
Game entities will be able to move freely through the first tile but not the second. The remaining first row tiles represent basic ramp physics (an entity’s Y coordinate within the tile is relative to its X coordinate within the tile). The first tile of the second row is a one-way platform. The remaining tiles represent blocks that appear in one, all-but-one or some variation of resolutions (the bottom of the 4 rectangles inside each tile represents whether the tile is treated as on or off in 2-bit resolution, second is 4-bit, and so on).
As Mimeo switches resolutions new paths will open while others will close.
(Since I’m working on the engine and supporting tools again things might take a turn towards ugly for a while. Bear with me if you’re just here for the pretty.)
