Mimeoverse: Mimeo and the Kleptopus King is a platforming game in development for the iPhone, iPod touch and iPad.

Select a resolution

Preview music

Requires Flash 10.0
Less than 72 hours left to get in on Retro Game Crunch, six games in six months—plus five bonus games! (For you development types, don’t miss the Retro Game Crunch Primers.)

Less than 72 hours left to get in on Retro Game Crunch, six games in six months—plus five bonus games! (For you development types, don’t miss the Retro Game Crunch Primers.)

Posted
Horror Vacui 2 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! It’s also been approved for the Mac App Store so it should be available on Day One!

Horror Vacui 2 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! It’s also been approved for the Mac App Store so it should be available on Day One!

Posted

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 and Fever), a number of freebies (like Lessn and Shortwave) and other projects (like a sequel to Horror Vacui and the next version of Designologue).

A more realistic estimate might be something closer to the five years it took Pixel to create Cave Story (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.

Posted
Still quiet, putting the new iOS/OSX game engine through its paces by revisiting Horror Vacui before returning to work on the Mimeoverse.

Still quiet, putting the new iOS/OSX game engine through its paces by revisiting Horror Vacui before returning to work on the Mimeoverse.

Posted
Mimeo in the Tumbleverse has been quiet lately. This is why.
SI2d Running on iOS and OS X
Posted

Just a quick note to point out that I’ve added a FlashNSF 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 guys use the same audio library 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 and sharing the tools I use to generate NSFs.

Posted

Pre-crisis gameplay and level design test. Temporary tileset. Block. Blocks. Blocking. Blocked. BLOCK.

Posted

This might be a long one. Mimeo is having a bit of a gameplay identity crisis.

Mimeoid

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:

The Mario template is also causing gameplay dissonance:

Limitations of touch controls compound these problems:

So how do I resolve these issues? Not exactly sure yet but here’s some possible solutions (some of which introduce their own problems):

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.

Posted
Some initial boss ideas and sketches (based loosely on the Veined Octopus).

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.

Some initial boss ideas and sketches (based loosely on the Veined Octopus).

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.

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

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.

Posted