While Permüt was the first game released by TripleFun, it wasn't the first game we worked on. That honour went to TED, or Tower et Défense in French.
TED was a mix between a game like Clash of Clans, and tower defence. It was destined for iOS (what isn't), and overall, we worked on it for about 6 months.
The story behind the game was that you were sent out by the king of the realm to obtain relic stones. These rare treats spawned naturally in certain areas where running water meets magic meets just-go-with-it. As you set out to essentially mine/collect these stones, the local indigenous population, consisting of goblins, orcs, and whatnots, take umbrage at your sheer cheek, and set out to ruin your day. They regularly attack your base through carefully scripted, predictable waves, which you need to defend against in order to continue pillaging the countryside at your leisure.
To repel the natives, you build defences and traps to slow them down, and towers to actually take them out. If you have a friendly magician at hand, you can also research and build spells that you can use during the battles, to swing them in your favour.
The king, not being one to put all his eggs in your basket, has also sent out a number of other players, which happily equals the number of players that currently have the game installed. These are technically your de-facto competition, and thus it's considered your right, nay duty, to attack their camp and pilfer their stones. Or buy them if you're a rich pacifist.
Behind every oak tree, there's a perfect little Flash acorn
In order to get the game design nailed down, I set to work prototyping it in Flash. It looked like this:
The original was done in about 2-3 days if I remember right, and I spent a day here and there adding in new features as they were required. All told, probably about 2 weeks were spent on the prototype. Obviously the benefits of being able to do this are huge, and I highly recommend rapid prototyping as a means of testing ideas. If it's not fun as a crappy 2D proto, then it won't be fun as a 3D bell-whistler.
The proto allowed us to play through the game really quickly, develop the layout of the map, the pricing system, the different timings, the AI, the wave layouts, and even simulate trading and PVP (albeit roughly). While it doesn't look like much, it's still playable. If we wanted to test something, rather than wait 2 weeks for a sprint to finish, it could be testable in a couple of hours.
We developed in Objective-C, our first time with the language. If you're coming from a - let's say normal - language, such as C++, Java, AS3, etc, Objective-C will hit you like a steel girder to the face. It's got some nice features, but nothing is intuitive. Even just trying to get simple stuff like constants working was a right pain. This StackOverflow question on constants has a whopping 712 votes, and the accepted answer has nearly 1000. That's about 1.5x my entire reputation. On a single answer. About constants.
This makes me cry inside.
Once you get over the initial WTF, it's not a bad language. Some features, such as Categories and Protocols, I love, and I wish we had something similar in AS3. But anybody that tells you they prefer it to its more sane C-based cousins is clearly drinking the Apple Kool-Aid. Lets be honest; it's iOS's popularity that's driving this language.
We were also using Cocos2d for the rendering. It's not my favourite library of all time and I'm going to avoid going into a rant about it, but it does kick-ass at getting graphics on screen. I don't think we had any problem keeping the game at a smooth 60fps, and we weren't exactly being super optimised.
For the code architecture, we opted for adapting the Ash framework by Richard Lord. I converted it to Objective-C and tweaked it to our needs. We were more used to coding direct OO-style, e.g. has relationships, so it took a while to get our heads around Ash, which is an Entity, Component, System framework. If you don't know why that's a good thing, read this and this.
In short, you have
Entities, which are composed of
Components can hold properties, or simply be empty marker
Systems are designed to work with a specific set of
Components, through a
Node object, e.g. the
PositionSystem, which updates the graphics on the screen, would need a
PositionNode, which would have a
PositionComponent and a
Every time an
Entity adds or removes a
Component, it triggers changes in
Nodes - removing
Nodes that no longer have all the necessary
Components, and adding
Nodes that now match the right criteria. All the main game logic is separated into discrete
Systems that can be updated without fear of breaking anything, and without having to load the entire architecture of the game into your head. While it demands more up-front work, it more than makes up for it in saved time later as you have less bugs, those that you have are easier to fix, and adding new elements is an absolute snap. I highly recommend looking into it for your next project. Especially if your next project is something like a tower defence game, where a lot of the logic is shared amongst objects.
Here's a pic of us doing actual planning, like big boy game developers:
So why no release?
10 months is a long time to work on something to just shelve it, so why was it put on ice? Simple answer: investment.
When you're looking for investors, it's much easier if you have something to show for it, something to prove that you can actually make a game, and make money doing it. Taking a critical look at TED, we would have been set for at least another year to get it into a playable state. For example, all the animations were hand-drawn, so any new character would take anywhere between 1-2 weeks to draw out all the poses, animations and effects from any magic spells. It was decided to shelve it and build something more immediate, i.e. Permüt, which ironically took around 9 months to build.
Check out some images and movies from the project, showing the camp, building, stones, magic, and the fighting.