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<p>- 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.<p>- 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.<p>- 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.<p>- 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.<p>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.
It says game development can be made simple and then throws a whole of jargon at you: clojure vectors, datomics, atoms, transactions, malli schemas...<p>Can someone explain?
To be honest I think this project actually failed. It is an overengineered mess and lacks any kind of clear structure.<p>The main problem is total lack of specification - because I didn't come up with a story for the game or I think games maybe don't need stories. So I just coded like a maniac because it's just fun to code in clojure
As a game dev, this GitHub is comical to me. Bordering on parody of the kind of academic navel gazing that game devs stick their nose up at. Cherry on top is the ugly screenshot.
This post has generated a surprising amount of conversation for how little documentation this repo has. Looking at the code this looks more like a project rather than a game engine. The property editor looks interesting. Seems like this post is being upvoted based on the title vs the content.
Kudos to you! I’m happy to see another Clojure developer like me using the language for game development, even though we sometimes make things harder for ourselves :) Currently, I’m developing a 3D multiplayer TPS shooter using Clojure. For anyone interested, here’s a demo link: <a href="https://prototype-game.pages.dev" rel="nofollow">https://prototype-game.pages.dev</a><p>I’ll also be posting a blog post about the journey soon!
There's already a commercial platform for game creation called Core, powered by Unreal Engine 4)<p><a href="https://en.wikipedia.org/wiki/Core_(video_game)" rel="nofollow">https://en.wikipedia.org/wiki/Core_(video_game)</a>
Sounds like a poorly-chosen name. It's already taken by these guys: <a href="https://www.coregames.com/create" rel="nofollow">https://www.coregames.com/create</a>
It would be interesting to analyze data of "time/complexity spent on game engines" vs "complexity/interest" of produced games.<p>As a game developer, I expect to see a log curve of diminishing returns of novel games given any simple templating/engine system.<p>In other words, the better you make your cookie cutting machine, the less variance your cookies will have.
> The whole game state is stored in one atom: app/state and entities are again atoms inside the main atom (like in our universe).<p>I don’t know clojure. Is this normal terminology, ie to use “atom” this way? Seems like a bad name for the concept since the whole idea of “atoms” is that they’re indivisible (back when physics thought they were indivisible).
Interesting! I worked on something similar once. I would recommend you go further and try to do this for 3D/4D. Orders of magnitude more interesting! In my efforts, I hit a wall where it wasn't very interesting anymore.<p>Also, how about clojurescript so you could run this in browsers?<p>My user test: <a href="https://www.youtube.com/watch?v=gcMBaQI7d-c" rel="nofollow">https://www.youtube.com/watch?v=gcMBaQI7d-c</a>
> The only thing missing is a game<p>I've seen this story of "I want to make a game" [proceeds to make a game engine instead] happen in my own life (my engines were never any good or complete though), and in countless other programmers lives.<p>It may be the trap of thinking that "If I get the hard part out of the way first (which is writing the engine code, right? Right? Anyone?), then the rest of the game making process will be easy" that gets me.<p>Or maybe it's finding out along the way that it was more fun to make the engine than the game itself: "check it out, I completely redid the particle effects and I can now do 100x more particles at 60fps, how cool is that?"<p>There's way more easier-to-see improvements in the making of the engine, than in the making of the game itself, and so we (ok, I) keep optimizing the engine because those are quick dopamine payoffs compared to the slower payoff of having a polished game that's actually fun for the target audience to play. Sure, I might tell myself that the game I want is only possible once I have the engine first, so I'd better concentrate on that before making the actual game, and there's some logic to it. But without a clear idea of what the game will actually be, it's easy to fall into the trap of endlessly adding and refining features, rather than actually try and use those features in anything beyond a slick demo.<p>To combat the tendency of only making an engine rather than a game in my latest hobby project, I picked an already existing engine (Phaser js) and tried to get something interactive on the screen ASAP "with the stupidest, least designed code possible", and it mostly worked to get me a playable (ish) game! Granted, it's a knockoff puzzle game but hey, I sometimes find myself "playtesting" it instead of what I should really be doing, which is refactoring the code for what I'd like to have it do next, so I'm marking it as a win.
No relation to the Core Games game kit.. thing..<p><a href="https://coregames.com/" rel="nofollow">https://coregames.com/</a>
i am going to check it out, thanks for sharing!<p>I am learning Clojure and would love to use it for some hobby game-dev, but I have not found a way to compile to html so I am using Godot instead. Not really in awe of the OOP approach though.
for the love of god do not use clojure for game dev<p>absolutely not recommended even for solo<p>i would not recommend it for any sort of web app either<p>clojure/atomic is ovverated
; set max speed so small entities are not skipped by projectiles
; could set faster than max-speed if I just do multiple smaller movement steps in one frame<p>jesus wept. sweep. c'mon.
I thought this was something to do with RPG Maker[1].<p>They (you?) should change the name given the obvious trademark and general confusion issue.<p>[1]: <a href="https://www.rpgmakerweb.com/" rel="nofollow">https://www.rpgmakerweb.com/</a>