I'd first like to apologize for the failure to provide community write-ups during the Week of Awesome. When I had initially started, I had fully planned to write a journal post a day, however, after day two of development, it became obvious that I was going to have to push aside lesser priority tasks, as the coding portion of this project took more effort and time than expected.
Regardless, this postmortem post will be lengthy as I believe that keeping the community updated though the journal posts is not only important, but a major part of what makes the Week of Awesome competition so challenging and rewarding. One does not get the full experience of surviving a project development life-cycle if the documentation (or in this case, community) phase is skipped!
This postmortem will expand on my previous diary posts. If you have not read my previous posts, and would like to, the posts can be found in my "WoA" developer diary, which can be found at the following link:
https://www.gamedev.net/blog/2220-woa-2016-team-bytetroll/
With that all being said, lets get started with Team Bytetroll's postmortem post.
As noted in my previous posts, I had a bit of bad luck this year. My normal tried-and-true team was busy with real life and alerted me to the fact that they couldn't participate this year (although, a day or two before competition, Riuthamus found out he had the week free and decided to compete; leaving me to compete against my own team). Furthermore, I had made the mistake of following the workflow I had taken in previous years and preplanned a week from competition start. While preplanning is normally good (yet alone a must), in retrospect, I took the wrong route when it came to selecting a programming language for the project. I had initially selected Java as my language of choice for three reasons:
1) Java has fast turn around time.
2) Java (for the most part) is stable and reliable.
3) Java (for the most part) is write once, deploy everywhere.
Moreover Java seemed like the logical choice as I have many years of experience in Java development (although not writing games) and am very familiar and comfortable with the Java universe (tools, the way things are done, etc). Also, despite slot machine gameplay being the only type of gameplay I had never researched or implemented in my 15 years of working in the industry, I figured that it was a slot machine, and there shouldn't be too much logic behind it. However, again, looking back in retrospect, this mentality would soon cost me.
It is at this time, however, that I would like to note that a majority of my frustration was not with the language itself, but with the limitations of the language -- something of which I should have foreseen. My original thinking was that several games had been coded in Java, all of which have at least average console performance. I found myself overlooking the fact that Java lacks a true programmer managed memory mechanism at the language level -- which is almost a must for any game. This proved to be the real hassle. Despite me being a first time LibGDX user, I had done my required research; making sure I was aware of their memory management scheme for releasing native objects. However, for what ever reason, I overlooked this fact, and didn't plan or account for it when creating my framework. The result was that my UI class was leaking obnoxious amounts of memory due to the way that I wrapped LibGDX's native "Texture" class. To make matters worse, I knew were and why the memory was leaking, but after multiple attempts (from both I and Migi0027) to patch it, had no way to solve the problem without a total rewrite of my framework (which at that point was close to 100 files and five or six thousand lines of code). As a result, I had to resort to my backup plan; knowing full well it was going to severely hurt my week. Despite this I kept true to my original promise[1]. I quickly cloned our in-house 'javac' compiler that I wrote and maintain at work and spent the next two days adding C++ style memory management to Java (which actually turned out pretty well). While it was a pain, it solved all of my leaking memory issues, and surprisingly turned out to be easier than rearchitecting my framework. This was not an ideal solution by any means, but given the context, it was my last and only option to stay alive in the competition..
After the memory leaking issues had been resolved, I was able to continue on with my last few days in peace; ultimately wrapping up and compiling my final build the morning of competition end. Implementing and structuring the slot logic was bit of a hassle, but an event system took care of that.
Other than that, there is not much left to say. I am considering open sourcing my project and am thankful I got the chance to compete again. It was a hell of a week and I had fun. I'd like to once again thank Sean Forbes (Riuthamus) and Miguel Petersen (Migi0027-cdk) for everything that they did for me during this week -- especially to Sean, who took the time to hand draw my assets, despite him having to create assets on his own team's WoA project. To both of you, I greatly appreciate it. You allowed my project to ship (literally).
- The Troll
[1] [size=1]Before competition start I made a personal promise to myself that no matter what happened, I was going to follow through, push, and finish the project -- even if that meant that the project was going to be shipped incomplete... even if that meant that I was going to have to finish the project after competition end.
Wait wait wait, you modded the Java language itself for your competition entry?! That is truly impressive!
As a fellow Java dev (professionally) I am curious: Why do you have your own javac implementation?