GameMaker is also a very capable 2D engine that you can use for free until you want to export, by which time you can get a subscription less than a cup of coffee.
Plenty of other engines beyond unity, no matter the game you want to make.
Or GameMaker if you are doing a 2d game, or Unreal if you don’t mind the learning curve. Plenty of other options beyond Unity.
I personally am a fan of jet-lagged, the game. Sam, Ben, and Adam from wendover productions/Half as interesting compete in various travel-based games across the world.
Absolutely, I’d personally never use Discord as I’d use Lemmy, but some people sure are trying even if it is very counter-intuitive.
Its not that strange: people use what they are familiar with. Most people have a Discord account these days and migrating over there is as easy as clicking an invite link. In contrast Lemmy is relatively unknown and untested to the general audience, and is a step higher on the hassle scale, even if it is a similar service to Reddit - not counting the usual fediverse complications.
People are drawn to go as far down the hassle scale as possible, the fewer steps between them and their goal the better.
Not that a lot of communities did successfully migrate over here, partially or not. Lemmy is a lot more active now than when I started looking into it during the initial API struggle in June.
I’m going to give you the advice I usually give new Gamemaker users who come to the engine expecting to make their dream game in a week but quickly realize that isn’t happening. You’ll have to adjust it a biy for renpy but the core idea is the same:
Start small: smaller than you thought possible. Start by making pong. Start by making asteroids. Learn how to do collision and movement by making a platformer where the one goal is jumping over a single ledge. The goal is to break your learning down to tiny, incremental steps, so that you are only learning one new thing or mechanic at a time. As you get more confident and start to get a feeling how to think like a computer and solve problems that could arise slowly expand to slightly more complicated projects, move from pong to brick breaker, to pacman, to something else small but has a few more moving parts.
Ask questions (find f.i the forum), look up tutorials, and do not be afraid of experimenting, of breaking things, of taking projects others made and changing things to see what haooens, of really asking “why” things work the way they do.
So, just take a bit of time. No need to be afraid of failing, programming is a skill like any other, it takes time to learn, you are going to suck for a bit. People learning the piano sound awful the first few months, and then suddenly with practice and diligence they start sounding kind of ok, then good, then actually really good. Same with cooking, knitting, writing, painting, building, and programming. All things that take time and effort to get good at. You wont make your dream visual novel today, nor tomorrow, but you will make something, and something is a lot better than nothing.
While it has problems of its own, instances could pool and share that knowledge. The first time an instance talks to a different insta ce it could just ask “hey, what other instances are you aware of?”. The main issue there is just instances obsessively sending exponentially growing lists of instances back and forth.
But no, that is the main bane of federated social media, discoverability without a center of truth
Maybe they are just thinking about those with a really bad internet connection, who will need the month to download the 125gb game.
Hi. I work at a conpany that makes digital card games.
Start by making the rules work. We generally use a callback implementation. We have a class that handles the game and enforces rules and dictates flow, classes that represent players, and then a rendering class.
The game will call relevant functions to prompt the players for an action, passing the game state with them. The players respond with what they want to do. The game calls the renderer to draw it out, and the renderer will then call the passed callback action. Repeat until the game is over.
When a human is involved then you just hook actions to buttons and pieces and clickable elements that the game catches and responds to if needed.
Really you can use any principle or design paradigm you want, but since you are making a “simple” turn based game just having it simple and well segmented is an easy way to keep a handle on it.