We create all kinds of mobile and web apps for clients; we are not talking about games here but business / utility apps. As clients usually want a ‘mobile’ app and not an iOS app anymore, we decided to go cross platform with Xamarin. It’s a great choice as it gives you the ability to still publish native apps on different devices instead of dealing with HTML5-based ‘solutions’.

We are also creating our new game in Unity which means finally we are going cross-platform with games as well! Stay tuned for that, it’s coming soon!

So many of you have been asking about the Android version of Soctics.. believe me, nothing would make me happier than having it already available. We’ve started the porting actually a long time ago but for various reasons we are always hitting one wall or another..

However, we haven’t given up on bringing Soctics to the world outside iOS. We’ll port it with Unity and hopefully still this year a significantly bigger audience can enjoy our competitive turn based football game

After the Unity port is complete, we’ll be able to introduce some new stuff in Soctics but it will have to wait for now. Mostly we are talking about some iterative changes and probably some cosmetics, nothing that would re-shape the game. We are pretty satisfied with how the game feels at the moment.

That’s it folks!

If you’ve ever wanted built a landing page or had the need for one, you’ve provably heard of LaunchRock. If not, have a quick look. LaunchRock makes an extremely good job at making it super easy to build a landing page. No HTML knowledge is needed. Among many features, the page lets your future customers share about your idea / app / future venture on Twitter, Facebook and LinkedIn. This is a great way to collect emails of possible futures customers as well as starting to build up the buzz about it.

When we decided to create a new app of Soccer Tactics Multiplayer instead of doing an update, it was clear that we had to use cross promotion to get our existing players know about our new product. For this, we built a LaunchRock site to collect the emails of our fans. Although, we have built a way to talk to them via Message Of The Day and feedback, about which I wrote last week, it was just a simple way of putting out text in front of the players.

We did try this first by simply showing the url, but only our most active and addicted players would take the effort to actually read the url and then open Safari and then fill the form. Not very effective and also, it turned out later, the mobile representation of the LaunchRock site was not that nice as it was on the desktop.

Since we wanted to extend our internal Message Of The Day service for long time, in a way that it can show media rich content, it was the time to do so. Instead of showing a default UIAlertView, we modified it to be able to show web content in a UIWebView. This is great, because we can now open pictures, videos if we liked, not just UIAlertViews.

The rich MOTD looked exactly like the one on the right. We are still hosting it http://soctics.com/launch.html. If you have look, there are a few things to notice.

There are two teasing pictures on the top of this screen so big that it actually won’t fit into the whole screen. This was good thing for two reasons:

1. We hoped, both pictures were eye catchy and it would engage our previous game’s players and
2. LaunchRock part takes some time to load at the bottom and while it gets loaded hopefully players are still watching the second picture.

Once LaunchRock loaded, it turned out that it wasn’t looking nice on a mobile screen. The font size was too small and the whole page could be scrolled sideways. Although LaunchRock’s support was quick and friendly saying they are working on the mobile version, we did not have time to wait so did our own way

It included a quite easy change within the relevant launch.css and another one to duplicate the email form.

The first part in the css is about to fit LaunchRock nicely on an iPhone. (We only targeted those customers. Like 90% of Soccer Tactics games was played on an iPhone). Adjusting the text in the middle and making it bigger so it’s easy to read without pinch-zooming.

The second part, to duplicate the email entry form, was done to maximize the likelihood of the conversion. On a mobile device, only some part of the page is visible and we wanted the form to appear two times.

If you have a look at the source of the html how it was done, there is some nasty things going on. (I must admit, I get dirty when it comes to html ).

Here is the relevant part:

 var count=0;
 function addSignup() {
 count++;
 if (count==14) {
 var y = $('#signupform-8M3HZA8H');
 var x = y.clone(true,true);
 x.attr("id","signupform2-8M3HZA8H");
 x.prependTo('#inviteform8M3HZA8H');</code>

$("#signupform2-8M3HZA8H > #email-8M3HZA8H").change(function(){
 $("#signupform-8M3HZA8H > #email-8M3HZA8H").attr("value",this.value);
 })
 }
 }

head.js(
 "http://launchrock-ignition.s3.amazonaws.com/ignition.1.1.js");
 head.ready( function() {
 $('#launch').bind('DOMNodeInserted', function(event) {
 addSignup();
 });
 });

There are a few things going on here.

1. There is a <div> in the html body with id=launch.
2. The content along with the id of that div will be modified once the ignition part is downloaded.
3. Before that modification, the addSignup() function is added to that div’s DOMNodeInserted event to catch when the div is being modified to contain the LaunchRock part.
4. The addSignup function simply clones and puts to the right place the signup form. It also changes the cloned form’s id otherwise the the sign up form would be moved not copied.
5. addSignup only clones for the 14th time the div is modified. After some trial and error it turned out that after the 14th  DOM modification, the sign up part could be cloned. (I am a bit surprised this code still works).

Okay, was it worth it? Well, a nice thing about LaunchRock is that is shows you analytics about the conversions  That showed that it was 3x less likely that a visitor would sign up but since it got delivered so many times it ended up being 8x more sign up than before.

There was one more (sneaky) thing we did while delivered our MOTD but it will be another post.

If you are interested in our MOTD module as a service, feel free to sign up for it’s LaunchRock site: motd.bitongo.com.

We gathered the numerous user feedback we received during the years and we discussed them about how we could incorporate the changes suggested by the users. Although we haven’t implemented everything, we used their feedback a lot during building our new features list. The original game was iPhone-only and we wanted to introduce an iPad version as well so we decided to create a separate binary for the iPad and keep the original for the iPhone. This is the historic reason behind not going universal.

We decided we lack on the following major fronts:

• lack of customization of team colors
• poor graphics
• poor sounds
• online mode is not deep enough
• AI not challenging enough

The first two points got handled by our new graphics design team. Have a look at thebefore / after images below

Graphics aside, the sounds proved to be another big task as well. We implemented an AI for the crowd that would react to events during the match, like a big goal save, a nice pass, etc. This increases the ambience atmosphere tremendously but it is not a simple thing to implement properly!

The online mode got re-written from the ground up using Erlang. F3r3nc is supposed to write about his experience with this system soon. Right now we provide our own matchmaking for friendly matches and official, ‘league’ matches as well. Implementing our own solution has the multiplatform support advantage over simply just using Game Center, although we did integrate GC as well for achievements and for friendly challenges.

We also started experimenting with new gameplay changes:

• kick-off mode
• new player types
• improved control mechanisms
• ball prediction: show where the ball lands at the end of the turn

The final result is essentially such a changed game that we had to release it as a separate product because our original Soccer Tactics players wanted to keep the ‘classic’ version alive and intact as well.

Especially the new feature called Binocular which predicts ball movement seemed to be a game changer. The feature is great as it gives players more control over their attacks but we did not want to upset the balance in the game. We decided to limit the number of binoculars to be used during the matches. These binoculars are consumable items that players can receive when they are playing online and there is an option to purchase them as well. We put emphasis on the mechanics of receiving / spending binoculars so it is not mandatory to use the IAP options at all.

We now look at Soctics League as the evolution of Soccer Tactics, putting our experience and feedback into the successor and making a superior product in all sense. We are very proud of it and can’t wait to meet you all online!

You can check out our official website for Soctics for the trailer and the download links.

The iOS market is more than 300 million strong and although competitive gaming is a niche, in such a big market it is now a reasonable market segment to target. Think about the successes of Deadlock or Hero Academy and it’s clear that multiplayer-focused games are not limited to desktop anymore.

We are in the final stages of creating our competitive game ourselves. We decided to create a Mac + iOS game where you can play against anyone with a Mac / iPhone / iPod Touch / iPad. As we are blending mobile gaming with desktop gaming here, we had to consider the priorities. We decided to treat the game as a mobile game in essence. I would like to share with you the decisions we made during the development:

1. brand new game: as we were building on our previous game Soccer Tactics, we originally planned to introduce the new gameplay and competition system as a monster-update. However, existing players really liked the original version and our new version completely changes the whole gameplay experience. Finally we decided to go with a totally new game
2. skill matters: although luck can never be ruled out from any game / sport / competition, statistically speaking a good player should beat a weak player more often than not. This might seem trivial at first but balancing a game where a beginner still has chance to win against a seasoned player while retaining the importance of experience and practice is very time consuming!
3. elegant gameplay: we were trying to keep our ruleset small and give the players the ability to practice and hone devious skills and strategies in our game space. We provide a practice mode where the player can focus on preparing different strategies
4. no prolonged games: this is a very important aspect when we are in the context of mobile games. The majority of our matches finishes under 15 minutes.
5. Game Center only for fun: when we started development, the Mac did not support GC at all. Now we know that Mountain Lion finally integrates this great feature and we might consider moving towards GC in the future. For now, players can only play friendly games with each other via GC and our league system is served by our own multiplayer server.
6. Own Multiplayer Service: as we couldn’t use GC on all our target platforms and we already had a pretty good multiplayer backend with our previous version of Soctics, we decided to roll our own multiplayer service. This gives us the freedom of staying totally platform-agnostic which might come very handy later as well.
7. connect players: to help the growth of our community, we wanted to implement chat in our game. As we had mixed experience with having chat in a game before, we decided to implement an ‘offending player report’ system along with the possibility to ‘parent lock’ the chat feature. We are considering an official forum as well to further facilitate player-to-player communication
8. periodic tournaments: this is a feature we are very excited about. We will run tournaments for specific periods of time. This can be used for several purposes, from giving out great prizes to pure ego-boosting challenges! Multiplayer in general is great for user retention, organizing tournaments is an even stronger feature!
9. Skill based rankings: We are using the ELO ranking methodology for ranking players in our tournaments. It is a great system and I advise to read about it if you are not familiar with it. Basically as people keep playing more and more, their ranking will display their relative strength within their league more and more accurately.
10. Deal with cheaters: Multiplayer games have their share of cheaters all the time. As we want to keep the league system as clean as possible from cheaters, we decided to make it difficult and very time-consuming to game the ranks and to cheat our league system.

As you can see there are many different aspects you have to take into consideration. It is also a good warning for anyone who plans to implement multiplayer / competitions in their game. It really blows up your scope! You can expect to spend at least as much time with the multiplayer mode as with all the rest of the game.

However, if you choose to move on and implement a strong competitive mode in your app, you will have one of the most powerful retention factors I have ever seen in a game. Our original Soccer Tactics game debuted in 2009, we introduced the multiplayer mode in 2010, and we have players who have been playing with the game ever since! How often do you get such loyal users in the mobile game space?

In most of our 2D games we used OpenGL and you might know what that means:

• Creating your own framework for sprites, frames, entities, animations
• (particle systems)
• if your game is level-based, some kind of map data structure
• map editor (it would preferrably be a separate product, easy to use etc.)

What if you need some physics? Nothing fancy for sure, just some collision detections, maybe bouncing here and there… Oops another couple thousand lines? What? You’d like to have a stable physics which is not juttery, does not depend on frame rate and all that kind of small-text-details stuff you only recognize you need when you are already knee-deep in… your own physics engine code? Sure it’s almost done so lets finish it anyway! Oh, 1 month passed already? Wow!

The list could go on and on. It’s impossible to estimate properly how long writing your own engine will take if you don’t have considerable experience in it already, and do you really want to spend so much time on it? Every time you re-invent the wheel, you are wasting precious time of real game development! If it takes for you to develop a game in 4 months and during that period you were building an engine in the first 3 months, what were you really doing? Wouldn’t it have been better to learn to use existing tools in a couple of weeks and then focus on the game aspect for 3 months instead of 1? The real value is what the users will finally experience in the game, not the fancy code you have managed to create to solve mind-boggling low-level technical problems!

I have fallen into the building engine category too many times. I think too many people fall into this category. Maybe it is an engineer hubris, we take pride in our work, building something from scratch sounds great because we feel we are not depending on any middleware or already existing tool and we will be able to create the perfect little engine that our app needs. I do not believe that anymore. We are going to create limitations in our own engine no matter what and we will manage to accept those limitations happily.

Most of the devs are not supposed to be building engines but should use the existing ones and even if they would hit some limitations on the engine side (maybe this is more of just a simple fear than a real fact), it’s still quicker to find workarounds in an existing system.

So what’s my advice really?

1. When problem-solving, stay as high-level as possible. When I’m talking about problem-solving, I am talking about creating prototypes. Best ones would be that would work on paper, just grab a pen and a scissor and start creating your game! If that’s not feasible, go with a language you are very comfortable with and can code very quickly!
2. When you have an amazingly solid game mechanism, choose an existing tool / engine that would cover the biggest subset of your requirements
3. The technology part is just 1 aspect of a game, it is not the game itself! Even if you hit a limit with a chosen engine, ask yourself the question: does this limit really affect my core gameplay? Is it crucial from a user experience point of view?
4. Don’t reinvent the wheel! I’m begging you! All the energy you’ve put in your own physics / rendering / sound engine should go into gameplay balance, elegance, rewarding systems, player immersion, storyline, character design etc!

I am not saying there are no cases where writing everything from scratch is a bad idea. I am saying people usually overestimate their needs / underestimate existing tools and focus on things that are, essentially, a waste of time.

So which one are you? Are you an Engine Dev, or a Game Dev, really?