Indigo: A game engine for functional programmers, in Scala | Hacker News Reader

Indigo: A game engine for functional programmers, in Scala

indigoengine.io

104 pointsbased254 comments

I tried it a couple days ago and so far my main gripe is that I am not all that familiar with Scala, which anyway seems like a great language. The project seems very well enginereed and the maintainer is very friendly (there is a Discord where you can ask questions and chat a bit). I'd recommend you to try it if you are curious about Scala.

As a side note, it's quite exhausting to enter into a random HN post and see that most of the discussion revolves around some negative comment that required zero effort. Not only the JVM aspect is completely irrelevant for this project, but this is an engine geared towards making 2D pixel art games for fun, not AAA games.

Regarding second paragraph; I called out this very tendency a few days ago (https://news.ycombinator.com/item?id=35601539) and someone came forward to defend it.

HN may not be a great place for makers to get feedback.

I was reluctant to write that paragraph, as I didn't want to derail the discussion into a third tangen about comment etiquette and negativity. But yes, I fully agree.

To be fair, at the time I am writing this the negative comment about the JVM is heavily downvoted and the top 2 comment threads are very positive.

I guess I'm adding my own to the pile with this, but your last paragraph resonates. I feel like it's getting to a point where one can predict with reasonable accuracy the first top comments just by the title of the post, and been thinking more and more about what a proper quantitative analysis of this feeling would yield.

I have been registered for a few years and I used to enjoy the discussions, at least when it came to technical topics.

I think HN has probably always been quite dismissive and contrarian (like that infamous comment about Dropbox), but to me it feels like that type of comments are becoming more frequent and lower effort.

Maybe I am just becoming older and tired of arguing online ^^

There is a growing ecosystem of frontend and creative computing libraries in Scala. It's a fun way to get into the language, and a good language in which to have fun.

Yup. I'm quite hopeful that Scala could become a very nice ecosystem for creative computing, not only due to libraries but also tools that enable a (near) live coding experience like Scala CLI, Polynote and SCRiBBLE.

It's not all sunshine and roses, but I think its heading in the right track.

Can't believe you didn't mention Minart! ;-) (https://github.com/JD557/minart)

The live coding experience is something where I think a lot more work could be done. This paper by Ravi Chugh et al, and a lot of his other work, points to interesting directions to take: https://arxiv.org/pdf/2301.13302.pdf

I find it difficult to write games without having fine grained control over memory management.

Are your games all 3d?

I think providing a steady frame rate, fast loading times, short transitions, makes the user experience a lot better when it comes to games.

Snake speed is too fast or is it my wireless keyboard ? Lost three times. :(

https://indigoengine.io/pirate.html performance is abysmal on Safari 16.3 and macOs 13.2.1. The oddity is that the framerate is being reported as 30-31fps.

Are you perhaps in energy saving mode? I get 60fps on a M1 laptop.

On Safari?

Interesting, I'm hosting https://scalajs-games.wiringbits.net and some users reported poor performance on Safari, still, I never dig into it, I wonder if you experience the same.

Ref: https://github.com/wiringbits/scala-js-games

Quite interesting how people are downvoting that when it is the reality, the game is a slideshow, it reports 30fps but might effectively run at 1 or 2 fps on my M1.

Running at 60fps for me, macOS 12.5

Are you running with Safari?

60fps for me. Is it an older Mac?

M1, are you running with Safari?

M2, Safari.

60 on iOS.

The JVM feels like a bad thing to write games on

As others have mentioned, Indigo is entirely written in Scala.js. Therefore, it runs on JavaScript in browsers. There is no JVM at all at run-time.

(A JVM is required to compile the code, but what you run and deploy has no dependency on any JVM stuff.)

Source: I am the lead author/maintainer of Scala.js and I wrote a personal game project in Indigo.

In general, I would agree. Simply because of how the games ecosystem is currently, not because of the JVM being good or bad generally.

But if you want to make a good game, and have the desire and skills to do so, the language doesn’t matter. My favorite game of all time, a quite successful game that has critical acclaim from people all over the spectrum, was written in Java.

It’s Slay the Spire, to answer the next obvious question.

Unless it is some AAA game, the JVM is more than apt for writing games, especially that the rendering itself is OpenGL/Vulkan libcalls either way.

GC pauses and a very high memory usage are still a problem. That's why we don't see many Java games (Minecraft was a notable exception and ran like a dog).

That was true about 20 years ago, but it's not really true any more.

The real reason we don't see many Java games is that most games are written using either Unity or Unreal Engine, and neither of those support Java as a first class language.

Exactly. Also both Unity and Unreal Engine have GCs and that hasn't stopped them from being used in most games. If anything, games can afford GC more than many other applications, because it's expected of a game that it will consume a lot of resources so they can just hog cores and memory and it's fine. You don't expect users to be running multiple games at the same time. Also, a lot of the more real-time work is offloaded to the GPU anyway.

There is a difference between a GC used for only a tiny fraction of objects that implement a certain interface (Unreal Engine case) and using a GC for all the things like Java does, which you cannot opt-out. In Java case the GC has to scan gigabytes of objects, and often the garbage production rate is also in gigabytes per second, hence an efficient general purpose GC implementation is much more challenging.

You're missing the point. There a small number of games that are extremely performance sensitive. Mostly FPS games. Java is not a good choice for these. Everything else is fine. The ZGC really does deliver on its claim. Pauses are very small (milliseconds) and it can handle heaps that are several GBs in size. However, this doesn't even matter for most games. A few pauses are fine in, say, a real time strategy game. My kids used to play Minecraft on a 10 year old Intel Mac running Java. It was good enough.

This is still true, albeit the problems are somewhat smaller or happen less frequently. All those low-pause garbage collectors like G1, ZGC and Shenandoah make no guarantees about pauses and all of them can degrade to stop-the-world mode of operation under some circumstances, and can cause pauses several seconds long. The difference is that they do it less likely, and the old ones did it all the time. The low pause collectors also have much larger overhead in both memory and CPU than old collectors as well as traditional allocation with malloc/free.

Btw, for games even a very low 1ms pause is more than 10% of frame budget, and can make the frame miss the deadline. I guess for indie games the quality bar is simply lower and occasionally missing a frame is ok.

There are plenty of indie games written in Java, there are low-lat GCs available for the JVM (ZGC) that promises sub millisecond pauses, and you don’t have to use a ton of memory, there are ways to manage it.

Minecraft was written in a very suboptimal way, its creator was a very novice developer — there are mods that easily increase performance many-many times.

The biggest problems are developer skills, and the perception only C with tons of inline Assembly goes.

Even Unreal ships a GC.

Dunno if I'd write games in Java since it's very geared toward server coding and the clientside/gui-side of things is all but gone from the language, but Java's GC is a lot more sophisticated today than it was 15-20 years ago. You realistically won't see GC pauses at all unless you're doing something very strange. The memory consumption has also gone down considerably.

Looks like it's Scala.js.

depends on the type of game. For 2D games libGDX is actually a pretty nice framework. Slay the Spire was written using it, and what did it gross like 100M?

I will say, having been the guy saying he really enjoyed StS in the sibling comment, that the devs of StS have gone on record saying that they probably would have chosen another library other than libGDX if they did it again. My understanding is that it’s simply the same reason as I mentioned in my comment - libGDX simply isn’t used enough and that’s a ding against it when you can go and use unity/Mono and have a thousand stack overflow questions for every one stackoverflow libgdx question.

Edit: apparently unity has been off mono for about 3 years now. Tangential but interesting

I think, in an age where ChatGPT can point you in the correct direction in niche questions, that popularity of a tech stack becomes irrelevant to whether you can find answers or not.

iOW, as long as a large enough userbase and codebase exists, popularity doesn't matter for getting answers.

Might matter for shaking out bugs, enhancements, etc, but not for learning resources.

> I think, in an age where ChatGPT can point you in the correct direction in niche questions, that popularity of a tech stack becomes irrelevant to whether you can find answers or not.

It's the exact opposite. I really don't know how you got this conclusion.

The quality of the answers from ChatGPT/Copilot/whatever highly depends on how many learning materials in the training set. In other words, popuplarity matters more than any time ever.

If you don't believe me, ask ChatGPT to write a Blender addon, then ask it to do something similar but for Houdini. The difference is day and night. By the way, Houdini is basically used for every single VFX studio. Even that doesn't reach the "large enough userbase" needed for ChatGPT to generate quality answers.

I thought you didn't have to use the JVM with Scala. Not so?

To be fair, Scala.js is a relatively new project, and I had avoided it for a while due to library compatibility issues and stability concerns. It now seems pretty freaking awesome. There is a concerted effort in the Scala community to break the dependency on the JVM, via Scala.js and Scala Native. This however requires porting the Java standard library to each platform.

> To be fair, Scala.js is a relatively new project

I don't know if you are aware, a few months ago, Scala.js turned 10 years old: https://www.scala-lang.org/blog-detail/2023/02/05/ten-years-...

10 years old is new tho. I'm not being sarcastic. See how old Unity and Unreal are.

Most gamedev still consider Godot new. Godot is 9 years old.

Scala is a JVM language. If it’s Scala.js, as referenced in a sibling comment, it’s still Scala being cross compiled. Therefore it’s still JVM at the source

I’m not sure this is true, it’s JVM if you are running JVM bytecode. I don’t think scalajs executes on the jvm

You are right. See my other comment for some more details.

> Therefore it’s still JVM at the source

Wat. No.

Scala is a language. It has compilers for Java bytecode, JavaScript, and native.

A language that just so happens to have built-in interoperability with Java.

The JVM flavor of Scala has built-in interoperability with Java.

Scala.js has built-in interoperability with JavaScript instead.

And Scala Native has built-in interoperability with C.

Yes.

Given Java's goal is "write once, run everywhere"...that's not a bad thing.

Minecraft seems to be doing fine.

Reply on news.ycombinator.com