This week we’ll release the free version and a content update for our first game, Candy Soldier. At the same time, we’ll start sharing some insights on our development process and the daily activities here at Sertão Games. In this post, we discuss what went wrong and right during the development of Candy Soldier.
Candy Soldier took exactly one month to be developed, from November 4th to December 5th 2011, the day we released it in the Android marketplace. After a short evaluation period, the game was also available at the Amazon Android App Store.
This game was a joint effort between Sertão Games and Estúdio Alicerce. This partnership began in early 2009, when Erick and Carlos Ranna from Alicerce met and teamed up for the Global Game Jam ’09, when they developed Pipe Mayhem, the game from which Candy Soldier characters and style derive from (the mechanics are completely different, though).
Firstly we were developing a war game with Unity 3D, aimed at iOS devices, but decided to hold that project in favor of a more straightforward one for Android. We did so because a very fast time-to-market was one of our early goals for the studio. Achieving that would give a lot of confidence for the next projects: it just feels really good to finish a project in time, having a nice product to show in the end.
Candy Soldier was our first game, and that means we had a lot to do in a short period of time:
- Choose which programming libraries/engines to use;
- Decide if we were going to create an abstraction layer/framework on top of these libraries (and develop it, is so decided);
- Organize a streamlined development process and decide for an asset pipeline (that last thing you want in your development process is a bottleneck);
- Prototype, play-test with gamers and develop the game itself;
- Design this website, facebook and twitter applications for the studio;
- Prepare marketing assets and so on;
It is a lot of stuff… Really A LOT. So before you decide to start as an indie game developer, think twice and liste to this: teamwork is the only way to go.
Before going through the classic wrong/right list of things, lets depict our decisions: since we’re very accustomed to and advocates of the game-object-components architecture, we decided to write a simple framework to abstract the use of the excellent Libgdx. It is worth mentioning that we’re a team of 5 people here at Sertão Games, and we also had the collaboration of Carlos Ranna and his wife from Estúdio Alicerce. So, lets go through the list.
1 – What went Right
– Writing a game-object-component framework
Putting it very simply: the game-object-components architecture organizes a game into Levels, each one a collection of Game Objects. Everything in a game is a game object, such as a floor, a character, a rocket, a menu, for instance. A game object is a composition of components that give its characteristics such as: Sprite Component (appearance of the object); Animation Component (sprites are animated); or a Physics Component, (the object is controlled by the physics engine).
Creating games this way means you don’t need to worry about implementing a game loop, etc. These components are also highly reusable, so the Sprite Component is used every time a game object has graphics, and so on. Given our experience with this architecture, developing this framework on top of LibGDX was straightforward and also very rewarding.
Our framework made possible finishing the game in one month, and we also have it ready for the next games to come. During the development of Candy Soldier, we decided to completely change the game mechanics half way to the deadline, and we didn’t have to change much code to do so because we had a solid foundation of reusable components. Re-composing objects and implementing a couple of new control components did it. We strongly recommend reading this post in Erick’s personal website.
We’re so excited about our framework that we plan to release it as open-source to everyone else. Stay tuned for new announcements.
– Remote communication
As we mentioned before, it is a lot of work to put a game together and this particular one would not be possible if we weren’t sharing efforts with the guys at Estudio Alicerce. The thing is that they are some 3000km (~1800 miles) away from us!
Since they were doing art assets such as sprites, animations and music, but not code, we decided to go simple and not actually use version control systems. We just used Dropbox to keep an assets folder synced. We soon decided for a naming and folder structure that successfully kept us out of troubles. Chat communication also worked a great deal, and a Skype video meeting once a week was enough to clear any doubts.
When developing a game, the single most important thing one can do is playtest. I’ll repeat: PLAYTEST. It’s the only way you can check if what you’re doing make any sense to the public, whatever it might be. Playtesting made us realize that our first proposed mechanic was very complicated to be understood, and that we would have a lot of work to make it work properly.
For those who haven’t read a good game design book or article, here’re a few tips:
- Shut-up: anything you speak ruins the “virginity” of your test player, especially when he already started playing. Remember, you’re not going to be available when player download your game and play for the first time. If you realize that you need to introduce something such as story or a clue to the goals of the game, write down this sentences, they’ll be the basis of your “tutorial level” in the final game.
- Observe: don’t ask anything, just observe the player while he goes through the game. It’s nice if some of the player are able to speak loud describing what they’re doing (but not all of them can do this naturally), but the single most important thing is to observe the player’s reactions: does he get surprised when something new appears (if not, it might not be standing out enough).
- Use metrics: there’re a lot of metrics/analytics frameworks out there. They’re very easy to setup and statistics will help you discover and quantize stuff such as: where are the places the character dies the most? what are the most difficult levels (those the player has to play more times to beat)? Metrics must also be used in the final game, as you can also consider your paying customers the testers that drive your next update.
- Don’t test in disturbing environments: noise and distractions are enemies of the sole most important thing you want to find about your game: does it put player in a flow state? for how long?
– Using a tilemap editor to do level design
When developing our framework, one of the first components we implemented was a wrapper for the TMX tilemap importer included in libgdx. We ended up creating two separate components: one to take care of importing the tile-layers; and other to convert a specified object-layer to physics objects in Box2D (with this approach it is easy to design platform levels, for instance).
However, we went beyond these two reusable components, and used our tilemaps to also position candies, movable platforms, etc. We used object layers, embedding attributes in each object, and could simply loop through these parsed meta-objects and custom-spawn our game objects based on this information. It a bit cumbersome at first to code this type of conversion, but it pays in the end with enhanced productivity.
For the record: we used the excelent Tiled editor, with its standard TMX export format, and PNG tilemaps.
2 – What went Wrong
– Bias in play-testing
Yes, I know I’ve said that playtesting was one of the things that went right, but it also had its negative side. Although it was very important to have actual people testing our game, it would be a lot better if we could have tested with “unrelated” people. Being a small studio means we ended up testing with some friends and relatives: don’t do that. We won’t do it again.
The problem is that this type of player is biased. They’re afraid to “hurt your feelings” and are always positive, and you DON’T want only positive feedback when playtesting. At first we created an online form to be answered just after the testing section, and even though the form was anonymous, we still had suspiciously good feedback (and no, the game was not good at that time yet).
As we mentioned before, don’t even waste your time designing such form, just observe the players and record metrics/analytics. Try to recruit anybody but your relatives and friend. And remember to use people inside your target demographics.
– Integrating features at the last minute
We split the team in different fronts:
- game design and assets
- framework and components
- social network integration
- website design
– Steep Learning curve
Even though the core development team is proficient in Java development and very experienced, some of the guys were new to game development, especially in the Android platform. This resulted in a lot of pressure on the ones who did have this experience.
In the end it didn’t result in any problem with the product itself, and we took care of this issue nicely in the following month. The new free version and the new updated levels with a new setting in the forest for the updated regular game were completely handled by the guys who were still struggling during the stint for the first release.
3 – Follow-ups
We consider this initial experience very successful, and we are very confident with the way the team handled the issues. We’re currently developing two brand new games (two new IPs): one for iPad; and a new free game for Android, soon to be announced together with the release of the source code of our game development framework. Stay tuned.