Celeste

Something I've noticed about software dev vs game design: software is better (easier to read, understand, maintain, etc) when you have clean, separated modules. Game design is better (more fun) when everything is connected (eg in an fps, everything relates to gunplay, damage systems, environmental destruction, in a building game, everything relates to building, the building ui, inventory, resources etc). I think this mismatch shows up in game code. Combine that with actual hard performance constraints, and if you're a "normal" software dev casually browsing some game code, it can be shocking (eg Celeste movement code: https://github.com/NoelFB/Celeste/blob/master/Source/Player/...).

forget TDD when you make a game, you want fast iteration time at all cost, gameplay is king, if you can't nail it fast enough, you'll make a bad game that is not fun it's all about the feeling Celeste's player class: https://github.com/NoelFB/Celeste/blob/master/Source/Player/... https://store.steampowered.com/app/504230/Celeste/

Celeste has a huge amount of code dedicated to the proper smooth movements. It requires both knowledge of "physics" simulation, as well as coding methods to get a particular desired outcome (ala, the feeling of responsiveness). It might not be easy for someone without coding experience to create. Have a look at https://github.com/NoelFB/Celeste/blob/master/Source/Player/...

I remember sharing that Player.cs code from Celeste in the gamedev subreddit, and getting all kinds of weird novice comments about how the code doesn't adhere to 'OOP Principles' or 'there isn't any unit tests' or 'you should split it into multiple files with 100 lines each' or 'you should use an ECS to make a real game'. Laster on Noel Berry did give a response explaining the various design choices behind their code: https://github.com/NoelFB/Celeste/tree/master/Source/Player Anyways, kudos to the team sharing their code even if it's a bit messy.

I've heard this so often, and I still don't quite get it. Let's say most of my game objects have a "Position" component, and all the X/Y coordinates are now in one big integer pool. With this setup I can now add 5 to each object's X position really efficiently. But what's the use case for that? Particle systems, and what else? My game objects always look more like Celeste's Twitter-infamous Player class: https://github.com/NoelFB/Celeste/blob/c32f134d210fcf710d750... Say about the length of the file what you want, but isn't it actually better for caching that all of the Player's instance variables are in one object, and not stored in components somewhere else? (Now, maintainability is another issue. But I've always found Ruby-style mixins much easier to reason about than the toy ECS systems I've seen.)

Project is seemingly dead with the latest commit being from 2018. Two major games with code on github I can think of are Amnesia: The Dark Descent (1) and Celeste (2) (1) https://github.com/FrictionalGames/AmnesiaTheDarkDescent (2) https://github.com/NoelFB/Celeste

It’s always great to be able to study the source code for successful, released, real games. I will note that this is actually the source code of the C++ rewrite! The original game was written in Flash, and this version was apparently written by Simon Roth. My impressions: The source code is a bit of a tangle here. There are magic numbers (https://wiki.c2.com/?MagicNumber) all over the place, plenty of god classes (https://wiki.c2.com/?GodClass), and in general you will have to do a bit too much archaeology to figure out what a particular class or member function is supposed to do (the function and class names don’t give you enough, and there are no comments to help out). There are a few WTFs in here, like the "int i, j, j;" in Script.h. THAT SAID, This is not really out of the ordinary for successful, released, real games. It’s not really

They have a Github repo with some of the source code up (mostly just stuff to do with character movement and control). https://github.com/noelfb/celeste Apparently it's based on this framework: https://bitbucket.org/MattThorson/monocle-engine/src/default...

You are assuming that they will release a turn-key working product. Its possible for them to just release key parts that are unique. For example: https://github.com/NoelFB/Celeste/tree/master/Source This game designer only open-sourced his code for the player object. As I am not a seasoned game developer I have enjoyed going through this code and learning some of the techniques. Maybe Digg can help bring up the next generation based on their techniques. Or maybe it helps foster a discussion around how not to implement something.