The Two Sides of Learning New Frameworks

This is the first time I’ve ever written a blog/article/story about anything to do with my academic experiences. Academia has always been particularly sacrosanct to me, and something that I preferred to keep to myself. However, for once I feel compelled to share an academic experience with all of those who are interested.

Originally I was preparing to create a persuasive argument against doing what I’ve done these past two months before the posting of this, but reflection on that led me to believe that to be too self-serving. An overly positive article would be facetious. So I shall split the difference and just give my experiences with as neutral of a tone as I can manage. So, with no ado at all, let’s get into this.

The Background

While the target audience of this little article will tend to be my academic peers in the same degree program as I am, let me give a bit of background into said program regardless, for the sake of those who might not be in this target.

At the time of this writing, I am a student in the closing sections of a Mobile Development degree at Full Sail University. As the name of the degree implies, it is focused on the development of applications (apps) for the now-current leading mobile platforms (at the time of this writing, iOS and Android. We shall see if there is a Tizen revolution in the future), consisting of, in my mind, five distinct blocks of classes. The first block consisted of “general skills”; there were classes on Photoshop and Illustrator usage which also doubled as basic marketing classes, basic programming classes, and some simple writing classes as well.

The second set of classes focused on the mobile web, the frameworks it uses, and the way you can develop cross-platform without the use of native code. This led us into the meat of the degree (in my opinion), the two blocks focused on iOS and Android. This isn’t a review of the degree, but suffice to say I had no complaints about most of the classes, despite

However after the (second-try) success of my Android final project, I entered into the last of my self-defined blocks. This was the “other important stuff”, a theory class on what makes games work as games, a class on doing cross-platform the hard way, things of that nature.

In this block is where I currently find myself at an impasse within the Immersive Application Deployment(IAD) class, an impasse that has its origins in my previous class.

The First Game

The class before IAD was Mobile Game Design(MGD), in which we needed to create a mobile game for either iOS using Cocos2d (Objective-C) or Android using LibGDX (Java). I’ve never been a fan of Objective-C, and I don’t see my view changing any time soon. It is, in my mind, a needless convolution of c-like programming languages without adding much substance over other modern languages used in mobile such as C# or Java. Therefore the prospect of creating a game, something I’m inexperienced in doing, in the language was a virtual non-starter for me. This reduced my options to one: LibGDX and Java.

Before I started the game, I was warned about a certain level of difficulty in using this library, that Cocos would be a better choice. I paid little heed to these warnings; Android was my preferred platform and Java was the third programming language I ever learned (this was some time in the fall of 2009). I was confident that I would be able to figure out the framework, and if I couldn’t, I was confident that I could just code my way out of things.

To be fair, this turned out to be true. In the end, I managed to pass the class with a closer-than-I’d-like A on my first go. It was nowhere near as simple as I first would have thought, however. I’ve softened my opinions on LibGDX since using it, but some facts still remain: it is not well documented, there are few good code samples, and the first-party GUI implementation is still horrific. This said, it is not an unworkable library, and in the end, it still gave me enough to pass the class when mixed with a large amount of “desperation coding” and rather generous deadline extensions.

At the time however, LibGDX left a bad taste in my mouth.

Immersion and Dissent

Moving into IAD I was in no mood to keep scraping by with frantic coding at the deadline producing hacky code. (in hindsight, that was what I continued to do, but hindsight is 20/20). I wasn’t amazingly thrilled about the game I had produced. It was farther away from the action-packed vision I had when I pitched the game, and was shaping up more like a game of Flappy Bird caliber, without the addictive value to make people ignore the simplicity.

With my interest in the original idea gone, I decided that I would try my hand at doing a complexity new game for IAD. I was, once again, warned against this, with a much stronger tone this time; only a handful of people had tried this, and they all had failed. I try not to be arrogant as much as possible for a 22 year old man to be, but in some areas I fail in this goal. Programming often tends to be one of these areas. So, I equipped myself with a “They failed, but they’re not ME” mentality and started concept work on a new game.

In reality, I had the idea for a new game already thought out due to a project in one of my PMA classes. For those not familiar with these classes, they’re run in parallel to the core degree classes to accent and supplement the core curriculum. So armed with my idea, a turn-based political game in the vein of games like Kairosoft’s Game Dev Story, I just needed to figure out how I wanted to make this game.

LibGDX was a non-starter. I was still in the “simmering rage” phase about my experience in MDG with the library. This seemed to leave the sole option being Cocos2d for iOS, but my hate runs deep with Objective-C. Therefore I started looking for Android alternatives. (this prompted another “it hasn’t gone well in the past” warning that I ignored.) The problem here is that single-platform mobile game engines are a scarce thing. In the end, I narrowed my choice down to three options, a Java library that I cannot even remember the name of, Unity3D, and Project Anarchy, with the latter two being cross-platform libraries.

The Java library was on the list for posterity; I wasn’t going to even humor the thought of another poorly documented, code sample lacking library. That left Unity and Anarchy, both somewhat overkill 3D libraries that could be simplified to do 2D projects as well. Both had ample support, proper documentation, video tutorials, and a large community. The final decider was the language, Anarchy used C++ whereas Unity offered the option of three languages: JavaScript, Boo(I have no idea what it is either), or C#.

C# was the second language I learned in a serious sense, and I felt even more conformable with it than I did Java, so my decision was made to do my new app using Unity and C#.

Republica, First Attempt (Unity)

Before going into my making of the game, let’s take a moment to describe the development environment I had adapted to work on this project. The below picture is an example of what I would have normally seen when working in Unity on this project.

Capture(thumbnail, click to enlarge)

The first thing you may notice is that I was working on a Windows computer for this project. I decided on that for two reasons, the first being my having two physical monitors on my PC. I use multiple virtual desktops on my MacBook when I’m developing on that, but having a second physical monitor is a luxury I wanted to have on this project. The second reason was one of convenience; I already had Unity installed and set up on my PC. In the end, it didn’t make much of a difference, so

Onto the workflow itself, on the main (left) monitor, I kept the bulk of Unity’s IDE. This is the part which linked all of my assets together, the “scenes” I created in unity, the “game objects” that were held in the scenes, and the scripts that got attached to the game objects. It is also where the debugging is handled for testing. The main monitor was also where I interchanged the Unity IDE with a web browser or a file browser as needed. On the second screen, I popped out the “game preview” display from the Unity IDE

Finally, on this second screen, was the code editor I used for the C# code. Most people said that using a modified version of Eclipse was better than using the stock MonoDevelop distro packaged with Unity, but I always found MonoDevelop capable of my limited needs, so I kept it.

With the setup explained, I can now get into my actual development process for the week. As it turns out, the native Unity GUI framework wasn’t really up to task for a text-and-buttons heavy strategy game like the one I had in mind, so I needed to find a framework to put into my framework (so I could frame while I worked). A good thing about Unity is it’s large asset store, filled with thousands of frameworks and other resources to get. With this said, it is called a store for a reason; while there were free resources, they were far outnumbered by paid resources, with full GUI frameworks going for as much as $400.

To continue my project I opted to chose an open-source framework called OpenGUI. Unfortunately, with this decision, I was back into the realm of undocumented frameworks that I had originally tried to escape from. I soon entered a familiar cycle, spending the lion’s share of the week learning the part of the framework I needed on my own through trial and error to have 1-2 days at the end of the week to actually do the work for my project.

Something I didn’t expect was how disjointing Unity’s workflow would be to me. To this point, I had only just played around with Unity, so the concept of the code (that you edit) being separated from the objects you see on the scene was a jarring change, a change that I could see as potentially very powerful, but jarring nonetheless. It is something I can see being interesting to learn in the future at my own pace. However, learning at the pace of “this week or you fail” takes some of the interest out of it, and I was back to the process of desperation coding (just coding until I got a result, best practices be damned).

Ultimately, what killed my project for this month was not a technical issue or a coding problem I couldn’t figure out, but rather a licensing issue.

Capture (thumbnail, click to enlarge)

Something that I did not know before I started the project was that some features that would be available for Unity projects on PC/Web aren’t available for use for Android or iOS. One of these features would be access to using .NET sockets. Broadly speaking, without the $1,500 dollar Android Pro license, I could not use the Internet in the way that I needed to in my project. I could use web features then run them on PC, but I could not generate an .APK while using the net features.

On a project with at least half of the features required involving network connections, this was a hard-and-fast game over. So, I failed my first try at this app, and none of my work could really be carried over to the next month. I learned a valuable lessons about reading the licenses on things.

Republica, Second Attempt (Cocos2d-x)

The smart move would have been to use my MGD project and LibGDX or if I were dead set on redoing my IAD project to do it in Cocos2d for iOS.

I can be surprisingly stupid at times. So, with that in mind, I opted for the least-stupid stupid move, and decided for my second go to use the multi-platform port of Cocos2d, called Cocos2d-x. 2d-x once again had me choosing between three languages again, with the set this time consisting of C++, JavaScript, and Lua. Despite me being familiar with JS and Lua, and having never done anything in C++ before, I opted to choose C++ for virtue of it being an Object-Oriented Programming (OOP) language.

Lets go into the workflow setup again, it is much more hacky this time around.

Screen Shot 2014-06-29 at 1.46.10 PMScreen Shot 2014-06-29 at 1.46.15 PMScreen Shot 2014-06-29 at 1.49.14 PM
(thumbnails, click to expand)

In theory, one can setup Eclipse to be a full IDE for Cocos2d-x projects. Theory doesn’t always pan out, so in the end, Eclipse was relegated to the position of glorified .APK packer for the project. The core of file editing took place in the “pseudo IDE” of a text editor (Komodo Edit) with Finder (the OSX file browser) open next to it. Building the project occurred inside a terminal window. Furthermore, any debugging that happened would take place inside this terminal window, as the C++ compiler errors would only be fully shown here. I usually also always had Photoshop open as many of the non-text GUI elements in the framework require images to work at all.

Working in this ad-hoc environment was actually somewhat more relaxed than Unity (for a while). It wasn’t elegant, but at the end of the day, I was writing code for everything including GUI, compiling it, chasing errors for 3 hours, then running it on a phone through Eclipse.

I added emphasis on something important in that last sentence. Since I basically had to learn C++ from scratch in the one month of this project, errors were plentiful and they usually cascaded into large error stacks that took ages to resolve. I wasn’t completely in the dark; I’ve used OOP languages/data constructs before, I’ve used languages that used headers and implementation files before, and I know C. Without that knowledge, I would have had no hope. But even still, the hurdles were significant and I once again ended up spending a large portion of the week trying to learn how to do basic things before even starting to work on the game proper.

In this regard, Cocos2d-x had a full set of docs and a downloadable set of sample code for those docs. A problem of communication however caused a bit of a problem with my Googling in this project. You see, the Cocos2d-x project was developed by Chinese developers, and a lot of the use of it is in countries speaking Chinese (Japanese and Korean too), which made searching for things online involving the library a bit of a chore.

Capture (thumbnail, click to enlarge)

I can read and write in (simplified) Chinese and Japanese at about the level of an elementary school student, so I could read a lot of the stuff given enough time, but nowhere near as fast as English. Furthermore, anything in Korean or traditional Chinese (simplified is used in mainland China, traditional is used in Taiwan and Japan) became an exercise of “Google Translate + luck”. You soon learn to miss the ability to find quick Stack Overflow posts and other web stuff when you need to rely on find your old textbooks from school to read the stuff (or re-translate the machine translation from Gibberish English to Human English).

This attempt also ended in failure, not because success was an impossibility, but rather success in the time I had was an impossibility. My lack of experience in the language hurt me a lot more than my lack of experience in the framework. Ultimately, I was done in by a lack of understanding networking in C++. The irony that Internet functions were what caused me to fail twice was not lost on me.

I was significantly improved from when I started the project; I could write whole Scenes without fatal errors now. But I still had (and have) a long way to go.

Conclusion

In the end, the simple take-away you could get from my experience is to not try and fast-track learning new frameworks and languages for important projects with tight deadlines. I’d agree with that point, and for the most part do. However, I find myself in a position of having mixed feelings about the whole thing. I torpedoed my GPA in a bad way, but ultimately that I went from a 3.8 to a 3.5 is going to be irrelevant in my future career. I also ended up adding an extra two months to my graduation, that’s a more meaningful impact. But as a counterpoint, I probably have learned a great deal of programming in multiple languages over this month, more than I would have learned otherwise.

I’ve improved my ability to write net code (by being forced to do it in the most bare-metal environment), and while I may lambast “desperation coding”, it doesn’t diminish it’s value to know, and I’ve likely gotten better at that as well. The question that remains to be answered is whether or that knowledge learned was worth running “F” grades. My gut answer is “no”, but that I have the question of whether it was a good thing in my mind is proof that I’m not sure of the answer.

I’m in a confident position to actually complete this project the third time around, and while I’m still trying to figure out exactly the content of what I’ve learned, I know I have learned something. That’s one of the things that I have learned, that coming out of a bad situation with a positive is not a complete defeat.

Michael Mancuso on EmailMichael Mancuso on FacebookMichael Mancuso on GithubMichael Mancuso on LinkedinMichael Mancuso on Twitter
Michael Mancuso
Jr Full Stack Developer at InteractWith
I'm a junior developer and a senior cynic. BS in Mobile Development. I blog and play video games. Occasionally I sleep. The views expressed here are my own.

Leave a Reply

Your email address will not be published. Required fields are marked *