Kotlin 1.0.5 is here
blog.jetbrains.com
blog.jetbrains.com
Some highlights:
- Great type system, with type inference.
- Full Java interop. You can literally copy/paste Java code from Stackoverflow and it's automatically translated to Kotlin. It doesn't feel like 2 different languages. Working with Java libraries doesn't feel awkward or foreign, like in many other JVM languages.
- Beautiful syntax that allows to construct some pretty advanced DSL, yet because it's statically typed the IDE can always resolve the DSL constructs and take you "under the hood" to the actual code that's going to be executed. This is in contrast to languages such as Ruby where most of the time when you encounter a DSL construct there's no easy way to understand what's going on.
If/when I finally need to get around to learning to make an Android app it's definitely the first place I'll look.
What I like to know is the following:
What are some of the challenging issues of using Kotlin?
Did you start from Kotlin or migrated from java to Kotlin?
What drove the decision to use Kotlin in such a visible app?
What are the top 3 - 5 improvements or things you want to see?
Thanks
1. Kotlin issues:
- Libraries that use reflection (such as Gson) can break some assumptions that Kotlin makes (for example, a read-only field may actually change). There's maybe 2 or 3 little things like that that may catch you by surprise, but once you figure them out it's easy to work around them.
- Stack traces in lambdas are obscure sometimes. Sometimes you won't get the line number.
- Proguard integration has proven challenging.
2. We started from Kotlin.
3. Learning Clojure and Haskell has made me yearn for more functional languages and better type systems. Kotlin has that, in a neat syntax that's very beginners friendly.
I'm firmly convinced that a good programming language needs:
- Strong library ecosystem
- Static type system + type inference. (I won't get into the static/dynamic argument here. Suffice to say that there's a whole class of bugs that you can avoid with static typing, and type inference makes the "but I hate these types cluttering my code" argument irrelevant)
- Killer IDE support (essential for productivity. If you're writing a large application without using an IDE that gives you code inspection and navigation, you're wasting your time)
Kotlin has these 3 things.
4. Top improvement: can't wait for Kotlin 1.1 to be released, and start using coroutines. Other than that, I'm happy with it.
At the moment I use vals, but it still requires me to mark injected dependencies as nullable (and coerce them with !! on use), which feels like I'm fighting the type system.
It would be really nice if there was some sort of "special" null that was of the non-nullable type, but could only be used when initializing variables.
Otherwise I'm sure you can come up with a good solution using delegated properties or something like that.
I also don't get your point about how lame Xamarin apps look. Xamarin apps use native layout components (could be wrapped with lowest common denominator abstractions in case of Xamarin.Forms, but it's optional), so they're 100% capable of looking the same way your native app would.
That's true, but noone says or recommends that all the code is shared. Typical Xamarin architecture and good practice assumes sharing the business (or domain) layer, and coding the views separately. In terms of reusability it's still superior in comparison to writing both versions natively. Obviously the level of reuse you can achieve that way very much depends on the nature of the application.
Apps written in Xamarin and kotlin work very differently :
-with Xamarin you have to add the Xamarin runtine and depend on its integration. This brings several downsides : http://www.slideshare.net/KonstantinLoginov/we-are-ditching-...
-Kotlin outputs bytecode, so from the outside, it is just the same as any android app written in java. The output is a standard android app with one more library (the standard kotlin lib with all its base methods)
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.
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.)
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).
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... 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.
1. Read/watch the naughty dog presentation on Last of Us port where they talk about their time step. I have to say if there's one company who puts out stuff like videos and articles/books you should read, it is Naughty Dog. They know what they are doing optimization-wise, I just happen to find most of their games boring and lifeless from a design point of view, but I can still respect them greatly.
2. Read the GDC presentation about entity systems and the "roster" approach linked below.
3. Read probably everything on the Bitsquid site. Some of it is dated or even not the best, but I pointed some people here before and it really opened up their minds to what I was talking about when they were looking at my code. Changed their view from "black arts" to "wow, that really is simple and makes sense."
4. Read up on Entity Systems. But do not read things written by bloggers, authors of "frameworks," and various Java stuff out there (ex: Artemis). I hate to be so negative, but what I usually found out there is mostly garbage, wrong, and the authors disappear when challenged or asked about the hard, non-obvious parts. If you want good info, read code that's out there and figure out what seems good/bad, and listen to some of the people in the industry like at GDC talking about it. I tried to find one more recent talks, but so far only came across the Amazon one which seems pretty weak (though still interesting) and basic with regard to low-level detail.
Games knowledge is a tough thing because everyone is professor know-it-all and usually just hobbyists and throw away mobile game devs. Most people working on games who are competent are too busy or too sick of it to write about it. I hate to sound like one of those people. And that's why I don't blog about it or normally comment much. The only reason I'm mentioning it now is to pass time while watching the election. My games career was making me go insane and it was either family or video game development, so now I have more time in life to rant here. So, yeah.
http://www.gdcvault.com/play/1022186/Parallelizing-the-Naugh...
http://www.slideshare.net/TerranceCohen/terrance-cohen-dynam...
http://bitsquid.blogspot.com/2011/09/managing-decoupling-par...
Per your game dev career, sorry to hear that it's so stressful. I've heard from several reliable sources that the game dev industry extremely overworks and underpays people, and that it has a high turnover rate.
As a husband and father of 5 kids, I can't imagine making games in a job like that. Part of the reason my game is still unfinished after 15 years is because web dev is a much more stable income which lets me give my evenings and weekends to my family, and in that time it's either spend time with them or spend time writing a game. So I have like 10 lines of code to show for the choice I've made :D
Regarding entity systems, I read a blog post somewhere which discussed a really good idea that I liked a lot for how to implement them. It recommended eschewing the typical OOP concepts and just writing a struct that had slots for each "trait" that an entity could have, like Movable (x,y & controls), Damageable (HP etc), Container (chests, boxes, secret bookshelves, etc) and in the update function, iterate each entity in the active game state and if they have a thing present, run the relevant function on it. Plus it allows things to have multiple aspects, like an "evil gnome" is both Damageable and Moveable but an "evil tree" is only Damageable, This sounds like a really doable approach.
Okay anyway, will bookmark those links and look into them more when I have time. Thanks for the recommendations.
An entity is an int, long, or something else depending on your needs. It should be light-weight and not cause garbage to be allocated, thus why a long is good. A UUID/GUID is bad because you cannot use the entity id to cheat into pool rosters or other uses, not to mention it is hungrier for memory and slower to generate. Entity IDs should be allocated, often atomically and in one place and from a single thread.
A component is the data that you mention and should be a class or map/dict depending on the language. It is just a collection of fields, usually flat. Allocation should be done from a pool. It should be attached to an entity and detached as necessary. This is like a foreign key relationship per component to the entity ID if you want to think of it in DB terms.
A system operates on collections of entities, usually per frame/tick. Generally it is looking for one or more types of components per entity and isolating the logic there.
You can go outside the entity system for performance reasons like rendering if you must. Purity is good, but a lot of people go crazy and wreck performance. Be smart. The other hard thing is communicating between entities and between components. There shouldn't be any hierarchies or hard-coded things like that. Usually what is best is a queue or mailbox approach that the system can read from and deal accordingly, and then perhaps something more sophisticated beyond that as required per type of game.
My advice for getting games done in general if that's what you want to do is to just build a game and not an engine. From that regard, do dirty things like using pre-built engines such as Unreal or Unity. Better yet, just make a simple game. You will learn less, but be far more productive as a single person. If however you just want to muck around and learn things, then go wild. One thing we used to do to test architectures and game concepts that might be of interest to save time and explore me is we would build big chunks of a game with wire frames, stick figure-like things, whatever. If it's fun playing as a cube, it will be fun playing with a fancy sprite or 3d model.
I've casually read a lot of people's advice on game dev, and while some of it is reflected in what you said, your comment kind of ties it all together. And it confirms something I've been thinking for a few months (possibly years)...
Everything needed to write a simple game is right there in C, using structs, pointers, and functions! Anything beyond that is over-engineering. And the conveniences that languages like Java bring are just simply not worth it in this context.
Because as far as I can tell, writing a game is basically writing a tight loop that enumerates arrays and calls functions on them. There's basically no need for any OOP beyond the simplistic method of using structs, pointers, and functions.
And considering I've just had 4 years of practice using data and functions (full time job writing Clojure), I think I'm a lot more comfortable with this pseudo-OOP approach than I would be trying to jimmy-rig Java to basically be C.
So that's what I'll probably do. Write a SNES-style metroidvania in C using SDL2. (Although I'm open to alternative suggestions, but from what I've read, SDL2 is probably best for this job.)
Thanks for your advice and for bearing with me as I think this through in this comment :)
Most of what I've been describing came about because people were in OOP hell, and decided to move towards composition vs. inheritance. As multi-core machines, GPUs, and more sophisticated games arose as well, there was more of a need to start thinking more in terms of what the CPU wants and pipelining things for the CPU, GPU, and such (think PS3 for instance). To some degree, this thinking was always there and circling back to 80s game programming, but a lot of people got off-track. For example, memory allocation was always a thing to the point where no sane person every used anything in C++ from std because of allocations and bad memory layouts. Structure packing has always been a thing of course too. Another was thinking about v-tables and how they just get in the way, especially when working on more limited platforms like the NES, 286, etc. in those days.
Games are mostly about enumerating a lot of stuff, very fast, per some measure of time, and then repeating. If this sounds a bit like a map or a reduce in functional terms, it should because it is. You have loops inside loops, and you try to operate on similar blocks of data, rather than jumping around all over the code or iterating mixed collections (or hybrids using co/contravariance). It turns out computers, especially x86, really like it when you enumerate things in a line. There's a fun presentation somewhere where Stroustrup himself shows how an array can be faster in many situations than a linked list when the linked list fits the exact description of the correct data structure.
Anyway, you can rig a lot of this into Java as you say, but fighting the GC is still considerably hard. Clojure itself is even worse because it generates garbage like nuts and you also end up doing things like transient! or using volatile! to work around other speed issues. I'm not sure about Kotlin would be, but as a JVM language dealing with JVMisms, I suspect largely the same as Java. Other languages that are more predictable or not GC'd fair much better for games, they are just not used as much because of the people in the industry, technical debt, tool chains, know-how, risk, etc.
Where I'd disagree with what you said is that those constructs are all you need. For certain parts of your game you still need quite sophisticated stuff. Threading primitives and complex pieces of code help that are a pain to write with just what you described. But these things are generally higher level. For example, scripting engines are a good thing to have and often not written in the same language (ex: lua). Editors are another example. They aren't part of your game directly necessarily, but these days they increasingly are on some level, at least some form of them. Either way, you benefit from building toolchains in a variety of languages to help a game. It's not just a single code-base and ultimately you only have so much time, so you take shortcuts like throwing in Lua to make life easier.
Regarding SDL2, it's probably great for what you are doing. It's more low-level, but if you want to build things from the ground up, it's a fine and well-tested choice. There are other alternatives, but mostly in the form of full game engines. Certainly you could do this with something like Unity and it'd be good enough. If you're going 2D, the one piece of advice I'd give you is I'd say probably these days you can get just as much done by making things 3D and fixing the camera most of the time, or using a hybrid. 2D is more difficult than people think and often sucks in certain engines (ex: Unity :) ). Anyway, it's just a matter of some head banging and time. If you go SDL, you'll learn a lot, just remember, build games, not game engines.
[1]: https://2016.javazone.no/program/kotlin-ready-for-production
https://www.techempower.com/benchmarks/#section=data-r12&hw=...
It appears there may be an issue with the benchmark? https://github.com/TechEmpower/FrameworkBenchmarks/issues/21...
Personally, I don't really care about benchmarks. Getting stuff done is more important at this stage. Eventually this may become more important but I'm not going to worry about it until it becomes and issue for us specifically.
On the other hand, it's controlled by Jetbrains—the company that now offers a "yearly license" of many of its compilers at the same price point it once sold them for, after which time they forcibly downgrade the software their users have paid for. It's not illegal and some even agree with the practice on an ethical level, but it's clear that Jetbrains is all about hoarding as much consumer surplus for themselves as they can.
If only Kotlin were truly an open project and well supported outside of the Jetbrains marketplace, e.g. by VS Code, I'd be cheering it on.
-former webstorm/rubymine customer
I'm not sure what more is required to make it truly open.
Once Jetbrains no longer controls Kotlin's future and most Kotlin users are not Jetbrains customers, then I'd consider it truly open.
Are you upset for the election in USA?
VS Code is miles ahead of Jetbrains offerings and has no yearly subscription fee.
MS was indeed one of my least favorite companies half a lifetime ago, but they've changed business models and are now pursuing a growth strategy (particularly wrt services) and have abandoned the fight to capture consumer surplus at all costs.
I've gladly purchased Jetbrains products in the past (and other dev tools as well). Noticing that a company is intent on capturing all consumer surplus they possibly can and disliking them for it is not the same as deciding they're "evil" for charging anything to begin with. Before moving to their subscription / hostageware "pay up or be forcibly downgraded model", I happily broke out the credit card and paid for Jetbrains offerings. I don't begrudge them that they sell software.
They just got too greedy and consumer backlash like this is the inevitable result.
What happened? Could you please elaborate?
And yeah don't forget Eclipse Kotlin plugin, fully open-sourced)
JetBrains open-sourced decades of their hard work, building world's best IDE. And you can benefit from it for free.
You don't even have to pay for webstorm/rubymine. Just install plugins you need to Intellij CE)))
UPD. When I pay for their job, I receive real stuff and not some obfuscated shit. The stuff that will be compiling even when the subscription ends.
There's no rule that says a for loop must only support a single iteration interface. That seems more like an implementation detail of the compiler than a problem with for loops in general.
The tooling is still a bit rough around the edge compared to the base Android one, mostly because the android tools team really does an awesome job.
It is still useable though, and the language is so much better than java that it is a breeze to use.
The only downside is that you have to interface it with java code, which brings a couple of issues.
I see a few people have adopted it - what do you guys see as the future of the language? Do you think java8+Lombok is moving in a direction that makes kotlin useless ?
Great language, greater IDE.
Kotlin is missing all of the most powerful Scala features. No type classes, monadic comprehension, higher kinded types, adhoc polymoprhism. :(
I tried to use Scala for Android in the past and I gave up after attempting to set it up for a few hours. Admittedly it was a while back, perhaps things have improved.
Your claim that Scala on Android works fine got me interested again, so I googled around, found that blog post from May this year (that's more recent than my own experiments), and apparently there are still hurdles: http://blog.scalac.io/2016/05/19/reflections-on-starting-and...
With this type of issues the thing that I'm wary about is not getting a "hello world" app to compile once, but that I can get a project up and running, then need to add something else to the equation (say, a DI, or some code processor), and things fall apart again in an X-Files fashion.
I've heard that Scala has long build times, too, but maybe it's a thing of the past as well - no first-hand experience here as I never got to that stage.
Just use sbt-android and skip all the other nonsense.
Compilation is impressively fast, as the plugin uses the information from incremental compilation to skip ProGuarding completely for things that haven't changed.
1 - Install plugin into Android Studio
2 - Configure the Gradle plugin
Enjoy Android development within Studio.
Scala:
Follow this several pages long tutorial:
https://www.voxxed.com/blog/2016/10/setting-up-scala-on-andr...
Try to enjoy while working around issues with Studio integration and common Android libraries.
I do like many of the more powerful features that Scala has, but Kotlin strikes a right balance of simplicity and power in my opinion.
That being said, yes Scala has a steeper learning curve than say, Kotlin or Go. But if you're going to devote the I don't know, next ten years of your life to working in a particular language, does it really matter if it takes two months vs. four months to ramp up?
Plenty of "ok-ish, but not too hard to learn" languages proliferate in that kind of climate, like go for small web services (where Erlang was too much of an investment). The Unix approach of 1001 ad hoc sub-languages (awk, pic, ed...) adapted.
Quite different from e.g. a J2EE developer's approach, who tends to think of career-defining technologies and languages, where Scala seems like a wise investment.
A programming with more features is not necessarily better. The limited features of Kotlin (compared to Scala) are an advantage, if you change your point of view. Some advantages:
* easier to learn (a Java dev will be more productive than in Java in a day or two)
* easier to maintain since Kotlin doesn't allow so much hard to understand code constructs
* fewer discussions about the one true style or way to do something
* it's easier to build good tooling
* much faster compilation
* smoother Java interop
* performance implications are more predictable