5 ms·

I have became a 100% Kotlin convert. Every single project I work on now is using Kotlin. I have also found that if you are using LibGDX Java game framework, it

I have became a 100% Kotlin convert. Every single project I work on now is using Kotlin. I have also found that if you are using LibGDX Java game framework, it's very trivial to convert it to Kotlin. I have been doing that pretty extensively and it has been very pleasant. Feel free to check my GH for some examples. Most notably, the Bayesian Classifier. Also be sure to check out the Kotlin slack room. It is filled with a bunch of great and active people. But most importantly, just go try it. If you come from Java and are hesitant to leave given all the nice libraries available in Java, Kotlin is for you.

sdegutis 10y ago
On the topic of using the JVM to make games, do you find yourself using the trick of not allocating any new objects (wither from Java or Kotlin) within the game loop? I've heard of that trick, and am considering using it because GC pauses are the main reason I'm considering avoiding the JVM for games.
- KennyCason 10y ago
  Definitely. The use of object pools for performance is common in game development regardless of language. It's something that I tend to add in as needed or when I have decided that a game I'm working on warrants this level of engineering. (i.e. I wouldn't care about it as much if I'm just programming pong or Tetris.)
  - sdegutis 10y ago
    Awesome thanks for the advice. Maybe one day I'll get around to making that video game I wanted to make 15 years ago. :D
    - KennyCason 10y ago
      Good luck! Game development is what got me addicted to coding to begin with! :)
- mike_hearn 10y ago
  Worth noting that Kotlin's support for compile-time inlining can help reliably eliminate object allocations that otherwise you'd rely on the JITC to eliminate. So that can help.
- KennyCason 10y ago
  A bit of a late response as I just noticed your comment "I'm considering avoiding the JVM for games." I have found myself in this boat many times. I have coded games in Purebasic, TI-83/89 Basic, Z80, C/C++, Java, Kotlin, Javascript, Haskell, Swift, etc. If you are an indie/hobby developer, don't worry about the language too much. Just do it in what's comfortable and enjoy the process. That alone will increase the odds of you completing the game by 50% (random number).
- optionalparens 10y ago
  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.
- iamcreasy 10y ago
  It's not just JVM - even if you are a Unity 3d user you need to work around GC too. There are programming guidelines to ensure less frequent GC pauses. IMO the trade off of having a GC worth is for small developers.
  - pjmlp 10y ago
    Yes, but it should be noted that Unity is using a Jurassic version of Mono.

sdegutis 10y ago

On the topic of using the JVM to make games, do you find yourself using the trick of not allocating any new objects (wither from Java or Kotlin) within the game loop? I've heard of that trick, and am considering using it because GC pauses are the main reason I'm considering avoiding the JVM for games.

KennyCason 10y ago
Definitely. The use of object pools for performance is common in game development regardless of language. It's something that I tend to add in as needed or when I have decided that a game I'm working on warrants this level of engineering. (i.e. I wouldn't care about it as much if I'm just programming pong or Tetris.)
- sdegutis 10y ago
  Awesome thanks for the advice. Maybe one day I'll get around to making that video game I wanted to make 15 years ago. :D
  - KennyCason 10y ago
    Good luck! Game development is what got me addicted to coding to begin with! :)
mike_hearn 10y ago
Worth noting that Kotlin's support for compile-time inlining can help reliably eliminate object allocations that otherwise you'd rely on the JITC to eliminate. So that can help.
KennyCason 10y ago
A bit of a late response as I just noticed your comment "I'm considering avoiding the JVM for games." I have found myself in this boat many times. I have coded games in Purebasic, TI-83/89 Basic, Z80, C/C++, Java, Kotlin, Javascript, Haskell, Swift, etc. If you are an indie/hobby developer, don't worry about the language too much. Just do it in what's comfortable and enjoy the process. That alone will increase the odds of you completing the game by 50% (random number).
optionalparens 10y ago
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.
iamcreasy 10y ago
It's not just JVM - even if you are a Unity 3d user you need to work around GC too. There are programming guidelines to ensure less frequent GC pauses. IMO the trade off of having a GC worth is for small developers.
- pjmlp 10y ago
  Yes, but it should be noted that Unity is using a Jurassic version of Mono.