So here we are then after almost a years worth of development, and the games not done. But before I go into the wheres, hows and what next, let me introduce who is working on this game.

Phil Maxey(Myself) Project manager, gameplay concepts, and the one full time coder on the game.

Craig Richards – Graphic artist working part time.

Gavin Harrison – Sound, working part time.

Shilo White – Extra coder working part time.

And what is the “game” ? The game is a fantasy themed strategy MP asynchronous iOS game, of which there are many examples of on the App store. You can build and grow things, train troops and then do battle with other players, you know the type.

I kept meaning to write a development diary but never got around to it, seeing we are at an important juncture with the project I thought this would be as good as time as any to start. I’m sure there are many game dev’s who have been down the road I’m going to write about and who are still going down it, and maybe reading some of this diary will help. In some ways it’s a cautionary tale but this is a game development diary not a post mortem of a game that was released and didn’t do well, and that’s kind of the point of this, things are still on-going, the dream is still alive.

I say game development diary, but it will be a mixture of game mechanics, life as an indie developer, the whole making money on the App store and actual code discussions.

So I hope you enjoy the ride it’s probably going to be involve lots of ups and down, but hopefully ending on an up. Feel free to comment!

How it all began

Throughout most of 2012 I was trying to work out what game to work on next. I know I wanted it to be an iOS game and I knew I wanted it to be a “big” and important game release, however due to the fact that I might well end up working on it alone it couldn’t be too ambitious, so Call of Duty on the iPhone was out for example. There was also the not so unimportant fact that I had never programmed a line of Obj-c in my life, having spent the last number of years as an AS3 game developer….on a PC.

I created 2 small Adobe AIR games published to iOS, called Balloodle and Wordora as an experiment to see what would happen if you published a game on the App store. Do games stand a chance of success just by the mere fact they are on the App store or do they sink without any promotion. I’m sure you can guess what happened, they both disappeared without trace, but it did teach me an important lesson which is of course there’s no point launching on the App store without promotion of some kind, and ideally a pre-established audience. There was also the fact that both games, especially Wordora were very basic games, nothing that is going to set the charts alight, so quality of game regardless of all the conspiracy theories about the charts does play a big role.

After a lot of time spent researching the App store charts, reading reviews etc I came to the conclusion that I wanted to do one of those “Fantasy multiplayer games!” without really understanding what that meant. Clash of Clans was doing well which was a game which clearly had a lot of work put into it, but there were a number of similar themed games which were also doing well and looked to me as game types which were “doable”, i.e. with say 6 months of work, maybe with a graphic artist working alongside me we could create something similar to those games and launch on the App store, even taking into account my zero knowledge of obj-c (so much for not being too ambitious).

Also during this I came up with the idea of going to a publisher to help with the funding. I had read/seen many articles relating to publishers active in the mobile game space which seemed to state that they would be willing to fund development of games they liked the look of, so that seemed a fairly good plan to work towards. Get the game to a reasonably advanced state and then go knocking on the doors of publishers and get them to help out with the final funding/developing.

Towards the end of 2012/start of 2013 I went looking for a graphic artist to work with me, and luckily found a great artist called Craig Richards. I then got myself the cheapest Apple development solution I could find which was a Mac Mini, signed up to the Apple developer program and set about learning Obj-c while working out how the game would actually work, what assets would be required etc.

The original game design

What I want to do at this point in the diary is take you through my original thinking behind why I came up with the game design I eventually did.

I looked at the similar games on the App store and they all seemed to have similar “ingredients”. You could build things, but usually not grow things. The multiplayer was important but usually not real time (I had no idea why that was back then, but got to a point when it made sense, which I’ll get to at a later date). Players needed to trade amongst each other and battle each other. Experience level or ranks of some kind were important. The games usually were based around some type of major building, castle, town hall etc, and the player had to manage buildings around the main one.

After looking at all that, I came up with the idea of managing a village, but I didn’t want there to be restrictive set locations where you could put buildings as most of these games have, but instead the player could place them anywhere on a grid. I also wanted to keep it to a single screen, I felt that it would be more manageable for players if they didn’t have to scroll the screen around to see where things were, so this meant we ended up with a village which was a 6×6 tiled grid, giving us 36 possible building positions.

I didn’t want upgradable buildings because I wanted to give the player more choice of buildings overall, but some of these would be locked due to the player not having the right status or rank.

I liked the idea of the player having a real royal type status in the game and came up with 8 ranks or statuses from merchant all the way up to emperor.

I wanted the player to be able to play as either male or female.

I wanted the player to be able to have more than one village to manage.

I didn’t think there was any need for any computer A.I opponents, it was MP only.

I wanted the player to be able to trade.

I wanted the game to be F2P and have a soft and hard currency, but I only wanted the hard currency to be used to finish tasks early. I didn’t want the hard currency to be used by players to buy their way to the top so to speak.

And finally I wanted the game to have board game elements. We spent a fair bit of time discussing how to do battles between players. I liked the idea of battles where you saw little characters fighting it out, but no matter how I came at the issue it meant the battles ended up being turn-based, i.e the player would have to wait until the other player had taken his turn, and that just wouldn’t work in an asynchronous game where I needed the battles to be self contained and could be over and done by just the actions of one player. I also really wanted to put dice rolls in the battle. Again I spent time on how dice could be used and eventually came up with making it as simple as possible, which is 2 dice roll on the screen, and if your dice scores higher than the enemies your attack is successful and then all the stats (strength etc) of whatever you attacked with would come into play, so the actual attack is 50/50 but the battle overall would lean towards whoever chose the more effective units to attack with. I liked that this introduced a random element into the battles, so the more powerful player wouldn’t always win, this is something I got from many hours of playing Risk.

So that was the game design that we started work on in early 2013.

Tools of the trade

Learning Obj-c went pretty well and I would say I’m definitely a fan of the language and Apples tools. Coming from AS3 Obj-c took some getting used to but now when I go back to AS3 for other projects AS3 seems pretty basic to me (I still think it’s good for what it’s for though). When I did get stuck Stackoverflow came in pretty handy, although I learned pretty quickly to try to not ask beginners questions as that usually get’s your question closed down, but all in all SO was a useful resource.

At the start of development I did lots of research on what would be the easiest way to code this game. What SDK’s, Libraries etc were out there that would make my life easier. At this point I have a confession to make. I’m not a hardcore coder. I don’t live to code things in the most efficient manner. To me coding is a means to an ends, it’s not an ends in itself, so whatever I can find that will help get the job done quick I’m all for. That’s not to say I don’t enjoy coding, I do, there’s nothing greater than bringing an idea to life, and being able to do that through code is great, but it’s the idea that counts, the game, the app, it’s people using, playing and hopefully enjoying what you have created that matters to me.

There were 2 main areas of this project that needed to be covered. The first was some kind of obj-c wrapper library that would allow me to code the game quickly, and the other was the server side of things.

For the wrapper library, there were a number of options, Cocos2D, Unity and Sparrow. I looked at Cocos2D but for the life of me couldn’t really make sense of it. Unity looked great and still does and I might well migrate to Unity at some point but it seemed more than what I needed, so that left Sparrow, which coincidently was built in such a way that would make it recognisable to Flash developers, so that’s what I want went with. I’m a big fan of Sparrow, Daniel the guy who built it is always happy to answer questions and there’s a tight knit community on the forums who are happy to help too. The framework itself is very intuitive to a Flash developer and covers all the tricky areas of multiple screen formats, using sound etc.

Next was the server side of things. This is an area I pretty much knew zip about. I’ve dabbled in PHP in the past, I was aware of services such as player.io for Flash, but I knew when it came to a game like this, I’m going to need a service/SDK that was going to be as easy to use as possible and could handle a large scale multiplayer async game, looking around Parse.com ticked all the boxes, the only drawback was that it was only a free service up to a point, but the great docs and simple SDK meant it was spot on what I needed, so Parse was the final piece of the puzzle.

Making it happen

The early days was all about me just getting something to work, getting objects on the screen, getting some kind of village appearing, getting the data loaded and saved from parse, Craig was sending across great graphics, and everything was coming together well but very slowly, and this is the first major point (no doubt the first in a long line of points I will eventually make before this game is launched) I want to make.

               1. DON’T UNDERESTIMATE HOW LONG GETTING THE UI RIGHT WILL TAKE IN A MOBILE GAME.

Games like this look very simple on the surface, even taking into considering the reliance on persistent data, technically you’re not trying to recreate a fully fledged 3D environment similar to say WoW or COD. But as we all know appearances can be deceiving. What I found was that the tiniest of features we wanted to put into the game would take from a few days to a week to implement, and that’s not with any playtesting of it, that’s just getting something functioning.  One of the biggest aspects to slow things down was the UI, i.e how to present to the player whatever new function we wanted in the game. UI is a whole skill all in itself, don’t let anyone tell you different. It’s not the same skill as creating a graphical asset in a game, it’s a skill relating to how those assets come together and are presented to the player, and for mobile games it’s of paramount importance. Making the UI more complicated is the whole aspect of monetization, afterall you’re making a game which is completely free for players to start playing so you need to build into the game and make apparent via the UI that money can be spent in certain ways, get that wrong and you make no money.

Work continued through 2013 and a number of target dates to present to publishers came and went, eventually we were ready to show something around early September, and we sent a TestFlight invite to a publisher. They looked at it and after a few days the verdict came back (I’m paraphrasing) that it’s too dull (especially at the start) and there’s nothing about it to make it stand out from the other 1000′s of similar games out there.

The first big changes

This was a disappointment. We had already spent many months of work on it and the first people to look at it where shall we say not that impressed. Even though my reaction to what the publisher said was disappointment, I had this nagging feeling that they were completely right, and this brings me on to points 2 and 3 that I want to make:

             2. YOUR GAME DEVELOPMENT TIME IS NOT JUST CODING OF GAME FUNCTIONS AND THE VISUALS, BUT ALSO CONTENT.

             3. DON’T SPEND ALL YOUR TIME CODING YOUR GAME AND NOT PLAYING IT.

You see I had completely under-estimated the amount of coding work involved and the amount of content a game such as this needs. Most of my time was spent just coding the basic functions of the game and putting in content which those functions would use, it led me no time to actually play the game which in turn led to a teeny, tiny problem…..there was no actual game. What do I mean there’s no game? well we had all the ingredients that a game like this would usually have and that was my main coding priority when working, to get all the game functions in and working, but just as with any recipe you can have a number of ingredients but that doesn’t guarantee that the end result tastes any good. The proof is in the eating as they say. So the version we showed the publisher had pretty much everything in it, you could build things, you could grow crops, you could train soldiers, it had a great dice/battle system to attack other players villages and you could trade. I concentrated so much on getting all of that in that I completely forgot about the actual gameplay, and there wasn’t any.

There are a number of reasons why that happened, the biggest of course is there only being one full time coder. Even though I’m working on it full time (and when I say full time, I mean morning to the early hours, 7 days a week) developing in a bubble is never a good idea, especially I think on a game project such as this. Unfortunately that’s all my means could allow me. But getting back to the main issues for the publisher, namely it was too boring at the start and there was nothing which would make it stand out.

I looked at what we had and at other similar games and decided to make 2 radical changes, the first was to scrap the idea of a fixed screen village, I decided to double the village size (making it 12×12) meaning the screen now scrolled and to implement a scrolling kingdom map which showed other players villages on the map. Doubling the village size was pretty easy to take care of, I already had some scrolling code from before and that went in quickly, but the scrolling kingdom map was tricky. The problems are these, how do you show a scrolling map of players villages if the map can be of infinite size (in theory) due to an unknown number of players? also how exactly do you position those players on that map? how do you calculate what space is available? what kind of coordinates do you use? how do you make it so that villages are close to each other but not too close? I asked these kinds of questions on forums and got lots of different answers, I ended up with the idea of using Parse’s GeoPoint object, which seemed like it might be a great way of doing it, but then it occurred to me that there’s probably a very simple solution. If there’s one thing I learned in all my days as a game developer it’s that 9/10 you can fudge something and no one will ever know the difference. the system I came up with for the map was a grid system, but to give the village positions a bit of randomness so they are not all placed on straight lines, was to make each cell in the grid made up of preset village locations (5 of them), so I can have these 5 nicely positioned villages in each cell, but the cell itself was just 1 of many in a grid. When a new player comes into the game, I just see what the latest cell is, see what spaces there are in the cell and put them in there, and when the cell is full up, move along to the next cell, in a kind of ever growing spiral shape. This system also kept the latest village fairly close to all the others. So that’s what I did and it worked great without me having to get involved with any of this real world geolocation business!

Those 2 changes took about 3 weeks to implement, not too bad and we were ready with a new version to present to publishers, and this time I was going to show more than 1.

Straw, camel and all that

You might of noticed something missing from the changes I implemented after showing the first publisher, but we will leave that to the side for now. So 3 weeks after showing the first publisher we went back to them and went back to 2 others, and the verdict?

“the game mechanics were competent but the one thing that is missing is that special hook to set it apart from other games in the genre.  Also the slow pace of the game was a turn off”

And that was pretty much repeated by the 2 other publishers as well. So after an extra 3 weeks worth of work, absolutely nothing had changed. This was pretty disappointing, the whole plan of getting publishers to help fund the final stages of the game was just not working out. But the reality was even though we had improved the functioning of the game, we still hadn’t solved the basic problems the game had, but before I go into that I need to say a few words about Publishers.

All the publishers I talked to were nice. One of them was happy to engage with me to a certain extent, but overall the impression I got was that unless your game was a sure fire money maker they weren’t going to be interested, and that’s fair enough, however that’s not the impression the publishers like to give publicly. I’ve read lots of news articles/press releases over the last 2 years about/from publishers stating how developer friendly they are, even to the extent that they will be willing to fund development of a game. Which is why I had the plan I did. My thinking was regardless of any faults the game may have at the 50-70% development stage, there was enough there that a publisher would have to be blind to not see the potential and would therefore be happy to help move things in the right direction with financial help. This I have found is not the case, infact I was told by a number of publishers something along the lines of “You finish the game yourselves and launch on the App store, if the game does well and makes lots of money then we will be happy to give you a little extra money in return for a chunk of your profits” the problem with that of course is that if the game is making money, why on earth would I give a chunk of my revenue away just to secure a bit of extra money? and equally if the game wasn’t doing well on the App store the publishers wouldn’t be interested anyway. So either way that position makes no sense to me. What does make sense is helping developers create something that can be a money maker prior to launching, but the plan from some publishers seems to be they are only willing to back a horse after it’s won the race.

I’m still on good terms with the publishers I’ve already had contact with and I’m looking forward to showing them the new version next year but after spending over a year of hard work (not to mention Craigs time as well) on the project with no support at all from any publisher and getting the game to a point where it will definitely do well on the App store, I’m going to need some convincing that it’s in my best interest to use a publisher, but time will tell.

Cha Cha CHANNGESSS

Getting back to where we were 3 weeks ago. The 2nd wave of publishers were not interested and gave the same reaction as the first time around, which meant I have to take a long hard look at what we had. For the first time since I started working on the game at the start of the year, I was able to look at the gameplay of what we had created and see where and what it lacked. A number of great ideas came from that process which I’ll be discussing over the coming months, but I also became sure of something very important which is point 4 and 5.

           4. YOU NEED PLAY TESTERS.

           5. ANY KIND OF MULTIPLAYER GAME IS A HUGE UNDERTAKING SO YOU NEED MORE THAN ONE CODER.

I always wanted this game to be thoroughly playtested and I always wanted another coder (preferably a more experienced one) working with me. I never managed to get the latter, and never seemed to have the time to find the former. There needs to be at least 2 coders working on a game like this, because so many aspects of this type of game need large amounts of work completed all in themselves, so for example social integration is an area which can take months of work all by itself. One coder can definitely do it all if they have to, but the quality of the end result will suffer and in the ultra competitive market that is the App store that probably equates to no revenue. There was a guy who was a regular on the Sparrow forums who seemed to know Sparrow all ends up, and was obviously very experienced with Obj-c, that guy was Shilo White. We had had a number of conversations, but he was always too busy to get involved, luckily though he had some time and now is the 2nd coder on the project. Shilo’s job is basically to take care of the all the stuff that either I don’t have time to or he’s just better qualified to do.

You need people who are fans of the genre of game you are making to play test your game, and you need as many as possible. Regardless of what ideas are implemented over the coming months, I’ve determined that they will be play tested to the hilt because to me that’s the only way of guaranteeing that what you have created works and stands a chance of success on the App store.

The games going to change a lot. I’ll talk about what the problems were with the old version and how the new ideas fix them in the next blog post.