Indie game developer 🇨🇦

Working on some games for game jams in my free time

Admin of programming.dev and frontend developer for sublinks

Account has automation for some scheduled posts

Site: https://ategon.dev Socials: https://ategon.carrd.co/

  • 97 Posts
  • 111 Comments
Joined 1 year ago
cake
Cake day: June 8th, 2023

help-circle














  • Nothing would change about the community itself if it goes from lemmy to sublinks. Still accessible on the federation as normal and on version 0.1 the core features should have parity

    Reposting my comment I did before:

    Sublinks is a drop in replacement for lemmy. In version 0.1 nothing should really be different between the two apart from the default UI looking different

    For world Ruud commented about that before and nothings been decided currently on theyre going to handle it (I assume youll see some sort of post in their meta community way before anything happens)


  • I’m working on the frontend for it rather than the backend so I’ll comment more about that

    But a new project allows for way easier change of the base aspects. For example im currently working on a theme system thats allows for dynamic themes created at runtime as opposed to it needing to be built in. Also a components library. If this was added onto lemmy ui it would involve massacring the current structure of the UI to essentially make it a new project anyways

    Originally was working on the stuff in a new UI on my own but I’ve merged that into what’s happening with sublinks since they’re making a new UI anyways as well and would let more of my UI changes to get connected up to the backend easily and shared across multiple frontends

    In terms of technologies it also allows the federation code to be completely separated out from the api. Federation is currently its own project so it can be scaled separately and its made in go

    Also allows for more organizational changes since we have more control over how the project is structured and the structure of how we talk to each other and decide on changes is different than how its done with lemmy (having a matrix space we talk to each other and there being weekly meetings as well)

    Moderation tools is the first milestone after parity but theres also other milestones as well in terms of changes made that differentiates it from lemmy visible on our task board thats public on the github repo


    Normal thats theres going to be multiple of the same type of software as people have different goals of what it should be and how it should be organized. Bevy and godot both exist in the open source gamedev space. Theres 7 misskey forks that all mostly aim to do different things but share the misskey api (and a lot of them also use the mastodon api). One of which (iceshrimp) is currently having a rewrite to change the tech stack and make it easier for them to add features





  • Ive been working on some game tools to let me make various games quicker without needing to do the same things in every game i make

    Above you can see two of them ^ Ive got an achievement system implemented as well as a toolbar that lets you trigger things easily for testing purposes (e.g. giving the player a weapon, spawning an enemy, etc.)

    Theres a data persisting system that will persist data in different scopes (e.g. room, level, run, game, permanent) that everything else uses. For example the achievement system looks at a certain category and a trigger (which is a key that the data in the persister is set under) so that whenever data is added to that trigger it sees if its higher than the amount needing to unlock the achievement (and if so unlocks it). The persister is decoupled from everything else by sending signals and then everything that wants to look at what data is set can (this would be the achievements, the unlock system, the dialogue system to see which dialogue is unlocked, etc.)

    Main tools I have made:

    • palette swapping (allows for swapping the palette of the game so that things like each zone can have different colors)
    • unlocks (what weapons, enemies, etc. are unlocked)
    • toolbar (debug helping)
    • persister (persists data through a scope)
    • logger (logs information (separate so other components can show the logs e.g. the toolbar or a terminal)
    • leaderboard (keeps track of scores of players)
    • data (reads txt files from a data folder for usage in the rest of the game for separation of data and behaviours. e.g. you can define enemies each in their own txt file and have a generic enemy object that has its properties set based on the enemy it is. Makes it so you can easily add new stuff