MicroGolf Challenge

Update 05/06/2016: MicroGolf Challenge is no longer available as it's been superseeded by MicroGolf Masters

I'm finally at the end of the backlog of TripleFun games! Presenting our current game: MicroGolf Challenge.

About the game

MicroGolf Challenge (hereafter, but not the very next after, MicroGolf) is the multiplayer cousin of our solo game, MicroGolf (hereafter, MicroGolf Solo). The solo version came out first, but we recently removed it from the app store, as aside from being only on iPad iOS, was causing confusion amongst players as to which one to take. The multiplayer version is, however, miles better, supports phones as well as tables, and gives some love to Android.

In MicroGolf, you play mini-golf against strangers - and since the last update, your friends - over the internet, in real-time. You pay a few coins to enter courses, and whoever wins the most holes comes out richer. The loser is left to cry into their empty purse. A second currency, diamonds, is used to pimp out your ball, giving it more power or precision, or just updating the skin. Before you cry "pay to win", logging in every day gives you free gold and diamonds, so at the very least, persistence will pay off.

Spending real life moolah will pay off quicker though.

As you progress, the courses will get more challenging (and fun), but the payoff will be bigger as well. Rio, in particular, is a right wall-smasher. Every week, the players that top the different rankings (world, country, friends) will win some in-game currency that they can use to improve their ball, thus regularly reinforcing the status quo amongst the players.

Unity

As previously mentioned, TripleFun split off into 2 studios; one in Paris and one in Bordeaux. MicroGolf Solo was the first game we tackled at Bordeaux, and the first game we created using Unity. This meant that I had to convert the most part of our in-house engine to C# (it now covers AS3, Objective-C, and C#, meaning we can interchange clients at will and the server doesn't care, and moving from one language to another is eased as all your fun tools are there).

Moving to Unity was an interesting experience; we'd started right around the time the new UI came out, which invalidated pretty much every StackOverflow post on the matter, but I guess, on the plus side, we only had to learn that side once, instead of spending a few months with something like nGUI before switching over.

Overall, I'd say the experience has been a positive one. I still love Flash, and it's my defacto language of choice for fooling around and making games, but it's hard to argue its benefits over something like Unity (unless it comes to web games, where Unity takes a distant third behind Flash and HTML5 - at least until the Unity HTML5 support improves).

Pros and cons ahoy:

Pros:

• The Unity codebase itself is pretty awesome. Aside from game specific code, it's pretty rare that we have to write anything bespoke. Everything is already included, and there's loads of game-specific helper code (e.g. RotateTowards() to look at stuff). Switching between 2D and 3D is a cinch; it's all very well written
• You're writing in C#, which is my second favourite language (I know that you can write in JS and Boo, but I'd say the vast majority of people write C#). The only thing I don't really like about C# is its desire to use UpperCamelCase for everything
• Building for iOS and Android is super easy. You still need Xcode for iOS, but it beats the Flash workflow by a country mile
• The Unity Asset Store is something else. You can literally buy full game code for about €60, which is insane. Anytime you need to write anything, there's an internal argument along the lines of I *could* spend a day or two on this, or I could just buy it for €15
• The tutorials and videos on the Unity are pretty excellent, though at times can be a bit tedious, and I'd really love for them to provide transcripts with pictures
• Even when you're making a 2D game, you're not limited to just 2D content. In an upcoming update, we've changed the balls in MicroGolf so that they rotate when moving (previous, because they were uni-colour, there was no need). I've done this before in Flash easily enough, but it's even easier to just add a sphere to the game and rotate it
• Native mobile builds are slimmer than Flash builds. For Duelo, we ended up removing the least-used card images from the bundle in order to get under the 50Mb limit on Android, due to the added size of embedding AIR. With MicroGolf, we're only touching around 30Mb
• Speed wise, suffice to say, Unity outperforms Flash

Cons:

• There's no built-in support for JSON or XML, which is pretty disappointing. In Flash, JSON and XML are first-class citizens, and working with them is incredibly easy. For MicroGolf, I ended up using simple .txt files for the levels and Newtonsoft Json.NET for socket communication, but neither is an amazing solution. With a Java backend, ArrayLists and HashMaps require special treatment, so you either need deep inspection for every message (heavy), or custom deserialisation per message (annoying). It's still something to work on
• While Unity has a built-in profiler, there's a few flaws that prevent it from being great:
  • The history is only as long as your window. Once it's off screen, Unity just discards it, which is ridiculous. This also makes it hard to compare subsequent builds, where you might want to check if what you've done has made a difference
  • It doesn't seem to drop down into everything. For example, when looking at our server connection class, Unity stopped at the Update() method, even though the only thing in that method is a call to a sub-object's Update(), so I've no idea what's taking the time in there. I'm not sure if there's a depth limit, or because this object is held as an Interface. Either way, not ideal
  • Co-routines are held by the class that executes them, so if you have a central class for this (so non-components can call co-routines), the hierarchy is wrong
• I'm not sure if it's just me, but I find it very hard to find support for Unity if I have a question. Currently you can go to StackOverflow, answers.unity3d.com, forum.unity3d.com, or ask on Twitter. On the numerous different occasions where I've had a question, I've received an answer maybe 2 or 3 times. Perhaps it's because I'm coming from the golden age of Flash, where you'd ask a question on Twitter and get an answer in 5 minutes, but with the sheer amount of people using Unity, it shouldn't be as hard to get answers on stuff
• Unity has, I'd say, about 5 different working scales, or spaces, at any one time, which can be a bit of a head-wrecker. There's local space, world space, screen space, screen space in terms of actual resolution, and screen space in terms of reference resolution (if you're using it). There's also object space, but you generally don't work it in much. Converting from one to the other is a challenge in itself, as you first have to figure out which one is being returned when you get measurements
• Speaking of measurements, you're spoiled in Flash with how easy it is to do UI stuff. x, y, width, and height, you'll never know how easy you have it
• Nested prefabs (i.e. MovieClips that you can reuse) don't work. There are ways around it, but by default, it's not there, which is something I would have thought of as basic
• Sometimes, when you update Unity, you will lose values, or previously linked objects will no longer be linked. And you will only see this when you play the game and come across a null pointer error. This terrifies me

Undecided:

• One of Unity's strong points is obviously the Editor (as otherwise, it's just a library). Getting Components at runtime is slow, especially on other GameObjects, so you're generally encouraged to link everything up beforehand. This moves your construction from code to the Editor, which aside from essentially hard-coding everything, it makes it hard when it comes to change anything. Searching through code for a value/field is simple, searching through the Editor for the same is not. As well as that, values in the Editor override values in code, and you can sometimes wonder why things are the way you set them. That said, tweaking things in the Editor is obviously faster than change-compile-test. As a side-effect, any parameters that you want to expose now automatically need to be public, or have the [SerializeField] attribute
• Whenever you make a new class you need to decide if it should be a basic class, or if it should be a component. A lot will depend on the final usage, but some classes can go one way or the other. Classes that are components will get certain benefits like automatic access to all the different callbacks, like Start() or Update(), and can also call co-routines on themselves. With classes, you have more control over the lifecycle, and they're generally smaller/quicker to instantiate. You also have better control over the call order for things like Update() (you can adjust script priority, but it's for the entire script). Generally, I use classes when it's code-only, and components when it can go on a GameObject, but it's not something I've considered solved yet

Most of the cons or problems can simply be attributed to being more at ease with a different language, and needing to figure out the "Unity-way" of doing thing. The more I use Unity the easier it will get.

Development

Microgolf Solo was developed to test the waters with the concept while at the same time getting our feet wet with Unity, in preparation for moving to it completely. With the multiplayer version, we had to solve the problem of communicating with the server (actually writing the client to connect and communicate) and deal with the problem of having a physics game work in sync on two different clients.

Generally with multiplayer physics, you need use deterministic physics (with the same inputs, you get the same outputs), fixed point, or modify your client-server setup. Well Unity isn't even deterministic on the same computer, modifying the client-server architecture wasn't something lightly undertaken (our server is shared amongst all our games), and replacing Unity physics with custom physics appealed to me about as much as repeatedly stepping on Lego, so something else needed to happen.

While we continued working on the features for the original release, our CEO, Nicolas, sat down and spent a few days coming up with a something that worked.

The final solution, which was surprisingly playable, was to reduce all physics iterations to just 1, anything physically related was to take place inside a FixedUpdate() rather than an Update() (including any attraction by holes in the level), and positions, velocities, and forces were limited to 3 decimal places, which would happen every frame. Forces and angles for shots would be sent to other players as ints, to avoid any skulduggery on behalf of floats, and at the start and end of every shot, the client would send the positions of all the balls, so that in the rare event of a desync, they would at least be forced back to their original positions.

While it seems a bit awkward, it did let us keep the built-in physics. We had some issues with the original scale that we had chosen (balls approaching a wall at a shallow angle, would slide along it rather than glance off it), but we were able to fix it simply by multipling everything by 10.

We also built out 2 different UIs; one for landscape (tablets) and one for portrait (phones). While it leads to a better app experience, it means twice the work when testing, as the entire flow has to be gone through again.

The biggest hitch when developing was probably that we updated Unity about a bajillion times. We seemed to have hit the perfect storm of new UI, Unity 5, new plugins, and 64-bit iOS. Whether because we were forced to or not, each switch brought its own lottery of figuring out what had changed and what was no longer there (not to mention which of our links no longer worked). If you can, fix your tools, as you waste too much time going back over things.

Play MicroGolf Challenge

MicroGolf is now available on iOS and Android, and is currently translated in English, French, German, Spanish, Italien, Portugese, Russian, Chinese, and Japanese.

You can also check out some images of the project.