gracie abrams
No title available
let's talk about Bridgerton tea, my ask is open
No title available
cherry valley forever
Lint Roller? I Barely Know Her
occasionally subtle
ellievsbear
𓃗
untitled
"I'm Dorothy Gale from Kansas"
Kiana Khansmith
Fai_Ryy
ojovivo
No title available
Origami Around
Phantogram Three
d e v o n
tumblr dot com
Claire Keane
seen from Canada
seen from Venezuela
seen from India
seen from Ecuador
seen from United Kingdom
seen from India
seen from Türkiye
seen from United States
seen from Ukraine
seen from United States
seen from United States
seen from United States
seen from United States
seen from United Kingdom
seen from United States
seen from United States
seen from United States
seen from Ireland
seen from Malaysia
seen from France
@mimeoverse-blog
Less than 72 hours left to get in on [Retro Game Crunch](http://www.kickstarter.com/projects/shauninman/retro-game-crunch-six-games-in-six-months), six games in six months--plus five bonus games! (For you development types, don't miss the Retro Game Crunch [Primers](http://retrogamecrunch.com/primer/tools).)
[Horror Vacui 2][0] is coming soon to the iPhone, iPod touch, iPad and Mac. It's the first game to use the framework I designed for Mimeo and the Kleptopus King. There's even a Mimeoverse audio Easter Egg hidden in the game's options. **Update**: Horror Vacui 2 is out now for the [iPhone, iPod touch and iPad][1]! It's also been approved for the Mac App Store so it should be available on Day One! [0]:http://shauninman.com/horrorvacui2/ [1]:http://itunes.apple.com/us/app/horror-vacui-2/id404573320?mt=8
While I removed the target launch date from the project description back in April or May I don't think I've explicitly addressed it on the blog. This question comes up a lot on Twitter and when showing the current demo in person. Holidays 2010 was an ambitious and, as subsequent work and research has shown, unrealistic estimate (New Super Mario Bros. took a team of more than 60 individual designers, programmers and musicians over two years to complete). In addition to doing all the design, programming and music for Mimeo and the Kleptopus King I'm also designing, developing and supporting two commercial products ([Mint][0] and [Fever][1]), a number of freebies (like [Lessn][2] and [Shortwave][3]) and other projects (like a [sequel][7] to [Horror Vacui][4] and the next version of [Designologue][5]). A more realistic estimate might be something closer to the five years it took Pixel to create [Cave Story][6] (although hopefully not *that* long). The bottom line is that this is a one-man labor of love and will take as long as it takes. [0]:http://haveamint.com/ [1]:http://feedafever.com/ [2]:http://shauninman.com/archive/lessn [3]:http://shortwaveapp.com/ [4]:http://shauninman.com/horrorvacui/ [5]:http://designologue.com/ [6]:http://en.wikipedia.org/wiki/Cave_story [7]:http://shauninman.com/horrorvacui2/
Still quiet, putting the new iOS/OSX game engine through its paces by revisiting [Horror Vacui][0] before returning to work on the Mimeoverse. [0]:http://shauninman.com/horrorvacui/
Mimeo in the Tumbleverse has been quiet lately. This is why.
[SI2d Running on iOS and OS X](http://www.youtube.com/watch?v=AheejpduucM)
Just a quick note to point out that I've added a [FlashNSF][0] player to the sidebar of the site. Now you can listen to the 16-bit version of the themes from the game on infinite repeat. The best part is that the [p1xl][1] guys use the same [audio library][2] I do in the game so the songs should sound identical—without me needing to manually trim and convert each track to MP3. For the curious, I've also written two posts on my personal site documenting my [workflow][3] and sharing the [tools][4] I use to generate NSFs. [0]:http://www.p1xl.com/fun/flashnsf/ [1]:http://p1xl.com/ [2]:http://slack.net/~ant/libs/audio.html [3]:http://shauninman.com/archive/2010/02/13/an_mml_bundle_for_textmate [4]:http://shauninman.com/archive/2010/07/06/mml_bundle_now_creates_multi_song_nsfs
Pre-[crisis][0] gameplay and level design test. Temporary tileset. Block. Blocks. Blocking. Blocked. BLOCK. [0]: http://blog.mimeoverse.com/post/786124409/this-might-be-a-long-one-mimeo-is-having-a-bit-of
This might be a long one. Mimeo is having a bit of a gameplay identity crisis.  Mimeo was originally imagined as a Mario clone. Run, jump, bump and stomp through levels and enemies while collecting bits. Powerups, instead of affecting the player character, modify the gameworld and graphics. Everyone seems to love the concept but I'm having trouble translating it into a coherent and compelling gameplay mechanic. Without a solid gameplay mechanic based around resolution switching the visual and audio variety is just surface decoration. And right now resolution switching is creating more problems than it solves: - resolution is in one respect a glorified health meter; a 2-bit Mimeo falls with one hit; 16-bit, four hits (with each hit dropping the resolution) - resolution is also tied to walls and bridges in each level; bumping up the resolution causes a platform to appear making it possible to scale a cliff or cross a gap; a binary state controlled by one of four inputs - because resolution is tied to both player vitality and level design, the latter must allow for completion with only the lowest resolution; this leads to an unsatisfying path of least resistance through every level that potentially negates the challenge of higher resolutions - resolution switching is an indirect action; it is performed by the player, not the player character; less satisfying than direct action and probably the hardest thing to reconcile The Mario template is also causing gameplay dissonance: - the upgrade from 2- to 4-bit comes with a growth spurt but has no analog in subsequent resolution upgrades; all narrow passages require a switch to 2-bit - after (implementing and then) removing the bump mechanic taller offers little benefit over shorter; while Mimeo jumps no higher he does have a greater reach of one tile; but he is also a larger target for enemies and projectiles - acceleration and momentum-dependent jumping (run faster to jump higher) undermine height obstacles with resolution switching based solutions - the current jump behavior (borrowed from Mario) is not suited to the vertically-challenged 10 tile high viewport; a standing jump spans 4 vertical tiles, 5 with a running start; assuming Mimeo must be standing on something to jump add 1; if taller, add another 1 to Mimeo's reach; that means Mimeo has a 6 or 7 tile reach when jumping, nearly three quarters of the screen Limitations of touch controls compound these problems: - because there is no tactile feedback and because (in the interest of visibility) touch points are confined to the edges of the screen, the player's thumbs can easily drift off a button at inopportune times; - a player's reflexes are only as good as their input device; Mario's core gameplay mechanic is jumping, falling in holes being a ubiquitous threat; occasionally erratic controls plus instant death equals player frustration So how do I resolve these issues? Not exactly sure yet but here's some possible solutions (some of which introduce their own problems): - decouple resolution and player vitality; which means the addition of hearts, a health bar, or hit points - simplify and normalize player movement; consistent behavior ensures that the player feels in control - clearly differentiate the impact each resolution has on gameplay; 2-bit empty space becomes a solid block in 4-bit which floats to a different position in 8-bit and runs along a regular looping path in 16-bit; different enemy behavior in each resolution including a vulnerable "hibernation" state; maze map that can only be navigated by changing to the correct resolution before exiting/entering room; rooms that prevent resolution switching until an objective is met - add ability to "herd" enemies into a desired resolution; possibly to activate their hibernation state or meet some other objective (does that mean that enemies don't exist across resolutions?) - adopt exploration gameplay with gradual but permanent resolution acquisition to eliminate "path of least resistance" problem; funny, before Mimeo was Mimeo and a Mario clone it was more of a Metroidvania; full circle So these are some of the problems I've been grappling with the past couple weeks. I'm not giving up. Putting a name on them makes them seem surmountable.
Some initial boss ideas and sketches (based loosely on the [Veined Octopus](http://www.youtube.com/watch?v=1DoWdHOtlrk)). Been quiet around here lately. I've been grappling with ways to integrate resolution switching into the level design. Or rather, with making resolution switching *central* to the level design. Because if it's not *the* core gameplay mechanic then (at least) three quarters of any work I do will be for nothing.
Late last week I made a good start on the programming for the Snowsquatch Frost Breath ability. The graphics aren't done so no video of that yet. Earlier this week I implemented moving platforms which involved taking the grid-based collision/physics engine and updating it to allow collisions with arbitrarily positioned entities (which was also required for Mimeo to be able to interact with frozen entities). The past two days were spent on miscellaneous graphic updates and some new sprites (one of which, an 8-bit Kiddo fleeing after being rescued by Mimeo, is shown above). Today I rewrote entity management. Previously when a level was loaded all entities were created, added to the map and ran on the same update cycle—whether they were on screen/map or not. This led to two issues. First, the most obvious, is that the game was running lots of logic that had no impact on the onscreen action on every frame. The second, most problematic issue was that locomotive entities placed at the end of the level were moving on (eg. towards the center of the level, down holes, or otherwise off map) before the player could encounter them. Now entities are only created and added to the map when their spawn point is within a few tiles of the visible area and removed when venturing beyond that extended region.
And from this week, the new Narwhelp Lightning Strike ability. This ability has gone through a number of revisions including: an indirect attack where the bolt always hits Mimeo and the resulting sparks create a limited area of effect surrounding Mimeo; bolts (accompanied by an irritating flashing screen) striking the three tiles directly in front of Mimeo; and the one I eventually decided on, a single bolt that strikes the nearest entity that attracts lightning. One example of the interesting puzzle possibilities I allude to in the video: an engine in need of juice situated below a resolution dependent block forces the player to change resolution to have a clear shot at the engine.
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: 1. minimize vertical motion 2. lead in the direction the player is facing 3. 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][0] [previously][1]: free-moving, zero-lock and platform-snap; each tied to specific regions of the map. [0]:http://blog.mimeoverse.com/post/574942897/just-completed-a-playthrough-of-super-mario-bros [1]:http://blog.mimeoverse.com/post/577060703/following-yesterdays-analysis-of-super-mario
Following [yesterday's analysis][0] 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. [0]:http://blog.mimeoverse.com/post/574942897
Just completed a playthrough of Super Mario Bros. 3. The goal [this time][0] was to document the camera/viewport behavior. A [surface examination][1] 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. [0]:http://blog.mimeoverse.com/post/527074030/played-through-new-super-mario-bros-on-the-ds [1]:http://replicaisland.blogspot.com/2010/01/elusive-perfect-platformer-camera.html