★ TouchArcade needs your help. Click here to support us on Patreon.

App development process (how do we differ?)

04-09-2011, 07:10 PM
Joined: Jul 2009
Location: Victoria BC
Posts: 1,170
App development process (how do we differ?)

Here is what we do at iLifeTouch.

Usually I think up the idea,

The team discusses the idea Y/N

Find a suitable name (getting harder everyday)

Do we have an existing better idea that needs to be published before the new idea? Y/N

Our bloodhound ( youngest team member) digs for any relevant information, existing code and competitive apps etc. He is really good at this. If we pass this stage we.....

...go straight to polished graphics ( very odd but this has been great for us)

We pretend the app is already built when we look at the finished app graphics.

We discuss changes to the graphics usually based on simplifying the build and how the elements work together. At this stage we hope to be done playing around with new add-ons.

Fix graphics as discussed.

Then we code the app to fit the graphics. This saves us a tonne of time.

Test and improve.

Test and improve again.

Then submit.

We always update our apps just after they go live. ( Usually we missed something or we screwed up somehow)

We usually juggle 3 apps simultaneously in varying stages of development.

This is how we develop apps. (Team of 4)

04-09-2011, 08:29 PM
Joined: Jun 2009
Location: Hollywood, CA
Posts: 1,869
my approach is rather different, but it's situation-based. I work with different people, on different projects - anyway here's my preferred method.

- lie in my bed thinking "hmm okay what raw idea sounds interesting? what has been interesting before (in gaming) that's been quiet/neglected for decades?" and then "how can such a mechanic be redesigned to take advantage of the unique interface available?" I think it is of chief importance to start fromhere, rather than shoehorn controls/gameplay in afterward. I hate virtual buttons.

- do research. what is already in existence on the app store that approaches my new idea? "if you have a good idea, chances are someone else has thought of it 1st.." Find the similar apps ad see what works/what sucks about them, and how mine can differentiate. Sometimes the gulf between the two ideas is quite large, but there's still territory to mine in there.

- research part II - start nabbing screen grabs/websites pertinent to the new idea. building up reference is key. Moreover, in general - what should this new app look like? what else will it be compared to visually? So many apps get stopped at the door based on their looks. it's good to keep a sharp eye on what "the standards" are

- time to go to Photoshop. Based on what's in my head, I'll stat mocking up what the basic screen will look like. crude graphics, maybe sprite rips from other games just to hold the space/get an idea of size and placement, HUD, and most importantly a very rough overview of how exactly the interface and control will work.

- now it's time to open a .txt file and jot down some notes. This is a nice companion to the mockup screen(s). Basically explaining the rough idea, what the game is about, what kind of (very general) scope it could have, how to control will work, some notes on reference as mentioned above. A very rough outline, short and sweet (maybe a page's worth of info) but enough to sell the gist of the app idea.

- and now, time to really get serious - the first draft of a design doc. This is a natural outgrowth of the original notes, and is essentially the beginning of a living bible for the entire project. This follows a fairly strict format (explaining everything from app overview, all features, modes, art and sound styles, detailed gameplay, and so forth). Even for a small app this could run for a few pages. It's essentially a fleshing-out of the earlier notes, put into detailed composition that any Tom Dick or Harry could pick up and build a full-fledged game out of, if they so desired. This must be impressive and complete in scope, if still missing serious revisions (at 1st) and with some general expectations put into budget and management. I'll likely spend an hour or two writing and refining a 1st draft,get it nice and clean and legible with some screens attached, and then send it out to a programmer for consideration.

- following this, if it is deemed worthwhile to go forward, the programmer and I will hash out some revisions of the DD and once we are both satisfied, I'll create some simple placeholder assets and he'll get moving implementing a proof-of-concept, which (depending on the complexity of the project) should not take very long - likely just a couple of days at most.

- once we have a working prototype in our hands, if it is something that translates well enough from concept to execution, we can go from there to stat putting together a rational schedule for how to go about executing things - probably have a very long meeting or two breaking down all the necessary tasks, how long they would take, rate different elements based on risk vs reward, and so forth. Production will begin in earnest as the raw gameplay is refined and "made fun" while a complete first round of gameplay assets are generated so we can quickly have a working, demonstrable version of the project. A rough interface will exist in rudimentary fashion for awhile as we work on the guts of the game; as that all gets refined, we'll concentrate on the shell. Meanwhile, I'll be working with a SFX persion to help out for the audio design of the game, giving them as much reference as I can for what things should sound like. Early rounds of testing will begin to see how people react to the game (I like to approach strangers in the bar and see how they respond to the WIP). This is one of the quickest and easiest ways to know if you are on the right path, or if you are putting together something that isn't very compelling, too frustrating, or just unintuitive.

- deeper into development, issues likely arise, and we try to keep tabs on things as they come up (always keeping notes). Bug tracking is important and applications like fogbugz is good for that; likewise versioning must be carefully maintained, I tend to be sloppy about it (email makes things too easy) but tortoise SVN is a good solution. I like to keep a comprehensive in/outbox of everything that passes my way, from assets to WAVs to marketing materials, so I can easily dip in and out and see what has changed/where I am at with things, especially useful when time stretches on.

- as the project is maturing, it's very important to monitor bugs, keep a constant list of things yet to implement vs time things will take/how much "unknown X factor" there is, to help trim down the list and keep a good bead on a targeted release date. A slip of a month isn't bad, but 3 months is unpleasant and 6 months is fairly disastrous (to the point where you might as well scrap the entire project if it's getting that far out, especially in this volatile scene). Mobile games, especially when developed by small teams, really should not require more than a couple of months of dedicated development time.

- further and heavier testing and refinement, the game is shaping up and should have a fairly solid presentation at this point. UI is still shaping up, but the meat and nuance should be quite solid ad a tutorial mode should be complete if not nearly so. Marketing efforts need to begin: develop a website, blog about the project, release some teaser information, maybe get some forum threads going and some Facebook/twitter activities. Any decent press connections should be contacted if your game is "AWESOME LOOKING," otherwise they can wait until later because they won't care. As you are a couple of weeks from release, it's good to push hard on beta testers (get a lot of them) and just get your name out there and your game's name as well. Start some promoting, whatever your preferred methods are (spending money or not) - but do SOMETHING.

- Is it ready? Enough features in? Shelve the half-finished stuff that'll take another 2 wees to work on and leave that for an update. Tighten up the in-game presentation as much as possible and go super-nuts designing your marketing materials. Screenshots, description, keyword searches, etc. Pump your threads and connections a bit more, dig into your contact pools and make sure people know what is going on. Launching an app is like firing a cannon: put everything behind it all at once, or it won't have enough juice to go far enough.

- Once it's all in place, submit and cross your fingers. You'll likely be in the middle of the previous step when you submit to Apple, which is fine - anyway when you get that magic email, send it out into the world. BAM. Fire off a press release to ALL your media contacts. Follow form, keep it short and clean, attach a PR kit to it (use a bitly link) with screens and URLs. Give the higher-ranking guys a promocode or two, don't ask if they want one or expect them to look at a free version, because they won't. You'll quickly burn through your 50 free codes on media alone, so make sure you get a good stock of gift codes for your app as well. Seriously. Shoot your press release to someone like prmac.com as well and they will hit some sources which will otherwise ignore you. You can expect to spend several hours running down a list of contacts and sending proper information to everyone. Don't forget to make some noise in your forum threads as well, and hopefully you can get a little organic buzz going as well. Also remember to push your email contacts (fans, etc) and twitter and facebook connections.

- sit there and stew it a little

- go out and have a beer, pass out after you get 3/4 of the way through the 3nd one since you've not slept in three days. Ahhh, the life of the indie developer.

04-11-2011, 08:14 AM
1. Sketch how the app would look like in my notebook (my notebook is like a sketch pad, with no lines, so I can draw there nicely).

2. Do the flow chart and finalize features (of course features will always be changed throughout the making).

3. Start coding with plain controls / graphics.

4. Debug debug, test test, debug debug.

5. Happy with operation -> Start graphics design.

6. Done -> Polish as much as I can.

7. Final Test test test test test x100 times.

8. Publish.

All me, one man show.
04-11-2011, 10:41 AM
1. I come up with an idea
2. Talk to my partner to flesh it out
3. Get the rules/gameplay set
4. He designs the look/feel of the app
5. I critique
6. See that everything matches up and will work well
7. Spend 7 months trying to figure out how to program the app since he's not an actual programmer (we're looking for collaborators!!)
8. Finalize app
9. Release, for victory
04-11-2011, 11:07 AM
Joined: Mar 2011
Location: In a car
Posts: 324
Interesting thread, i have a question that has been on my mind for a while but havent find an answer yet!our process is the same , we are two guys, i am the developer am my partner is a graphic designer!my question is, when there are several developers how do you assign each ones job, and coding wise do you settle on the same vars, class names etc so later one of you puts the code together?i am thinking of expanding and have no clue how this works!thanks a lot!

My Twitter:@Tudor

Last edited by MrLeQuack; 04-11-2011 at 11:11 AM.
04-11-2011, 11:50 AM
Joined: Mar 2009
Location: Oslo, Norway
Posts: 731
  1. Go through my head to see if I can come up with a new idea.
  2. If not, find one from my notes
  3. Contemplating about the idea, thoughts about complexity, design etc.
  4. Veer off in a completely different direction going with another idea
  5. Prototyping this new idea
  6. Discover that it sucks
  7. Sulk for a day
  8. Go back to point 3
  9. Prototype that idea.
  10. If it seems to work: Make a melodramatic cry to the world "Why didn't I do this to begin with???" If it doesn't seem to work go back to point 1.
  11. Refine whatever idea I ended up prototyping.
  12. Starting to get confused over which idea I actually decided to go with.
  13. Becoming distracted with some new fresh idea.
  14. Making a note of the new idea in Evernote to be use it for a future point 2.
  15. Finally deciding on a look and feel
  16. Sending out a way too premature beta
  17. Trying to lock down the feature-set.
  18. Failing at locking down the feature set (just one more thing).
  19. Fighting myself. Staying on course, refine, refine, refine
  20. The really hard bit, the final couple of weeks, getting rid of kinks smoothing everything as much as possible
  21. Desperately wanting to do something else, but battling it out.
  22. More of point 21
  23. Starting to think seriously about marketing
  24. Sending out final beta
  25. Getting it back with loads of error-reports
  26. Banging my head against the wall
  27. Sending out another "final" beta
  28. Biting my nails
  29. Sending the app of the Apple
  30. Starting to work really hard with the PR-stuff for real
04-11-2011, 12:05 PM
Joined: Oct 2009
Location: Melbourne
Posts: 250
I make games by myself.. starting a project is fun. Finishing it is hard work. Overall it's like a compulsion... my process, so far, has been like:

1) feel a strong need to make something
2) start off by messing around randomly, trying to put into practice whatever code techniques i've been reading about lately which have interested me
3) if it works, think up what kind of game i could turn it into
4) implement the basic gameplay (i make graphics and audio as i write the code which needs it)
5) play it lots and write lots of notes on ideas of stuff to add
6) implement that stuff. tweak what's already there.
7) loop steps 5 and 6 until the game feels good
8) occasinally ruthlessly scrap massive chunks of the gameplay if i don't think they're working - and sometimes add completely new mechanics which change the game entirely. (the key in my game Forget-Me-Not came about like this - originally there was no door & key... when I added that mechanic I knew the game was heading in the right direction)
9) suddenly realise i've forgotten to add menus, game over screens, etc, and grumpily implement all that stuff
10) send to friends to test.. more tweaking... release!

..so basically I don't plan much out at the start, I just make a general idea and then let it grow randomly until I like it..

Very interesting thread idea! I never really tried to put my game making process into words before..
04-11-2011, 02:02 PM
Here is a glimpse into our game development cycle (I posted a bit more detail on this on our blog here):
  1. To start off developing a game we brainstorm until we find a concept that all three of us agree on and would like to play in hopes that if all three of us can get excited about a game idea, it will excite a large group of others.
  2. We determine the market viability of the idea, how we would monetize it, and how hard it would be to develop
  3. Then we go into game design mode and write up a full description of the game and explore/discuss all aspects of the game play
  4. We boil that down into the basic concepts that will make it ‘fun’ and we create a working proof-of-concept to test it out and see if we can pull it off. The idea being that a game should be fun at its core even without fancy graphics and polish.
  5. If the game passes the proof-of-concept phase, we get fully mobilized and hire an artist and start producing the finished graphics and framework.
  6. Our developer lays out a detailed release outline detailing what features will be added when, and we extensively test and debug each release as it comes out.
  7. More and more features start to creep in, Chris gets exasperated at our never ending fountain of ideas, and we all take a step back, discard most of the fancy ideas, and reorient ourselves to making a simple fun game based on the core principles that were in the POC.
  8. Polish is applied gradually as we complete various aspects of the game, we try and polish up each piece of the game before we move onto the next piece so we see the finished product as we go and keep the excitement alive.
  9. We share our successes and our setbacks with each other as we go and we provide the moral/practical support needed to keep each member stoked about the game.
  10. We also try and keep deadlines and pressure to a minimum as we go, while still working as hard and as fast as our schedules will allow. This keeps the development fun and easy going and nobody gets stressed out.
  11. After many months of hard work and elbow grease, we release a game that we are proud to put our names on, that is unique and fun, and that ‘hopefully’ will appeal to a large variety of gamers.
  12. Rinse. Wash. Repeat.