With Windward being so close to 1.0 release, I found myself looking back at the development process that got the game so far — the good, the bad and the unexpected. It was certainly an interesting project!
Sid Meier
Very few people know that the development on Windward started as sort of a joke. I remember walking up to the legendary game designer Sid Meier at the 2012 Game Developer’s Conference after one of his talks that covered game developers copying other game developers and asked him half in jest if he’d mind if I did something similar and created a game inspired by his “Pirates!” game. Naturally Sid being the cool guy that he is just said “sure, go for it!”
Now, I admit it was just a jest at the time, but the more I thought about it the more I realized that it may be a good game to make regardless. The first reason was obvious — I needed a game project in order to properly test NGUI — a UI system I created that quickly snowballed in popularity on the Unity Asset Store. A proper game project would let me use my own UI system in the same environment as other game developers would — in other words I would be “eating my own dog food”, so to speak.
Another reason for Windward being a good project to start with was that the game itself was a pretty solid match for my understanding of the Unity game engine at the time. Everything I needed to do there, I either already knew how to do or could figure out without too much difficulty.
Having spent quite a bit of time playing Sid Meier’s Pirates! many years ago I already had a good understanding of what elements I enjoyed in that game (sailing, combat), and which elements I utterly despised (dancing, sword fights), and so the initial goal of Windward was to simply focus on the elements I enjoyed and add multiplayer.
The Challenges
That right there — multiplayer — was when I’ve hit my first snag as a game developer. I’ve done multiplayer games in the past, but in C++. Even using Unity I’ve always bypassed their networking solution in favor of my own solution written in C++. This time though, I decided to stick with what Unity offered. That turned out to be my first mistake.
Now, don’t get me wrong. As much as I can grumble about it from time to time, I absolutely love Unity. It’s a truly fantastic game engine that I plan on using for years to come, and Windward simply wouldn’t exist without it. Unity is easy to learn, trivial to extend, and C# is an absolute joy to work with. What would take several minutes to compile / run in another game engine takes a few seconds in Unity. It’s a wonderful and extremely powerful tool — but like all great things, it’s not without its faults.
The first fault was the UI system — which coincidentally was something I happened to have worked around with NGUI before I even had to make any solid use of it. That saved me a lot of headaches. The second shortcoming, as it turned out, was the networking system. Unity’s built-in networking left much to be desired. Without getting too much into detail I’ll just say that it’s one of those features that clearly was never meant for prime time. Quick-and-dirty things — certainly — but nothing serious like an entire game.
Unfortunately for Windward, I chose to stick with Unity’s networking and ended up with a lot of issues that I had to either dance around or simply ignore. As the project grew, so did the issues related to networking. In the end it was simply often too difficult to get it to behave in a reliable, controlled manner.
Another mistake I made was entirely my own. I deviated too much from my original plan of making an adventure/RPG game and instead ventured too far into the arena-based combat. Maps in the 2012 prototype of Windward were all static, pre-made — and the game itself was basically a collection of skirmishes played solo or with friends. While fun, it happened to be too distant from the original vision I had for the game and the longer the development went on, the less I came to like it.
With Windward’s sales accumulating to a whopping $800 or so over the course of 8 months, expenses paying contractors exceeding $35k, and the networking issues begging a complete redesign, I finally made the decision to take a step back from it for an undetermined amount of time. This also happened to be around the same time I accepted a job at Unity Technologies, so between that and NGUI I simply wouldn’t have had any time for Windward anyway.
A New Beginning
Fast forward almost two years to the summer of 2014, I was back at Tasharen. With Unity’s new UI system that I originally helped them kickstart finally hitting open beta, the 8-12 hours a day I used to spend on supporting NGUI every day went down dramatically. Suddenly I once again had time to work on game development; I once again had time for Windward.
Learning from my mistakes I chose to scrap 99% of the work I’ve done on Windward. I kept only the art. Starting with a clean slate was a refreshing experience. This time around I used my own networking solution I wrote back in 2013 called TNet (Tasharen Networking). The way I designed it was perfect for Windward, and as an added benefit of its design it handled saving of the game absolutely for free. Imagine that — saving done entirely by the networking engine! It’s like ordering a car and having it come with a personal parking space at the heart of downtown next to your workplace.
Well, bad analogies aside, this time around I chose to forego the arena part of the game altogether and build the procedural world as the first order of business. With the massive world in place, I added towns with their own supply and demand issues for the player to tackle. Combat came next — the fun part — and with it the completely rewritten AI system that was bound by the same sight-based rules as the players.
In Pursuit of Perfect Sails
The only tricky part of the whole process turned out to be the ships themselves. I stubbornly wanted nice looking cloth sails that swayed with the wind, and that meant using Unity’s cloth system… of which there turned out to be two. Sadly, both had their own set of bugs, just like the built-in networking I used in 2012.
The first system was based on an interactive physics-based cloth. The most glaring disadvantages of this one was the setup — using colliders to hold vertices in place, and the fact that it animated in the physics update instead of the frame update. In layman’s terms, it made cloth jittery, and always lagging behind the ships. It wasn’t pretty.
The second cloth system was based on skinned meshes, which thankfully didn’t suffer from the jittery movement. Unfortunately the setup process for this one was even worse — with the built-in tools simply not working for what I had in mind and often crashing Unity outright. Also, cloth movement done this way only happened in one direction. Think of it as wearing pants — pants that can only extend away from your leg, and never into your leg. Sounds proper, right? Sure is, unless you are trying to make flat sails that can go either way.
Worse still, the second approach turned out to have other bizarre issues — such as errors showing in the console every time an object with cloth was destroyed. As it turned out, once created, the cloth objects could never be destroyed or even disabled (!!), or the game would spit errors and quite frequently — simply crash.
Despite the issues I chose to stick with the second cloth system — the skinned mesh approach. I learned that if the skinned cloth was set up from code it behaved drastically different from the cloth that was set up in the editor. It actually behaved like I wanted! That left only the second problem to deal with — the cloth creation being permanent… I admit I was never able to figure out a way around it, despite the many things I tried. In the end I simply chose to disable the cloth component, leaving the game object enabled and active in the scene. This prevents the errors from happening at the expense of a very obvious memory leak. Fortunately simply switching regions (read: loading different levels) cleans them up.
There were other issues of course… for example the first time any ship’s sails appear on the screen there is a noticeable jump where they spring into place, despite being set to “animate off-screen”… or pausing the game leading to all cloth simply disappearing and the game running at a reduced framerate until the player switches scenes… Neither of these bugs I was able to work around, but thankfully they were minor enough to ignore for the sake of the added look of cloth sails flapping in the gentle wind.
At this point I’d like to point out that Unity 5 — the next iteration of the Unity game engine features a brand-new cloth system that addresses most (if not all) of the issues I just talked about. I gave it a try and it’s indeed a lot better, and infinitely easier to set up as well. Unfortunately I couldn’t switch to Unity 5 as it also happens to completely redesign how car mechanics work, leading to all my ships no longer sailing about at all and I didn’t have the patience of redoing everything and re-learning how it all worked.
What’s this, you may ask? What do cars have to do with Windward? Well — all ships in Windward are actually cars. They have wheels that only touch the water plane, and the hull that does not. This is what gives them the nice physics-based animations with them being affected by the wind, sharp turns and abrupt collisions. I wanted a true physics-based approach this time around to make the game’s animations seem as nice as possible without having to hard-code anything, and this seemed like an obvious approach to take.
Early Access
Well, I digress. Once I worked around the quirky issues I went forward with the Early Access release on Steam — and this is where I have to say that out of all the platforms I tried publishing games on, Steam has been my favorite by far. Throughout the Early Access I kept releasing new updates to the game almost daily — meaning there were nearly daily updates for many months.
With Steam the release process is very simple — compile with Unity for all 3 platforms, place the build results into the proper folder and run a batch file. After that all that’s left is to navigate to the publisher administration page and make the new build public. What a breeze! No lengthy approval process, no jumping through hoops to publish for different platforms… adding achievements, trading cards, modifying the store page — everything was ridiculously straightforward with Steam. It was a pleasure to work with.
And so we’re brought back to… today. The game is in good shape with all the desired features in place. In its current form, Windward is a sandbox game where players are in full control of their own adventures. The game’s unique mix of fast-paced naval combat and a tranquil, serene atmosphere of exploration, questing and trading lets Windward appeal to gamers both young and old.
So I guess the only question that remains is — will it appeal to you? Well, there is only one way to find out. :)