Have worked on many games and game engines for several decades. Here's some quick advice that applies mostly regardless of the JVM. 1. Allocations of any kind

Have worked on many games and game engines for several decades. Here's some quick advice that applies mostly regardless of the JVM. 1. Allocations of any kind are often the most expensive operation per frame, or at least some of the ones that are fixable (you can't just not have physics in some games). As such, avoid allocations per frame. 2. Notice transition screens, loading screens before levels, brief artistic animated overlays (things like ROUND 1 - READY!). These just aren't for fun or to hide just disk IO, they can actually be used as a time to do controlled allocations. Let's say you're doing a Metroidvania for instance - perfect time when changing areas to load new stuff. 3. Use fixed-sized data structures like arrays. Vectors, Lists, any kind of dynamically resizing data structures are generally your enemy. Sure you can use them in non-essential parts, but it's an easy thing most of the time. These help you control the amount of allocations, and moreover ensure that your game runs predictably, especially when pushed hard. You shouldn't be letting your game get into insane states that would allow allocating 5 billion bullet objects even if your vector and a machine with 64 gigs of rams can handle it. Obviously some exceptions, but there's sound reasoning. 4. Operate on fixed-sized data structures in sequence. It's harder on the JVM, but in most platforms you can start trying to use this to help the runtime optimize for you, or better yet, get things to fit nicely into cache lines. Things like "events" and "callbacks" may seem helpful, but they are actually your enemy, even on the JVM. You are better off using a queue or mailbox approach if you need more performance and less GC surprises. 5. Pool. But don't just pool and allocate, make sure you are pooling efficiently. On some platforms, this means tightly packed structures with no holes. One cheat you can do is actually use an ID system and work with that to index into an array-based pool by getting via index instead of a search. Using dicts/maps for this is the wrong approach for so many reasons. There's an older GDC presentation about this somewhere I can't remember, but it talks about this in relation to entity systems and uses the term prius a lot. Free list might be something else on your google for this. 6. Pack your textures when you can. Do things like use a sprite sheet. It's not just the GC pauses that are the enemy on the JVM, but also hitting the file system. This will help reduce it at the cost of potentially more memory for a single texture. 7. Don't go wild with classes. Try a data-based approach. This cuts down on GC and is the basis for some flexible architectures like entity systems. Of course you may still need classes as containers if you are using Java, but you'll end up with less ugliness and perhaps less classes and instantiations of those classes this way. 8. Check out your JVM flags and tweak things more if you must. Check out https://docs.oracle.com/cd/E40972_01/doc.70/e40973/cnf_jvmgc.htm#autoId0 https://docs.oracle.com/cd/E40972_01/doc.70/e40973/cnf_jvmgc... for an example. Not the best guide, but my first google hit to just demonstrate. On a semi-related note, don't do stupid stuff like reflection or dynamically load in things that are just going to make the JVM angry. Simple is better than clever here. 9. Use a good time step for your game loop where you separate your sim time. It doesn't necessarily fix GC pauses, but it does ensure that if things are running slow you can respond and interpolate. 10. Related to the last point, try to do more per frame and don't assume all work is the classic game loop of render per tick. Naughty Dog did an interesting presentation on The Last of Us port to PS4 you can read about where they talk about optimizing the way they process frames. If your game permits similar approaches, it gives you a chance to squeeze out some performance this way. I have many more tips, but this is just off the top of my head. Some of these might seem like micro-optimizations, but they actually end up shaping your game's architecture so it is definitely important to think about it early if you are serious about not putting yourself in a performance corner. You can certainly develop games on the JVM. I personally don't recommend it unless it's for pleasure. C or C++ is still the way to go. I am sure you can have fun with Rust too doing it, but there's just so much ecosystem and people talent tied up in the former choices that it effectively makes anything else far behind. That said, you can write a good game in any language, and if you are just sane about your game it will be fine. Even with GC pauses, for some type games, ex: strategy that isn't real-time, your users would barely notice and it wouldn't effect gameplay. In short, be pragmatic no matter the language, stick to some of the above, and enjoy yourself and just get it built. Language is the least of your worries in the end, but still worth paying attention to on some level.