Hacker News Reader

Comment by klysm | Hacker News Reader

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).

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.

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.

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?

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.

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.

Minecraft seems to be doing fine.

Reply on news.ycombinator.com