Libgdx 3D API

The 3D API for Libgdx is hardly a new thing as it has been around for many months. I initially peeked at it back around when it was first proposed and the initial implementation. The work they have done with it is absolutely awesome, but the framework is still missing some key aspects. Xoppa did a wonderful tutorial on the various aspects of the API and introduced a bunch of the main concepts here. Those who are familiar with OpenGL and 3D rendering in general will probably be able to quickly skim over most of it and look at a few examples without much trouble.

It certainly matches what it was originally intended to do by mimicking the design of the Scene2d API. It also provides a great number of utilities to help with working in 3D. I have minimal knowledge of creating 3D models, but I do know how to work with already existing models so most of it isn't that new for me. There seems to be a pretty common theme, if I want to do anything in 3D for games as an indie I better start learning 3D modeling programs (i.e. Blender). There isn't anything officially included which deals with shadows (but there is an experimental directional shadow light which uses shadow mapping). Being experimental is kind of lame because I want to use it and most of what is inside it does not look experimental to me. In fact, it matches pretty much what I have done in past test projects with shadows.

No 3D particle system is really going to put a huge damper things because it is a very important aspect to any modern 3D game. Particle effects is almost as fundamental as sound effects, but it looks like I will have to roll my own solution if I want to have such a system in a game. I could always do things with bullet, but sometimes I just want something simple like smoke which doesn't need to be modeled accurately, but just provide a visual for people. Minus the whole missing features which feel essential, the 3D API is very easy to work with and looks fairly expandable. Hopefully a few more 'nice' features are added to support the previously mentioned parts, but overall I am satisfied with it.

No More Scala

My love/hate relationship with Scala is finally coming to an end. I am ditching the language entirely not because I don't like the language, but the biggest issue is tool support and well... the lack of it.

Using Scala has slowed down my development time because nothing works as well as it does when working in Java.

When it comes to cross-platform development you need to make sure everything you are working with will behave as expected and without causing you more complications or headaches. This is very important for people who are working on very small teams and can't afford to be spending time diagnosing issues. Scala does work well when you think of development speed in terms of how many characters it takes to do a task. However, that is a very biased view of development and almost backwards way to develop. This isn't the early 80s where programs are only written using a basic text editor and some syntax highlighting. It is expected to have a full IDE providing you with everything you would want and more. Scala has IDE support, but all the ones I have worked with seem to be missing the key features I use all the time in Java. It just feels so backwards and slow to not have an intelligent code completion/assist. Or be missing auto-generation of common code snippets with context awareness. Then having the tools you rely on break or fail to work on occasion for no good reason other than you've been using it for too long in one sitting.

The part the drives me nuts with Scala is trying to use it for game development. It offers a huge potential for providing many features to speed up development, but trying to make it work flawlessly/efficiently with Android has only caused more issues than solutions. I am using Java libraries because the lack of good libraries for Scala is frustrating and even the standard library for Scala is written with poor documentation and strictly from the functional point of view (not that their is anything wrong with it, but not everyone knows functional languages inside out and be able to infer what symbols used by the DSL mean). Scala libraries are notorious for using specialized DSL for no good reason other than because the developers think/feel it makes it awesome. DSL means steeper learning curve for all developers trying to use the library. Additionally, it means when someone is trying to do something outside of the status quo, its impressively complicated to bend a DSL designed for a certain workflow to do something else. Libraries should be convenient, easy to use, and perform effectively at the tasks they are built for. Most of the popular (non-enterprise) Java libraries follow these key aspects; hence, are popular by many hobbyist/professional developers.

I am strictly going to be using Java for game development from this point forward as I have not found anything I can develop 'code' in faster. When I say code I am not referring to lines of code, but am actually referring to features and functionality. One common complaint with Java is the verbosity of the code, and that is a very real issue. However, this is why I make extensive use of tools which automate tons of the boilerplate code. I can only hope Android will eventually support Java 8 because so many amazing features are coming just around the corner. It is ironic that iOS might support Java 8 before Android because of AOT native compilers... which actually makes me wonder if using such a compiler might allow me to make native applications for Android using Java 8. Oracle seems to be hinting at it... maybe the stars will align and I will get the best of all worlds.

Status Update

It has been a while since I last mentioned anything here. Naturally, that usually means it is a good time to write what I have been up to lately. I could always write more about what I have been doing recently (other than research/school work), but this post is getting excessively long.

I recently wrote an addon for the Minecraft Mod called TerraFirmaCraft. However, I am only really doing bugfixes and discussions related to it for the next while because there are two big things I'm concerned about. TerraFrimaCraft Build 78 and Minecraft 1.7.x update. Both of these are going to have significant changes to the addon, one will force me to rewrite any network code I have created. This is primarily why I won't be making any new content for the addon in the near future, as I know I'll have to redo a lot of it if I decide to tackle some more of the complicated things.

Minecon 2013 was a huge disappointment, no I didn't go but just watching some of the streams made me realize a few things about Minecraft. The community appears to be hugely based on youth and the developers really spoiled the whole event by having NOTHING exciting to talk about. It really was just a weekend about praising Minecraft and talking about random things most people aren't overly interested in. Okay, so they talked about twitch, but do we really need more people streaming Minecraft? It is kind of a saturated thing as it is... Then again with all the new consoles, streaming is apparently going mainstream (no pun intended). There are really only a handful of reasons to watch a stream... You want to see how someone skilled at the game plays (meaning the game really needs a skill factor). You want to watch a person/group of funny people play a game for entertainment. You want to see what mods/mechanics/achievements/other game features are like because you want to learn more about them. Beyond that, watching someone else's stream really doesn't provide a whole lot of value. By allowing a lower barrier of entry to streaming content really adds no benefit and will probably bloat streaming services with a ton of streamers nobody really wants/is going to watch.

Blizzcon 2013 in contrast to Minecon 2013 was absolutely amazing. Blizzard is obviously a much larger company, but they really understand how/why they should do a convention. They showed off Hearthstone and Heros of the Storm very effectively which added a ton of hype about the games. I haven't really played many card games, but I do like how simply and complicated Hearthstone is, and will likely play it a bit when the game goes open beta. Heros of the Storm looks amazing from what is already shown. The issue I have about League of Legends is the grind in the game and it is too competitive. I like some competition, but I mostly play games to enjoy them and playing multiplayer over and over has never really appealed to me much. Hence why I only played Starcraft for the first couple weeks when it comes out and then sorta stop playing it. Diablo 3 expansion looks promising, feedback so far from the beta is fairly positive and considering they are actually allowing people to beta test the entire game means there shouldn't be that many surprises this time.

Side note, the types of games I really enjoy are turn-based with time constraints. Example, blitz chess, any turn-based game with a short turn timer. Why a short turn timer? Because it forces people to think quickly and plan only slightly into the future without giving them time to evaluate all possible moves. Additionally, it keeps the action flowing and makes the game interactive so I don't sit there for a couple minutes waiting on someone else to do something. I don't enjoy real time games very much because it boils down to reaction time in many cases (when you play skilled player vs skilled player). Obviously that is a gross simplification as some real time games can involve a ton of strategy as well. 

Randomness makes games more interesting. This also means even if you know the 'best' way to do something, you could still lose. Some people hate that concept, but if you could predetermine what is the best way to play, why bother playing at all as you know walking into the game who will win. Randomness also evens out the disparity between really good and really bad moves. Sometimes the best move could result in a poor outcome but more often then not it will prove to be a good outcome. This means you shouldn't do the same thing every time and you need to adapt to the variables in play... it makes planning ahead less critical and being able to deal with the current situation more important. This is the reason why the current best backgammon bot only looks 2 turns ahead at most... Or why some of the best competitive bots in Tetris only look at the current piece and not what is in the queue (especially if the queue is shared between competitors).

Java 8 Method Reference and Lambda Performance

I happened to come across a post on SO talking about performance of methods called via reflection and method handles. I was under the impression that method handles was a Java 8 thing. To my surprise it is actually in Java 7 (I've been coding android for a while so never played much with it). I figure it would be worth while to extend the answers there to show off the performance of some of the Java 8 features. I.e. lambda and method references. It doesn't actually answer the question there so I won't pollute it on SO but I can write it here to show it:

I took the basic code for the micro-benchmark (again micro, does not truly reflect real world performance). A quick dump of my laptop specs (cause people always ask):

Operating System
Windows 7 Ultimate 64-bit SP1
CPU
Intel Core i7 620M @ 2.67GHz 46 °C
Arrandale 32nm Technology
RAM
4.00GB Dual-Channel DDR3 @ 532MHz (7-7-7-20)
Motherboard
LENOVO 2516CTO (None) 53 °C
Graphics
ThinkPad Display 1440x900 (1440x900@60Hz)
DELL P2211H (1920x1080@60Hz)
256MB NVIDIA NVS 3100M (Lenovo)
Hard Drives
298GB HITACHI HTS725032A9A364 ATA Device (SATA) 33 °C
SD Memory Card (NULL)
Optical Drives
Optiarc DVD RW AD-7930H ATA Device
Audio
Conexant 20585 SmartAudio HD

The code I am running is pretty much copy paste from the SO post, but I added a few lines to add in the Java 8 stuff. Anyone familiar with Java will see the new syntax and be in awe at the performance.


And of course here are the results:

reflective invocation (without setAccessible) 4.847 ns
reflective invocation (with setAccessible) 4.593 ns
methodhandle invocation 11.511 ns
static final methodhandle invocation 0.000 ns
direct invocation 0.000 ns
method reference invocation 0.000 ns
lambda invocation 0.000 ns

Which pretty much means the performance is no better than static final methodhandles OR direct invocations... which goes to show how huge of an impact these new constructs will have to functional programming in Java. I am impressed.

TerraFirmaCraft and Minecraft Forge

I recently came across a wonder mod called TerraFirmaCraft which has proven to be a fairly amazing rework of survival Minecraft. It adds a huge depth to the game play, and unlike every version of Minecraft since early alpha when I first started to play it actually makes the game harder and removes all the 'mob farming/automation' from the game. I find it pretty amazing because a lot of the new red-stone stuff is 'neat' but it really just makes the easy parts of the game even easier. I wouldn't be able to describe all the changes it has done to the game in a single post (well at least one that people would read) so instead I will simply put it this way: Everything takes more effort, nothing is automated, and you really have to actually work towards your goals. It means when you actually build your first house in TFC it feels like a huge accomplishment because you probably spent a few days trying to gather resources and fighting off significantly more powerful mobs.

This mod has also reminded me of all the parts about Minecraft I really enjoy and how Minecraft Forge allows me to actually tackle some of my mod ideas without trying to dig through Minecraft source (yuck). Needless to say, TFC is still in a beta and has lots of areas to improve. On the other hand, it is very fun and I agree with the premise of the project. As a result, I have decided to contribute my time and effort towards the project to improve it and by writing a couple add-ons for the core mod. My first change has been to revive an older addon which is no longer being maintained called TerraBow. I will likely take the information about it and make an actual page here for people to view. I will also be making posts about other mods I write for TFC and make occasional progress reports (since doing that seems to both tell people I am making progress, and gives me something to refer to).

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.

Bullet and Libgdx

A long time ago I was under the impression libgdx used jBullet (Bullet 2.72) for the 3d physics. However, to my warm surprise this is not the case at all. It is actually using (Bullet 2.81rev2613) which means its light-years more evolved than jBullet. There are a few other factors that make it better overall, but it uses unmanaged memory with a garbage collector as a fallback. I find it oddly funny how hard it is to find out what version of Bullet libgdx was using. I ended up having to look through the revision history for information on it.

So maybe this little post will help anyone else who is curious about it.

Modding KSP with Scala

TL:DR Just use C# for making addons with KSP, it really isn't worth spending all the extra effort to use a JVM language.

Getting Java 1.7 to work as a mod with Kerbal Space Program is 'easy'. However, the same trick appears to not be able to work with Scala 2.10. It looks like the bridge between Scala and C# is just a bit too far. However, it isn't the end of the world because it still works.

IKVM.NET is pretty good, it does the job well and actually makes the whole thing possible. However, there is one big catch that really hurts when working with KSP. I'll quote the author:

First limitation: Currently only custom attributes that have a default constructor or a single one-argument constructor (taking a supported type) are supported.

The second limitation is that not all parameter types are supported, only the Java primitive types (where Java's byte maps to System.Byte), type literals, strings and enumerations are supported (and single dimensional arrays of these types). Custom attribute parameters typed as Object are not supported.

Java

The issue is most things in KSP work by using attributes and thus IKVM.NET will choke on a number of these attributes. However, there is a way around it: inheritance. If you take an attribute and subclass it (to meet the above limitations) IKVM.NET will happily work with the attributes. This does mean you have to write a C# adapter to provide attributes you can use as interfaces in the JVM world. Below is an example of what I mean:

public class EditorAnyAttribute : KSPAddon {
    public EditorAnyAttribute() : base (KSPAddon.Startup.EditorAny, false) {}
}

Doing all that you can compile your java jar into a dll and slap it into the Plugins folder for your mod, just like you would normally put in your C# dll. However, you also need to put in the IKVM.Runtime.dll and the IKVM.OpenJDK.Core.dll (totaling just over 5MB). If you use some of the other classes, you will also have to provide dll for them as well.

This means your plugins folder will look like this:

[mod].dll
[ksp_attribute_layer].dll
IKVM.Runtime.dll
IKVM.OpenJDK.Core.dll

Pretty gross.

Scala

Now if you simply try to apply the same process to Scala, it won't work. There is an issue between the annotations generated for attributes by IKVM.NET and how Scala expects an annotation to work. The end result is scalac will complain the annotation is not defined. It will insist it is not defined and cowardly refuse to believe in it. This means you need another adapter in Java to actually use the annotation and then from the Java code you can call your Scala code. Another nice catch is you will also need to use IKVM.NET on the scala-library.jar to use any of the Scala objects, but out of box this doesn't work.

I'm going to assume I will need to apply proguard onto the scala-library.jar first with my jar file to strip it down only to the tiny bits I'm actually using (sounds very much like the Scala workflow for Android).

This means if you want to use Scala your plugins folder will look like this:

[mod w/ java wrapper].dll
[ksp_attribute_layer].dll
scala-library.dll
IKVM.Runtime.dll
IKVM.OpenJDK.Core.dll
IKVM... (other IKVM libraries depended on by Scala)

At the end of the day, yes you can use Scala to make a mod for KSP, but you are going to have to use 3 languages and 2 tools to make it happen. Your mod is going to be a massive binary blob to even make the simple things run. This means KSP loading time will also be increased by the fact you are now loading a number of extra dlls.


In conclusion, you can do it and in order to keep yourself sane you are going to need to automate the whole process because its going to be painful (Gradle for example). Additionally, you will need to write code to fill in the gaps between C#, Java and Scala. Using Java isn't quite as bad and reduces the number of steps required to build a mod, but you still are going to need to use some C# to hook it up for working with some of the attributes. This basically means you might as well just do the whole thing in C# and not spend the time making things compatible.

Kerbal Space Program Modding

At the time of writing (KSP 0.20.2) modding Kerbal Space Program is actually rather trivial.

When I say trivial, there is a very nasty catch to the whole modding process. You need to be relatively familiar with some of the Unity Engine code AND you need to be ready to figure out how to use undocumented code. Fortunately, there is a nice guy in the modding community who has come along and helped ease this process by creating some XML documentation on github.

It isn't really enough, because the documentation is very skimpy and the biggest issue is figuring out how everything hooks together. Of course, if you plan to simply add a few parts to KSP that is a very dead simple and well documented process. On the other hand, if you plan to add a complex new set of features to KSP, you are going to have to learn by example from the source code of other mods.

If the guys at Squad (people who created KSP) really want to make plugin developers not cry, and do a better job of modding the game, they need to publicly expose some of there API so that modders have a much smaller learning curve.

I looked at a few mods and re-created the sub-assembly mod to work with the 0.20 plugin system as a test. My next task is to port it over to Scala to test my Scala -> IKVM -> KSP workflow.

I'm at a disadvantage already because of a lack of experience with C#, but I've used the language before and can easily learn it because of my experience working in a number of languages. Right now I'm really curious to see if I can easily integrate JVM languages as a viable modding option for KSP. I mentioned IKVM in my previous post, but I also came across jni4net.

My current issue with IKVM is the huge amount of bloat required to simply add a minor feature to KSP (I have to add in 5MB of dll just to log "hello, world" from Java. On the other hand, jni4net acts as a bridge between the languages using proxy classes and is significantly smaller, but its Windows only, requires 64-bit java, etc.

The end result, my only real option is to use IKVM if I want to develop mods for KSP using a JVM language.

Kerbal Space Program + IKVM + Scala

Lately, most of my time has gone towards Kerbal Space Program. At first the game is very frustrating and has a very high learning curve, but you should expect that when the point of the game is rocket science. Minecraft is making significant progress towards its modding with the recent release of 1.6.1; however, it still has a long ways to go before I will consider actually attacking it with my ideas. KSP on the other hand already has full support for modding, but the game has Unity limitations (32-bit/single threaded), which is unfortunate but also offers large benefits of rapid development because of all the tools and assets provided by the engine.

The kicker is I would need to develop in C# to make a mod. There is nothing wrong with C# and infact it has some huge improvements over Java in many of the language related points. However, Scala makes C# look pretty bad (okay LINQ is still kick ass) and why spend the time monkeying around with C# when I could simply use Scala?

The bridge between Java and C# is called IKVM, there might be others but that is the one I know is used by projects such as LibGDX for compling to non-Java platforms (iOS). It does work pretty well and I know IKVM can be used with Scala without any real hiccups.

The big question is how well can I minify all this into a plugin for KSP?

Even bigger question is will it even work and will it work relatively well?

I expect issues, hiccups and probably making myself want to give up. I will end up reporting progress and information here as I work on it, although I admit I seem pretty bad at that.

Windows 8 and Windows 8.1

My review is simple for Windows 8:

Windows 8 - Teaching an old dog new tricks
Windows 8.1 - Teaching an old dog not as many new tricks.

That about sums it up.

Build Systems

Build systems are painful, and I'm sure most developers will agree. Fortunately, there are many solutions for build systems which support various languages and offer a wide range of capabilities. For the typical developer you will never really need to worry that much about a build system. However, if you are serious about developing applications you should not ignore the productivity you will gain from a real build system. The main reason comes from the fact that you will need to deploy your application at some point. Is it really worth putting in all the time to invest in learning about various build systems? I would say yes and no.

Firstly, make sure you research the different build systems for your language(s) and their capabilities for deploying to your target(s). Once you have figured out which ones are feasible, then you really need to look into what people say about the build system. This will usually give you a good indication of what to expect from the build system (i.e. its pros and cons). Never get fooled into thinking you have 'the best' build system, because no matter how great you think it is, there will always be cons.

Secondly, spend the time to learn the build system, practice with some of the basics on how to use the system, build some dummy projects and work your way up to more complicated builds. Once you feel comfy with it, look at your project of interest and create a build for it. Along the way, figure out if this build system really fits what you want and need. If you did the last step, you know the alternatives and before you invest your time into setting up your project. That means you can easily switch to a different build system before you start getting frustrated.

Thirdly, use the build system. Make sure you can automate almost everything so that you will never really have to worry about deployment again. Doing deployment by hand is error-prone, slow, and usually fairly painful. The beauty of using a build system means you can easily do a cross-platform deployment and pre-package your application by simply pressing a button when you're ready. Additionally, you can check for library updates, run unit tests, or simply setup the versioning information for your deployment. This all happens automatically and you really only need to worry about it when you setup your project or make changes to the configuration. The best part is, most build systems provide a configuration script which you can throw into a VCS (Version Control System). When you decided to go back to an old version, the build system will grab everything it needs and run without you having to think about what you used to do to deploy the application.

The real cost is learning how to use a build system, but its no different than learning how to use an IDE, or learning how to use a VCS. The most commonly known build system is 'make' but just because it's common doesn't make it the best or the only one. Remember, there is no silver bullet and one size does not fit all.

Gradle, after doing some research I came to the conclusion this was probably the most ideal build system for me. However, it was designed for IntelliJ IDEA and not for my personal choice of IDE... the bloated Eclipse. Don't get me wrong, Eclipse is pretty sweet (hence why I use it), but it seriously has issues with performance, responsiveness, and memory usage. Netbeans I can't stand working with because it reminds me so much of Visual Studio, but that is more of a personal opinion than truth. Gradle's integration into Eclipse is pretty decent from the looks of things. Finding "Eclipse's Gradle plugin" is a bit of a pain (not to be confused with the "Gradle's Eclipse plugin") and you have to install Eclipse's Groovy plugin. Groovy, in simple terms is kind of an extension to Java so using it as a language for a build system is pretty epic.

It looks like Gradle offers support for Android and offers support for packaging and deploying applications to Windows, Mac, and *nix (read Linux/Unix) in a way that makes sense for each platform. It also has support for many of the JVM languages and comes with integration with other build systems, such as Maven, Ant and Ivy. Really, it sounds almost too good to be true. However, I still need to play with the Scala side of it, and see how effective I can combine the deployment plugins with the 4 platforms I target (Android, Windows, Mac, and Linux). Most importantly, I want to see how well they work with LibGDX and if that works out well I might also write a nice tutorial on how to get it all up and running.

I guess I should also mention how I'm considering writing a number of tutorials for LibGDX, but not a beginner tutorial. If anything, it would be tutorial that quickly covers the basics of LibGDX and then jumps into building an actual game with the above technologies.

Postponing Game Development

Finally, after finally having a bit of free time I've decided to change my focus to enhancing my knowledge in some deeper topics. Instead of spending time on small projects, I feel I should expand my general knowledge  in a couple of areas.

Firstly, I want to explore Gradle to see if I can leverage it for projects and get myself some more knowledge on serious build systems (I was also considering ANT but for the time being I think Gradle would be a wiser choice.) It will also be fun to play around with a little bit of Groovy. I would like to learn how to set it up for non-trivial projects (i.e. libGDX) but also allow me to easily create deployments for each platform. I've been manually doing deployments for a while and I do know how to do it, but it comes to a point where I should be able to automate it and never have to worry about it much again.

Secondly, I really want to expand my knowledge in the computer graphics area. It really fascinates me and more importantly I can see it being extremely rewarding now that I've had a decent taste of some more advanced topics. Rendering is pretty awesome, especially to get some realistic looking images, but I want to dig more into some of the more advanced interactive programming. This will focus mostly on 'desktop' graphics as being so constrained with mobile isn't exactly satisfying. Especially to play around with advanced lighting/particles/fluids and explore geometry and tessellation shaders. Maybe AMD (ATI) will get its act together and work on first-class compute shaders for even more fun, but I'm sure it will simply mean I need a newer graphics card (rolls eyes).

Thirdly, I need to expand my knowledge in machine learning and artificial intelligence. I have a few bits and pieces of basic knowledge from games and a bit from other sources, but nothing substantial that will help me in the next couple years. I am going to need a solid foundation before the end of the summer; otherwise, I will deeply be regretting it and I would rather not make my life stressful if I can avoid it. The advantage of digging into this area is that I will be able to directly transfer my knowledge into other projects and games.

Lastly, I have a couple of other high priority events I need to worry about, contests/personal events/etc. Thus, I want to keep things off of my plate for the time being until the dust has settled.

Parallel Programming

Considering how important parallel programming is today it is incredibly difficult to find ways to utilize the GPU in a truly cross platform manner. I would not be surprised if this area gets huge amounts of attention over the next couple years. Considering many newer supercomputers are very reliant on using CPU/GPU hybrid architectures to push both processing power and reduce power consumption it only seems logical that utilizing the power of the GPU is important for computational intensive applications.

Now that there is finally a serious standard on how to approach parallel programming which supports multiple platforms it seems quite feasible to use this in applications. CUDA is great, but is for NVidia; Renderscript is cool but its for android only; that leaves me with OpenCL. However, trying to do this in a cross-platform manner isn't a trivial task and more so if you are like me and trying to do it from the JVM side.

I had a crazy idea: Scala + LibGDX + ScalaCL + Android while retaining cross-platform capabilities and then applying networking. It sounds fairly straightforward but I already know how impossible that would be to fully integrate without gouging my eyes out. Long story short, I will easily have to wait another year or two before that is even possible. Not that I am concerned, phones with OpenCL support are only starting to roll out and majority of the market wouldn't be able to support such a crazy setup.

At the end of the day, I will have to stick with Scala and LibGDX, which I am still only in the initial stages of testing for feasibility. I can still dream... lol

Scala Again

Scala has been a love/hate of mine for the last year or so because of how lackluster the tool support was a year ago. However, it looks like the Scala community is not only growing, but also maturing a bit. It is a fantastic language with so much potential that I look forward to using it more and more. I am a bit rusty with it so I figured this was a great time to really relearn the language with the new features in 2.10. However, the lack of up to date tutorials is rather surprising. I haven't searched for very long, but still that seems rather surprising.

I'm using some older tutorials, and I am aware of some of the changes since the tutorial was written, but it would be nice to find a good solid set of tutorials for Scala in 2.10. I will probably being prototyping a game for Scala + Android using libGDX in the near future so I'll be able to provide some more insight into how that works. I might even go as far to write some tutorials on using Scala with libGDX, but I will first have to see how feasible it really is.

Scala 2.10 + ScalaIDE + LibGDX + Android = True

I decided to do an experiment since I'm tired of working on PaintParty for the moment. I wanted to see if I could integrate LibGDX with Scala and run it on an android device without any issues.

It worked flawlessly, and ScalaIDE has certainly improved over the last year so I might start to seriously consider doing development with Scala now. I admit I've become a bit rusty, but I have already learnt Scala once, I'm sure it wouldn't take much to relearn the basics. (The advanced topics in Scala scare me, but with time, I will learn to love them). The biggest thing missing with ScalaIDE was some basic error suggestions and a customizable Syntax Highlighter. The suggestions still has some work, but it is a huge improvement over the old version I used.

Scala is one of those things were you can use it interchangeably with Java. This means for better or for worse you can use all the Java libraries with it, the syntax might get a bit funny because of crossing languages but it does work perfectly well.

The means, when I get back into working on Combatics Evolution I may start on it in Scala. However, before I go through with that kind of investment I will need to write a small game that can run on Android using Scala. In fact, I have a very simple idea I would like to make which could turn out to be a simple new game. I guess we will have to see in the next few weeks, until then I will be going full tilt with PaintParty.

Edit:

I've noticed this post has gotten a decent number of views. For people who are actually interested in setting this up correctly I will point you to my answer on StackOverflow until I get around to actually writing a tutorial. From my initial tests it works perfectly fine, but because of linking source to the android target, it likes to rebuild the android project when you make changes (its also blocking when android builds so pretty dang annoying).

Combatics Evolution Updates

So, I haven't started work on the project yet as I am focusing on finishing off PaintParty as well as a number of other minor projects. I have however had the chance to replay Diablo 3 and play Starcraft 2 HotS. Both games are a great inspiration to want to get back to working on CE. At this point in time a have a few things I will need to do before I can seriously get the game into a more reasonable state:

Update Combat Graphics:
- Use lighting and other rendering effects.
- Provide switch between perspective and orthographic.
- Optimize rendering for OpenGL ES (this is a big one)
- Update units to use 3D models (probably without animations, based on new LibGDX 3d code)
- Particle System and Effects (for spells/abilities/etc)
- Allow for in battle dialog (for story and such)

Update Combat Engine:
- Network the game engine for multiplayer and to simplify further design.
- Optimize and compress combat system
- Allow for large-scale maps
- Implement abilities (always going to be the slowest task)

Update World Map:
- Create something a bit more than the current squares.
- Flesh out a world zone
- Create 2-tier world layout (regional maps and world map)
- Allow for in world dialog (for story and such)
- Create 'quest/mission' system

Update Game Mechanics:
- Revise attribute system (minor).
- Revise buff/debuff system to be more customizable
- Rework ability system by providing more unique and interesting abilities as well as a better upgrade path

*Update Artwork:
- This will probably require gathering some open media content, but will still remain a low priority for now.

This is a decent sized list and easily 2-3 months of work full time so I will have to judge and see what I can manage. The first task I will focus on is getting the game engine networked since everything else will be built on top of it. I've spent a significant amount of time testing different was to network games and determine how to approach it for CE. I believe I have a solution, but when I start to seriously work on the game come April I may have something different to say.

PaintParty: Upcoming Preview Release

After a short trip to visit a new place, potentially where I will be moving in a few months, I have had lots of time to think and like I seem to frequently do, I've changed my mind. Anyways, first thing to talk about is PaintParty.

The application itself is a bit rough right now, and some features are missing from our third iteration. I won't have time right now to push a preview as this week I will be swamped with midterms, but I will try to harden a few things and get ready to push a preview next weekend.

I've decided to drop my ideas for any sort of Minecraft mod. It is pretty clear to me that it is going to take months before any sort of early modding api will come into existence. Therefore I should focus my effort else where, that means back to Combatics Evolution.

Over the last couple months I have played around with a number of very important aspects of the project, and I feel ready to tackle the harder parts of the game. Including networking, skills, and full-3d with good performance. I won't be touching it till probably April at the earliest, but that is the current plan once I finish with PaintParty.

Valentine's Day Update!

I am convinced that Mojang is not currently working on the Plugin API. They are instead focusing on engine fixes and improving the overall quality of the codebase for Minecraft. I pretty much understand the codebase issue and engine problems since the last time I looked at Minecraft source I ran away and refused to touch it. The code screamed of code smells virtually everywhere I looked and after monkeying around I decided to wait for their official API.

Could I develop for Bukkit? Sure, but if I want to focus on UI, core gameplay, system level, effects/sounds/animations and other more complicated features which require client modding? Doing server-side mods will only help me alter current existing features. Anything extra will involve a bunch of workarounds/commands and nothing really pretty will come out of it. I mean I could always take the Deathcraft approach and practically rewrite the game, but how does that help me work on features which are suppose to add to the game?

Do I want to hack away at a client and continuously have to update my code to match the latest changes with the engine re-writes? Sounds like a heck of a lot of work and simply a bunch of rework which really turns me off. The whole situation has become depressing considering how Mojang has decided to go tight lipped about the Plugin API since Minecon. Honestly, I wouldn't be surprised if the next piece of info I get about it comes at the next Minecon. I've played around with networking a physics engine instead, it appears my initial gut feeling was pretty close to what industry does, but a few tips and tricks I didn't know (especially the source engine) might be handy. However, I think I will focus my efforts on school and working on assignments/projects.

I have been busy on PaintParty, we are well into our third iteration and we are looking to do a preview probably at the end of this iteration (March 1, 2013) to get feedback on the application. I'll probably post an Android APK and throw up an applet on a cloud instance to deploy it. Seeing how I've done it before and this time I have WAY less things to freak out about it should be easy to do.

What's New

I've been busy, as always, and have had a number of exciting things happen in my personal life. However, my activity over the last while has mostly been working on PaintParty. (Link at the top). I have also been spending a bit of time thinking about some more RPG mechanics for Minecraft. I won't be doing any real prototyping until shortly after 1.5 is released simple because it is too close to a new release to start hacking away at a Minecraft client.

In preparation for a Modding API, which really just seems like a promised feature which is repeatedly delayed, I am writing up an RPG testing application. The point is to test out different combat mechanics and quickly prototype various ideas. The application uses a physics engine and is networked so that I can really focus on the client/server aspect of Minecraft, but also easily work with a simplistic physics model for characters. It will support multiple people and such, but it isn't really a 'game' but more of a testing application with simplistic graphics and mostly focuses on behavior instead of looking nice.

I have come to the decision to compete in the Google Code Jam this year, just to see how I rank up in the world against other programmers. While I hate the 'style' of programming contests (write a short program quickly to solve a challenging problem), I believe it will be a good way to test my skills and see where I am at. Then again, I'm indefinitely at 'always improving' so I'm not sure if it really matters how well/bad I do.

Kingdom of Amalur: Reckoning

First things first, Kingdom of Amalur: Reckoning (KoAR) is a good game and is comparable to Skyrim in many aspects. However, Skyrim is a significantly better game overall for a number of reasons but I'm not really here to compare games. If you have looked at my Minecraft posts you will notice a trend where I am wanting to add RPG elements to the game. However, I won't do it by simply adding new items and locations, but actually turning the core game into more of an RPG.

Ideas and concepts are the most exciting part of developing a game, but rarely what you think actually turns out to be as awesome as you originally thought. I like to look at how other games did certain mechanics and evaluate mechanics on a number of factors. Most importantly, when you look at a game mechanic you need to think about the purpose of the feature and how much depth it really offers the game. I don't always follow it like a rule, but its a great guideline for any serious project.

In KoAR, the skill system irritates me. The whole purpose of the system is to allow you to build up your character's non-combat capabilities in unique ways. A great concept, but its poorly implemented. Lets look at the skills and some strengths and weaknesses with them:

Alchemy
Pro: Allows me to make better potions as I progress in the game.
Con: Without spending points in this, getting materials is a nightmare. It ruins the experience of gathering herbs at the beginning of the game and makes it very painful without heavily investing into the skill.

Blacksmithing
Pro: Allows you to craft really good gear and break down components from other gear.
Con: It is single handedly the best way to get good gear and makes repair kits the unquestionable best way to repair damaged gear for dirt cheap.

Detect Hidden
Pro: Improves the exploration of the game and makes the mini-map really powerful.
Con: Doesn't offer much for benefits and can easily be skipped by simply having a keen eye.

Dispelling
I just hate the mechanic in general, seems like a waste of time instead of actually adding 'depth' to the game. Whats the point if I can quickly fail it and in the worst case have to cure some curse for dirt cheap?

Lockpicking
Again, the mechanic isn't fun and seems like a waste of time. I could easily apply this to every game where they put in some sort of lock picking 'minigame'.

Mercantile
Horrible mechanic, completely inverts the scaling of difficulty. The better at this skill the easier the game becomes, and at the start of the game everything is retardedly expensive and earning money is difficult. Later in the game I am flowing with money and everything is dirt cheap. Economy and skills do not mix.

Persuasion
Pro: Interesting mechanic, as it changes the flow of things, but like mercantile you make the game much easier by investing into this skill (and using it).
Con: Can easily be abused by save/reload.

Sagecraft
Pro: Well done mechanic, works great and isn't flawed in its approach.
Con: Potentially devalues gems in the later part of the game, but isn't a huge deal.

Stealth
A combat skill, not sure why it should go with the above ones since it actually has a big impact with combat mechanics and the finesse builds.

If you played Skyrim, some of these comments also apply to that game as well. However, KoAR has a worse system overall with how skills work.

One of the things that KoAR does well is the combat system flows smoothly, and the targeting isn't intuitive until you understand how the attack/camera works. Combinations and such are very interesting, but certain combinations are significantly better than others which leads to gameplay becoming mundane and repetitive. Additionally, the gameplay is pretty easy even on harder difficulties. It is rare for me to feel even threatened in most situations, and I'm not even using very good gear.

The ability trees in the game do not offer much when looking at depth. Pure characters are significantly more powerful than hybrids, many points are used simply as filler and the active ability system is very clunky. I understand the console version is different in using spells, but for PC. I should press 1 key = 1 spell, none of the 'equipping' crap that only exists because of the console.

The alchemy system is numerically split up evenly, but I feel potions in general are too short of duration for me to want to use them and the benefits are fairly potent but when the game is easy overall, making myself even stronger isn't really useful. Tuning the difficulty, decreasing the benefits of potions and increasing the duration would have made the alchemy system much better. It feels like they added it in because its an 'RPG-element' but didn't give it a whole lot of purpose.

Blacksmithing is well done, the random factor isn't very good but that is something you can't help. I feel selling gear with high mercantile is much better than salvaging for the first half of the game. Itemization and stats aren't very interesting and certain ones are significantly better than others which makes the choice super easy for different classes (not very deep or interesting) Itemization shouldn't be cryptic, but it should be more than just 'the number is bigger and my class uses it'

The equipment interface in KoAR is horrible, and I mean horrible. It works because of consoles, but the fact its just a treelist makes it very painful to check gear/equips and compare items. The whole inventory system is a nightmare in general, but the list method seems to be a favorite for consoles. Side note: Minecraft figured it out so why big budget games can't is beyond my comprehension.

The destiny system is good, but it becomes very clear that hybrids suck compared to the three main builds. You will notice huge increases in damage and capabilities early on and never need to waste points on 'filler' you won't ever use as the hybrid. Also, please never add 'abilities' which improve a characters proficiency with weapons. This was a huge issue with Warriors from WoW for years and Blizzard finally figured it out in the more recent expansion packs. Honestly, do not create 'skills/talents/abilities' which determine what weapon your character becomes good at. It just means when you get a new shiny weapon that is different you will need to rebuild your character for a new weapon, its just plain annoying and a waste of time.

Twists of Fate system isn't good for the game. It basically means, if you do side-quests, then the game becomes easier. In reality, it makes balancing the difficulty of the game harder and KoAR didn't do a very good job on difficulty.

The chat system I have mixed feelings about, as it targets a varied audience. For those interested in lore it is great, but to anyone else it simply gets in the way of a smooth flowing story and the exciting part of fighting things. Lorestones are an interesting concept of portraying lore in a non-invasive way, but half the time they are abstract and unclear without thinking about what is being said. This just ended up meaning they felt pointless except for the little experience bonus they offer.

One final comment and this isn't just for KoAR, but many RPG games in general. Fast travel sucks, it is nice and makes the game flow better, but it simply sucks. Why? If you need a system to get around fast, you haven't made the game interesting enough to explore or admire. If traveling instantly from location to location is a core mechanic, then what is the point of building a vast world if the only reasonable way to explore it is by going to a menu between missions/combat/events. Fast travel, and to a lesser extent portals, is a flawed fix to a flawed problem in the game. I should instead be given the ability to travel around quickly, not instantly, and I should 'want' to explore the world instead of just get to the destinations. Just like life, it isn't about the destination, but how you got there.

Minecraft - Plugin Concept (Mob Levels)

I have to say, many of the RPG mods I have looked at have been disappointing over the years. Some simply add more content with little consideration for difficulty, others focus on adding cool new things, or even more dimensions and bosses. While these methods can be exciting, they get pretty lame only after a short while and rarely sustain a player's interest.

I want to keep my mods with a Minecraft theme, but add true RPG elements to the game. I have a few games in mind on how I want to draw these elements from, but that isn't really important right now. First things first, Minecraft has 'infinite' size worlds (at least for PC and by infinite I really just mean ridiculously large. So what draws the player to explore these massive worlds? Usually its the hunt for resources such as diamond, redstone, and maybe iron. I don't see how any other resource really ensures the player explores.

It is flawed. This is because these reasons to explore are basically near bedrock, why would the player ever want to go far away on the surface? To get away from other people, to build new things, to start something new but keep the old world. None of these are really about exploring, the intent of these reasons are just to build more stuff. Now before anyone starts telling me about how Minecraft is a sandbox game, I just want to say that I know. I'm really looking at just making things more interesting since a sandbox is great, but once you are in my position where you have played this game for over 2 years, you really just want something else to do.

Enchanting and levels are very tightly bound. They need to be separated so that 'rpg-levels' can become something meaningful. I would simply call the old level system 'enchanting power' or something along those lines. Instead, there will be something called "Power Levels" (PL) which have nothing to do with enchanting and literally do what you would expect, making your character more powerful. Obviously, you probably have heard this term from other places, which is fine because it is typically associated with the concept of the higher the power level the more powerful the entity is.

I'm going to be vague on details because I am simply putting out my concept and not really wanting to get into details on how it would work or what specific values are supposed to mean except for a few minor ones. For instance, all characters would start in a world at PL 1. Instead of getting experience from kills, you gain essence from what you kill. Earn enough essence and you gain a PL. When you gain a PL the overall abilities/attributes of your character increase very slightly and you gain Skill Points (SP) that you can spend towards different aspects of your character. These aspects would consist of combat related abilities such as faster attacks, more damage, more health, gain natural armor, better blocking, and potentially new things I would add through other RPG elements. Additionally, they could be spent on other things such as faster block breaking rate (some for different types), faster base run speed, faster sprint speed, longer sprint distance, jump height, larger hunger bar, and many others.

So how would you gain experience? Obviously, I want to ensure exploring and if you could simply stay in the same place and grind experience that would take away from the game. Well, when you start a world you spawn in the overworld at roughly an x,z location of 0,0. So lets assume at that location and the relative area nearby ever mob would spawn at level 1. As you move away from the start location, the strength of mobs would increase relative to the distance from 0,0.

There is a catch, as you move away from the center you would be moving linearly, but the area would be a quadratic. This means mobs cannot grow in strength linearly, or the area for new challenges would get massive. However, if I make mob strength increase by squaring the distance, then once you start getting to distant locations, mobs will become exceptionally powerful very quickly. Instead I'll compromise with something in-between the two called log-linear. An example formula would be: y = (x * log(x)) * 0.05 + 1, where y is the level of the mob, and x is the distance (in chunks) from 0,0. Additionally, the amount of essence you get from killing a mob would be proportional to the difference between your level and the mob's level. So killing lower level mobs would yield very little essence, and killing higher level mobs would yield lots of essence.

But how does this promote the player to explore? Well, obviously there needs to be an incentive for the player to explore other than just gaining some arbitrary power levels. More on that another time.

Minecraft - Plugin Concept (Equipment)

Continuing my exploration of plugin concepts I felt like there was a need to write down a few more ideas I've had. I will keep posting more ideas and trying to flesh them out in more details as time goes on. I might even create a site or something simple to store it in a simple and easy to navigate way. Anywho, this topic is about equipment.

What is equipment? Well first thing for those familiar with Minecraft is the helmets, chest pieces, leggings and boots. The part that has always bugged me is that it simply stops there and it isn't like adding more would be challenging in any way. However, equipment is also pickaxes, shovels, axes, hoes, swords, bows, fishing rods, flint and steel, I would even say compass, clock and map.

Homestone

My first idea is pretty simple, closely related to a hearthstone from World of Warcraft, I always wondered why the game never came with a simple item for teleporting back to your spawn point. It would make the most sense to craft a single-use item which can be consumed to teleport you to your spawn point following the same rules as when you die, except without killing you.

Many servers have simple commands like /home which offer the feature, but to give a player a cost-less way to teleport is extremely powerful and can easily be abused. Instead, it should be a crafted item, I suggest to craft the Homestone you would need 4 obsidian blocks in a diamond shape with an ender pearl in the middle. This makes it fairly difficult to craft, but something which could be farmed very easily to create relatively large supplies. The item type would be stackable up to 16, as a 64 stack wouldn't make it feel very important. Additionally, in order to use it the item there would be a 2 second delay or so. The same concept as eating food, this is so it cannot be easily abused to get you out of any bad situation but could be used to help if you need an escape.

Now that I've covered this one particular item of interest, lets get into equipment.

Equipment Interface

Obviously, if we want to expand the equipment we will need a larger interface. However, I would much rather create a new one instead of stretching out the inventory tab. Keep the inventory tab simple and remove the player component from it, assuming in the near future that will be easy to do. Instead a new hotkey will allow you to open up an interface similar to what we currently have, minus the crafting section.

Additional Equippable Armor

We will add additional armor slots to the current layout to have the following equip-able armor slots (This will require a rework of how armor works):

• Head
• Neck
• Shoulders
• Chest*
• Bracers
• Belt
• Gloves
• Ring
• Legs
• Feet

Italics - Indicate what is new

* - This model will need to be changed to not include the shoulder pieces.

The motivation behind this is to add significantly more depth into the game in regards to armor and making equipment choices. This is very important to any 'rpg' like systems as only 4 armor slots is quite workable, once you get used to it the choices you have to make become very simplistic.

In addition to having to change how armor works, enchants will also have to change as well as a few other minor changes to Minecraft in general.

Equippable Tools

Additionally, I would like to have slots for 'tools' This removes some of them from the inventory, but more importantly gets them off the placement bar. Instead of 'selecting' a tool, you would instead equip it onto your character and use it. There would be an easy way to equip tools, as you simply hover over the item in your inventory and then press a hotkey to equip it. Then whenever you are wandering around in the world, you simply press the hotkey and the tool switches into your active hand. Press the hotkey again, use the mousewheel, or press a number key and it will disappear. This would work great for Pickaxes, Shovels, Axes, Hoes, Swords and Bows.

For each tool, there would be two slots for each of these items, a primary and a secondary. To differentiate them you would press SHIFT + hotkey to select the secondary, and have a hotkey for swapping the currently active tool with the secondary version. Why only two? Well, I never really seen the need for more than two tools items with different enchants/types.

Auto-Equip Tools

When the primary slot on each tool type is empty, or when an active item is broken. The inventory will be searched for a replacement tool and it will automatically equip it into the slot. This avoids the unnecessary need to keep opening the inventory interface or equipment interface when acquiring a new item or replacing a broken one. It will also naturally select the worst one, first based on item quality, then item enchants, and then durability. I usually find I want to get rid of bad tools first before using good ones.

This feature would need to be able to be disabled easily.

Other Equippable Tools and Effects

Other items also make sense to be able to equip them, but they have slightly special effects. They also would only have a single slot for them.

Compass/Map Slot - This slot is shared between map and compass, it will not be auto-equippable because it wouldn't make sense without some complex logic. When a compass is equipped it will be displayed on the HUD as a 3D arrow pointing towards Y-127 and north. When a map is equipped it will be displayed as a mini-map on the HUD which either rotates with your direction being constant or has the player rotate on a constant map.

Clock Slot - This slot is interesting because it really will only have a single item ever. The whole point would be to add a time element to the HUD. I was tempted to make this occupy the same slot as the compass or map... however it would be very rare to find a situation where a clock would be better than a compass or map and if you did use it then it would be very temporary.

Fishing Rod/Carrot on Stick Slot - This slot is shared between the fishing rod and the carrot on a stick items. As with the map it will not auto-equip, but doesn't offer any real extras beyond what it currently does.

Non-equippable tools

Flint and Steel - This is mostly a rarely used item, not really needing its own slot. Usually you only have one unless you have some very pyro needs.

Buckets - These items are mostly used as 'blocks' so equipping a bucket makes little sense. You could argue a bucket with milk is a valid item, but that fits more into the consumable one with potions.

This outlines some of the basic concepts I have, I will certainly have to revisit armor types in more detail but for now this is plenty.

Minecraft - Plugin Concept (Armor Types)

After some monkeying around in Minecraft, I've been toeing around with a few ideas. Waiting for an official plugin API could be very slow. Heck they are barely into the inception stage of things, hopefully things will get sped up.

Going back over my list, I've decided a 'Stronghold' like plugin which could be absolutely sweet... its a very big scope and for this time is way beyond anything I would even want to tackle myself. Additionally, I'm not sure how Minecraft would work with it as I certainly would need to limit what could be built and not, which really takes away creativity from the game. While I could potentially work on some of this stuff right now by modding the client, which I have strongly considered for prototyping. I would rather spend some time doing game design instead of hacking in ideas.

Instead, I would rather focus on core game-play aspects of the current game and enhancing the depth of it. Mojang said the API will initially be for adding features to the game and not removing. This means my initial plugins need to add to the current game and not focus on changing it or overhauling it.

Here is what I have come up with so far, and yes I realize the possibility of people 'stealing' my ideas and I could even be doing things which have already been done. But in either case, life goes on.

Armor Types - I like how we currently have leather, iron, gold, diamond and chain. They each have 3 properties: Durability, Armor, Enchantability. So going off of that, what can I do to add something without changing what currently exists? Easy.

Gold-plated Armor - This would be a new type of armor, it would look like iron armor but the edges would be gold. This armor would have the same durability and armor value as iron. However it offers an Enchantability slightly higher than diamond (11), since chain is special with a value of 12 I wouldn't want to equal that.

This armor is crafted by taking an iron piece and placing it in the middle of a crafting table, then putting gold bars around it as such:

Chest - 4
Legs - 3
Helm - 2
Boots - 2

Hardened Iron Armor - This would be another new type of armor, it would look like a darkened version of iron armor. This armor would have the same durability as diamond armor. The armor value would be 19, instead of 15 from regular iron or 20 from diamond armor. (+1 to each piece above iron). However, it would have a low Enchantability of 7. Which is essentially the lowest in the game, this would make sense since it is hardened and thus not easily enchanted.

This armor is crafted in a similar way to Gold-plated Armor except using iron bars instead and with different values:

Chest - 8
Legs - 7
Helm - 5
Boots - 4

These changes provide a number of benefits with minimal costs:
- The gap between iron and diamond is smaller, with two options for intermediate armor before diamond.
- These items would be more available but there power also requires an increased cost.
- They keep diamond armor as the best in the game, which is critical given the current state of things.
- They keep the special bonus of using chain armor by having it more enchantable than Gold-plated.

Additionally, it provides an addition to the game without changing the current features or removing features.

Now since you would be crafting a new item using a previous item with the potential of lost durability, what should happen to the durability? Well, it would be bad to fully repair the item, but I feel there isn't much depth by leaving the amount of durability the same. Instead I suggest, taking the amount of durability which has been lost, and adding back half of it to the new Hardened or Gold-plated item.