Celeste shares its movement code for all to peer at

The makers of Celeste have shared a big slab of the platformer’s code, letting everyone dig down into the intricacies of its movement. “Maybe it’ll interest you if you’re curious how some part of that works!” game director Matt Thorson said. Given how secretive the games industry can be, it’s nice to see a game with such great-feeling movement spill its guts for all to inspect.

“We just posted our 5400-line Player class (C#) from Celeste in all its messy, mostly-undocumented glory,” Thorson explained on Thursday. “This is the code that handles Player input/movement/states.”

If you’re curious, have a nose over on GitHub. I’m no programmer so what I can glean from it is limited, but I’m sure many will enjoy it. I’d also be curious to see if this level of insight helps speedrunners hone techniques and master quirks.

I have no practical or intellectual use for this myself but I shall certainly memorise a few lines so I can barge into discussions of Celeste spouting such wisdom as “Ah yes well but what else would you expect given that ClimbUpCost = 100 / 2.2f?” You are all encouraged to throw drinks in my face when I try to pull this nonsense.

The game is good, by the way. Check Adam’s Celeste review for our official word.

16 Comments

  1. TauPhraim says:

    The most intriguing thing about this, is how they managed to create a game that feels so slick and polished, while programming 5400-lines messy (pleonasm) classes !

    • R. Totale says:

      Today I learned a new word.

    • aepervius says:

      In my experience 5400 lines class do not really impact slickness of the result, or how good the run code is at the end, but just lower the maintainability and readability of the code.

      • Jeremy says:

        Truth.

      • ersetzen says:

        There is also something to be said for having everything related in one place instead of smearing a state machine into a 45 file jigsaw puzzle. It makes it harder for new people to get on board but that probably isn’t a problem for a small indie team.

        From glancing over the code, it seems really readable despite its size.

    • Premium User Badge

      Ninja Dodo says:

      There’s an interesting thread on twitter about this. It turns out writing elegant code and shipping working games are two very different things:

      link to twitter.com

      “Here’s the thing though: • They knew the code wasn’t perfect but had the guts to release it anyway. • They successfully released a game, which is 10x harder than writing nice code.”

      “Watching r/gamedev cry foul about the coding style in Celeste’s open-sourced Player class is kind of like listening to a bunch of freshman culinary students making fun of Alton Brown’s recipes because they think he ties his shoes wrong”

      I seem to remember the programmer of Super Meat Boy also describing his code as being “held together by duct tape” and that’s a pretty good game, you guys…

      • TauPhraim says:

        It’s certainly possible to get a good end product with messy code, just much harder. And even that, I guess is reduced by how much mentally tough you are, but I wouldn’t say there’s absolutely no correlation.

      • King in Winter says:

        As someone who makes games for a hobby – pretty much just releasing for game jams – I have to agree. When facing a deadline, be it just for a jam, you almost certainly face a dilemma:

        A) write elegant code.
        B) write messy code that works, and finish before deadline.
        * Choose one of the above.

      • Premium User Badge

        Ninja Dodo says:

        I’m not a “real programmer” (more of an artist/animator with excursions into light coding) but I definitely find a preoccupation with the ‘correct’ way of doing things gets in the way of actually getting stuff done and working. While smartly constructed and readable code no doubt helps create better software (especially in a team) there is a time and place for simpler solutions and there is definitely some overlap in the venn diagram of people who are snobs about perfect code (or art for that matter) and people who never finish anything. (see also: writing your own engine)

        Worth noting too that for novices, learning as you go by building things is greatly preferable to waiting until you’ve learned *the proper way* before attempting any project. Better to learn by doing and gradually improve.

    • Lord Byte says:

      I haven’t looked at it, but from a pure technical standpoint. If that class does all it needs to do, and none if it is required elsewhere… There’s no need to split it up.
      I’ve read much worse code that kept getting needlessly split in classes calling classes calling classes, which does not improve readability either.
      If the class is self-contained, and will not need to be reused elsewhere (and doesn’t need to return values), it’s perfectly fine no matter what the size is.

      • Baines says:

        That depends on which theory of coding you follow, which changes every five to ten years.

        I remember one period where people were taught that no class should be more than around a page long, and that anything larger should be broken into more classes.

    • onodera says:

      I remember browsing the source of a different published game that had no loops because the creator didn’t know they existed.

      • ThTa says:

        Yup, that’s this gem.

        Anyway, I’m ambivalent about the “messiness” of the code. We’ve certainly got plenty of ways to make things more readable and maintainable (and comments really wouldn’t change much here), but I can certainly see the appeal of not having to constantly refactor and organize things in particular design patterns. It’s a bit excessive here, but if it works for them, it works.

        And really, it’s far from the most ungainly class I’ve seen. (Though many of the worst offenders were generated, rather than written by humans.)

        • Eleriel says:

          I Loved A Game About a Dragon! but/and that code gives me hope for my potential future as a game dev.

          I kind of want to make a project of turning that code readable while at the same time keeping it working exactly as it does now… (not for any nefarious purpose, mind. just to see if I can.)

  2. SuddenSight says:

    This is pretty awesome. Tutorials to make basic platformers are quite common, but most of them don’t go much farther than arrow keys to move and jump. Celeste has deceptively complex movement mechanics, with a dash, wall jumps, swimming, sliding, and limited grab and climb abilities. The game also has unusual momentum mechanics, where some movements like walking and jump preserve your momentum, while others such as the dash do not. So this code is honestly pretty cool to see.

    However, it would definitely be at least 10,000% more useful if it was well commented. But then again, all code would be.

  3. ThePuzzler says:

    ClimbUpCost is the stamina cost per second for climbing up (100 / 2.2f means ‘about 45 and a half’). By the look of it, you can climb up for around 2 seconds before getting tired.