September 20, 2013

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.

No comments :

Post a Comment