21–30 of 224 posts
I love Clojure, but isn't a functional language with immutable data structures an odd choice for developing a video game?
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
Earlier quoted context omitted.
High performance real-time games it is questionable. Any genre that is more static turn based can be a great boon.
Check it out, it is handling hundreds of entities at >>60 FPS. And I still did not do much performance optimization (there are still many lazy seqs around and unoptimized code). Also most of the sprite rendering is the main problem, which an atlas texture could also improve even more. (Right now all creature animations are separate texture files). And you can always step down a level to java if the need arises!
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 do so regardless of the type of GC you are using.
There are some techniques you can use to get around this -> re-using entities. Using C# structs. Not doing allocations/deallocations inside the main game loop if you can.
For small enough games it is irrelevant but as soon as you start to get a larger game with lots of memory allocations/deallocations it really crushes performance.
- 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 the most utilitarian - it gets out of the way, and it's easy to avoid spaghetti without requiring a really strict engine-dictated structure.
- Godot. I hated it. All of the awful heirarchy of OOP, a really poor builtin language, and "signals", which are meant to decrease spaghetti but only increased it for me. Maybe I was using it wrong? I very rarely use inheritance to the point of being bad at using it.
- Pygame, back when I first learnt to code. It's quite nice for small projects - it's procedural at heart but you can make your own OOP or functional layers over it. There have been some surprisingly large projects made in it.
I don't know Clojure, but it's interesting to see someone make a functional implementation of something that stereotypically seems like a good fit for OOP.
Earlier quoted context omitted.
Check it out, it is handling hundreds of entities at >>60 FPS. And I still did not do much performance optimization (there are still many lazy seqs around and unoptimized code). Also most of the sprite rendering is the main problem, which an atlas texture could also improve even more. (Right now all creature animations are separate texture files). And you can always step down a level to java if the need arises!
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…
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.
I love Clojure, but isn't a functional language with immutable data structures an odd choice for developing a video game?
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
Functional is all about transformation of data structures, and a game is nothing more than a function that takes {state, mouse, keyboard} as input and returns {new_state, output} where output is a set of Vulkan commands, or pixels that you bitblt to screen. Rinse and repeat in an vsynced infinite loop.
I think the linked articles above betray the fact that they were written 15 years ago when functional programming was a niche quasi-academic idea and no one was used to building stateful programs with it. 15 years ago it was all about Java and C++. Lisp was as forgotten as it is today. In 2024 most above average programmers have experience in functional logic, and it is not that arcane of an idea. The reason that it is not widely adopted is that functional programming is not as performant as imperative semantics, and you need all the speed you can get. On the other hand, imperative often means buggy mess as game complexity grows and painful debugging session trying to understand who and why changed this state variable.
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…
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).
I thought this was something to do with RPG Maker[1]. They (you?) should change the name given the obvious trademark and general confusion issue. [1]: https://www.rpgmakerweb.com/
Do I have to change the name ? Given it's just an open source project and the name is actually just 'core' . It's an rpg maker tool and functional engine.
Proper grammar would be "an RPG making tool".
Additionally, you deliberately wrote "RPG Maker" rather than "RPG maker". Capitalization is important, kind of like how "US bank" and "US Bank" mean completely different things (former is a generic reference to an American bank, latter is the name of an American bank).
So yes, I would change the name if I were you (and you have from what I can tell, good job) because it's infringing upon the RPG Maker brand and trademark but most importantly because it's just confusing.
Can someone explain?
Earlier quoted context omitted.
Do I have to change the name ? Given it's just an open source project and the name is actually just 'core' . It's an rpg maker tool and functional engine.
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.
It is (was) marketing failure and an unnecessary legal risk if this gets bigger and comes up on Enterbrain's radar.