Hacker News Reader

Comment by kgeist | Hacker News Reader

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?

View on HN

Copy edited their blurb:

Core is an experimental tool that simplifies the process of creating Action Role-Playing Games (Action-RPGs) by providing a unified set of tools and a streamlined approach to game development. It represents game elements (entities) and their properties (components) as simple data structures, allowing for greater flexibility and easier modification. The entire game state is stored in a single container (app/state), making it easier to manage and update the game's data. Core also provides a graphical user interface (GUI) for editing game content stored in a single file (resources/properties.edn), making the development process more accessible to non-programmers. By using Malli schemas for data validation, Core ensures that the game content is consistent and error-free, reducing development time and improving the overall quality of the game.

To be fair, it asks whether game development can be simple. It just so happens that the answer is probably "no".

Betteridge's law of repo descriptions, or something

Game development can be simple, but the game with either be boring (games with thousands of identical rooms are simple to make), or trivial to finish with no replay value (because there isn't much you can do). In the real world games are all complex as making an immersive world requires complexity.

There are a few games like suduko that are about that are simple and yet have high replay ability. If you can come up with another game on these lines great, but such games tend to be very different from the things. Good luck in making an exception.

Mandatory "simple is not the same as easy": https://www.youtube.com/watch?v=SxdOUGdseq4

Clojure vectors are just lists, basically.

"Atoms" are mutable references to immutable datastructures (Clojure is immutable-by-default). You can kinda think of them as pointers, but with specific update semantics.

Transactions are similar to database transactions: mutate several datastructures simultaneously, but only 'commit' the changes if all operations succeed. Roll back and (optionally) retry if any part fails.

Malli schemas are just a way of doing typechecking in a dynamically-typed language.

Datomic is a bigger topic. It's an implementation of a non-SQL database system based on immutable datastructures, in which all changes are appends rather than being destructive, allowing you to 'rewind' the database and view it at any point in the past.

Clojure the language has a built-in state management model, which this project attempts to apply to game development. The best way to learn about this model IMO is to watch the talk 'Are we there yet' by Rich Hickey (author of Clojure).

Well Balatro didn't so it's not hopeless.

I don't think gamedev was ever simple, but I do believe the process can be streamlined. From my experience the biggest choke point (outside of keeping everyone aligned properly) is asset production. Arguably the most important aspect to make games sell, but the 3d asset pipeline has only gotten more complex.

If you can streamline on that (and stay lean as a team) I imagine you can dramatically shorten development.

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.

> 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

Reminds me a little of this Flappy Bird demo which makes use of DataScript's Datalog rules https://frankiesardo.github.io/minikusari/#!/minikusari.tuto...

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.

It looks simple and elegant to me, and I've only used Clojure a little before. Perhaps you're just not very experienced as a programmer in anything except mainstream languages.

Maybe it is simple. I won't truly believe it until they battle test it with a decently involved game.

And I'm not even talking some fancy 3d title. How much would I fight against the framework if I wanted to try and recreate Thomas was Alone or Baba is You? Seemingly simple games but ones with very involved systems and state management.If it can truly handle all those edge cases and saves me times after rampup, I can concede it as simple.

The result of the experiment is that no, it's not simple.

Clojure the JVM Lisp language, not closure the concept I think.

A clojure vector is just a vector. Like a Java vector or C++ vector.

The rest seem to be Clojure concepts or libraries. It's a bit disorienting because the language isn't capitalized in the link.

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.

I did, found the clojure docs. Now I'm even more confused. What is so special about clojure vectors - as opposed to a python list, or C array? Some uses in the example seem like a better match to python dict, a C array of structs (linked list of structs?), perhaps a C++ std::map. Depending on what your goal is I know of dozens of different data structures and algorithms (they are part of the basic things a CS major covers) However clojure was called out specifically as if there is something more that is both important to this discussion and non-trival in some way with the way arrays/lists/vectors are implemented in other languages.

The key idea behind Clojure data structures is that they are immutable, but don't require a full copy on update, because an updated version partly reuses the initial version. The data structure that enables this is called HAMT (hash array mapped trie). Clojure's implementation modified the initial Phil Bagwell's implementation of HAMT in a subtle way in order to make performance characteristics not degrade over time.

Interesting, it makes more sense now. Though I'm not clear if you want/need that in a video game. In general you want two data structures, one current state of the world and one next state - since they have a lot of similarity it at first makes sense to do what you say, except the you lose the advantage of vector: it is very cache friendly to iterate on a vector, or even two vectors, while it appears (without knowing internal details) that your HAMT is less cache friendly as the next element is not in the next memory location.

Of course I'd need benchmarks to make a real judgement. The above is my gut reaction.

Reply on news.ycombinator.com