Hello! I’m making a new project for Celeste, and I wanted to share my ideas with you!
I've made quite a few projects in the past. Many of which have mysteriously fallen to the wayside; usually due to a lack of motivation or a badly-defined scope. This log hopes to address both of those problems, so I can feel the adrenaline of actually finishing something for the first time in a while!
Part of the loss in motivation can be contributed to the fact that making things takes a long time. The hype and encouragement brought by a deliverable really helps in keeping that motivation, so delaying it to the end quickly leads to burnout. My solution to that (hopefully) is to make the article you’re reading right now a deliverable! Sure, it might lessen the impact of that final release, but what's the point in preserving that if it never happens.
Also, if I don't come to a conclusion of what "done" means at the start, I can keep doing and doing until it's done to death, but still never feels done. The purpose of this initial devlog is to set all that straight before I even begin making anything. I'm going to be spending some time explaining the whole idea and why I'm making it, what the scope is, and set some goals I'd like to complete by the next log.
The Vision
Celeste is a game with an incredibly high skill ceiling. As a result, sharing that skill is a common desire among its players. Sites like hardclears exist to track clears on extremely hard levels, and sites like goldberries exist for logging deathless runs on levels, but there's currently no great place to just log all your Celeste progress.
Some players have made custom spreadsheets to keep track of their clears, their golden progress, or anything else they want to track. That certainly works, but it has some pretty major disadvantages, like the barrier to entry, the need to add literally everything manually, and most-importantly, the lack of standardization. A clear on a map could be represented entirely differently between two people, both on a human-readable and a machine-readable level. This is the gap that Celestat is trying to fill!
Celestat aims to be a data repository for Celeste Levels, Celeste Clears, and Celeste Level Statistics. Unlike the alternatives, it keeps tabs on all the levels you play, however you want to play them, in a standardized format that can be used to compare between levels or players. Additionally, that data is then publicized for anyone else to build upon.
The Implementation
This idea is literally in its infancy, so there's a bunch of implementation details that are still fully unknown. However there are some high level implementation details critical to the identity of the app that differentiate it from others which are important to mention:
The power of Telemetry (or Celemetry if you will)
Firstly, "keeping track of all levels and all their statistics" is a lot to ask of a person to track, so that's why a person won't be. Mods like MapInfoDisplay by corkr already pull data from the game to show on a stream overlay. The logical next step is to make a telemetry mod that takes all that data, and ships it off to a data repository to show off to your friends.
This allows for the granularity of the captured data to be as big or as small as you want it to be. If you're freaked out by sending all that data, and just want a list of clears to be automatically managed for you, go for it! Want the level you are actively playing to be public so you can display it wherever, sure! Want every death's location to be stored in a blob for each room so that you can generate a heatmap of where you died most often on a really difficult room, no problem!
The other advantage to this is that you can pull old data from Celeste’s native save files, allowing you to retroactively import a bunch of clears and goldens right off the bat. You're not going to get perfect granularity with that of course, but at least it allows players to start with something other than an empty profile.
Decentralized Data
The plan is to have the data stored using ATProto. If you don't have a technical background, and have no idea what that means, then good news! It will literally act identical to any other app you've ever used, so there's no worries there. If you do have a technical background, but are unfamiliar (or curious), let me give the extremely-unrehearsed elevator pitch:
ATProto (or the authenticated transfer protocol) decentralization protocol for creating large social apps. It’s used by all sorts of kinds of apps, the most popular of which is Bluesky. The basic concept is that rather than having all your app data gated behind the wall of whatever app you're using, the data is owned by each user and aggregated together with modern internet infrastructure to form the app’s cohesive view of the data, hence the data is decentralized. The advantage to that is that each person who comes along and uses the app has full and complete control over their data.
ATProto fits for this project really well for several reasons. Firstly, the main downside of ATProto is that all data stored in it must be public.1 This is quite the downside for a lot of applications, but the whole point of Celestat is to share the data publicly, so that isn't an issue.
Secondly, the Celeste community is full of nerds like me that are perfectly capable of making their own apps, mods, widgets, or anything else. Keeping data decentralized means Celestat won’t become "yet another silo for data to be stuck in." It allows my fellow nerds to extend the data provided to do anything they want. This means anyone with the right knowledge can make "now playing" overlays for Twitch, or a hook to include consistency tracker data, or a mod to make a Mario Maker-esque death counter mod that actually fetches data from other users.
Lastly, there's basically no overhead to the users that just want to make an account and upload their stats. I plan on hosting my own personal data server (or PDS, where account data can be stored,) so the people whose eyes have fully glazed over this entire section, can log in and add data with a simple “Log in with Discord" button.
These details are just what I know so far. There's still heaping piles of information that is missing, and questions that need to be answered for me to actually start building anything. Many of those questions require a little more experimentation to come to a good answer. While I think I have a few of those answers now, I'm going to save those for next time so I can answer a larger bulk of questions for the next devlog.
What Celestat is and isn't
This step is perhaps the most overlooked in a lot of projects. While I've spent time thinking about what a project should be (usually after I've already started it,) I think it's a good time to make a list of goals Celestat attempts to accomplish, and a list of things that should not be implemented while the vision is still fresh. While things on this list may change, I'm reserving major changes for glaring issues, as feature creep is a common cause for unintentional enshittification.
So without further ado, the important part:
Project Requirements
Celestat will keep an up-to-date data store of both modded and vanilla Celeste levels, including their names, their creators, their difficulties, their room nicknames, the collabs/packs/contests that they are a part of, and their relations to other sites (gamebanana, hardclears, goldberries etc.)
Celestat will allow users to add entries representing levels they have played, cleared, want to play, or no longer wish to play. Users can optionally accompany that information with additional data, like which maps were played during a single session, how many berries they've collected, how long their clears took, the status of their special-clear progress (full-clears, goldens, winged, etc), how many times they've died on a map or a room, or where they've died in a room.
Users will be allowed to submit requests to add or change map information, such as their names, creators etc. (everything listed above). Users can vote whether the changes are a good change, and can be included in the database if good requests are made.
Celestat will provide a mod that can be installed into the game, that records data and stores it locally. When an internet connection is available, that data is synced to their user's repository, and thus deleted locally to save disk space. The scope of which data is automatically recorded and sent must be configurable, and the service must be usable without the use of the mod.
Project Requiremen'ts
This section can be a little more controversial, so rather than just listing points like above, I'm going to justify why each decision was made. I'm going to go from (what I believe to be) most controversial, to least controversial:
Celestat is not a leaderboard service. No verification of scores will be done.
The first reason this isn't a requirement, is mostly because it's impractical. Storing data in ATProto means users control their data. That means they can put anything they want as data. While it wouldn't be allowed by the frontend I create, users could still make their profile say 203/202 strawberries, or show their clear time on chapter 1a as 80:08:13.5, or imply that they got 9dp on their first try. As a result, verifying user data is a high-complexity task, for a feature already well-implemented by sites like goldberries or hardclears.
That's not to say it's impossible! You could use some digital-signature shenanigans to have a trusted party sign scores they deem valid for some requirement or another. It's possible for something to implement that functionality, but that something will not be Celestat. By virtue of decentralization, the data is there for someone to extend to that use case if they wish.
Celestat is not a discussion platform.
While it's a shame that the current Celeste discourse is gated behind a Discord server (and even sometimes private Discord servers), allowing user text, especially potentially high-intensity debates, invites a whole well of moderation issues that are not worth worrying about.
The one exception to this is difficulty changes. Due to the volatility of hardclears star rating, that difficulty will be kept strictly managed by hardclears, and shown on the site using an API integration (if that's something that's possible!) Generally level difficulties will remain with whatever difficulty they were declared at launch to reduce confusion no matter how hard Tower XIV is. But in the case something really needs to be changed, a temporary discussion forum might be put up. Either way, that wouldn't be through Celestat directly.
Celestat is not an account service.
This is a bit of a nuanced point, but the point I'm making is that user accounts are entirely managed by ATProto. The user accounts provided, via "log in with discord" as an example, will be fully functional ATProto accounts to reduce the complexity on my end. This also means that users can use other ATProto services with an account hosted from my hosted PDS, but it is strongly encouraged if you plan on using multiple services to use an external account, or migrate to an external PDS if you've already gotten your start here.
This is also important to note because this means things like OAuth, authentication, or authorization will have to run directly through ATProto without any Celestat feature getting in the way.
I'm sure there will be a few things I've missed to add in either list, but most of the larger points have already been laid out, so I imagine there won't be too many additional changes.
What comes next?
As I said earlier, I want to make a set of goals to complete by the next devlog (ideally two weeks from now.) These goals aren't guaranteed to be completed by then, and I certainly won't let their non-completion limit myself from writing another devlog. This is only meant to give a good idea of what to be thinking about, and what I'm working on next.
Work out ATProto nuances: There are a lot of (worthwhile) complications added when using a decentralized data model. Questions like "Who owns levels?", or "Is a collab of levels and a contest the same kind of object?" are important to get answers to. I have an idea of what those answers may be, but thinking about this longer, and reading some responses to this will give me a much clearer answer.
Draft a few lexicons: If we are storing standardized data, that data needs to have a really good standard. Starting early on a basic shape of what that data might look like, and finding as many issues before actually storing data in that format will save a lot of headaches later.
Figure out how to get data from the game: I've done a little bit of playing around with modding, and I didn't include any leads I made on that in this entire devlog, because I honestly have a little more than no idea how to do that. Figuring out what data is easy to get, what data is hard to get, and what is impossible to get, is a defining factor of what features we may be able to include.
Conclusion
It's pretty rare to come up with an idea that really excites me nowadays, and considering I got one that got me to write up this massive blog post is really exciting! Beyond a new portfolio piece, I get to start building things for a community I haven't built anything for yet, which I'm excited to do!
If you read through this, and had any thoughts, like "wow that's a great idea!" or "what is this guy on about", I'd love to hear them. I expect a lot of the next devlog to be answering questions generated from responses to this devlog, and clearing up as many inquiries annd issues earlier than usual will save lots of headaches.
If you have don't have much to say, but are excited about this becoming a thing, or just enjoyed reading an app proposal for a game you've never heard of, I appreciate you making it this far!
Finally, if you want to see more of my projects, or more of my writing, I host my main blog using the same service where I'll post anything not specifically a devlog for this project, so check that out if you are interested.
Can't wait to get working on this, I will see you in the next one!