Making Games with Kotlin(kotlin.christmas)
kotlin.christmas
Making Games with Kotlin
https://kotlin.christmas/2019/11
78 comments
Sebastian Deleuze who is one of the Kotlin people working on Spring just gave a presentation of the status of Kotlin support in Spring: https://www.infoq.com/presentations/spring-kotlin-boot-kofu/.
In short, if you are using Spring and are ignoring Kotlin, you are missing out a lot of good stuff. Or in other words, the same that happened to Java on Android is now happening to backend Java. You can still use it but why would you when things can be so much better with a simple upgrade to Kotlin (I've migrated tens of thousands of lines of code, it's easy). And yes Java 9-14 added a bunch of things that are definitely nice/useful but it doesn't come close to Kotlin in terms of expressiveness and language ergonomics.
Also, KotlinConf was on last week. There was a nice presentation about the state of kotlin-js, which is getting some nice updates in the next year including much better dead code elimination resulting in very compact minified code (< 100kb is now feasible for simple stuff), better integration of existing typescript type script defifinitions (i.e. support for most relevant npms out there), better build tooling in the form of an improved gradle plugin. Or put different, Kotlin might start doing to typescript/javascript what it already did to Java. IMHO it's a more capable language than typescript, which I consider to be pretty nice but it just lacks a bunch of things and comes with a some ugliness that relates to backwards compatibility with js.
In related news, Kotlin native is also happening. So, Kotlin is joining a list of full stack languages that used to be really short.
In short, if you are using Spring and are ignoring Kotlin, you are missing out a lot of good stuff. Or in other words, the same that happened to Java on Android is now happening to backend Java. You can still use it but why would you when things can be so much better with a simple upgrade to Kotlin (I've migrated tens of thousands of lines of code, it's easy). And yes Java 9-14 added a bunch of things that are definitely nice/useful but it doesn't come close to Kotlin in terms of expressiveness and language ergonomics.
Also, KotlinConf was on last week. There was a nice presentation about the state of kotlin-js, which is getting some nice updates in the next year including much better dead code elimination resulting in very compact minified code (< 100kb is now feasible for simple stuff), better integration of existing typescript type script defifinitions (i.e. support for most relevant npms out there), better build tooling in the form of an improved gradle plugin. Or put different, Kotlin might start doing to typescript/javascript what it already did to Java. IMHO it's a more capable language than typescript, which I consider to be pretty nice but it just lacks a bunch of things and comes with a some ugliness that relates to backwards compatibility with js.
In related news, Kotlin native is also happening. So, Kotlin is joining a list of full stack languages that used to be really short.
I tried using Spring with Kotlin last year but it felt verbose as if I'm writing Java so we decided to implement support for Kotlin in our in-house Netty-based server (https://github.com/buremba/netty-rest) and use it. Great to hear that Spring finally has native integration with Kotlin!
What's the status of Kotlin Native for writing backend apps? I really like it but I wouldn't want to get dragged into Gradle, JARs and JDBC again...
The native compiler is maturing and they are moving the JVM and JS compilers to the IR format they have developed for that. Additionally, they are going to support a new type of library that compiles to IR and that is reusable for all platforms.
They already have a few multi platform things. Mainly Ktor currently, which kind of should work on native. Additionally, you can target the node-js ecosystem via Kotlin-js. Also, one goal with Spring Kofu at least is also supporting GraalVM at least.
They are also adding more platforms to the native target.
Reading between the lines with what was announced last week at Kotlinconf, I expect a lot of this stuff might stay at least partially experimental through the 1.4 cycle (current is 1.3.61) and would expect that they might start pushing harder on backend native stuff around 1.5. Also there are still a lot of question marks around things like WASM where e.g. MS has a more clear strategy with .Net and Blazor.
They already have a few multi platform things. Mainly Ktor currently, which kind of should work on native. Additionally, you can target the node-js ecosystem via Kotlin-js. Also, one goal with Spring Kofu at least is also supporting GraalVM at least.
They are also adding more platforms to the native target.
Reading between the lines with what was announced last week at Kotlinconf, I expect a lot of this stuff might stay at least partially experimental through the 1.4 cycle (current is 1.3.61) and would expect that they might start pushing harder on backend native stuff around 1.5. Also there are still a lot of question marks around things like WASM where e.g. MS has a more clear strategy with .Net and Blazor.
Thanks a lot for all the info! :)
Problem is that thanks to Android (stuck on partial Java 8 support), and JetBrains plans to put Kotlin everywhere as they try to build a business on top of it (Borland Turbo Pascal style), there is only so much that they can access on the JVM while making Kotlin code portable, specially regarding the Valhala, Panama and Loom roadmaps.
There is nothing keeping them from not making some constructs not portable to certain platforms. Mostly they try to do this with standard language constructs (of course), but for example the 'dynamic' type is completely javascript specific.
This only goes for Valhala. The other examples seem to be java playing catch-up to Kotlin (Panama for Kotlin native and Loom for co-routines).
This only goes for Valhala. The other examples seem to be java playing catch-up to Kotlin (Panama for Kotlin native and Loom for co-routines).
Co-routines aren't the same as Loom, as they require explicitly code and thus might not interop cleanly with the new Loom thread semantics.
Does Kotlin/Native support multi field value classes?
Yes you can get around portability issues with multiple platform Kotlin, as many other guest languages have tried to.
However then one begs the question why use the language at all, when having to write the same stuff multiple times.
I rather have the JVM, .NET take the OS decision away, not see them as yet another OS to deploy on.
Does Kotlin/Native support multi field value classes?
Yes you can get around portability issues with multiple platform Kotlin, as many other guest languages have tried to.
However then one begs the question why use the language at all, when having to write the same stuff multiple times.
I rather have the JVM, .NET take the OS decision away, not see them as yet another OS to deploy on.
Yes, the upside of one language should be that you don't have to write the same stuff multiple times. But if you don't want the downside of having one common denominator holding you back, then you have to write some parts specifically for each platform. That is the option Kotlin gives you. And my point was that this doesn't necessarily mean it will hold the specific platforms back (which seemed to be your point).
I the company I've been working at in Austin and we've been increasingly choosing Kotlin for our backend services as well. We started with Scala and found the ramp up to be tough. I came from a company that used mostly Ruby before and had no JVM experience at all and I found kotlin really easy to get productive with in a short amount of time. I actually prefer it in many ways not to everything else I had done before (I think I just really like static typing).
I'm curious to know what difficulties you found using Scala and your experiences transitioning to Kotlin, if you are willing to expound upon it.
I have been using Kotlin on the backend for 4 years. I never used it on Android!
That's interesting.
I'd be more inclined to use Rust/C++ for the android devices since they are slow and more inclined to use Kotlin on the server because they are powerful :D
I don't know the situation on mobile but for cross platform Desktop the JVM is a great target for "write once, run everywhere", and Kotlin is a modern language that fixes or improves a lot of Java's common complaints.
Assuming a JVM is installed, distribution is as simple as sending a packaged .jar file.
There is a huge ecosystem of available libraries in Java, many with Kotlin wrappers for idiomatic usage.
Assuming a JVM is installed, distribution is as simple as sending a packaged .jar file.
There is a huge ecosystem of available libraries in Java, many with Kotlin wrappers for idiomatic usage.
Assuming JVM is (or will be) installed is a little risky though, isn’t it? We got rid of it in our enterprise setting some years ago, and we hardly seem unique in having removed JAVA from our available techs in our area.
I know games aren’t exactly meant for enterprise, but it’s been even longer since I had a JVM on my private computer. Maybe I’m alone in that?
This is not to shit in Kotlin, it’s certainly a nice language, but I wouldn’t expect widespread adoption to be what it was a decades ago.
I know games aren’t exactly meant for enterprise, but it’s been even longer since I had a JVM on my private computer. Maybe I’m alone in that?
This is not to shit in Kotlin, it’s certainly a nice language, but I wouldn’t expect widespread adoption to be what it was a decades ago.
One usually just bundles a jre and package the whole thing to a binary[0]. You wouldn't even know the game you're playing is running java. One could probably improve this further with modules and the newer additions to java/jvm (jlink).
[0]: https://github.com/libgdx/libgdx/wiki/Bundling-a-JRE
[0]: https://github.com/libgdx/libgdx/wiki/Bundling-a-JRE
Yup, with jlink you don't need to ship a full JRE, just the parts your binary actually uses. The user just runs a small binary and doesn't need to install and update a separate JRE.
I haven't seen a pc without java since forever.
But I'm a java developer so each to his own bubble huh? :)
My recent java experience is that you end up having to tune it and keep multiple versions and screw around a bunch if you’re doing more than one thing with it. Stick to Android dev and it’ll be fine after the initial config, but switch to something else or try to run some GUI java project off Github and you’ll lose time configuring it. I “nope” out of a lot of Java stuff as soon as I see it’s Java, as a result. If anything the situation seems a little worse than it was in, say, the ‘00s.
I sympathize with your problems, I also had to juggle multiple versions for a period of time on multiple projects. Docker thankfully eliminated that and even without it the most you have to do now days is to point "$JAVA_HOME" to another folder. Java and it's ecosystem is better than ever and the language updates since java 8 are great to work with. The JVM is great. Spring boot finally removed most of the the multiple days config issues. Everything is mature, every problem has one or more library to solve it.
> Assuming JVM is (or will be) installed is a little risky though, isn’t it?
At least in Linux the package management systems enable packagers to specify dependencies such as the JVM. In Windows perhaps it's possible to bundle a JVM of choice.
At least in Linux the package management systems enable packagers to specify dependencies such as the JVM. In Windows perhaps it's possible to bundle a JVM of choice.
Didn't Java fail spectacularly in the desktop application space?
I wouldn't say "spectacularly", as I don't remember that many attempts at true end-user apps. Enterprise is ripe with Swing.
Nowadays of course the web has blunted our pain receptors for memory bloat and non-native UIs, thus you're probably running three Electron apps right now, compared to which Java is Win32ASM.
And as others pointed out, for games it doesn't matter anyway. You're not building a AAA-game or something for a 6510, so GC pauses and memory consumption don't matter, either. Plus rapid-development, refactoring and a setup where OOP actually makes good sense.
I wouldn't start Kotlin for that, but if you already know it, there's no reason not to use it.
Nowadays of course the web has blunted our pain receptors for memory bloat and non-native UIs, thus you're probably running three Electron apps right now, compared to which Java is Win32ASM.
And as others pointed out, for games it doesn't matter anyway. You're not building a AAA-game or something for a 6510, so GC pauses and memory consumption don't matter, either. Plus rapid-development, refactoring and a setup where OOP actually makes good sense.
I wouldn't start Kotlin for that, but if you already know it, there's no reason not to use it.
GC is also not that big of an issue in these type of games if one's careful of using pools for the various objects, and then release stuff at appropriate times.
On consumer apps yes, specially due to lack of skill from many apps with programmer art.
On the other hand, Android tablets and laptops are part of the new desktops.
On the other hand, Android tablets and laptops are part of the new desktops.
It's more that Desktop development just fizzled out. These days if you are targeting fortune 500 companies with custom applications, you'd have to support multiple platforms in any case and the web makes that a no brainer. Add mobile to the mix and it's game over for desktop app developers.
I'm sure there are still people doing it but it's becoming quite rare that that does not involve electron or similar with a lot of web technology. I haven't come across any projects involving desktop UIs in recent years. Plenty of native IOS/Android + web. But absolutely nothing that had desktop UI on a roadmap or backlog or even on a nice to have list.
Java used to own that space when it still existed. IMHO that went away between 2005-2010 time frame. Before that you could get away with not supporting OSX (or Linux, ever the afterthought) and building stuff with Visual Basic, Delphi or whatever.
I'm sure there are still people doing it but it's becoming quite rare that that does not involve electron or similar with a lot of web technology. I haven't come across any projects involving desktop UIs in recent years. Plenty of native IOS/Android + web. But absolutely nothing that had desktop UI on a roadmap or backlog or even on a nice to have list.
Java used to own that space when it still existed. IMHO that went away between 2005-2010 time frame. Before that you could get away with not supporting OSX (or Linux, ever the afterthought) and building stuff with Visual Basic, Delphi or whatever.
Laptops and tablets are doing quite well for desktop developers.
And Android Java is still kind of Java, so Android running on ChromeOS or tablet plugged into a docking station, and one gets a desktop.
And Android Java is still kind of Java, so Android running on ChromeOS or tablet plugged into a docking station, and one gets a desktop.
I wouldn't really count either as "Desktop". It's basically mobile development for phones and tablets, which I wasn't excluding. ChromeOS is nice but mostly about running web stuff plus whatever kind of works from the Android or Linux ecosystem. I don't think there are a lot of people targeting that specifically.
Enterprise applications are almost exclusively web based. And consumer software that isn't games is mostly web based in electron or one of a few remaining big desktop products (e.g. MS Office or Adobe tools) and also a long tail of relatively niche stuff.
Enterprise applications are almost exclusively web based. And consumer software that isn't games is mostly web based in electron or one of a few remaining big desktop products (e.g. MS Office or Adobe tools) and also a long tail of relatively niche stuff.
Last time I used a box or tower based desktop was in 2005, since then I only worked in offices where "desktops" are laptops, or more recently 2-1 hybrids, which most people use just like the desktops of yore plugged into docking stations.
It works fine for cross platform tools where how good the GUI looks is not a concern. As an example the last such app I seen was a tool to cleanup some save games for a video game that was Windows and Mac so the person that made the tool used Java and Mac users could benefit of the tool, For Windows only games most such tools use .Net and Windows Forms.
Good GUIs are possible, just that not everyone bothers to read books like "Filthy rich clients", having a designer on their team, or shelling out for component libraries like JGoodies.
What I mean is "good looking GUIs" , as a dev when I create a basic tool , something that are not for customers to see and complain about I don't care about fonts,paddings, "professional looking design" , you get your buttons and inputs and job is done.
The tool I use daily for making money is Intellij, I don't f* care that the menus and buttons do not match my DEs, I would also prefer programs that use the system defaults rather then try to implement a better theming with custom buttons,colors and whatever some designer with big ego thinks is cool today(I can't understand why they like slim fonts with low contrast colors)
The tool I use daily for making money is Intellij, I don't f* care that the menus and buttons do not match my DEs, I would also prefer programs that use the system defaults rather then try to implement a better theming with custom buttons,colors and whatever some designer with big ego thinks is cool today(I can't understand why they like slim fonts with low contrast colors)
Do really games count as desktop applications though?
minecraft is written in Java I believe.
As well as the JVM, there is Kotlin/Native, based on LLVM. This allows a Kotlin mobile app to run on JVM in Android and as a compiled binary on iOS. It can also target WebAssembly to run in a browser too.
Kotlin/Native suffers from not having neither the same sematics as Kotlin on the JVM, nor the large pool of available libraries or performance.
Most importantly, Kotlin Native has no proper multithreading, it only uses JS-style single thread
There's threading, just not as painless as in JVM
https://touchlab.co/kotlin-native-stranger-threads-ep-1/
We're even getting early support for multi-threaded coroutines
https://github.com/Kotlin/kotlinx.coroutines/blob/native-mt/...
https://touchlab.co/kotlin-native-stranger-threads-ep-1/
We're even getting early support for multi-threaded coroutines
https://github.com/Kotlin/kotlinx.coroutines/blob/native-mt/...
Oh, multithreaded coroutines will be really good news when working properly
On a side note, there seems to be a lot of links being posted from vanity TLDs such as .christmas. Isn't there a risk of these links ending up broken in a matter of nothing?
Most of these have been originating from bekk.christmas it seems, who are making advent calendar blog posts leading up to christmas about a variety of topics under various .christmas domains.
They apparently did it last year as well, so the domains have lasted at least a year, then?
They apparently did it last year as well, so the domains have lasted at least a year, then?
.christmas seems to be owned by Uniregistry[0], which also owns at least 26 other TLDs, so I think we can expect them to continue providing service.
[0] https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...
[0] https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...
My concern doesn't lie with the TLD registrar, but with the interest in, say, maintaining a .christmas domain in non-christmas times of the year.
There is chrismas every year.
Yes, and it's relevant for a month tops?
Who will be more compelled to click on a Christmas link in, say, July? A christmas-themed link in February or March seems stale as hell.
Who will be more compelled to click on a Christmas link in, say, July? A christmas-themed link in February or March seems stale as hell.
We saw a steady flow of traffic all through last year on a few .christmas domains from last year's advent calendars.
I don't think they seem stale, but perhaps out of season Either way, we're committed to keep this content online for the foreseeable future, and write a new edition next year if people find it interesting.
I don't think they seem stale, but perhaps out of season Either way, we're committed to keep this content online for the foreseeable future, and write a new edition next year if people find it interesting.
Domains expire after a year, so it you'll always be renewing around Christmas. Unless you were referring to maintaining the site itself, which yes, probably won't have any new postings around July.
On a side, side note — Are those funky TLDs really widely supported/interpreted as links when not using http in main-stream apps (Mail or even browsers)?
Worse, everything.anything is now treated as a domain, leading to accidentally trying to browse when watching to search for dot separated programming terms such as libraries.
This happens on Twitter a lot. I've seen a lot of people referencing names of libraries, events, etc. and them being turned into links to URLs that don't exist. (.app is a common one for this.)
It also happens, rather unfortunately, with my aging parents who love to sign off emails with 'xxx' and are often missing the space after the final period and ending word of the email. Some of the results are guaranteed risky clicks.
Twitter could try to resolve this domain first before formatting text as a link.
Accidental typos (better yet, missing space after a period) also triggers some clients to send HTTP requests to the pseudo-URL to build up a quick view, which sounds like a potential security problem.
why would the TLD disappear?
Shameless plug: I'm working on a multiplatform library (https://github.com/Hexworks/zircon) which can be used to write roguelike games with ascii and/or tile based graphics. The whole project is MPP Kotlin (99% common code). We have a LibGDX renderer as well (although we're not using LibKTX yet).
Kotlin seems to have a lot of the tooling required to make games pretty quickly. That's not to say it's not a massive undertaking! The demo at the bottom is just mindblowing
My goal is to make a full kotlin android/iOS/backend game with shared business logic. How fare are wew from that?
Quizlet has been doing shared business logic with Kotlin - Ankush Gupta has written and talked about it https://medium.com/tech-quizlet/shared-code-at-quizlet-kotli....
We've been experimenting with this model too, as "write once, run anywhere" is very tempting for business logic, but those platforms have traditionally fallen down when it comes to UI and other native functions (e.g. alarms, sensors, etc). So far, it's proving very do-able. Non-trivial in some areas such as multi-threading, but a lot more practical than replicating the same logic across Android, iOS, and web.
We've been experimenting with this model too, as "write once, run anywhere" is very tempting for business logic, but those platforms have traditionally fallen down when it comes to UI and other native functions (e.g. alarms, sensors, etc). So far, it's proving very do-able. Non-trivial in some areas such as multi-threading, but a lot more practical than replicating the same logic across Android, iOS, and web.
There was a talk about it at KotlinConf. https://kotlinconf.com/talks/6-dec/124273/
The individual talks' videos aren't up yet but you can probably find it here: https://youtu.be/nfb6lDnvtKQ?t=13852
The individual talks' videos aren't up yet but you can probably find it here: https://youtu.be/nfb6lDnvtKQ?t=13852
Why not unity? (It's an obligatory question at this point)
Because it's not FLOSS. At least that's my reason.
Because I absolutely love Kotlin and I feel I'm much more productive with it. I have a hard time working with script languages and feel confident on my code nowadays.
Also, Kotlin let you use tons of java libraries.
Also, Kotlin let you use tons of java libraries.
C# is hardly a script language, also Kotlin Native is hardly a tool for gaming with its lack of real multithreading support
I both wrote games with Unity and Kotlin. Kotlin makes me much more productive and libgdx is well more suited for 2D games. Backend in unity?
Is targeting iOS better now with libgdx? Couple years ago the iOS support was kind of spotty.
MS did not like competition to Xamarian so they have killed RoboVM unfortunately...
EDIT: Apparently it's not dead and there seem to be up-to-date instructions here: https://medium.com/@bschulte19e/deploying-your-libgdx-game-t...
EDIT: Apparently it's not dead and there seem to be up-to-date instructions here: https://medium.com/@bschulte19e/deploying-your-libgdx-game-t...
I can confirm that. I have a couple of games on App Store that use it. I built them initially in 2015 and have updated them a couple of months ago with the latest libGDX.
I used RoboVM just like that person in the article, but I used it with Intellij IDEA instead of Android Studio.
It works and it's pretty easy and straightforward to set up.
I used RoboVM just like that person in the article, but I used it with Intellij IDEA instead of Android Studio.
It works and it's pretty easy and straightforward to set up.
I know that a killer feature for Kotlin is that you can use the same code to compile to JS, JVM and Native. Is it actually feasible in practice? Can I make a game that will compile to JS, JVM and Native all with the same code? I assume the core logic would be shared and I'd have to implement platform-specific routines for things like drawing and input, but would this actually work?
Only if all the libraries you use aren't JVM specific. In this case, the developer is using wrapper for a Java library so I doubt it's possible.
There's no reason the wrapper couldn't be enhanced to use the Java library on the JVM and something else on native but it would probably be a lot of work.
There's no reason the wrapper couldn't be enhanced to use the Java library on the JVM and something else on native but it would probably be a lot of work.
Although not strictly a game engine, OPENRNDR[0] could probably be used to create one in Kotlin.
> OPENRNDR is a tool to create tools. It is an open source framework for creative coding, written in Kotlin for the Java VM that simplifies writing real-time interactive software.
[0]: https://openrndr.org/
> OPENRNDR is a tool to create tools. It is an open source framework for creative coding, written in Kotlin for the Java VM that simplifies writing real-time interactive software.
[0]: https://openrndr.org/
Is LibGDX still a viable option for MacOS? I'm unclear about how well supported OpenGL is after Catalina.
We are using Kotlin in most of our backends running on AWS. We are very(!) happy with the Kotlin developer experience as well as the adoption curve that we have seen throughout our company. I can only highly recommend giving it a try and do not believe it is only meant for App development.
At the risk of seeming an ingrate: Does LibKtx also do 3D?
Hopefully, it gets more attraction from different platforms because staying in the JVM land and being able to use an expressive & lightweight language is great!