41–50 of 224 posts
It says game development can be made simple and then throws a whole of jargon at you: clojure vectors, datomics, atoms, transactions, malli schemas... Can someone explain?
I am using them to construct side effects which I call 'transactions' (similar to datomic) [:tx/foo 3] where :tx/foo is a keyword and uniquely identifies the component behaviour.
Oooh, this is cool. I always like to see different approaches to game dev (despite never having published a game!). So far I've tried - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. I think it's heavily dependent on the game. Part of it will be my own incompetence. - Unity. IMO the system of gameobjects with composed modular components is…
Godots signals are such a huge step up over Unity's built in classes having a lack of modularity.
How do you even make sense of that? Godot vs Unity basically have the same scene/node/component model except Godot does it better imo. Eg) What is the difference between a prefab vs a scene in Unity anyways? Basically nothing, it's just (I'm speculating) a tech debt mistake in their design, probably still going because of how light maps work today.
Unity's advantage over Godot is it's 3D renderer, built in physX, il2cpp backend for C#, profiler, general runtime performance and console support.
Godots design is objectively more cohesive, as Unity has simply splintered into 10 different design directions since ~2018.
I'm not trying to be a hater, I just think signals are a huge advantage for writing modular, simple stuff in Godot. I think there's plenty of great reasons to prefer Unity to Godot but "signals" is not one of em.
Oooh, this is cool. I always like to see different approaches to game dev (despite never having published a game!). So far I've tried - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. I think it's heavily dependent on the game. Part of it will be my own incompetence. - Unity. IMO the system of gameobjects with composed modular components is…
> - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. Can you expand a bit about why this was messy or comolicated? I found the paradigm leads to pretty well organised code (sometimes you get the odd large system, but it can be broken down into smaller systems, sub systems or composed out of smaller functions).
For this reason I agree - developing games using an ECS design requires more discipline to manage complexiy, compared to an imperative one.
Oooh, this is cool. I always like to see different approaches to game dev (despite never having published a game!). So far I've tried - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. I think it's heavily dependent on the game. Part of it will be my own incompetence. - Unity. IMO the system of gameobjects with composed modular components is…
I view 3 users 1. Complete Novice 2. Engineer dabbling in games 3. Professional game designer.
For #2, they are more likely to prefer C# as they probably already have experience with it, or otherwise will be familiar with the similar Java language. Also it's a nice resume boost to say you've used C#
For #3, I can't imagine the godot language is better for large scale games than any custom language. C# just has way more resources put behind it
For #1, I kinda see it. But they would probably be better learning a language with more tutorials available. Or if they're struggling, pygame is probably a better place to start.
Earlier quoted context omitted.
It is completely possible and has interesting trade-offs. Here are some of my favorite blog entries related to functional game development: https://prog21.dadgum.com/228.html https://prog21.dadgum.com/23.html https://prog21.dadgum.com/24.html https://prog21.dadgum.com/25.html https://prog21.dadgum.com/26.html
After doing functional programming for a while now (6 years of Elixir) it seems obvious to me that it is possible and no more complex than using imperative logic. In fact I would go so far as to say that managing complexity (i.e. state) is much easier to do in a functional style than imperative. Functional is all about transformation of data structures, and a game is nothing more than a function that takes {state, mo…
Earlier quoted context omitted.
No. By the power vested in me, I hereby permit you to keep your project's name, and to point at this man and laugh at him.
A name has to meaningfully differentiate amongst its peers, which calling an RPG making tool "RPG Maker" when it's not associated with the brand clearly does not. It is (was) marketing failure and an unnecessary legal risk if this gets bigger and comes up on Enterbrain's radar.
Earlier quoted context omitted.
the issue with JVM/java was always that when that GC triggers you are just absolutely hosed. C# tends to be a bit more forgiving about when it triggers GC and how. The generational garbage collector in C# will tend to be more reliable or at least I never ran into super huge issues with the places I've used C# for game dev. The JVM GC has this unfortunate effect of having very bad pauses occasionally. And appears to d…
Minecraft is written in Java, it doesn't look like the choice of platform kept it from becoming a success.
Oooh, this is cool. I always like to see different approaches to game dev (despite never having published a game!). So far I've tried - Bevy (Rust ECS engine), which is nice at first but has a lot of problems with its implementation and can become rather messy. I think it's heavily dependent on the game. Part of it will be my own incompetence. - Unity. IMO the system of gameobjects with composed modular components is…
Earlier quoted context omitted.
A name has to meaningfully differentiate amongst its peers, which calling an RPG making tool "RPG Maker" when it's not associated with the brand clearly does not. It is (was) marketing failure and an unnecessary legal risk if this gets bigger and comes up on Enterbrain's radar.
[flagged]
>Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
>When disagreeing, please reply to the argument instead of calling names.
>Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.
>Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.