Skip Navigation

Tab :godot: :git: :linux:
Tab :godot: :git: :linux: @ tab @mastodon.gamedev.place
Posts
0
Comments
8
Joined
2 yr. ago

  • @MarshReaper a rock paper scissors approach could be a good choice. If it isn't a core mechanic then yeah it's just extra complexity (not worth having to start with).

  • @MarshReaper replicating the hook of Smash seems unfeasible (your favorite characters smacking each other). Finding libre characters isn't hard but finding ones to fit the gameplay might - is Tux having tux the main appeal? I would look at what other clones have done and try to replicate them but with a twist.

    Maybe the twist could be something to do with it being FOSS. Like you can "read the source" of the opponent, or modify your character's abilities per match.

  • @Smorty @db0 if my plugin was the tipping point that made someone open source their game I would be rather happy. If they had to remove it to avoid following its license: look before you leap??

  • @lutris@fosstodon.org Anyone see the CES MSI LoL cheating monitor? Are there any cheats that's can just be run on another undetectable computer?
    Anti-cheat is a temporary solution which loses in the end.

    This could be motivation for Linux users to create their own MOBAs. Ideally free software, and with an alternative answer to user's cheating.

  • @popcar2 guess I've been lucky, just enabled sharedarraybufffer and worked on itch

  • @plixel @Rodeo if the parent is creating the children at runtime then that's the time to connect signals in code.

    If the child already exists as part of the parent's scene you could connect it's signals in the editor (built-in signals or your own signals). Then in code just run singalname.emit(args) when needed. You can still connect them in code if you want [e.g. iterate over getchildren()].