Java 8 Developer Preview

I'm sure 99% of developers don't use the bleeding edge, but my curiosity got the best of me and I decided to see what does Java 8 really mean. The big thing about Java 8 is that it means less boilerplate code and performance increases without having to write much code at all.

Edit:

If you would like to try out Java 8 w/ Eclipse for yourself, there is only two easy steps:

• You will need to download and install the JDK8 developer preview from here.
• Get a bleeding edge Eclipse build from here. (Note: this is a preview and likely will have a few glitches).

However, I don't get to have candy and eat it because Android doesn't support anything past Java 6. It is actually kinda depressing because a ton of things I like about Scala are being added into Java 8. Let's do a quick comparison of what has been added after Java 6 (this is by no means complete):

Java 7

• Try-with-resources, basically the equal to 'using' blocks from C#. If you aren't familiar, think of them as automatically closing of resources/streams/etc.
• String switch statements, before you were limited to integer types and enums. C# has had this one for a while and it also came with Java 7.
• ForkJoinPool, a concurrency method to support load balanced parallelism by allowing thread pools to steal work from other busy threads.
• ThreadLocalRandom, a random generator which is thread-safe!
• New Java Path features, fixes up some major issues with Java and file systems (such as path normalization across platforms, symbolic links, etc).
• Multiple catch statements, reducing the number of catch clauses.
• Type inference on generics!

(A few things are missing from the above, but I really don't need to make this longer)

Java 8

• Lambda Expressions, basically a dynamic invoke of a method which uses type inference for the arguments and allows you to create closures with them. It really simplifies the language and removes the need for anonymous classes! 
• Ex: Arrays.sort(x, (s1, s2) -> s1.charAt(0) - s2.charAt(0));
• s1 and s2 are Strings (type inference), you sort them based on the value of the first char.
• Method References, create a lambda and pass it around like an object. Who wouldn't want that!
• Default Methods, create stubs or default implementations in your interfaces. This is pretty huge as it basically allows Java to do some 'smart' multiple inheritance and allows you to write a single implementation common to multiple classes.
• Streaming API, functional operators for collections (or even arrays) in Java. Think of it as LINQ for Java if you come from C#. It also performs lazy evaluation to make life even better.
• Parallel Collections, want to make your sorting parallel? want to perform a bunch of actions on a collection in parallel? You can now do this via the streaming API to basically make your code parallel without actually writing anything special for it.
• myList.parallelStream().forEach((s) -> System.out.println(s)); // Parallel
• myList.stream().forEach((s) -> System.out.println(s)); // Serial
• New JavaScript engine built-in which offers near V8 level of performance (from what I've heard).
• Removed PermGen space from JVM (most people have no idea what this is). Basically means less configuration of the JVM when running applications.
• A non-internal API for Base64 encode/decode (Long over due).
• New Date & Time API, based on Joda Time!
• Statically-Linked JNI Libraries!

(Again, a few things are missing from the above, but I really don't need to make this longer)

That list is pretty big when comparing it to Android's Java. I believe there are a few ways to get some of the Java 7 features working on Android, but I know almost everything in Java 8 is very likely to not work with Android. Scala 2.11 is targeting Java 6, in part because of Android, which means they will not be able to gain any significant performance improvements provided by the latest version of Java. I would expect 2.12 will be targeting Java 8 and hopefully so will Android by that time.

What I hope is in Java 9:

• Full type inference! I really would love to seem something like var/val from Scala or even just var from C#. It is pretty clear not all types need to be visibly shown for all variables and the compiler can infer most of them just fine. Lambda is a step in the right direction and shows they are starting to do it, but really this should just happen for the entire language.
• Default parameters and named parameters. When you use this in other languages it feels so clunky in Java to not be able to specify defaults, or have to ensure the ordering of parameters with no hints as to what parameters you are actually using. Overloading is very annoying because of this and could really improve the language as a whole.
• Reified Generics, I'm tired of dealing with type erasure. It doesn't bother me for 99% of the things I am working on, but the odd 1% I do it really bugs me.
• GPU accelerated Java, I know they are working on it!
• An improved JNI interface, the current system is pretty harsh and it really doesn't need to be.
• There has been talk about improving the built-in collections to be more efficient and handle large data.
• I would also hope they would improve the built-in collections library to support additional types of collections. I.E. Guava Collections and Apache Commons Collections. I would also really like to see some built in support for Graphs, JUNG is nice and all but there really should be something built in for this fairly common data structure.
• Implicits or method extensions would be cool as they really enhance a language, but I could live without this. 

Ah well, I can continue to dream... 

Unite 2013 - KSP

I almost feel obligated to write a bit more about KSP after watching a video from the Developers talking about some of the various strategies they took to building the game. First of all, I am actually pretty impressed at some of the techniques they used to approach the problems they encountered. Not only did they solve them, they did a pretty good job with it as well.

I'm curious as to why they picked using double floating point numbers instead of 64-bit fixed point numbers for the orbital mechanics. I mean precision is really a big deal when dealing with large scales so using something like integers where 1000 represents 1 meter would sound like a better idea. If you used 64-bit signed integers, they can hold 18446744073709551616 values... or more exactly, give you the range of 9223372036854775.808 meters both directions from an origin with 1mm precision. For comparison:

9460730472580800 = 1 light-year

9223372036854775.808

And you would have highly deterministic 'floating-point' errors at all scales. If you can count 1mm as a floating point error... And if that is the case you could always 'add' more decimal digits.

I do love how the re-entry effects were done, pretty awesome. Even more cool to know the same effects are used for showing high speed air drag and such. The planetary models were done in a very smart way and I have absolutely nothing to disagree with the approach taken. I also found the multi-camera rendering to be pretty cool. Treating each layer separately and then rendering them on top of each other. Considering I had never noticed it, Squad did a pretty good job with it.

I look forward to seeing what else is done with KSP as some really cool techniques have been applied to create a Solar System scale game.

The End of Summer!

I certainly have been neglecting to write anything on the blog, but I also haven't been doing anything significantly productive for the last while. I spent most of August writing a few mods for KSP in my spare time, and learnt about Unity in the process.

KSP

If by any chance someone from Squad does read this post, I love your game and I can appreciate all the hard work you guys have put into it. I also know how you might feel about being 'locked in' to Unity and why you picked it, but I can see a number of issues with your current design and having to rely on Unity.

I don't like Unity. It is a great tool for prototyping and rapid application development, but it abstracts away a ton of things you really do need to consider when developing a video game. It also reinforces the idea of poor design by making everything a 'script'. That doesn't mean it won't work, but it certainly is going to cause a number of headaches for when Squad tries to add networking to KSP. I will bet a large sum of money they will not be able to "effectively" turn KSP into a multiplayer game without rewriting significant portions of the game. They may try to get around the issues with their design (some inherited from Unity) by applying some sort of network framework to the game. I'm sure it will work, and you might be able to play with a handful of people, but it will never scale to tens/hundreds of people.

Okay, I am making a bunch of claims and not really supporting any of it. I also am not going to go into too much detail on it or else this post will just be some big long rant. The main concern is the usage of globals and singletons throughout various scripts in KSP. It makes it easy to access various information without any concern for abstraction; however, it forces a crazy tight coupling between various modules, which can sometimes be acceptable. Unity even promotes it by allowing you to access instances of created 'objects' directly. This means your objects are not only tightly coupled, but it gives the illusion of low coupling by not directly showing the dependencies. Now, the reason this will cause issues with networking is because of this design. The game and all of it's modules are expecting to be able to access everything directly with no concern about 'external' updates. This can be cheated (read as 'done easily') by abstracting away the current objects and synchronizing updates to them on the main rendering thread, but its likely going to have a large impact on the performance. Still synchronizing the physics between multiple clients with heavy physics interactions is not something the game is currently setup to handle. It may be possible to have multiple people in the same 'universe' but not be able to interact directly with physics.

The Unity physics engine is very outdated and really needs to be brought in line with the current hardware. It currently runs on the CPU, which is fine for simple things, but really if you want to do simulations the GPU needs to be utilized. Poor Squad, they will have to live with it until Unity is updated to support a more modern 3D physics engine. Another big issue is how textures are handled. As far as I can tell, they are simply loaded individually and applied one by one. Instead, they really should be stitched together and used as a texture atlas. This is really concerning when I see some textures are only having about half (or less) of their data used in rendering. It is just how modern texturing is done... Luckily, KSP is for computers, so the performance is pretty amazing. If KSP tried to run on a console, or mobile device, I would be impressed if a large ship rendered at more than 1 fps. Even on a good computer, I can see some nasty I/O bottlenecks for large ships. CPU running at sub-50% and GPU hardly sweating and my frame-rate is barely cracking 18 fps.

There are supposedly some performance improvements coming in 0.22 and hopefully those will fix some of the bottlenecks, but performance really looks like it has been left behind and a major focus on features instead. I agree with that approach, but once a few more core components are done there should be some serious time spent looking at performance. Performance is a problem that will keep compounding and without occasionally making improvements it will make the overall game suffer.

Libgdx

After August, I decided to poke around with some libgdx and Scala. Again, I keep getting annoyed by how some key features are missing from Scala IDE (code completion such as generating unimplemented methods in subclasses and javadoc/scaladocs not being shown for any code). I can work without them, but it makes my productivity plummet to the point I could probable write code faster in Java. Another really annoying thing is Gradle integration with Android is pretty much broken for any JVM language other than Java. The issue appears to be a few features missing from Gradle that the Android team want before they can add support for other languages. It really ruins my whole plan of easy deployments; however, everything else with Gradle works great and I will likely switch to it once I can use Scala with Gradle and Android.

Robovm looks like it is coming along very nicely and there seems to be some pretty big support for it. I love the idea of being able to effectively use libgdx to target iOS with native code. I'm happy to wait for it to continue to mature, but I am wondering how hard it will be to integrate that with Gradle...

I am currently in the process of prototyping various designs with libgdx and Scala. I'm also looking at some very awesome box2d tutorials and possibly hook it into the box2dlights project as well. My biggest issue right now is figuring out a 'simple' game I want to make. Most of my idea's are way over the top to do alone, and anything simple just doesn't seem interesting enough. I am probably going to settle on making something simple (maybe even just make it open source for the heck of it and allow people to see the source for another game written with libgdx). I am also curious about Nextpeer, as they really look to be filling in that minor issue of 'playerbases' when it comes to Indie games. However, there is also Scoreloop (which looks to be dead now) and Google Play Services (not sure about it yet, haven't played with it). This is where the whole 'needing some game idea' would be helpful. I would then be able to play with these technologies and get a feel for them.

My most promising ideas at the moment are:

- Restart work on Combatics Evolution (probably start over again as I want to network it and now I actually understand what I need to do to make it happen)

- Start work on a game inspired by FTL (also network cause that is the part I feel is really missing from the game)

- Start work on a 2D ARPG with a heavy focus on physics and multiplayer (random world generation and all that)

- Start work on a simple tower defense, probably single player, but free to play and open sourced.

Ideally, if I had infinite time and no real life commitments... I would do the tower defense, then concurrently work on the ARPG and FTL-like game. After, I would restart work on Combatics Evolution.

It always boils down to figuring out what I want to do and motivating myself to do it.