#tttthursday

ties thursday?

tits thursday?

teeth thursday?

Games require lots of iteration. Often times this will lead to one off attempts at new mechanics, or tweaks to existing code. Over the course of a game project, this can turn a totally sweet system of organized classes into a hodge podge of bloated objects. Eventually you’ll get to the point where adding a simple feature can take hours of work due to the bugs and rippling effects it has on the rest of the class that’s likely doing completely other things by this point.

  But refactoring. Wouldn’t that take so much more time? It’s easier to just add one little function. When do I make the call to refactor the code instead of patching something in?

  There isn’t any specific rule, but pretty much as soon as you understand a better way to organize the code, you probably should. Although it’ll take a bit more time now, the amount of time you save in the future will be immense. Additionally, adding features (to the appropriate classes) will take less time every time with well organized code. Of course there are times when it’s appropriate to simply add functionality to an existing class. Let’s take a look at my most recent refactor.

  In BOSSES FOREVER 2.BRO we have this main title screen. It tweens in a title, displays a list of options, and allows the player to start the game. This seems pretty simple, and it is, but the main menu class ended up being 1400 lines of code.

  That’s a lot of lines for a single class. It is! A programmer once told me he tries to keep classes down to 300 lines. That sounds like a good number. A much better number than 1400.

  But I was still pretty stubborn. I was fine with the class being this long. We’re close to completing the game, the menu works, and so any refactoring would just be to clean up the classes for my own sake (and maybe coding pride). There was a problem. Of course there was though. I wouldn’t be telling this story if there wasn’t.

  When doing the port to Haxe Flixel, I received a compiler message that informed me that FlxButtonPlus didn’t exist as a class I could import it. This was an essential class I was using in order to create buttons that could display sprites for their states. This was needed because the default buttons were changing their states on hover, and I had to have my menu work with a keyboard or gamepad. Seeing how most of those 1400 lines were just instantiating and placing buttons, horrible copy/pasted instantiation code, it finally got to the point that refactoring this would be likely the same amount of effort as changing the implementation to work without the FlxButtonPlus class.

  First, a look at bad practices. How did the class get to 1400 lines? Well, this code was started 2 years ago, when I made the original BOSSES FOREVER. Some initial problems were starting with a menu that took specific button presses to activate certain menus. Then I added the functionality to select options with the mouse. Next came the ability to customize controls, a much needed feature. At this point I didn’t think to split it off into its own class. This caused a cascade of decisions to include all menu functionality in this class. With customizing controls, leaderboards, and character select, this class got bloated pretty quickly. I also ended up taking out that mouse functionality and made the whole menu work with the game’s current controls.

  My first tip off should have been when I needed to instantiate many buttons. This code should not have been copied for each button, but should be a function to create a dynamic button to be places and hooked up to the proper callback on select. Or even better, a button class that extends the game’s default class giving the functionality I need. This was taken care of by that FlxButtonPlus class I used, but I didn’t properly refactor for creating buttons with all the functionality I needed. Copying and pasting code is a prime candidate for a refactor.

  Next was the individual menus that the player had to use. Customize controls works vastly different from leaderboards, and neither of them need to know about each other. They do share the common functionality of bringing up a submenu, but the content and interaction within is completely unique. This sort of case is a prime candidate for making a generic class for a submenu (including display, open, and close functions), that is extended for the individual functionality of each specific menu.

  Finally it just took a long time to add in a button. I had to copy the code, paste it in, create my new button callbacks, and then update the positions of all buttons to align, and adjust my functions that activated and displayed all buttons on the screen. Creating and placing a new button should be a few lines of code, not a half hour of tweaking.

We’re now on our second Haxe port for BOSSES FOREVER 2.BRO as we make our way towards launching on OUYA. Originally, the game was made in ActionScript 3 using the Flixel framework. This works great for showing the game on the web, but has that horrible limitation of not natively supporting gamepads. Once the OUYA dropped, it was an obvious choice.

Fortunately there is an action script like language called Haxe. What’s particularly awesome about it is it can compile to many different targets including flash, OSX, Windows, Linux, and even Android. Seeing this is the best way to get both high performance (using native code) and all the features we’d ever want for the game (gamepad and cross platform support) we decided to port the game over to Haxe.

The first attempt took a long time. Although the language is mostly the same, Haxe is much more strongly typed. It required me to be a bit more particular about how I’m handling my objects. Eventually though, I got through the thousands of lines of code and had the game building to Android. It was a bit of a hassle, as I could never get the android build to just work. I also got to learn a lot about Android emulators and the sdk.

After getting pretty far on that, having the game running but just needing controller support, I was hit by crunch at work. This was fairly good timing though. At this same time a group of people were working on OUYA controller support for Haxe. By the time I had come back to work on the game, OUYA (and more) gamepad support was integrated into Haxe. So I grabbed the sample project and tried it out. But it wouldn’t compile. It was looking for something called openfl. After a bit of research I discovered that this was added to the Haxe 3 library.

I had been using Haxe 2.

Installation for Haxe 3 on my Mac held me up for a little while, but I’ve now got the game back to running on the OUYA, this time with controller support. Despite all the issues, it’s still far easier than porting directly to native code. Of course this could have been a good opportunity to simplify and refactor the whole codebase, porting will keep the gameplay as similar as possible across multiple platforms.

Besides suggesting Haxe for your multiplatform action script project, I also want to leave a bit that helped me figure out how to get that android build working. If you’re getting compiler errors for an Android target, try out these solutions:

- delete your hxcpp.hxconfig file and run openfl setup android again

- install the android sdk and ndk using openfl setup android and leave them in the default locations

- update the android sdk with the android tool

-- There was a bug in the version I used where I had to remove the original folder so the tool could install the newest version of the sdk platform-tools