Jump to content
  • Advertisement

LordYabo

Member
  • Content Count

    1
  • Joined

  • Last visited

Community Reputation

867 Good

About LordYabo

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. LordYabo

    Inside the Indie Art Process of Archmage Rises

    Hello,   So first off a clarification, these aren't concept drawings.  They are actual game art.  Since it is final product in the game, I can afford for it to be good.   Now about "prohibitive for an indie developer" it all depends on what budget you are working at.  The term "indie" is used to describe a whole host of devs.  I was listening to an indie haven podcast and the female game developer guest said "Steam charges $100 to be on their store!  I can't afford that!  That's insane!"   If that woman has a computer, a roof over her head, and internet, she DOES have $100.  Maybe she is spending it on something else right now, but all that says is that the something else is more important than her game dev career.   What I don't understand is how an indie will pour months or years into their project, and then balk at paying $5,000+ in art.  To have invested sooooooo much and then stop at the last 1-2% is like buying a car and then leaving it in the driveway because you refuse to pay for the fuel.   Money is congealed life.  We trade our time for money, but we also trade our money for time.  I could spend 3 hours cleaning my house, or I can hire a maid to do it for $60.  I'm out $60 but I just gained back 3 hours I can focus on my game or something else.   This is what I've learned in life: an expert can always do something faster AND better than an amateur.  So let's say I, who am not an artist, is going to do the art for my game.  Well I suck at it, so I'm going to spend a month of my time doing the above picture and it will look horrible.  Now did that cost me money?  YES!  Even though I didn't pay someone $$$ to draw, I still paid me.  How did I pay me?  Well in rent, food, living expenses.  If my monthly expenses are $1,000 then I just paid me $1,000 and used up a month of time to make a crappy picture.  Better to get a real artist to do it in 4 days.   The other option many indies pursue is partnering for a stake.  The team works for a % of profits when the game ships and sells.  This way no $$$ has to change hands, and you only have to pay if there is actual profit.  The downside of this is finding people who are willing to do this.  The really talented people have no problem finding paying work, so they would have to be really impressed with your project for them to forgo paying work to work on your project.  The second is that people who are not yet talented enough (or haven't figured out how to get paying work) are the ones most likely to take a deal like this.  That could mean you aren't getting the best work you could and could be a competitive set back.   I'm currently working and using the pay from my job to pay my artist expenses.  My wife and I are living on less because we are pursuing the dream of the game.  It is that important to us.  I can't think of anything being more "indie" than that, and it is totally within reason for me as an indie developer.
  2. LordYabo

    Inside the Indie Art Process of Archmage Rises

    Riuthamus I would like to make articles that are easy to read.  Can you give me examples of what made it hard to follow?  Can you give me suggestions on how you think it could have been easier?
  3. LordYabo

    Looting Game Design Gold from *Sid Meier's Pirates!*

    I'd play it!  I agree that does sound like an interesting setting.
  4. [font=arial]"Good artists copy, great artists steal." - Pablo Picasso[/font] [font=arial]Sid Meier's Pirates![/font][font=arial] is arguably the most important game ever made . . . and it also ruined my week. You see, I'm working on [/font][font=arial]Archmage Rises[/font][font=arial]--[/font][font=arial]and part of my elevator pitch is, "It's like Pirates! but with mages and permadeath."[/font] [font=arial]"Live the Life" is exactly what this Pirate simulator delivers![/font] [font=arial]Pirates![/font][font=arial] and I have known each other a long time. It's been 27 years since I slipped my 360 KB 5.25" floppy into my Tandy 1000 and "Lived the Life." Having not played it for a while, just this Sunday I fired up the 2004 edition to see what it could teach me. (I grew up in a culture that didn't watch TV on Sunday, so I revel in the freedom of being a pirate on the Lord's Day!) The 2004 edition by Firaxis is a great example of how an old game's inner beauty can be recast for a modern audience. If you've played the 2004 version, you've basically played the '87 version--and vice versa. [/font] [font=arial]What I learned this week is valuable to me, and hopefully to you:[/font] [font=arial]Like any creative project, a game design/concept is born in a lucid moment of inspiration. I can literally see the game I want to make before I've touched a keyboard. But like a ship on the open seas with wind and waves, the game development process includes drift. Programming, art choices, new features, all the little decisions along the way potentially introduce drift one away from the core concept of the game. And I'm one guy! I can't imagine how AAA teams do it with dozens (or hundreds!) of talented developers.[/font] [font=arial]So as I sailed the Caribbean as a Dutchman in a War Sloop, I was confronted in stark contrast with how much drift has already occurred in Archmage Rises. I'm disappointed in some of the course corrections I need to make, but I'm happy overall with the experience.[/font] [font=arial]Like Neo, Sid showed us the way toward true open world design[/font] [font=arial]I glibly wrote that Pirates! could be the most important game ever made. It is something a game developer friend said to me this week--and at first, I felt this was a ridiculous thought. Later on, I realized he may be right after all![/font] [font=arial]Pirates[/font] is one of the world's first open world games and yet a mashup of four different types of games. I hear many people pay tribute to Grand Theft Auto III as the "first" open world game--but for all of Rockstar's inventiveness, they've got nothing on Pirates. Let me explain why: [font=arial]Gold Chest #1: Living World[/font] [font=arial]Each town has a simulated economy and garrison. The brief text immediately tells you the towns status.[/font] [font=arial]The game world of Pirates! is alive and hums along with or without your involvement. A whole Caribbean economy is simulated under the hood. European powers go to war with one another. Towns grow or decrease in prosperity. Raiders or invasion forces decimate towns. Towns change hands through simulated battles. Governors get replaced bringing economic prosperity. Famous pirates (NPCs) travel the world, causing havoc. From the same starting point, no two games are the same.[/font] [font=arial]One specific example: Should a trade ship traveling from San Juan to St. Kitts arrive, both the sending port and receiving port get a small economic boost. If the ship is lost at sea (or to you), they both suffer that loss. The economic prosperity of the towns determines how much money they have to buy your goods, and which items are available for sale/trade. [/font] [font=arial]There are no neutral actions you can take in the sandbox. Whatever you do, the world will change accordingly.[/font] [font=arial]Gold Chest #2: Emergent Behavior[/font] [font=arial]Who told those French raiders to attack that town? The living world.[/font] [font=arial]Pirates![/font][font=arial] has a few very simple rules at play. But it has the right rules--so with all the simulated agents, you have the right ingredients for emergent behavior. [/font] [font=arial]I was merrily sailing along and saw not one, but two separate French raiders sally up to a Spanish town and let loose their canons. No one, from me to the developers, could have predicted that two raiders sent from different towns would happen to attack the same town at the same time just as I was sailing by.[/font] [font=arial]Similarly, I decided I wanted to attack a particular ship--but by the time I got there, it was close to town. So my sea battle became a land and sea battle--all because of the timing of when that ship left its port. Our paths converged, and I had to deal with the consequences.[/font] [font=arial]Gold Chest #3: Permanent Presence[/font] [font=arial]This is my story. There are many like it, but this one is mine.[/font] [font=arial]As you loot ships, the economies of the towns are impacted. If you favor one European power, it will dominate your version of the Caribbean. You can help towns permanently change hands from one nation to another by sacking the town or sinking reinforcement troop ships. Each action has a lasting consequence and a profound feeling of "I did that!"[/font] [font=arial]Presence[/font][font=arial] is reinforced through the map/log. It shows where and when every one of your actions took place in the world. This is your story in the Caribbean; it is personal. This is what keeps me coming back over and over again.[/font] [font=arial]Gold Chest #4: Different Strokes[/font] [font=arial]Given you can only play as a pirate, the game has a wide variety of play styles within a seemingly confining genre.[/font] [font=arial]First, if you are more action-oriented, you can make money by looting ships and entering sword fights against ship captains. But if you are more merchant-minded, you can amass a large fleet of trade galleons and become a merchant trader of sorts sailing from smaller producing towns to larger consuming towns. In a small way, it has a bit of Railroad Tycoon in here. :-)[/font] [font=arial]Every ship in the game can be captured and controlled by you. So you can play a small fast raider in a 12 gun sloop, or a massive lumbering 48 gun Frigate. The battle tactics are entirely different.[/font] [font=arial]You can staunchly play for King and Country of your starting European power. Or a heartless, opportunist smuggler playing all sides against each other. And anything in between.[/font] [font=arial]Get estates and get married to a governor's daughter. Even do it multiple times! It's one of the only games I know of that allows polygamy.[/font] [font=arial]Gold Chest #5: Procedurally-Generated Quests[/font] [font=arial]I'm hunting me some buried treasure![/font] [font=arial]The living game world is fully utilized as the game generates quests based on current conditions. [/font] [font=arial]A barmaid whispers of a certain treasure laden ship traveling to a nearby island. Or a governor asks you to escort a new governor to his destination. A traveller is willing to sell a treasure map to buried treasure. [/font] [font=arial]While I suppose these can become eventually repetitive, I find them far more engaging than Destiny's quests. Probably because if I do successfully escort that governor, the world permanently changes. In Destiny, the Vex will still be there the next time I shoot them--and the next, and the next after that.[/font] [font=arial]Gold Chest #6: Emergent Story[/font] [font=arial]Am I the kind of pirate to hunt down and assassinate other pirates? It's up to me![/font] [font=arial]The 2004 version of Pirates! has a story of recovering/avenging your kidnapped family. You can complete this or completely ignore it. [/font] [font=arial]I'm more interested in the stories I make myself. :-) I play as a Dutchman with a score to settle with the Spanish. Sometimes I'm the scourge of the north, or the south. Sometimes I'll pick on a town barricading it from all outside shipments, or spread my reign of terror evenly.[/font] [font=arial]The game's simple rules and living world allow me to make up my own stories and play them out to my heart's content. This is where people smarter than me have identified it as moving from "game" to "software toy." This seems to be a common thread in Sid's games, and why they stand the test of time.[/font] [font=arial]You can also play Pirates! on pretty much anything, which is awesome. If you haven't played this gem, you are in luck![/font] [font=arial]Pirates![/font][font=arial] is available on just about everything except WonderSwan:[/font] [font=arial]iPad, iPhone, Windows Phone, Windows XP+, Xbox 360, Xbox, Wii, PSP, Windows 3.x, Sega Genesis, Amiga/CD32, Apple II/IIGS, Atari ST, NES, Commodore 64, Dos, Macintosh, Amstrad CPC, NEC PC-9801[/font] [font=arial]Steal Good. Copy Bad[/font] [font=arial]What was Picasso talking about, really? He was referring to internalizing the concept or style of a work of art, not merely copying it. It's the difference between a photocopy and a memory. In programming, we have a similar idea in the form of shallow copy versus deep copy. [/font] [font=arial]So what do I mean when I say I'm making Pirates! with mages? [/font] [font=arial]I do not mean having a 3D map with a mage running around attacking merchant caravans to impress governors and marry their daughters. To me, that would be a shallow copy.[/font] [font=arial]I am implementing the six gold chests of design above in spirit. Most of my effort is focused on creating a plausible, living and breathing fantasy RPG world. One where nobles (my equivalent of governors) have personalities and ambitions. They procedurally generate quests based on what is happening in their territory and with their neighbors. You as the player decide which nobles you want to side with and which ones you want to use to test your new Fire Rain spell on. I'm taking what Sid did and going further with it. You have a home base (your mage tower)--and based on your fame (or infamy), nobles will send out raiding parties against you! So being naughty (or nice) has a lot to do with your personal security. This is one way the player will feel presence and permanence in the game world. Ultimately, I want to give players the ability to tell their own story. This, I hope, is what makes my game successful and keeps people returning for more. [/font] [font=arial]In short, I'm stealing. In the best sense of the word :-)[/font] [font=arial]SDG[/font] (Cross posted from my personal game dev blog.) [font=arial]You can follow the game I'm working on, [/font][font=arial]Archmage Rises[/font][font=arial], by joining the [/font][font=arial]newsletter[/font][font=arial] or chatting with me about it on the [/font][font=arial]Facebook page[/font][font=arial]. You can tweet me [/font][font=arial]@LordYabo[/font]
  5. Oh the irony... My wife downloaded the free version to her iPad last night and started playing it on the couch. She played it longer than she ever played the pay one. Booooooooooooooooo!
  6. LordYabo

    Behind the Scenes of Catch the Monkey

    Behind the scenes screenshots during the development of Catch the Monkey
  7. Intro I'm Thomas Henshell (LordYabo), co-designer and programmer of Catch the Monkey. I work at an indie mobile game shop in Burlington, ON called Mirthwerx. In a previous article we talked about how we took Catch the Monkey from ideation to deployment and marketing in the app store. This article is about how we made a free version to advertise Catch the Monkey and our brand. A Bad Demo Example Making a free version (lite, express, demo, whatever you want to call it) is not as simple as it first seems. I remember when I downloaded the demo to Dead Space for my PS3. I hated Dead Space because of the demo. Sure it had great graphics and concepts, but the interface was confusing, the weapons made no sense to me, my motivation in the level wasn't clear, and I spent the whole time either stuck or constantly dying. I never wanted to play Dead Space again. Not for free and certainly not for money. It just so happened that Dead Space got an amazing review on Gamespot and the price point went below $20, so I irrationally took a chance on it. I don't like survival horror games in general, but this one was so well done I really enjoyed it. So here's the issue: A bad free game can prevent people from finding out about your good paid game! Are you advertising a Game or a Brand? During the core testing phase, I happened upon a video presentation by fellow game designer Matt Rix for his game Trainyard. In the video, Matt makes a key point about free versions of games: Don't make crippleware, make a GOOD free game that stands on its own. When I heard this, I knew he was right. If people like your free game, they will want to buy your pay game. I don't mean this in the sense of Doom where after 10 levels you want to play the next 20, that is obvious. There is something more subtle going on here that has to do with building your brand, not just pushing a widget. What I mean is if you give someone something free, they appreciate you (it's like a present) and then they are intrigued to see what else you have. There is even a sense of an honour system like with albums that say "pay us what you think it is worth". For the indie developer, these are all things we need to build the brand! With this direction we started brainstorming what our free version would be. The Free Features The first order of business is to determine what to give away and what to keep only in the pay. Of course, we fired up XMind and whiteboarded until we settled on a few things. Obviously when you make a free version, you are working from the assets (art/code base) of the pay version. So this will limit what you can and cannot do in your free one, unless you really want to start the whole development cycle again. We determined the following principles: Don't do anything that would make the people who bought the paid version regret their purchase. The free version should complement the pay one, and theoretically co-exist side by side on the player's device. Don't do anything that would make a person regret buying the paid version AFTER playing the free version. I recently had a negative experience with an iPad game where I played 12 levels of the demo, bought it, and then had to play through those same identical 12 levels. I regretted buying it, and I did not want to spend hours redoing my previous progress. I didn't bother to play the pay version. (InApp purchase obviously solves this.) Give the free player the same experience as the pay game. For us, it is: to tickle and play with cute monkeys Give the free player a different goal and experience than the pay one. Something they can achieve in the free one. When it comes to advertising, always put your best foot forward. The illustration I will give will sound ridiculous, but it was a real debate. The banana animation is not as cute as the ducky animation. We needed a "pickup toy" in the free version and had to decide between the two. We wanted to save the ducky animation for the paid version, but decided if we are making a billboard ad we should put our best work on it. A free customer is less invested in your title, therefore they need a quicker more streamlined experience. Given the above, we decided the following: Remove the store, tool select, and star power management features. This makes the game faster and simpler to play Remove the catching of stars, as there is nothing to save up and purchase Oops! Catching stars is fun and breaks up the game rhythm, so put them back in but for a different purpose Give the player 10 plants at the start. See how many waves of monkeys they can fend off before losing them all. This is an entirely different goal and play style than the paid game. Give them 4 of the 10 tools. This holds back a majority of the paid game, yet still lets them get a similar experience. Create colored stars that give you a special ability like raining down gum from the heavens. This all sounded good to us, especially the protectionism of defending your plants across wave after wave (I can't think of any popular game that has that feature J). Unfortunately we had to create some new functionality, but it was so good that we went and added that to the main game as a bonus update for those who already bought the main game. The tools we chose to include in the free version are not the tools you sequentially get in the paid one, we spread them out. This way if you play the free version for a while then play the pay one, you don't feel like you are wasting your time as you go through the first set of levels. All in we estimated it would take a day to build and test the free version. It ended up being 20hrs. We once again proved we suck at estimating testing duration. J While adding the new colored star powers to the main game, we thought about adding the endless wave mode to it as well. That would be significant work (we can't just cut & paste it in) so for scheduling reasons we decided customers can just download the free version if they want to play endless mode. The Result I'm loathe to reveal this, but these two results are so ironic and funny I'll share it just with you if you promise not to tell anyone. [indent=1]1) Some people when play testing PREFER the free version over the paid version. Totally not our goal, but we're happy people like it! [indent=1]2) The free version is closer to the initial vision of what Catch the Monkey should be. With the pay version of Catch the Monkey complete, and using that as a palette, we were able to make a tighter more streamlined version. I'm not saying this is a rule (though it could be, I only have one experience thus far), but sometimes you need to build in order to know how and what to cut. On the whiteboard everything seems better than it really is. We (the development team) still prefer the paid game to the free one. The pay one has more depth and strategy to it, so we prefer it. But check it out for yourself and post a comment here or on our blog or tweet us at @Mirthwerx which one you prefer. We're almost done the android version. So our next article will discuss the issues involved with making an android version. To know immediately when the next article is available join our twitter feed @Mirthwerx or on facebook.
  8. LordYabo

    How we Built an iOS game on PC

    [quote name='davepermen' timestamp='1332951368'] Great article indeed. You stated that the tools allow you to develop for wp7, too? I'd love to see this game on my Lumia. [/quote] While the tools allow us to deploy anywhere, the hardware requirements do not. CtM is so chock full of animation that we aren't able to bring it to many other devices. We couldn't get the android tablet version to run on the asus transformer, but we could get it to run on the playbook. It has to do with how the OS/Device allocates memory and our way of utilizing it.
  9. [quote name='nikos_' timestamp='1333635268'] Hi LordYado, that sounds really really useful! Where is the 'build config file' and where/how exactly you "plug the ID number" to it? thanks Nikos [/quote] I'm not sure what you are referring to. In Marmalade there is an MKB file which holds all your special values, such as your code signing file, or author id, etc.
  10. [quote name='Looka' timestamp='1333537580'] Great posts, thanks! So what was the total time between comming up with the idea of a game to the first copy sold? [/quote] Our scheduling was very sporadic across 2 years. Total full-time build time was: 2 months initial build 5 months testing, polishing, fixing, deploying about 3 months of artwork
  11. [quote name='talf' timestamp='1330214952'] Thanks for these interesting tutorials! There's lots of information here!! :)Would it be too much to ask you the [left]review site you found and sent your app?[/left] [/quote] It took us a while to compile that list especially all the email addresses we collected. We're still working on it so at this point I don't feel it is something to share. I explained how I went about getting the list so hopefully that helps.
  12. [quote name='Nessa' timestamp='1329978328'] MIT game desing opencourseware link is broken and how much have you done cowboys? btw good job [/quote] Thanks, i fixed the OCW link. Eventually I'll learn how to cut and paste!
  13. Hurray, we made a sale! Thanks for your interest in the article series and whomever voted 5 stars for it. :-)
  14. This series chronicles Catch the Monkey from ideation to sale worldwide in the App Store. You can read other articles in this series here: Part 1: Design & Prototyping Part 2: Building the Core Part 3: Balancing & Polishing You can find out more about Mirthwerx and our projects at our website. Intro We had a game! Hurray! It worked, it played well, it has a beginning, middle, and ending. We were ready to get the sucker out the door. But before release, we had to go through the final stage of development: testing. Wow, what an eye opener! No one Knows How to Play Your Game, and They Don't Care to Learn! I submit I may be the strangest person alive. I grew up in the 80's and early 90's. This is where many of my early gaming habits formed. Back then when I bought a new computer game, such as Civilization, Ultima, or Wing Commander, I would sit down and read the entire manual cover to cover before attempting to play the game. And this was when manuals were works of art: the civilization manual was over 100 pages and filled with fascinating sidebar historical facts. I continued this practice, though I've stopped now that the manuals are nothing more than epilepsy warnings and telling me where the square button is on my controller. (Fortunately board games still have amazing manuals, so I can enjoy those ) The good old days when games were hard and manuals were thicker than your arm! Apparently no one else read manuals so the gaming industry moved away from them altogether. Players want to play, not learn how to play. I sort of knew this, I read about it in game design books, but I didn't have the experiential knowledge of it. It quickly came. At our pre-release party (unfortunately 3 months before the actual release, but who's counting) we had several iOS devices with a 4 level demo version of Catch the Monkey installed on them for people to play. We watched people pick up the game and play it for the first time. We learned two things: people enjoyed playing with the monkeys, but they had no clue how to do it. So while they had fun, they were frustrated not knowing how to use the various tools. It seems obvious as I write this, but we discovered our need for tutorials built into the game. All I can say is that when you work on something closely for 2 years you lose track of what is "intuitive" and what isn't. Observe strangers and reality will come crashing in. So, we used our character dialog system to retrofit in a tutorial system. First Iteration of Tutorials. Nobody reads em. Weeks before release, we tested with a focus group of teenage girls (our demographic) to see how they enjoyed the game. I squirmed in my seat as I watched them tap "next, next, next" and completely bypass the tutorial to get on to the game. Once there, they didn't know how to use certain features, started losing, and became frustrated. Final version of tutorials. If you can't follow that, there's no helping you!!! We learned valuable lessons as we went through three iterations of tutorials: People assume they already know how to play your game. I can't for the life of me figure out why they come with this belief, but they do. Work with it, not against it. People don't want to learn (because of the above), they want to play. So teach them one basic thing and set them off playing When teaching, we observed the average player's patience is two: Two screens of slides, two steps of interaction, two dialog boxes, then they don't care anymore and want to skip forward After playing, people want to learn. There is a correlation between how long they play and how interested they are in learning to play. In the first 2 minutes, they have 0% interest, at 5 minutes they have 10% interest, at 10 minutes they have 50% interest. You have to space your lessons appropriately Remove all flowery "in character" text from the tutorial, they want to learn as quickly and efficiently as possible and could care less if a character starts each sentence with "" They don't want to read, they want to do. Make the tutorial visual and interactive Pre-plan your tutorials into the main story/progression of the game. Don't do what we did and try to retrofit it in, it was a lot of work after the fact Testing with Testflight As previously mentioned, iOS locks down the devices to which you can install a binary. This requires the unique UDID of each device, registering it through the apple portal, including the provisioning profile at compile time into the binary, and then copying a provisioning profile to the device through iTunes (which provides zero feedback if it was done successfully) and finally copying the binary to the device through iTunes. I can't think of a process more antithetical to the apple "it just works" mantra. So, you can do all that OR you can use testflightapp.com. Testflight for build distribution during testing; epic win! With testflight, you send testers (family, friends, enemies) an email link and they go to it on their device. Testflight takes care of finding the device UDID, os version, make/model of device, and sending it to you the developer, installing the provisioning certificate. As a developer, all you need to do is register the device id to your binary. Now you can upload a build (with release notes) to testflight, and everyone you autohrize is sent an email a link to download it. It bypasses all the silly itunes file copying. Testflight's reporting allows you to see who has what installed. Valuable when they start reporting problems as you can definitively say "Oh, that's because you're on a build that was so yesterday! That build was terrible! Install the NEW build, it's wonderful." Testing with Non-Gamers Would you rather know about an issue during development, or once it's released? Of course during development! Testing with people who play similar games as the one you are making is very helpful. You can be sure you are meeting your demographics' demands and they can often make suggestions or give articulate feedback on issues as they have a frame of reference. However, we found great value in testing with people who have never ever played an electronic game in their life. You know who I'm talking about: your mother-in-law whose only game experience is yahtzee on the dining room table; the friend who didn't know brick breaker was pre-installed on his blackberry. The official term is blackbox testing. These people can confirm if your tutorials work, but more importantly they do things you never in a million years would do. But make sure you watch them closely, they won't be able to tell you what they did or did not do. Here is an example: We finished our final bug free never crashes build Dec 15. Over the Christmas holidays I showed a non-gamer friend the finished game. Within 2 minutes of playing he crashed it. How? He never once lifted his finger from the screen. If you recall from part 3 about our gesture system, it tracks the current finger position every 50ms. Well if the player never ever lifts their finger from the screen, it becomes one giant gesture of 2,400 points after 2 minutes (affecting performance). Even worse, the initial target object of the gesture may be destroyed while waiting for the gesture to finish, resulting in a NULL reference and therefore a crash. It was relatively easy to replicate and fix once I saw what he did, but I have to admit I never imagined someone not lifting their finger! How Do You Know When You are Done Testing? This may seem like a silly question, especially coming from a business software background. In business software you would already have all your test cases written before hand (Right?) and execute them. When they all pass, you know you are good to release. Typically we would then get the customer to test the application in a pilot project, and that is the "real world" test. If it's good, we release. Well in games, it's different. There is no "customer" to sign off and take responsibility that the application is good, you just have to decide at some point: it's done. Release too early, and the game will crash or misbehave for customers. Release too late, and you've squandered valuable effort that could have gone into another title. I was listening to the MIT Open Courseware on Game Design and they asked this very question: how do you know testing is done? Their answer: When you are out of time. When you can't take another step forward, you might be done testing. That seemed like a cheeky answer, but having now lived it, I agree. Now, of course, we made certain all features worked, it was as fun as we could make it, and it didn't crash. (Of course now as I write this we've heard reports of a bug in one of our tutorials, oops!). The game will never be perfect, there is always more to add, more to test. There comes a point where you have to draw a line in the sand and ship it. For perfectionists, this is a very difficult thing to do. I am fortunate that I'm not working solo on this project, both the artist and I together were able to agree the game was ready to go out. That gave me confidence I wasn't deluding myself or just fed up. J For those soloing it, I recommend you ask a friend to be your "quality control" and help give you the thumbs up for releasing. Judging the Difficulty I read in the book Level Up: Guide to Great Game Design that the game makers are the worst people for judging the difficulty. So, I knew this going in, but it is still difficult in practice. Obviously the first people that need to be happy are the ones making the game, that is your first quality control gate. We also tested on young children (3, 8, and 9). Why? Because they'll test for free all day long and they have nothing better to do. (And they are the artist's children). We found that young kids love to play Catch the Monkey, but the mid game was too hard for them. So thinking this was a secondary market, we created an Easy mode that gives the player more energy and reduces the maximum number of monkeys in the field at a single time. The kids loved the easy mode and were able to finish the game, so we were happy. Later, when doing focus group testing, two of the teenage girls couldn't get past a certain level and were getting frustrated. We recommended they restart the game in easy mode. As soon as they started playing in easy mode they said "Oh wow, this is much more fun." At this point we had a dilemma: do we make easy mode normal mode, and normal mode hard mode? We did and made all the code changes to reflect this. Then, a few days later, we fixed a bug in the Level GM AI and found it was working much better than previously. So we flipped it all back to Easy and Normal rather than Normal and Hard. Big mistake. Now that we have released and friends/family have been buying it, the most common complaint we hear from casual gamers is that it is too hard. When we tell them through facebook to try it on easy mode, they always come back with "Oh wow, this is much more fun." Even post release we're still learning things the hard way! Here are the key lessons we've learned: Make the game too easy, rather than too hard. Too easy can still be enjoyable, too hard never is. Casual gamers are not looking for a challenge, they are looking to pass the time. Easy fits within this expectation. Don't make the game hard with the ability for the player to opt into easy. Make it easy with the ability to opt into hard. Releasing to the App Store After making it through the arduous testing phase, we were ready to release this sucker. This has several steps: [indent=1]1) Making a build signed for App Store, as opposed to ad-hoc provisioning build [indent=1]2) Uploading the binary to Apple [indent=1]3) Waiting for approval It was time to fire up Visual Studio one last time and create an app store build. It was relatively easy to do, I simply copied the deployment options from my test flight build in Marmalade and off I went. Now here's the thing: you cannot test your app store build before you upload it. Why? Because it can only be installed on a device through the app store. So better get it right! And we didn't. iTunes Connect is how you control your app in the app store I made two blunders when doing the final build. The first was somehow I didn't copy the proper icon image settings from the internal build to the final build, so it went to the app store with the default app icon. Doh! The second was far, far worse. We knew our game didn't work on anything below iPhone 3GS or iPod 3. I saw other games show this requirement in the app store along the left column. I didn't see any way to set this through marmalade deployment, so I assumed it was done in the app store itself. Well when you upload an app, especially your first, iTunes Connect walks you through a wizard. The answers you provide can never be changed, you got one shot to do it right. These we did right. Again, I didn't see anywhere I could set the requirements, so I figured it was after I uploaded the binary. I uploaded the binary and it went into the queue for review and approval. Well, 8 days later, it was approved. But still no way to set the system requirements. It wasn't until later that I found out you need to modify the plist.info file to include the OpenGL ES version to 2.0 to target the devices we wanted. No biggie, I modified the plist.info file and proceeded to upload the new binary. ERROR! Apple does not allow a developer to set more narrow restrictions on an application update than the app first had. So in short: if your initial version says it will run on iPod 2, you can't later do an update that makes it no longer run on iPod 2. We screwed up the one thing you cannot correct through an app update. After much back and forth with apple support we had to resort to putting the requirement right into the app description. We already know people don't read, but it's the best we can do at this point. And one final thing to know about releasing to the app store when you make your app on a PC: you REQUIRE a mac to upload the binary to apple. ITunes Connect used to allow you to upload through http, but no longer. There is a binary uploader program in the iOS SDK that checks and uploads your binary to apple. That uploader program only works on a mac. So while you can build and test the entire app on a PC, you need a mac for 10 minutes to upload your final binary. I've seen someone suggest just going to an apple store and using a demo mac to upload. In my case I already had the mac mini, so it wasn't terribly inconvenient, but it was a real surprise. Releasing to the World By default, all apps uploaded to apple are released to every itunes store in the world, unless you specifically turn a store off. There be a lot of iTunes Stores. Fortunately you only need 6 translations to cover them all. We had always intended to release to multiple countries, so we tried to minimize the amount of text in game and use symbols where we could (the monkey story sequences use icons rather than text for this reason, although it actually made more sense conceptually too: how do you write "monkey speak" anyway?!). The key is to get your app description translated from your native language into the various app store languages. It costs about $100 per language to use a translation service to translate our app description. Of course, the difficulty is we have no way to judge how good the translation is! Initial Marketing As I write this fourth part, our game has been out in the world for 22 days. Sales haven't skyrocketed, so we're in no position to advise on how to market a game. However, there are two things we can share. First, Apple controls the app store. They make their decisions based on volume. The sections like "What's Hot" and "New and Noteworthy" are driven by volume. The more volume you can drive in the initial days, the more likely you are to appear in those sections. Obviously the key is to get into the "Top 100 Free" or "Top 100 Paid". The only way you get there is through volume. We've made it to #45 in the Family What's Hot. Go little monkey! Go! Secondly, we knew review sites are important to get initial buzz going, but how do you find all the review sites out there? A google search will return some of the biggies, but also blogs that haven't been updated in 2 years. So we devised a clever way to make a short list of review sites: most games put their reviews or quotes from review sites in the top part of their app description. By clicking through about 20 apps we were able to compile a list of 41 respectable mobile game review sites. Most if not all review sites work from a backlog of about 3-4 weeks. And they all want a promo code to get the game for free, they won't pay money for your app. Apple allows you 50 promo codes per release. Once you make a new release, the unused promo codes are invalidated. In the 3 weeks we've been waiting, we've had 1 review come back. Fortunately it was a good one. For our next title we'll be doing more on the pre-release marketing side to get the game buzz out before release. As we were taking so long on Catch the Monkey and we didn't really know if or when we would be done, we had to forgo pre-release marketing. Conclusion Well, there you have it: a summary of our ups and downs over roughly 2 years trying to make an iphone game. We set a goal, and despite great difficulties, achieved it. Beyond this, three things have brought great satisfaction: 1. Our first review came in: We received 4/5 stars and an editor's choice award from the family mobile gaming site famigo.com. It's nice to know someone objective thinks what we made is good! 2. A review someone wrote on the US store: How fun can catching monkeys be? Hours of fun! I love this game because it's something for my kids to do that's different from princess games and phonics--and it's something that I can do when I'm commuting, waiting for my next appointment, or just to relax. This has got to be one of the best non-violent games I've ever seen. Great graphics, good story, and entertaining for everyone. 3. The popularity of these articles. When we first set out to talk about our experience, we didn't know who would be interested. Over 3,000 reads and counting on the first article makes all this writing effort worthwhile! Thanks! What's next for Mirthwerx? We're currently working on a few things: Playbook version (taking full advantage of having used Marmalade) Android version (dido) Free version (different from a lite version, it's a different but similar game) And our second title which is a puzzle game for the masses (remember, turn based!) I've enjoyed writing these articles, I hope they've been of benefit. I have some ideas for maybe doing an "encore" 5[sup]th[/sup] article next week, but I'd be looking for questions or comments from people before I decide to do it. Until next we meet, Lord Yabo
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!