main

ContributionsPostmortem

Indie Showcase: Arges System’s Hairy Tales (iOS, PC, Mac)

February 14, 2013 — by Martijn van Dijk

Arges Systems is a micro-studio doing game consulting and application development in Unity – their specialty is on game logic and AI. Arges Systems has been partnering with companies specializing in 3D graphics and visual design, as well as doing contracting for companies building games with Unity. In this article, Ricardo J. Méndez (founder of Arges Systems) shares some insights on their just-released Hairy Tales.

I initially founded Arges Systems to take advantage of my experience running remote teams and projects. We had been doing contracting on various game projects for a couple of years before I decided to switch gears and start working on our own stuff. I had just decided to pull the plug on a turn-based strategy game for which I realized the scope was too ambitious and was chatting with Yuriy Mazurkin, our concept artist, about possible themes for a follow up game. The conversation drifted to Russian illustrators - somehow we ended up talking about Ivan Bilibin and it got me thinking about action/adventure games.

A sword-wielding octogenarian

A sword-wielding octogenarian riding a warhorse charges forward from a hill. Nordic forests and evergreen trees spread before him. He’s also butt-naked.

It was a simple, straightforward picture by Russian illustrator Ivan Bilibin, from his Marya Morevna series, and my first encounter with Koschei the Deathless. He’s an archetypal antagonist of Slavic folklore, an even more evil version of their better-known Baba Yaga.

I took one look at it and with its combination of adventure and absurd, I thought “damn, this would make for an excellent slavic Zelda-like game”.

You can’t get there… from here

I wanted to do a game that was different, and this wasn’t it.

I experimented with gameplay styles while Yuriy drafted some concepts. We drafted several ideas for scenarios, including a story, but it quickly became apparent I had nothing new to say about the adventure genre. I wanted to do a game that was different, and this wasn’t it.

Partly as a way to cleanse our creative palate, I started experimenting with mixing puzzles in. You had to maneuver the main character through a corrupted land, frozen in time, but elements got un-frozen as you approach them. This had pros and cons, since you could activate machinery just by being near it, but enemies also came alive. The puzzle aspect was to figure out what to do when. I decided to discard this version as well. It seemed like a one-trick pony, with the sort of read-the-designer’s-mind approach that I hate, and lacked replayability - once you know the solution, that’s it. Also, the game was taking on a somewhat stoic tone that I felt dragged it down.

You will notice I haven’t mentioned anything about the modeling side of things. We had overenthusiastically already started modeling before I was done with the design, because I wanted to get the time-consuming assets out of the way - or at least properly estimated. Despite it being a bad strategic decision, it had a positive side effect: it made me realize early on that the 3D artist we were working with just wouldn’t cut it. The quality of his work had been in decline, he wasn’t paying attention to details, and both Yuriy and I kept having to bounce work back to him with notes. Eventually I had to let him go and start looking for a new hire. Fortunately we found Ash Barnard, from the UK, who meshed with the team perfectly. He has an eye for detail, very expressive animations and more importantly, just the right sense of humor to make the Hairy Tales animations memorable and peculiar. Ash also brought in a good eye for gameplay, and helped criticize mechanics as I was coming up with them.

Through several experiments and iterations, I ended up landing on something close to the current approach. The first few iterations were fixed stages, based around arrows that directed them and fences that made them turn two sides to the right. It also featured a first draft of the spreading corruption, with the twist that if it spread to a tile with a fence, then it got corrupted and the fence turned into a deadly wall of flame. I can hear the thought gears as you try to figure it out. Playtesters weren’t getting it, and even when they figured out stages the reaction often was “I know this is how it’s supposed to be, but don’t know why”.
That would not do.

Concept art for Hairy Tales

Dragging it there

I started paring down the elements. At this point we’ve been in a production iteration limbo for months, and all the associated hair pulling is starting to take its toll on me. Everything is self-funded, so Arges is hemorrhaging cash while we experiment, and my focus is split between the game and the client work that is funding the process. I started trying different games to relax - mostly playing demos, so I didn’t get too involved and lost track of the project. One day I was playing a demo of Atlus’ Catherine, moving Vincent around, pulling and pushing blocks into place, and then a light bulb went on. After simplifying the elements, the stages had felt too straightforward, and the new levels depended mostly on size for their complexity. What if players could drag tiles from one place to another?

I didn’t tell the team, just sent them a build where some later stages required them to move tiles. They were rather surprised at first, but immediately saw the possibilities, like tiles that drag Hairys from one place to another, weapons you can re-use or teleporters. So finally, after months of iterations, we had a design we were happy with.

The 90-90 rule

It took a lot to get from a game’s design to the final product, of course. We still had to design the look for the various tile elements as we were going, which kept Yuriy involved while Ash created the models and I both coded the behavior and came up with the stages. Yuriy was also helping with the texturing. His true love is painterly work, however, so he came to me when we were about to enter the final stretch and brought up that he wanted to move on.

As sad as this made me, since I enjoyed working with him, I helped coach him for interviews and gave him a sterling recommendation. He ended up getting employed by Yager in Berlin, who recently published Spec Ops: The Line, and I expect is right now working on their next project.

At about this time I brought on board composer Levan Iordanishvili as a contractor to work on the game’s music. He liked the game and offered to take care of the sound effects as well. To ensure both were cut from the same cloth - he did a smashing job of re-creating the sound that Ash’s animations made in your head when you looked at them, and his scoring of the three worlds and bosses was top notch.

One of the levels in Hairy Tales

Calling it

I had initially planned to release with five worlds and five bosses worth of content, for a total of 75 levels (15 per world). Playtesting had demonstrated that players needed a gentler level progression than the breakneck pace we initially had, so each world had increased to 24 stages. If we kept the same number of stages per world, we were looking at 120 stages total, plus the extra time it would take for the two other bosses and possibly new enemies to keep things lively. The scope was getting out of hand.

I made a judgment call. We would be launching with 72 levels and three bosses, using some minor characters as mini-bosses. Once we saw the initial reactions to these levels from our players, we could release a couple more worlds as add-ons and expand on those qualities that players enjoyed the most. The team agreed, and we geared up for polishing the worlds we had fully designed.

The initial stage sequence introduced one concept after another, presenting a more concentrated experience which gave the player little respite, with no stages that they could use to experiment with the mechanics they had just learned before throwing a new set of concepts at them.  After various rounds of playtesting, I introduced some intermediate levels that presented the concepts they’d just learned in different contexts, so that they could play around a bit more, which made the initial learning process smoother.  However, it also led to the initial stage sequence feeling a bit drawn out, so I then had to adjust the sequence once again. This process went on over several iterations, even after we had released.

ContributionsGame Development

Four game design essentials for developing mobile/tablet games for toddlers - by Ian Schreiber

January 24, 2013 — by Mariia Lototska

Ian Schreiber has been in the video game industry since the year 2000, first as a programmer and then as a game designer. He has worked on eight published games, two textbooks, two free online courses in game design, and several other things he can’t talk about since he’s still under NDA. He has taught game design and development courses at a variety of colleges and universities. He is a proud father of an almost-two-year-old, whose favorite activities include talking on the phone, going to the zoo, playing iPad games, playing in the sand, and tucking her stuffed animals into bed, although her favorite “toys” by far are mommy and daddy. From this experience of seeing his child playing with an iPad, Ian shares four game design essentials with us on developing games for toddlers.

1. Design for a child’s hand and touch

If you actually make a distinction between finger-swipe and palm-swipe, and if your hit boxes aren’t really tolerant of near-misses, you’ll have a hard time convincing me that any kids tested your app before release. Most storybook apps are pretty good examples of how to do this once you get them started - any kind of finger or palm swipe to the left or right turns the page, plus there are buttons in the corners to flip pages if you touch them.

2. Avoid having loading screens

Is there really a reason or need to have several gigabytes of 3D animations in a kids' game?
Is there really a reason or need to have several gigabytes of 3D animations in a kids’ game?

If your loading screen takes more than a second or two, my kid will think your app is broken. She doesn’t understand the concept of loading screens, but she knows how to hit the button to get out of your app and pick something else. If your game is aimed at young kids, just how much complexity do you want to have in there?

I suggest two ways of testing your loading screen. One is to set an actual metric goal, like half a second or less from startup to full load, and then you would just measure it. The other would be to test with actual young children, give them an iPad, have their parents guide their finger to touch your app in order to open it, and see what the kid does from there. I recommend you test with some kids who have iPads at home, so they know how to hit the button to exit an app when they get bored.

The trick is to not have loading screens of any noticeable duration in the first place. Most kids’ apps don’t particularly need to be all that complicated, they should not have a massive memory footprint or CPU requirements in the vast majority of cases. I assume any app that is running into long loading screens is either not (completely) optimized (i.e. the programmers were incredibly lazy with memory allocation or the use of inefficient graphics algorithms) or else it contains far too many assets for its own good.

3. In-App purchases don’t work

Don’t monetize via in-app purchases

In short: Don’t monetize via in-app purchases, I turned those off ages ago (as did any other parent who knows better). Also, if your business model relies on toddler miss-clicks when parents aren’t looking: well… you’re the one who has to live with that on your conscience.

My toddler doesn’t really grok in-app purchases yet, so the subject of how to let her buy something that she wants in a game hasn’t really come up. I’m pretty sure she kind-of-sort-of understands the concept of exchanging money for a tangible object like a toy or stuffed animal, but in-app purchases are another layer of abstraction that my almost-2-year-old hasn’t really figured out yet. Mainly, any purchase screen, subscreen, or menu that takes her out of the game, she just sees as some kind of annoyance that takes her away from the game.

I decided to disable in-app purchases after seeing far too many stories of parents whose kids made hundreds of dollars worth of purchases without the parents’ authorization. Yes, there’s a password in there, and my kid probably doesn’t have the manual dexterity or understanding to key in my password. Yet. But she’s an information sponge who has shown herself quite capable of mimicking just about anything she observes. I know it won’t be too long before she’ll be able to enter my password and surprise me. Better to be safe, than trying to fight a protracted battle between me, my daughter, some hapless developer, Apple, and my credit card company.

4. Do you monetize through in-game ads?

I just can’t imagine ads working on really young kids (1.5 to 2.5 years) in any conventional sense

My kid doesn’t grok ads. She might click on it by accident or on purpose because it looks colorful, but then you just take her out of the game and confuse her and she’ll shut the thing down and try something else. If you use a third-party ad server that asks a 2-year-old if they want to find a date on Zoosk, your app is getting deleted. (No, “it’s a third-party component, we have no control over it” is not a valid excuse. Your app, your responsibility.)

I just can’t imagine ads working on really young kids (1.5 to 2.5 years) in any conventional sense. Perhaps an advertising expert would disagree, but just from observing my (pretty smart) kid right now, she really just does not understand the concept of ads in the way that advertisers would like. It’s like designing all-text ads in the Japanese language, to an audience of monolingual English speakers: 99% of your meaning is lost. And if you’re asking how to interest the advertisers, I’d say you’re asking the wrong question! The real question here should be: “Okay, so in-app purchases and ads don’t work. What’s the way to monetize a very-young-children’s app, then?”

The answer: monetize via app sales. Make a free version of your app that shows what’s cool about it, just enough for a kid to play around and get engaged and interested (and for the parent to observe this). Then make a paid version with the full feature / content set unlocked. If it’s a ridiculously simple app that kids just find fun anyway, like a set of interactive flashcards or a counting or drawing app or something, I’d expect to pay 99 cents for it. If it’s a more full-featured app, like an interactive storybook that will either read itself to you, let you read it, or let the parent record it in their voice, plus some minigames related to the story, I’d expect to pay $4.99 for it. Those seem to be the price points of the successful apps I’ve seen, and why spend more when there are plenty of great apps at these prices already? Only time I’ve seen anything go above $4.99 is when it has a golden IP like Disney.
Alternative monetization if you have a whole series of apps: make one app totally free, charge for the other ones as above. A lot of storybook apps do this, but I’ve also seen it for apps that use the same core engine with a number of different themes.

But… there is hope!

If you want to know the best apps out there, instead of just taking my word for it (after all, I’m just a random developer who’s never made a kids’ game, mouthing off about this because I have a toddler and am frequently frustrated by the apps I download for her), I’d recommend searching on Google for “Best apps for kids” or “must-have ipad apps for toddlers”. Then just find a number of top-10 lists from other random parents mouthing off and take note of the apps that seem to be on a lot of the lists. Besides that, you can try the top-selling kids’ games in the App Store or look for other articles on kids’ games.

That said, there are some games I would put forward as positive examples (and one mixed example):

Toca Docter HDToca Doctor HD - similar to the Trauma Center series or the Operation board game but for a much younger audience. First of all, it is a perfect example of a game that is designed for kids. There are basically no loading screens and the main menu is a giant button that takes up most of the screen so my daughter can start it on her own. After pressing the giant button, you’re taken to the main game menu where the only controls are things that flash or animate so it’s pretty obvious where to touch (and the hitboxes are generous). Each touch takes you to one of a variety of WarioWare-style minigames. Playing it for the first time, the minigames were hard for her to figure out on her own, but once I guided her hand with each of them she was able to do most of them on her own. Each minigame also has an exit button that’s always in the same corner, so it’s easy to exit a minigame when you’re stuck.

Toddler CountingToddler Counting - a very simple app where it just asks you to count some number of objects using your voice. Touch an object and it counts 1, then 2, then 3, and so on until you’ve touched them all. When done, it gives verbal praise (and in some cases an additional sound, like if you’re counting kittens it’ll meow at you). The free version does this like 4 or 5 times with fixed content and then locks up; the 99-cent paid version has more content and keeps going forever.
Again, there are no noticeable load times. Besides that, the main menu has two really big buttons: “easy” for counting 1-10, and “hard” for counting 11-20. No other controls at all, just touch the objects. About as simple as it can get.

I Hear Ewe Animal SoundsI Hear Ewe Animal Sounds - another simple app. No main menu at all - it just throws you right into the app. The screen is divided into 12 large buttons, each one with an animal icon on it. If you tap an animal, the graphic will enlarge. Then a voice says “this is the sound an owl (or whatever animal) makes” and it plays the sound. You can sweep between three pages worth of animals with a finger or palm swipe.

 

Miss Spider’s Tea Party, and Toy Story Read-Along - both of these are interactive storybooks and similar in format. The main menu has relatively small buttons and does require my input to start off, at first. However, she’s seen me do this enough now, so she can start up the app and select what she wants on her own. The app features options to read the story manually (finger-swipe, palm-swipe, or touch a button on the side of the screen to turn pages); have the story read to you (basically playing a video, pages turn automatically, voice reads to you, words highlight as they are read); and play some mini-games with the story theme (small jigsaw puzzle, card matching, etc.).

Miss Spider's Tea Party
Miss Spider’s Tea Party

While neither of these seems to have any load times, both have a brief intro animation on startup (same way the Sega Genesis always started up with “Seeee-gaaaaa!”) so I suppose it’s possible that it’s doing some loading while that animation plays, without announcing that it’s doing that - if so, clever for them.
So both of these apps include a lot of rich content and lots of stuff to do, which is pretty impressive for free apps. The other storybooks in the same series cost - and cost a lot - but they do show how you’re getting your money’s worth with the free app.

Play Phone - this one, I have a love/hate relationship with. Every time my daughter starts it up I debate whether I should delete it. On startup, first thing it invariably does is pop up a small text dialog asking if I want to leave the app, for reasons I don’t understand. Tapping ‘no’ reveals the main menu, which has three buttons which are all horizontal and spaced fairly close together. One of these takes you to the actual game, another to the developer’s page, and the third pops up some kind of announcements page (and they like to make frequent announcements that are, of course, completely meaningless to a toddler). So, a play session of this basically starts with my daughter starting the app then calling me over to help her past the main menu.

Play PhoneOnce you get past that, it’s a simple app where you have a standard 12-button phone layout. Hit a button and it plays a short animation. My daughter finds quite fun, even if I find it grating to hear the same sounds over and over. Additionally, the app includes one button where the parent can record their own message for playback on one of the buttons. This is done by hitting a two-button combination, in order to prevent the kid from recording over it accidentally. Great idea for a feature, but there are two problems, which I assume came from a simple lack of field testing. First, hitting the playback button before anything is recorded leads to the app locking up for 30 seconds or so. Second, hitting the record button on its own pops up a small text dialog that explains how to record properly. which is fine for me, but meaningless to my daughter, and difficult for her to dismiss if she brings it up by mistake. The app is free though, so I guess you get what you pay for.

Currently, Ian is (again) under an NDA. However, you can check out some books he co-authored: Challenges for Game Designers and Breaking Into The Game Industry. Be sure to check out his blog as well.

logo
SUPPORTED BY