[HN Gopher] Core: New way to develop video games
___________________________________________________________________
Core: New way to develop video games
Author : resatori
Score : 155 points
Date : 2024-09-08 18:21 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Dalewyn wrote:
| 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/
| resatori wrote:
| 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.
| resatori wrote:
| I am actually also open for names, I don't know exactly what
| this thing is.
| Drakim wrote:
| Maybe change your wording to "an RPG maker", as "RPG Maker"
| is already an established brand.
|
| As for names, maybe something cute like ClojRPG?
| resatori wrote:
| But I don't know exactly what this thing is. I have coded
| like crazy on it and created a new component system &
| datomic-like transaction-data like effect system, so it
| is more than just an RPG maker. Its a whole new way to
| write games.
|
| For example side effects are just vectors of `[:tx/foo
| param]`.
| Drakim wrote:
| Then maybe something more generic sounding like
| ClojEngine? Naming is hard lol. Core is fine, but maybe
| add one more word to it, because googling just "Core" to
| find your repo is difficult.
|
| But I highly recommend changing the capitalization of
| Maker to maker to avoid being mixed up with the product
| RPG Maker. Adding "an" helps signal that it's a
| descriptor instead of a name too.
|
| Core: An RPG maker and engine for Clojure.
| 0xEF wrote:
| GamesCore - generic but serviceable name.
|
| CrystalCore - because RPGs must have some sort of magic
| crystal, it's the law
|
| CreataCore - why limit the name to RPG theme in case it
| develops into something larger?
|
| Just a few quick name suggestions for OP.
| card_zero wrote:
| If it aspires to become like Unity you could maybe call
| it "Clunj".
| BaculumMeumEst wrote:
| 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.
| Dalewyn wrote:
| 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.
| Dalewyn wrote:
| >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.
| hatsix wrote:
| only the owner of the copyright can make you change, however,
| being able to search for articles, tutorials, bugs,
| solutions, etc will be easier if you give it something unique
| CaptainOfCoit wrote:
| I think it's a "Maker" that happens to make "RPGs", not a "RPG
| Maker" engine. A bit like you could still call your shop a
| "photo shop" if there are photos for sale there.
| ramon156 wrote:
| It's like calling your project "engine" and telling people they
| can't call their project engine
| the_gorilla wrote:
| What about calling your project "GameMaker"? Is that taken?
| kleiba wrote:
| I love Clojure, but isn't a functional language with immutable
| data structures an odd choice for developing a video game?
| Vekz wrote:
| High performance real-time games it is questionable. Any genre
| that is more static turn based can be a great boon.
| resatori wrote:
| 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!
| virtue3 wrote:
| 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 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.
| kleiba wrote:
| Minecraft is written in Java, it doesn't look like the
| choice of platform kept it from becoming a success.
| jsheard wrote:
| It was however completely rewritten in C++ when they
| needed to port it to more constrained platforms, every
| mobile and console version uses the C++ codebase while PC
| has both versions in parallel. If you ever intend to
| release your game on multiple platforms then Minecraft
| isn't an example to follow unless you're up for starting
| over from scratch at some point.
| pjmlp wrote:
| A side effect from specific platforms not allowing Java,
| and Microsoft buying Mojang.
|
| Notch surely isn't sorry for having coded it in Java.
| jsheard wrote:
| It worked out for Notch, sure, but most indie devs don't
| get the luxury of only considering console ports _after_
| they 're already set for life from initially only
| releasing on PC. Planning for cross-platform from the
| start is table stakes, especially now the Switch has
| become just as if not more of a popular platform for
| indie games than PC is.
| mrkeen wrote:
| Bad performance did delay one of the big new-biome-type
| releases in the Java version.
| SkiFire13 wrote:
| If anything using Java made it extremely moddable and is
| IMO part of the reason why it became a success.
| jay_kyburz wrote:
| Unity's new incremental gc saved our bacon.
| lupire wrote:
| 60 FPS of 3D objects in a 3D world?
| resatori wrote:
| I find it very natural to work with because clojure is based on
| the JVM so the project uses libgdx under the hood (deploys to
| all platforms, huge library) and I can use lisp for everything
| else to do basically anything.
|
| Combined with clojures way of handling immutable datastructures
| so well & the excellent protocol system
| (https://www.freshcodeit.com/blog/clojure-protocols-and-
| the-e...) I could separate the whole game easily into separate
| components.
| kleiba wrote:
| Sorry, but I feel like your comment does not actually address
| my concern of whether having to deal with immutable data
| structures in a functional way would lend itself especially
| well to video games.
|
| Of course, the Clojure approach is great for a lot of use
| cases, but video games traditionally do a lot of mutable
| changes to components. That doesn't mean, of course, that it
| cannot be done any other way, but it would certainly be a
| different approach.
| resatori wrote:
| I don't understand your concern. Would you mind phrasing it
| differently?
| kleiba wrote:
| Oh, and allow me to add: I'm not criticizing, I'm just
| putting a possible concern out there for discussion. That's
| why my original post was worded as a question.
| runeblaze wrote:
| It's not _that_ weird -- your next AA game or AAA game will
| probably not use it, but in React (reducer, or Redux), very
| interactive stuff, immutability is often seen.
|
| Also Clojure has better performance prospects than Ruby and
| Python, both have seen "real" usage in commercial indie games.
| Jare wrote:
| It's a lot easier to embed Python than Clojure. Oldest
| examples I recall are Severance: Blade of Darkness by Rebel
| Act Studios, and (coincidence, nothing to do with the
| previous) Blade 2 by Mucky Foot, about 25 and 22 years ago.
| dagmx wrote:
| Tim Sweeney seems to be betting that's the direction with UEFN
| where Verse is a more approachable take on Haskell.
| thesuperbigfrog wrote:
| 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
| sph wrote:
| 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, 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.
| smellybigbelly wrote:
| Could an expert strong man the argument that functional
| programming languages like Haskell could in theory be more
| performant than C because of the nice properties of pure
| functional languages?
| sph wrote:
| CPUs are imperative and pervasively mutable. Languages
| like Rust are able to have so called zero-cost
| abstractions that are reminiscent of functional
| programming (iterators for example) but the thing is
| abstractions are by nature always slower than the real
| thing.
|
| But not all games are AAA FPS that require ingenious
| optimized codepaths to perform well, not in this day and
| age, so this is why you see commercial games running on
| "slower" abstractions such as C# (AOT compilation doesn't
| make it less of an abstraction layer), so you can very
| well design a commercial game in Haskell or Scheme or
| Lisp or Clojure if you wish. Nothing stops you, apart
| from the lack of serious game dev frameworks built in
| those languages.
|
| It all depends on the compiler, really, and it is
| asymptotically hard to compile functional languages so
| they perform as fast as C for example. There is no market
| for "high performance Haskell or Clojure", so there is no
| compiler that good either.
| neonsunset wrote:
| "Cost" in C# comes from the (ab)use of classes for
| transient data, virtual/interface calls and automatic
| memory management. Another source of difference is in
| compiler capability of Unity's own flavours: IL2CPP, Mono
| and Burst, versus .NET's CoreCLR JIT and NAOT versus
| GCC/Clang. However, the latter has much less impact on
| "application code" and more impact w.r.t loop
| autovectorization, for which in C# you're supposed to use
| bespoke portable SIMD API which is fairly user-friendly.
| For the former, you are not "locked" into a particular
| paradigm like with Java or Rust and can mix and match
| depending on how hot a particular path is (for example -
| construct buffer slices with LINQ because there are only
| 16 of them, but each one is 512MiB large, so do the
| actual work with Vector<T>).
|
| JVM languages have a huge gap* in low-level capabilities
| where-as C# sits next to C and Rust in many of the
| features that it offers, even if the syntax is different.
| JVM implementations also come with significantly higher
| FFI cost. This makes them an overall poor choice for game
| development. Your experience of writing a game engine in
| pure C#, calling out to rendering and other device APIs
| will be massively better than doing so in
| Java/Kotlin/Clojure/etc, because of both runtime
| capabilities and ecosystem of interop libraries.
|
| Also, C# _has_ zero-cost abstractions in the form of
| struct generics which are monomorphized like in Rust, and
| performance-sensitive code relies on this where
| applicable in "modern" codebases.
|
| * Projects like https://github.com/bepu/bepuphysics2 are
| impossible to implement on top of JVM without calling out
| to native components. No, the incubating Panama vectors
| are not in the place to provide good performance there
| either.
| Barrin92 wrote:
| >a game is nothing more than a function that takes {state,
| mouse, keyboard} as input and returns {new_state, output}
|
| but that's a completely convoluted approach to identity in
| a model for a videogame. The reason Rich Hickey took that
| approach in Clojure to state and identity is because in the
| domains he cared about he wanted to prevent the destruction
| of past state. (he wanted to avoid what he called "place
| based programming" IIRC).
|
| If you want to implement a git like versioning history say,
| you really care about any change to state as a collection
| of individually immutable snapshots. But in a videogame
| that's completely artificial. Nobody thinks about a
| persistent entity in a game as a collection of states at a
| million points in time. It's much more natural and
| performant to think of your entities as persistent and
| mutable and you basically only care about where they are
| now.
| deisteve wrote:
| Coming from clojure I'm very wary of any non-mainstream
| languages like Elixir, Rust, Clojure etc.
|
| It's a costly business mistake to build your tech stack
| using any of the above languages. The trade off simply is
| not significant enough to matter vs using mainstream
| languages with 10,000x the number of mindshare.
| deisteve wrote:
| the biggest tradeoff is talent pool
|
| you won't be able to find them in enough numbers and it would
| be tough to gauge their proficiency too
|
| unless you are purely interested in it for academic purposes,
| its best to avoid clojure and any sort of esoteric languages.
| Even Rust development is riddled with false roads and
| mirages.
|
| i just want to save anyone reading this 5 years of their
| time. You don't get better when you are constantly having to
| re-invent the wheel for essentially shaving off roughly
| 20~30% lines of code you'd write in python, php, ts. It's
| hardly a fair trade off
| tinyspacewizard wrote:
| Functional Programming hasn't even been tried for game
| development, really. There is a lack of overlap between the
| game dev industry and academia. The studios are (rightly) risk
| averse and try to use the same broad strategies to build games
| - OOP, maybe ECS for large swarms, etc.
|
| Personally, I think that FP _could_ be a great fit, but we
| first need to come up with architectures that solve real game
| development problems. We have to do this with small scale
| experiments first (game jams are perfect for this) and then
| scale up only if they succeed.
|
| This project is exactly that - kudos to the author.
| CyberDildonics wrote:
| Game programmers are mostly extremely skilled and well aware
| of functional languages, how they work and what they do.
|
| They aren't using them because they aren't a good choice for
| delivering games that need to run fast and consistently in
| real time.
|
| Immutable data structures and garbage collection might be
| nice for people writing something, but that isn't what
| someone buying software wants, they want smooth and fast.
| Alex-Programs wrote:
| 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 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.
| spoiler wrote:
| > - 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).
| pizza234 wrote:
| While any design requires discipline, ECS systems have little
| or no coupling between them, and they very easily end up all
| over the place; in addition to the chaotic design, one ends
| up also not having an idea of what happens when.
|
| For this reason I agree - developing games using an ECS
| design requires more discipline to manage complexiy, compared
| to an imperative one.
| spoiler wrote:
| I've not had much issues understanding what runs when,
| because for the most part I didn't need to care that much,
| and when I did it was possible to order/schedule systems in
| Bevy. That's even a bit easier nowadays too, since the API
| improved!
|
| With regards to the chaos: I think it can be avoided, but
| like you said it requires a bit of discipline. I don't feel
| like it required that much more than normal software
| engineering (but I'm also the type of person that documents
| and tests everything even on personal projects lol). The
| plug-in system makes it easy to help bring order too.
|
| This is all through a bevy-tinted lens, since I've done
| very little game dev (dabbled with UE and Godot) outside of
| bevy, though!
| p1necone wrote:
| I agree with this - ECS lets you write totally decoupled,
| composable bits of game logic very easily, which is super
| powerful. But in my experience if you're not careful you
| end up with a hundred perfectly decoupled little things and
| it's really difficult to remember how they actually all
| come together to make the whole game you've built.
|
| Easily grokable filenames and file structure are very
| important, and bevy specifically has a pretty nice plugin
| system which lets you really clearly 100% isolate groups of
| state/logic into more sensible sections instead of
| ultimately having some root level game loop that's directly
| setting up your 100 tiny little poorly named things.
| alice-i-cecile wrote:
| Yeah, I'm one of Bevy's maintainers, and I've seen folks
| get tangled up (or overengineer things wildly) if they go
| in without a clear plan. ECS (and a strong compiler) makes
| things much easier to refactor, but I generally agree that
| the more flexible nature demands more discipline.
| juliangmp wrote:
| > 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.
|
| Not game dev either but I do have to say that I find Godot's
| design to be one of the best oop desings I worked with. I tend
| to not use oop much today (C++ embedded), though I did learn
| programming with C# so I'm fairly used to inheritance.
| HideousKojima wrote:
| >and "signals", which are meant to decrease spaghetti but only
| increased it for me.
|
| Signals are basically just event subscriptions. In fact, if you
| use C# with Godot you can actually just use C# native
| delegates/events.
| nightowl_games wrote:
| As a professional game dev who has years of experience
| producing real products in both Unity and Godot, I am totally
| not with you about your thoughts on Godot vs unity.
|
| 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.
| seanthemon wrote:
| I think the original commenter just really likes "plug and
| play" solutions with a lot of hand holding which is what
| Unity is excellent at. The problems come down the line.
|
| Godot is objectively a way way better tool
| monkeydreams wrote:
| > Godot is objectively a way way better tool
|
| If you like things like Godot, Godot is the type of thing
| you will like.
|
| Seriously though, Godot works way better for me using C#
| than it does with GDScript and the OOP structure means I
| can refer to classes by their identity.
| Thaxll wrote:
| GDScript sucks big time, it's not even close to C#. They
| should drop that Python like language and go full in C#
| integration.
| TillE wrote:
| The core developers are too enamored with GDScript, but
| that's fine, C# and C++ (GDExtension) support is excellent.
| There are only a handful of API functions which are
| hampered by their need to support GDScript, so it's
| something you can basically just ignore.
|
| You don't even have to use Nodes much, though they're great
| for lots of stuff. For real performance, you can drop all
| the way down to their thin wrapper over Vulkan and do
| whatever you want.
| glimshe wrote:
| GDScript makes simple things simple and complicated things
| complicated. It's pretty good for the simple parts of your
| game. You can still use C# for its complicated parts as
| they integrate well.
| farazzz wrote:
| I love everything about Godot so much, except for its UI
| system
|
| It is just so confusing to me and took me over a day to get a
| simple menu aligned how I wanted
|
| it might just be me not understanding how it works though
| nkrisc wrote:
| Godot's UI system is easier when you realize that Control-
| derived nodes are even more granular than even HTML
| elements. They're more like Tailwind classes.
|
| Yes, your UI will be a tree of Control nodes 20 levels
| deep, and that's fine.
|
| Your root UI node will probably be an HBoxContainer, or
| VBoxContainer, each of which simply arranges their children
| horizontally or vertically, respectively. Between those two
| nodes you can create 90% of UIs you'd want to.
| jayd16 wrote:
| Unity is a bit of a mess but to compare apples to apples when
| Unity has more features seems not quite fair.
|
| Are signals significantly better than Unity events or is it
| more that the API uses them heavily?
|
| Honestly, why doesn't Unity retool SendMessage() and public
| API callbacks to be an exposed Unity event? Unlike merging
| prefabs and scenes, that's not even a breaking change.
| NotAnOtter wrote:
| I'm not that familiar with Godot but the built in language
| always felt like a misstep. Maybe someone more familiar with it
| can make a defense.
|
| 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.
| r-w wrote:
| Godot lets you use whatever language you want. C# included.
| Supermancho wrote:
| https://github.com/Godot-Languages-Support/godot-lang-
| suppor...
| steeleduncan wrote:
| Godot has supported C# for a while now. There is no need to
| use GDScript
| vyrotek wrote:
| Unfortunately Web Export is not supported with C# in Godot
| 4.X. And probably won't be for a while*. It's the ONLY
| reason I even bother with GDScript.
|
| https://github.com/godotengine/godot/issues/70796#issuecomm
| e...
|
| And despite my best efforts to statically type everything
| in GDScript, the language is full of holes that lose all
| the safety.
| kasztelan_ wrote:
| I wish that was true. I just started rewriting my project
| from C# to GDScript today so it can run on 32 bit ARM
| android devices.
|
| Let's say I'm not a big fan of the language. Why the hell
| they decided to not implement normal for loops, was just
| googling how to iterate an array backwards and most people
| were like "just invert the array and iterate over it, bro"
|
| They should have just used Typescript, it's a sweet spot
| between safety and productivity.
| nkrisc wrote:
| The docs have an example of iterating an array backwards:
|
| https://docs.godotengine.org/en/stable/classes/class_@gds
| cri... var array = [3, 6, 9]
| for i in range(array.size() - 1, -1, -1):
| print(array[i])
|
| Admittedly not very pretty but it certainly works.
| moomin wrote:
| Now I've never used it, but there's always a case with an
| engine with its own objects to have a language that
| understands those objects natively.
|
| Unreal Engine started out that way.
| lairv wrote:
| Isn't pygame closer to SDL or raylib than a game engine ?
| raytopia wrote:
| Pygame is a wrapper around SDL.
| smitec wrote:
| I'd recommend giving Raylib a look if you haven't. I've been
| working on a couple small ideas using it lately and it feels
| very aligned to being a game 'engine' for people who come from
| a more classic software engineering background.
| Supermancho wrote:
| > 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.
|
| Having programmed for over 25 years now, this was my
| experience. I feel like a little more IDE introspection or
| tooling to make the signal/listener connections more
| manageable, is the special sauce that's missing. The event
| pubsub moel becomes unmanageable to document/control with any
| non-trivial application. Godot has no encapsulation or tracking
| support, allowing all modules to hook to any event leads to
| spaghett, which you learn when working with large projects in
| various languages (JS et al).
| vyrotek wrote:
| I recently learned that the popular game Balatro was made in
| LOVE. I had never heard of it until then. But looks
| interesting.
|
| https://love2d.org
| panza wrote:
| I'm a commercial dev, previously used Unity, now using Godot.
| This comment rings true of GD Script and signals. I get around
| this by using C# and its event handling.
|
| Working with nodes and editor bugs (or features? Hard to know
| really) is probably the most frustrating - you can really feel
| that this was initially built for 'smaller' projects.
|
| For this reason, I rarely use the editor outside of setting up
| the scenes and a general hierarchy.
|
| Daily tools: Emacs (with C# LSP) most of the time. VS Code for
| debugging. Godot editor for tweaking the scene tree.
|
| Perhaps this perspective is useful for other devs thinking
| about Godot.
| kgeist wrote:
| 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?
| stavros wrote:
| To be fair, it asks whether game development can be simple. It
| just so happens that the answer is probably "no".
| kitd wrote:
| Betteridge's law of repo descriptions, or something
| resatori wrote:
| A clojure vector is an inbuilt data structure of the language
| and looks like this: [1 2 3]
|
| 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.
| CyberDildonics wrote:
| > inbuilt data structure of the language and looks like this:
| [1 2 3]
|
| array / vector
|
| > construct side effects which I call 'transactions'
|
| setting a variable
|
| > where :tx/foo is a keyword
|
| variable or hashmap
|
| > uniquely identifies the component behaviour
|
| running a function
| vasco wrote:
| Have you considered googling "clojure X", where X is each of
| those things in commas? Other than datomics which has some
| result pollution everything else has great first page results.
| the_gorilla wrote:
| This is common among programmers. They come up with some
| insane, convoluted set of rules that they happen to like and
| then declare it simple and elegant. To anyone on the outside it
| looks schizophrenic in nature.
|
| Of course it has a component system. I just hope no one sees
| this mess and thinks that if THIS is considered simple,
| videogame development isn't for them.
| resatori wrote:
| The result of the experiment is that no, it's not simple.
| astlouis44 wrote:
| There's already a commercial platform for game creation called
| Core, powered by Unreal Engine 4)
|
| https://en.wikipedia.org/wiki/Core_(video_game)
| nightowl_games wrote:
| 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.
| doctorpangloss wrote:
| On the other hand, making things intellectually stimulating:
| even if you waste 100h making clojure datomics in order to make
| 1h of level content, 1h>0h, and if it were boring and therefore
| you wouldn't make it at all, you've come out ahead. The
| "Jonathan Blow uses Jai" thesis of indie development.
| Dansvidania wrote:
| it _does_ say it's experimental.
| frompdx wrote:
| 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.
| TechDebtDevin wrote:
| LLM generated comment?
| slater wrote:
| No relation to the Core Games game kit.. thing..
|
| https://coregames.com/
| ccvannorman wrote:
| It would be interesting to analyze data of "time/complexity spent
| on game engines" vs "complexity/interest" of produced games.
|
| As a game developer, I expect to see a log curve of diminishing
| returns of novel games given any simple templating/engine system.
|
| In other words, the better you make your cookie cutting machine,
| the less variance your cookies will have.
| Apocryphon wrote:
| Superb username
| Dansvidania wrote:
| can you please elaborate?
| resatori wrote:
| Thanks, it is from a time when I read too many osho books and
| started a blog...
| deisteve wrote:
| for the love of god do not use clojure for game dev
|
| absolutely not recommended even for solo
|
| i would not recommend it for any sort of web app either
|
| clojure/atomic is ovverated
| resatori wrote:
| To be honest I think this project actually failed. It is an
| overengineered mess and lacks any kind of clear structure.
|
| 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
| Dansvidania wrote:
| i am going to check it out, thanks for sharing!
|
| 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.
| resatori wrote:
| https://github.com/xpenatan/gdx-teavm
|
| This is a libgdx backend for web. Should be possible to use
| with clojure but haven't tried. This is actually the most
| interesting next step for the engine I think - would let anyone
| try the game from the browser!
|
| Even if it's would be hard on performance o think it would be
| worth it - I would just make the game turn based then
| Dansvidania wrote:
| will check that too, thanks!
| jbverschoor wrote:
| Does nobody use cocos?
| breck wrote:
| 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.
|
| Also, how about clojurescript so you could run this in browsers?
|
| My user test: https://www.youtube.com/watch?v=gcMBaQI7d-c
| lincon127 wrote:
| Making games has always been simple. Making engaging games is
| what requires a little more work.
___________________________________________________________________
(page generated 2024-09-08 23:00 UTC)