Super Meat Boy Galaxy: Ransomed for Alms

Donate Now, here, then. [ Edit: Donation Deadline has Ended. Not enough was raised to Ransom the game.]
I never wanted to make money off this... But you could help someone in their darkest hour.

Super Meat Boy Galaxy is a prototype I put together for my friend Tommy’s 30th birthday a bit more than a year ago. I only recently released a video, and it seems to have gained a fair bit of attention.

For me, it was just a bit of a throw away experiment. It was never intended as a “pitch” to make such a game (although Tommy and I discussed something a bit like it a long time ago when working on Goo!). The video started to get interest from various reputable web sites and pretty soon, had more youtube views than every original work of mine, combined. As you might imagine, this made me feel… ehhhh… “great”.

Much to my surprise, some people said they’d like to try it out, or would be quite excited about a game based on the premise of “happy death” 3D platforming. Obviously, this is encouraging to hear, but I’m trying to be realistic about it all. From experience (soul crushing, inescapable experience) I know that going from a playable concept piece to a full game is degrees of magnitude more difficult than pooping out the initial prototype, while the end result is often only a few times more fun (if at all).

Releasing it as a “real” product, for money, has its own issues: I genuinely wouldn’t have the time to support it as it stands, and I haven’t the means or hours in the day to develop it further. And developing it further would be rather a case of “ill gotten gains”, since I’m riding the success of Tommy and Edmund’s fantastic game. Basically, if I could just make prototypes for the rest of my life, that’s what I’d do. All the sweet, none of the sour. But then, I’d never be able to charge for them, so it’s hardly realistic.

Ethically, and practically, I just can’t do anything with this project. Charitably, though…?

To that end, I will be releasing the Super Meat Boy Galaxy prototype. It’s going to cost you, though.

I’ll release the Super Meat Boy Galaxy prototype for free as soon as my demands are met: raise 10,000 quid for The Samaritans, and the prototype will be released, free for all onto the internet.

Windows, Mac, and Linux (when I get around to it) builds will be available in one bundle.

Bear in mind that this is a prototype, and as such will not be as friendly and polished as a final game. Its main purpose was to investigate whether Super Meat Boy’s kinaesthetically pleasing platforming physics could survive the leap to 3D, given the right camera and level layouts.

I’ll probably use a torrent so that costs aren’t eaten up in hosting. I have to figure out how to do that… but it’s cool, I can probably work it out! No worries! There will be other methods of downloading, also, in case your ISPs are weird about that kind of thing. However you get it, it’ll be free to copy and pass around. I *may* have to do something about that music before I release, though.

I’ve chosen The Samaritans to be the beneficiary of these donations. I’m sorry it’s not from an international charity, but… this is for personal and private reasons. I hope you understand.

All donations go through, which seems like the best way to get money to its target without so many processing fees. Also, it lets you pay what you want, which is good, right?

3 thoughts on “Super Meat Boy Galaxy: Ransomed for Alms

  1. Pingback: Super Meatboy Galaxy Ransomed For Charity — Mac Gamer

  2. Hi – I am currently learning to code in unity – and love your SMBG project! I was wondering if you had any tips or advice on creating those sort of tight controls for a 3d platformer? Thanks!

    • Basic architecture: Don’t use the standard Input.GetButtonDown or Input.GetButtonUp, as they give you 1 frame of delay (unless that’s been fixed)

      Instead, keep a copy of last frame’s Input.GetButton for each button you’re watching, and compare it against this frame’s Input.GetButton

      Make sure you have an Input polling script (with the above stuff in) which has it execution order set to earlier than every other script.

      Make use of delegates so that you can register events to your input polling class’s input signals. This way you have all your inputs directly updating your other scripts just BEFORE every other script runs its own “Update”. i.e. your won’t lose a frame anywhere. i.e. if your input polling script notices that jump has been pressed, and your player character class has registered to listen for a “jump down” button press, then by the time the player character’s “Update” is called, you have already dealt with the change in jump velocity.

      In terms of responsive animation, physics and feel: Cheat.

      Creating obsessively realistic physics is rarely going to result in a great feel. Great feel requires a lot of tweaking, experimentation, and iteration. Set aside a great deal of time (over a period of weeks or months) to be able to iterate on the feel.

      Keep your movement as close to 1:1 with your controls as possible, i.e. adding secondary momentum aspects is only going to add to a sense of “indirect” control. Smoothing should often only be used for non essential visual elements. The thing you directly control should be clearly tied in an immediate way to your controls.

      Don’t be afraid to “jump” to maximum velocities, rather than accelerating up from zero. Create visual effects which imply a great amount of force being used (shock waves etc.) to justify this rapid change. You’ll find you get more of a sense of kick and power out of changes.

      If you want a powerful jump, don’t just set the velocity when the jump occurs – move the character up the amount they would move due to occurred first frame of velocity being applied. I.e. pretend like the jump occurred the frame *before* you pressed the jump button. Be more responsive than you should really be allowed to be :)

      Be honest about what your interface (be it mouse, joystick, control scheme) is good at. Let it lead your design decisions If it hurts to tap a touch screen, probably don’t ask the player to do that! Make a game which uses swipes instead. If you’re using a D-Pad or arrow keys, consider that it FEELS very “on or off”. Make your game character respond in the same way. Similarly if you have an analogue stick, make sure it’s responding to subtle movements.

      Try not to design control schemes for multiple interfaces at once: mice are great for pointing and clicking, and not so great at swiping. Touch screens are good at swiping but not as nice for pressing and holding. They both use the idea of pointing, but they are physically comfortable in entirely different ways, so don’t imagine that you can port a design straight from one to the other. The interface defines the game.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>