In the past, for three of our largest productions we had a publishing agreement. The publisher had been in charge of doing usability & beta testing for our games, with camera recordings, questionnaires, targeted player groups, the whole lot. We used to get the videos and watch them as a team afterwards. I’ve got to tell you, especially during the usability, those videos were most of times heart-breaking and not in a good way. That taught us how important usability is and how crucial it is to test things outside our core team.

In our studio, we also tested our games with friends and family but in a much more informal setting – them playing, and us, behind their backs watching and keeping notes. However, for the last two years we’ve turned to self-publishing; we no longer have access to a publisher’s usability perks. As a result, for our latest iOS game, A Clockwork Brain, we decided to design the usability session from scratch.

Prior to this, none of us had any working experience with formal usability testing. I, myself, have had some experience in questionnaire design and facilitation of experiments, based on previous work in university research.

The research, design, and deployment of our usability session took one month from start to finish. We wanted to share what we learnt with you, and we hope you find it helpful. As there are a lot of things to talk about, we’ve split it in two articles.

This here, the first article, discusses the hardware and software setup that we used.

Things we’ll talk about in the first part are:

• Equipment used (i.e. camera, device case).
• Software for capturing video and sound.

Setting up cameras and making the usability sled

We wanted to monitor the players while playing: both their facial expressions as well as their actions in the game. This called for a two-camera setup. The first would be a camera that faced the player. The tricky part was to find a suitable second camera that would face the device.

We discovered a number of very useful approaches. The first one is by Harry Brignull (of “90 Percent of Everything”, a treasure trove of material on Usability!) which shows how to make an iPhone usability sled for £5 by using acrylic. The second one, by Nick Bowmast uses a similar approach . The last, by Belen Barros Pena, has the capability to fit a number of different mobile devices and is constructed of Meccano parts.

We decided to do something similar to Brignull and Bowmast. Equipment required:

1. Hard protective crystal clear case for the device (depends on what you want to use, we had one for iPod and one for iPad). Costs around €5 on Amazon UK. While the other methods don’t use cases, we thought it would feel more natural to the player’s touch.
2. An acrylic (we call it plexiglass)  strip (26cm x 3cm x 3mm, at around €2)
3. A way to heat the plexiglass. The safest way is by a strip heater. We, instead, used a blowtorch. Keep in mind that you need uniform heat, not direct flame, on the plexiglass, so use blowtorches with great care. Nick Bowmast ingeniously uses a toaster instead!
4. Good quality, light, webcam with microphone, capable of being mounted on the plexiglass strip. We used Microsoft LifeCam HD and were extremely happy (costs around €42).  Its base can easily be removed and the camera attached to the strip.
5. A second webcam with microphone that would point towards the player. We already had a Logitech Orbit AF Webcam (€66) in the office so we used that one.

After heating and bending the strip to the desired angles, we drilled the mounting socket for the camera. Once the Lifecam was securely mounted, the kit was extensively tested. When it became absolutely certain that the angle was correct and the Lifecam did not obstruct the player’s view towards the screen, we heated/attached the plexiglass strip to the clear case.

There are a number of benefits in using such a sled setup. For starters, the distance between the camera and your device’s screen is always fixed. When you setup your camera’s focus, you will observe that, no matter how the user holds the device you will have a steady video stream.  Secondly, the way the camera is placed does not obstruct the player during the game. It also does not enforce him to remain at a specified position. The player is free to use the device as he normally would, whether he is left- or right-handed.  The added hard plastic case gives an even more natural feel for the device; gadgets like these are expected to have plastic cases. Finally, adding/removing the device from the sled is very easy, since it only requires detaching it from the plastic case.
An obvious downside to this setup is the extra weight (about 80-90 gr for the iPod/iPhone and 100-110 gr for iPad). Through the sessions, however, none of the players raised an issue or showed any sign of tiredness. Here is the distributed weight:

• Case: ~18 gr (iPod touch) ~30 gr (iPad)
• Camera: ~50 gr
• Plexiglass strip: 10 gr

Another downside is that you will need a separate sled setup for each different device that you use (plexiglass strip glued to device case). Also, such a setup will always require you to know what device you will use during usability; testing a game on a user’s touchphone when you don’t have a case for that phone would be a problem.

We will now look at how we setup the recording from the camera setup.

The odyssey of camera recording

We wanted to have a formal usability setup, where the player would be alone with the game in a room and would not be hindered by our presence. Fortunately, we have a conference room in our studio which was perfect for this.  We put a high-spec desktop PC there, and connected it to the two cameras and speakers.

The following step was to set down requirements for our recordings. Making such a list of requirements is extremely useful. It makes you think more clearly about the whole procedure and forces you to start setting down fixed rules about what you want and what you don’t want from your usability session.  This is what we considered mandatory for our session:

• A good quality of continuous video streaming from the usability room to where we watched.
• Monitor both cameras at once (picture in picture).
• Record voice as well as video.
• Communicate in real time with the player through microphones. We didn’t want to barge in!
• Reliable software – usability flow should not be disturbed due to technical reasons.

We tested a number of different free and cheap webcam and screen recording software under Windows, such as Camtasia, Amcap, and VLC. Here we should also mention Silverback (for Mac) which we did not test, but read a lot of good reviews about it.

Some very useful articles that helped us:

• Cheap alternatives to Morae
  
• Record two camera feeds using only free software

None of that software fitted the requirements we had set so we went on to trial Morae by Techsmith.  We were quite hesitant as it was a very expensive piece of software and completely outside our budget (€1,427).  It is quite powerful, having a wide range of research features, but frankly we did not need most of them.

Morae is made up of 3 distinct components: Recorder, Observer, and Manager. The Recorder records the feed from the two cameras or from a camera and a computer desktop. The recording can be enhanced, if wished, by tracking mouse clicks, handing out surveys, breaking the study in tasks and recording a log. The Observer allows you to observe the Recorder feed remotely and also commence or stop Recordings.  The Recorder files are saved in Morae’s proprietary video format that can then be opened and edited with the Manager.

We found out that the Observer can save the live feed from the cameras locally in .wmv format. We also discovered that when you turn the sound off in the live feed, the streaming is of much higher quality.

So this was our resulting setup:

• Install Morae Recorder on the PC in the usability room and set it up properly.
• Use the default template configuration for “Hardware or Mobile Software device study”.
• Remove everything related to task logging/mouse effects/studies/markers and surveys. We did not need any of that.
• Have a Skype voice call between the computer in the usability room and one of ours. This allowed to hear any player comments and to talk to them if needed.
• Install Morae Observer on another PC. Have audio-less streaming, and save the video in .wmv format (the saved video does include sound).

By doing this, we eliminated any direct need of the Morae Manager. The Recorder will always save in the Morae format, which we were not able to view, but the quality of the Observer .wmv was quite good for our needs, as it offered what we wanted.
Techsmith sells an Observer and Recorder bundle separate from the Manager bundle, at €333.  You can see how this price range is much more affordable for us!

Once the setup was confirmed, we run a series of test sessions in order to ascertain the optimal light conditions and camera settings. These of course will be different per room and camera, but two things really helped: artificial light and a piece of black velvet cloth.  During usability, we lighted the room with artificial light set to a specific level. The room’s blinds were always shut, no matter the time of day. This way, we were always in control of the light level.

We also covered part of the recording area with black velvet. This piece of cloth will set you back about €15 but it is worth it. It ensures that the dark background absorbs the light and will make your device recordings so much better. Our velvet was a 50cm x 50cm area, attached with Velcro strips on the wooden table. The participant was instructed to try and constrain any moves around that area.

Conlusion

We hope you’ve found the first part of our usability design useful. In this article we have explained how we decided on which hardware and software to use for our usability sessions. If you do not have a portable application like we did, and you want to record from a desktop and a user-facing camera, things will probably be a bit easier. If streaming observation is also not a big issue for you, you will find that one of the free/low-cost software options would probably be just what you need.

Until this point, the cost for our usability setup is:

Stay tuned for Part 2, where will focus onto the particulars of usability sessions, such as game specifics, participant recruitment, questionnaire design, session facilitation and usability results.

There came a point in the production of the game that we decided it was time to move from the prototype graphics we’d been using until then, to the final ones that we had envisioned.

That meant that we had to look for an artist, who would be working remotely, full time on the illustrations and UI elements that were needed for the game. Since this task
was to involve a freelancer, I decided to place an ad and wait for the right person to
come by.

As it usually happens, we received a lot of applications, some good, some bad, but nothing
that really stood out. When we hire someone to work with us, we are looking for both expertise and professionalism; in case any of these are lacking, serious issues could come up later on.

In the past, when I would look for an illustrator, I would take my time, going through the different portfolios, talking to the candidates who seemed like a possible match, making sure I was doing my best to find… the best.

When stinky projectiles hit the fan!

This time, however, I’d given myself and the project a silly deadline; a week to find the person who would be hand-painting all of our game’s graphics, for a game in which we had invested many months already!

This limited time frame led me to hire the most unsuitable person, even though, just as we were signing the work-for-hire contract, deep inside me I felt I wasn’t making the right choice.

A couple of days later, not only had this person given up on the project he signed a contract on, but he also “ran away” with over $1,000. That money was our downpayment for some of the pieces he was supposed to do and deliver in layered PSD format!

We were left with a couple of JPG files, completely useless for our project and a kind of bitterness that we hadn’t felt before. We’d lost money and time, two of our most precious assets, but most importantly I’d personally lost trust for people in general; a rather scary thing to happen to someone!

That day, working with a remote contractor ever again seemed impossible. However this was exactly what we had to do for the project to continue.

Asset naming conventions reflect a really simple concept: How to name assets, or parts of assets. However, when it comes to adhering to those conventions, it’s anything but easy.As with the previous post, I’m going to take a look at the conventions by using Maya’s Dress Up as an example. My examples will focus on image assets but what I’m going to say can again apply to other rich media.

Use self-descriptive names

The rule of thumb is that from the name one can understand what the item is.  When I say ‘one’ it does not mean you who created and will name the file, but anyone in the team who might make use of, or need to reference it, either now or in the future.

For example, the filename “bigboss1.obj” is not very descriptive, while “final_boss_lvl_01.obj” is surely better.

In Maya’s Dress Up we use the term Garment to denote anything that Maya might wear. This can range from a different hairstyle to dresses or a bracelet.  The garment assets are saved in a directory structure like:

• Wardrobe/Accessories/Gloves/
• Wardrobe/Bottoms/Cropped/

When we began work on the game, a garment was identified by its full path, for example the ID for a set of crimson fur gloves would be “Wardrobe/Accessories/Gloves/Fur_Crimson”

Some time after release, we realised that this was not efficient and we decided to use the filename as an identifier.  This created issues as we now had duplicate filename issues as:

• Fur_Crimson (the set of gloves from Wardrobe/Accessories/Gloves/)
• Fur_Crimson (a fur scarf from Wardrobe/Accessories/Scarves/)

Our mistake was that the name was not self-descriptive. We did not lay out a future-proof naming convention for the garments, while we did pay serious attention to colour naming. After discussions, the following convention was used:

(material i.e. velvet)+ (style i.e. Tank) + (subtype i.e. cropped or sleeveless) + (type i.e. top or pants) +colour

Now, valid garment names would be something descriptive, such as OvalBuckleBelt or SuedeJacket.

Not all of the elements had to be used simultaneously, but the end name had to be descriptive.

Once this was done, the whole wardrobe had to be properly renamed – and unfortunately, this escalated to:

1. Renaming all layers inside PSD files (one garment has about 5 layers and there are hundreds of garments).
2. Validating correctness of names.
3. Re-exporting all assets to high quality.
4. Creating assets again for iPad, iPod/iPhone and Retina display.
5. Creating a relationship table (old garment name – new garment name) to safely transfer a player’s saved styles to the new format.

So, we certainly did learn a lot from this and we hope by explaining it, it will help you to avoid such a scenario. Plan forward and see what might work for your game to avoid extra costly (and perhaps boring!) work.

Enforce the rules kindly but firmly

If you have rules about how you want things named in your projects, tell the asset creators first. Don’t assume they will know what you want without you telling them so.  Psionic (“mind-reading” for those of you without a D&D disposition) powers are not out yet.

Give clear instructions, and explain why things have to be named in such a way. Explain to them that Box01 or Layer9 will simply not do.  Make the artists part of the whole asset processing cycle and describe what happens to the art after it leaves their hands. A good artist will immediately see your point. Doing the opposite negatively affects teamwork.

After the naming incident, we created a set of guidelines for the artists here in Total Eclipse. In it we say something like:

What goes on once the artist delivers the artwork

Our task is to export all those garments, one for each colour, to be used in the game. We know that when artists paint, each garment may have a lot of layers inside it.

Here’s what we have to do for each item after you finish:

[procedure steps described for exporting stuff for iOS]

You can help a lot with points #1-5 by following a few guidelines for naming and organizing stuff. We’ll summarise them here and then explain why we need them and what it is that happens.

Our guidelines then contain guidelines like:

Put unused layers in group UNUSED. Colour the group in red.

Keep layer naming understandable. Don’t name layers as Layer15 or Vector. Either group them under a sensible name or rename them.”

If you don’t want to pressure the artist, or if you are the sole creator and really can’t bother, think about this:

Five years down the line you want to re-export the assets for a new device but a) the artist has left or b) you haven’t opened the PSD in said 5 years. You will have frankly no idea what is layer 56 and Group 2.

Scripts are your friends

Enforcing naming conventions is one thing but checking that they are being followed is another one entirely. One obviously cannot be expected to look at layers or directory files one by one.

In certain cases, like with PSD files, we are using Photoshop scripting to check things for us. The script loads a text file with the correct file names and checks it against the PSD. If any layer is named differently or is not found, the script gives an alert. Check out PS-Scripts for a similar source. The site is a treasure-cove for Photoshop scripting .

Some things to watch out for when dealing with text files.

1. Make sure that your script checks for Upper/Lower case compatibility. OS X and the Unix file system are very VERY strict on such things.
2. Try to avoid spaces in your file names or at least make sure you ‘escape’ the space characters properly.
3. When you use text files make sure they are saved in the correct encoding. DOS and Unix save end line and EOF characters in different ways and parsing a text file line-by-line may lead to problems if it’s not in the correct encoding.
4. Use a good text editor (avoid notepad) such as UltraEdit. In fact I can’t recommend UltraEdit enough, for all kinds of scripting. I think I’ll write another post dedicated to level scripting and UltraEdit.

Another thing you might need to do is recursively rename files spread on different directories. If you have a Windows system, DOS batch scripting is a really useful (albeit sometimes frustrating) tool to work with. You can have conditional and nested statements making it a powerful tool. This site has a good overview and examples of commands. I am sure Mac OS X’s automator does something similar but I’ve never used it.

Archive for the future

When an asset is created it usually goes through many iterations (or revisions) until the end result. Naming those revisions sensibly is also very important. You can use numbers, dates, or the alphabet to indicate sequence, such as final_boss_lvl_01_rev.A.obj; whatever works for you, really. Remember, however, to always, always, indicate clearly what is the final product that was used in the game. Have the word FINAL attached, move it into an IN-GAME directory, but make sure the distinction is clear. You will need to use those assets again and if you can’t tell which file holds the rough sketch from the end result you’re looking for trouble!

Conclusion

Everything in this post boils down to this:

1. Take some time to define a naming system.
2. Set guidelines for naming and handling assets and their revisions.
3. Enforce the conventions by keeping the asset creators informed.
4. Use scripting and other tools to check that everything is correct.

It is a small investment that will pay off and save you big headaches in the long-term.

Well, this ends the second part of the Managing Assets series. I hope you enjoyed it, as always comments are welcome!

The modern day has seen some dramatic changes in the field of writing. Less than a hundred years ago, a reader could expect a novel with paragraphs that went on for a page and exposition that carried on for an eternity. That was a time of tell, don’t show and visual writing was unheard of.

A novel these days tends to be quick paced, consisting of three lines conjuring images to the mind. This has largely been the result of how pervasive movies have become. Eventually, the precepts of screen-writing seeped into novels and short stories, changing the nature of writing at its core.

My education was firmly rooted in classical literature. I’m a movie fanatic and love plays. Video games were a hobby and pastime that I really loved but I never thought about writing for them more than passively (usually when a game’s story was bad and I thought that there was no way I could do worse). Still, familiarity breeds curiosity and when the opportunity came about, I couldn’t turn it down.

Fashion Boutique was my first experience both with Total Eclipse and working on a video game. I outlined the story aspects and provided scripts for the comics that made up the transitions between levels. It was a fun but challenging project, especially considering just how much of a departure it was from my normal work.

The rapport I built with the development team of Total Eclipse allowed us to take on an ambitious Hidden Object game, one that thrust the player into a new genre with unique characters and an in depth story. Our mutual love of old adventure games forged our direction and we set out to create a pitch.

The first incarnation of The Clockwork Man was to design a puzzle game like Cogs. The player would take gears and springs to put together parts for a massive mechanical structure, a clockwork robot that would eventually become animated and move around and maybe even help finish itself.

I’m not a puzzle guy. I can come up with a high level concept but the actual logistics are another thing entirely. While I was floundering in my attempt to explain this vision, I was directed to try one of the Mortimer Beckett games.

I had seen hidden object games in the store but I couldn’t figure out the appeal. From afar, it just looked like a way to pretend to clean up a messy room and since I didn’t want to pick up my own real world junk, why the heck would I do it virtually?
Wow, was I insanely wrong!

I played the heck out of Spooky Manor and when I reached the end of my demo time limit, I immediately bought it. Unfortunately, there was only a tiny bit of game left after that but it didn’t matter. My imagination was captured and when Total Eclipse proposed that the Clockwork Man be a Hidden Object game with plot, I was in.

Clockwork Characters

Miranda and Sprocket were the first things I thought of even before my botched puzzle game idea. She was to be a young engineer/tinkerer with her tiny robot companion full of personality. I wanted him to hang around to cause some trouble as well as provide a story based hint system.

Their back story and personalities required little effort. They came about naturally as we discussed what we wanted to happen. Miranda lived with her grandfather and Sprocket was a gift from her father, a man whose fate we left ambiguous. We established that her family was affluent from their successes in science and that she was fulfilling tradition by diving into the engineering vocation.

Miranda herself was a character that I wanted to be empowered; a woman in an era that would have otherwise shunned such aggressive ambition. This was the joy of the steampunk genre—social class could be turned on its ear and someone like Miranda could not only be assertive without consequences but respected for it.

Sprocket was an intriguing character. We didn’t delve into exactly how he worked or why he was autonomous with a personality. He speaks in beeps, grinding gears and odd tones. Even his subtitles show up like an old Batman fight scene (Thwap!)

Miranda was an easy character to describe for the artists but Sprocket had many incarnations. Oddly enough, either through my write up or the genius of the artists, one of the sketches was exactly what I saw in my head. The Sprocket you see on the screen literally crawled from my imagination onto the screen and that’s a testament to Total Eclipse’s ability to interpret the concept so entirely.

A World of Steam and Wonder

The steampunk genre had not quite saturated the market the way it has now. At that point, you couldn’t buy a Victorian inspired outfit on Xbox live for your avatar and the very first dedicated conventions were still being organized. We had an opportunity and a challenge; capitalize and casualize a burgeoning setting.

At its heart, steampunk is the Victorian era reinvented. It’s the Time Machine and 20,000 Leagues Under the Sea and the League of Extraordinary Gentlemen or the Wild Wild West. Using their materials and ingenuity, they created devices that have the Victorian aesthetic with modern functionality; airships, computer style gadgets, robots, and anything else that the imagination can conjure up.

There were many advantages in adopting the Victorian sci-fi approach. First off, we had free reign to create anything we wanted, shaping the world to fit our storytelling needs. This included just how wild technology had become, what clothing would look like and to what extent the British Empire had dominated the world.

Steampunk was a great horse to bet on with its rise in popularity. Standing as one of the first (if not the first) casual game to venture into this territory, The Clockwork Man looks and feels like those old classics that I grew up with while adopting some modern ideals and cinematic storytelling.

Setting the Stage

Our first outing was to take place in a fictional South American town called ‘New Coventry’. This afforded us the opportunity to limit architecture to something familiar and not too outlandish. Anyone who had seen King Solomon’s Mine or an Indiana Jones movie could likely relate quickly to the place.

Also, by setting it in South America, far from the technological hub of London, we added a little isolation. Airships may have shrunk the globe but with pirates patrolling the airways, no one was willing to leave the safety of the town. Miranda and Sprocket would be effectively trapped there throughout the mystery.

The Clockwork Man 2 enjoyed a little more globetrotting than its predecessor. Miranda spends some time delving into her past and enjoys a foray into London, Ireland, and parts unknown (no spoilers here!). The great thing about this transition from the first game to the sequel is the grand nature of travel and how it captures the adventure of something like Around the World in 80 days.

Each place in the Clockwork Man 2 holds danger and mystery with a little hint of the familiar. A key goal while outlining these games was to never ostracize the player with something completely outlandish. As a writer, I want to be as inclusive as possible especially when a sub-genre like steampunk tends to attract an exclusive crowd. To avoid this, I cater to both sets of people; those that know nothing about the setting at all and those who love steampunk so much they never leave the house without their goggles.

Two games, two different approaches

The Clockwork Man 1 was outlined and scripted out with headings that said things such as ‘insert puzzle here’ or ‘put some game play in’. Naturally, this allowed for a story heavy game to be realized but it hampered the creativity of those clever ‘game’ folks. A key focus of Total Eclipse has always been ‘organic puzzles’ or simply put, the things people do in the game must come from the environment in a logical manner.

The first game made this a lot harder for them because events were practically ‘hard coded’ for lack of a better term. It’s not that I was some unyielding psycho who wouldn’t change anything but once the story was written, we tried to work within that guideline. I would hesitate to say that anything suffered from this approach but it absolutely lacked the sort of cooperation that I referred to at the beginning of this document.

The Clockwork Man 2 was more ambiguous and was developed as a concept in motion more than a set in stone tale. I came up with a framework that provided room to move within the context of the overall story. I knew that events had to go from A to B to C but the transition between each point was not detailed in anyway. This provided the game designers to put together puzzles, adventure segments and hidden object play without having to worry if they were treading on some plot point or another.

This approach allowed The Clockwork Man 2 to feel more complete as a game. Each aspect shared equal importance. Story and game gelled cohesively and the end result was a longer experience that still had character development and resolve. Plot was not sacrificed but rather bolstered the entire project as transitions between events became seamless.

When the puzzle pieces were put on the same board, the meat of the tale was created through a collaborative writing process. Through multiple outlines, summaries and rewrites, the details of the story took shape. The risk of working like this is that it can be cumbersome if the team disagrees consistently but such problems can be overcome with decent planning. Everyone was on the same page with The Clockwork Man 2 and the group approach made a huge difference.

To be more specific, I wrote out the script for The Clockwork Man 1 before anything ever happened. This included all dialogue, story and events. Puzzles were designed by the Total Eclipse team but it would be fair to say that they were hampered by the specificity of my script. This limitation was something that we pointed out in the post mortem process.

With the second game, while I certainly had a great deal to do with the concept and initial presentation of plot, the actual creation of journal entries, dialogue and several specific story elements were created by the Total Eclipse team. Their direction came from that first outline and push concerning the overall plot and they filled in the blanks with their own creative input.

Mutual creation relies on tightening the structure as the different elements of plot fall into place. By the end of our project, everything fit together without seeming out of place. The results are what you see in The Clockwork Man 2: a functioning setting, an engaging story and everything moving within the rule set of the shared imagined space.

The Way Ahead

Working on The Clockwork Man games was one of the great joys of my professional career. The characters, the artwork, the story, and the game play all were fantastic examples of creative people coming together to build something special. Naturally, I’m biased but my opinions are not founded solely on the pride of a creator.

Total Eclipse was unafraid to take risks with this project and was willing (though sometimes hesitantly) to dive in to some of the crazier details that I came up with (a great example is Miranda’s white hair).  When we pitched the game and began work in earnest, it was an exciting ride that ended in a product that anyone could be proud of.

This particular article was little more than an overview of conceptualization and the very broadest approach to storytelling and The Clockwork Man. I’ll be following this up with some details on how the outline process worked, script writing and even how detailed the character descriptions were.

Until then I look forward to the next chapter in The Clockwork Man series whether it be another Hidden Object game, a book, a graphic novel or something else entirely. I believe in the art direction, the characters and the story enough to know we can continue to creatively explore Miranda’s world.

Yes, and Sprocket’s world too.

Assets are everything that makes up your game, apart from the source code/script files (managing source code is a different topic and will not be discussed now).  Assets can come from a variety of media and different people may be responsible for creating them. For example:

• Music: Musicians
• Sound effects: Sound Engineers
• Illustrations: Artists
• User interface: UI designer, Artists
• Animations: Artists
• 3D objects: Artists
• Movies: Producers, Artists
• Dialogues/Text: Writers & Localisation teams

A lot of different professions, there. All these people have to be aware of, and in agreement with, the following project conventions whenever they create one asset:

1. Asset quality
2. Asset naming
3. Asset backup and storage

The person responsible for informing and enforcing the creators about conventions is either the lead artist/sound/music/writer or, in smaller teams like ours, the producer/associate producer.

Communication and good teamwork are very crucial here. A non specialist (i.e the Producer) has to have a good level of knowledge of the specialist’s (i.e. artist) field of work in order to explain what the project requires.

I’m going to take a look at the conventions by using Maya’s Dress Up as an example. My examples will focus on image assets but what I’m going to say can equally apply to other rich media.

The quality vs. cost trade-off

Maya’s Dress Up, our most recent game for iOS devices, is extremely asset-heavy with thousands of images. Let’s have a look at one of the game’s typical assets, a necklace. After the producer and artist agree on what will be painted, the quality must be established. In images this can be expressed in terms of DPI (dots-per-inch).

• Cost in money: The more DPIs and the larger the image is, the more you will pay for the art, as the artist needs to add extra details in the illustration.
• Cost in time: The more DPIs, and the larger the image is, the longer it will take for the artist to deliver.

The following image shows one of the necklaces done for Maya. Here, in Total Eclipse, we generally stick to 3oo DPI per illustration.

Turquoise Butterfly Necklace in different resolutions.

On the left side you can see the level of detail that it was illustrated – at 300 dpi. The right shows the level of detail that would be needed if one would make it at 72 dpi. The chain links are no longer visible nor is the glass glow on the butterfly. Surely that should save a lot of the artist’s time – or not? Let’s suppose we have 500 items.

• Avg time needed for a garment at 72 dpi -> 1 hour (500 total)
• Avg time needed for a garment at 300 dpi -> 2-3 hours (1000-1500 total)

Looks like a ton of hours would be saved if the lower quality is chosen. This is how the necklace looks on Maya on a venerable 1st-gen iPod Touch with a 480×320 resolution:

“Pretty small” you might think. Suppose for a minute that all of the assets were done in low quality. Then Apple goes out and throws an iPad at you with a 1024×768 resolution. And after a bit, it comes up with a new iPhone sporting a Retina display, of all sorts. This doubles the device’s pixel density of each image and effectively requiring an 960×640 resolution.

If you wanted to move to those new devices, you would need to scale upwards.

Scaling Upwards

“Artist”, I hear you say. “Make me images for this new display”. The artist will rightly tell you that she’d have to work double the time and re-do all of the art to a higher quality.

Total time = Old time+new time = 1500-2000 hours

Have a look at the next image. Click on it to see it full-size.

You can clearly see the difference between scaling up and scaling down in resolution. Image #2 is derived from a low, 72-DPI source file while #3 from a 300 DPI one. The quality level in #2 is bad, the image very blurry and non-crisp.

To go from #2 to #3 for all your asset library roughly means doing all your assets again. It would take a good artist hundreds of hours of work.  This would put a burden to your pocket and probably to the artist’s morale as she’d have to do the same things all over again instead on working at something different.

To go from #3 to #2 is a matter of resizing to the dimensions you need.  The following image shows some platforms that we could export to from one 300 DPI source file. Don’t worry, this is not a sneaky announcement for iPads with Retina display (although, you never know).

Scaling Downwards

When the artists draw at the high quality resolution, details seem crystal clear and fine line-art shows. When you scale it down you must sacrifice a ton of detail. The trick is to sacrifice non-crucial detail –  detail that does not define the image itself.

One very important thing to remember is that even though the artist might draw at a high resolution, she must often check how the end result looks like in other resolutions as well. Previewing the work while it’s being created, on the intended medium scale, should be an integral part of the artist’s task.

Even when dealing with vector graphics, where scaling up or down is much less painful than raster,  keep in mind that line art will scale accordingly. If you have fine line-art, scaling an image down will make thin lines disappear. If this line-art actually ‘defines’ your illustration, then there’s extra work to be done, thickening those lines.

Detail Overkill

Put only as much detail as you’re prepared to pay long-term. Most of the times, there is no point dealing with assets with a ludicrously high quality. The software that you use might get slow and unwieldy, documents may crash, hard drives fill up faster than you’d like.

Think about what the actual size of the asset will be on your primary medium. Consider if the slower completion times are worth the steep increase in detail.

Using assets elsewhere

Keep in mind that if you want to use assets from your game to other mediums, like posters, collector’s booklets, printed DVD covers, t-shirts or a magazine advert, you will need high-resolution assets, otherwise it will look bad. And there’s nothing worse than beautiful artwork printed in bad resolution.  Or wait, there is: Bad artwork printed in bad resolution. (Here’s the antidote to that link).

Identify the key assets that make up your game such as the logo, music, video, and characters and invest towards higher quality.

Conclusion

The first convention about assets boils down to this:

You more easily scale down, than scale up. Future-proof assets justify the cost.

Study your project carefully and strike a balance between quality, quantity and scalability of assets. Find your game’s golden ratio between cost and future-proofing. Do not limit yourself to the current device you are building on.  When porting a project to different platforms, high-quality assets will save you both time and money which you can then spend to properly polish the game for each platform.

]]> http://blog.totaleclipsegames.com/managing-assets-part-1/feed/ 5 http://blog.totaleclipsegames.com/the-clockwork-man-steampunk-goes-casual/ http://blog.totaleclipsegames.com/the-clockwork-man-steampunk-goes-casual/#comments Wed, 16 Feb 2011 13:00:01 +0000 Argiris Bendilas http://blog.totaleclipsegames.com/?p=266 Continue reading →]]> This article was originally posted at Gamezebo.com on Aug. 30^th, 2010. We have since updated some of the images and text.

The birth of The Clockwork Man World

Think London, England, turn of the 19^th century. You are walking down glistening wet streets dressed in your best Sunday dress (or gentlemen’s suit). Something momentarily blocks the sun; you glance up and see a commercial zeppelin flying above, probably bound for Heathrow. The world of The Clockwork Man is much like our own, and yet not. It is filled with wonders of Steampunk fiction, where the ingenuity of the industrial revolution blends with futuristic steam-powered machines. An amalgam of anachronistic technology, Victorian values, fashion and décor makes up this familiar and yet fictitious world that had never been attempted in a casual game before. Back in 2008, creating something like this was quite a challenge (and risk) for us in Total Eclipse.

How could we make such a place believable and inviting? To familiarize ourselves with this intriguing era, we researched numerous sources: from Jules Verne’s works to websites of Victorian antiques.  Robert, our writer, is a huge Steampunk fan and his enthusiasm fueled our vision for something grand. Thus we began designing the first Clockwork Man.

It’s hidden object, but not as you know it.

Story and setting alone are not enough to make a game stand out; gameplay comes first. We focused on taking the hidden object genre to new levels, by “introducing a twist”.

We looked at hidden object games of the time and realized that they shared a common characteristic; you were always looking for objects in a static area. We came up with the idea of introducing multiple layers in each scene, essentially giving it more depth.

This was the birth of zoomable and scrolling scenes, two terms that we coined just for the occasion. Zoomable scenes usually consist of 2 levels; the zoomed out and the zoomed in one. The player can seamlessly move between the two, feeling as if she’s moving forward or backwards in an area.

Whereas in “traditional” hidden object games you search for items on one screen, now you’d have two or more. That increases the scene complexity and offers more quality playtime, as players can now explore what in essence is a larger area.

Scrolling scenes are made up of images positioned at different depths. The players feel like they are actually moving around and inspecting an area. The movement can be horizontal or vertical. Scrolling scenes also add rich complexity to a location. Instead of looking for objects that are visible on the screen the whole time, you have to move around to find some of them. You see, front layers may be covering objects at one angle but not when looked at from another one.

Zoomable and scrolling scenes are much more expensive to design and implement, because they require multiple graphics per scene. They usually cost thrice as much as a static one.

Both of these mechanics also required extensive prototyping as they had never been done before and we frankly had no clue if they would even be playable! We were actually told that our idea wouldn’t work at all, and we had better emulate what others were doing at the time. Luckily, we didn’t listen.

The visual style of The Clockwork Man

Apart from the unique gameplay mechanics, we wanted our game to stand out visually. We set out to discover a style that would be vibrant and immersive to the players.

Zsolt and Peter, our background artists, turned our vision to reality, giving life to this enchanting world by drawing and painting everything by hand. Starting with rough sketches, to clean-ups and finally painting over line art, they created the world where our characters would live in. The naive, yet determined, Miranda and Sprocket, her adorable robotic friend, would soon be flying from London to South America to discover the truth about Miranda’s grandfather’s secret experiment.

After 13 months of hard work The Clockwork Man was released in March 2009. By that time we had gone over the game’s available budget from our Publisher. However, we were elated to discover that not only did we gain a lot of loyal fans, but the players were thrilled with the new ways to find hidden objects.  A scant week after the game was out, people were already asking for a sequel. We knew we had to go back to work!

The Clockwork Man: The Hidden World

No matter how hard you work on something, it will never be perfect. We gave our best for The Clockwork Man, yet, given more time and money, we could have gone further. Realistically though, at some point you just have to release the game.

As we begun work on the sequel, players’ reviews and comments started coming in. It’s important to go beyond praise, and see what people didn’t like much. Armed with that knowledge, we set out to make The Clockwork Man: The Hidden World a greater success than its predecessor!

We would keep everything that worked in the first game, even improve it, and fix/adjust/get rid of anything that players didn’t like. We had the same Publisher money as for the first game, yet we wanted to make something grander.

Listening to our players

Most people liked the first game’s story, but also felt that it ended abruptly. We wanted to ensure that everyone who followed the sequel’s story would be overly satisfied. One of the toughest challenges was to extend quality gameplay time and integrate it seamlessly with a rich storyline.

Everyone loved the graphics of the first game. They were definitely one of the production’s best assets. For the sequel, we created even more vibrant scenes spread over varied viewpoints and added animations. We filled them with era-consistent objects, each of which required an hour, on average, to make. Athina, our illustrator, hand-painted over 700 of those objects.

The novelty of the scrolling and zoomable scenes was brought back for the sequel. We multiplied the number of scrolling scenes – even introduced a vertical one, inside a treehouse, which seemed like a great place for us to do so.

Sprocket

Everyone seems to adore Sprocket, although he never utters a word of English during the games! Instead, he speaks in robo-tongue and only Miranda understands him. Often opinionated, and sometimes mischievous, he is a loyal friend, and in the sequel we gain insight as to how strong their friendship is. Sprocket was our take on the boring ‘hint’ button. Each of his gadgets is tailored specifically for him and the gameplay. We went through numerous design iterations to make them work contextually.

The Hidden World

Designing the Hidden World was another huge challenge. It had to be a land that would instantly amaze the players; it had to blend a primitive world with a birthplace of technology. Above all, gameplay had to make sense. This proved to be the most daunting task, since the last 2 game chapters take place there. We can’t say much as it would spoil the fun, but we were influenced by wildly different things like: Easter Island, Eden Project, pahoehoe, and the movie “Metropolis”. We hope that we have managed to pull it off well!

Puzzles, Cutscenes and Music

A lot of players asked for more puzzles and we listened. For the sequel we created 14 original puzzles. They were the most costly features of the game. Each puzzle relates to the story and location; they are different from the usual staple of brain-benders. The majority of them were designed from scratch. We pride ourselves for having created these unique experiences that tie to the overall story arc.

The puzzles cannot be skipped. To us, it does not make sense to create a game where you can just skip parts of it. It makes sense, however, to have a robust hint system. We programmed progressive, detailed hints available from Sprocket- so detailed that for some puzzles Sprocket shows how they can be solved. Along with the puzzles, the sequel has many more interactive or, as we call them, adventure, moments.

We also wanted to give the game a cinematic feel. At first, we toyed with static, single-screen, black and white cutscenes. In the end, we went for something more exciting. We created animated cutscenes, with tailor-made music and voice-overs.

Music, in an atmospheric game, can really boost the player’s experience, so we asked the music composers to give us their best. In the end, one can enjoy a beautiful soundtrack of over 40 minutes of original music that can also stand on its own. We’re very proud of the outcome.

The DRM-free approach

After 14 months of production, having spent more (again) than the available budget and ending up paying from our pockets, The Clockwork Man: The Hidden World was released mid-July 2010. As a special treat to those who chose to purchase directly from us, we decided to offer the game DRM-free. This means no serial numbers, managers or other pesky things. Also, the price would include Windows and Mac versions [ed: and later on Linux], plus our companion Guide.

People really appreciate the ability to play their owned games without DRM and on their platform of choice. We believe this to be again a first for the casual scene. After the Clockwork Man series, we are now making all our games DRM-free.

We hope that you will appreciate the hard work that has gone into the development of The Clockwork Man series and most of all that you will have tons of fun playing the games!

As part of our next game update, we wanted to let players import an outfit that a friend had sent them. In other words, if the receiving player had the game installed on her device, she could import the styling selections of her friend directly into the game.

The easiest and most obvious way to do that was to use Custom URL Schemes.

Custom URL Schemes

A URL is formatted like this: schemeName://host/path?query.

The scheme name of a URL (also called protocol) is its first part. For example http:// or ftp://. Except for the natively supported schemes, http://, https://, ftp://, mailto://, tel:// and sms://, iPhone provides the ability for developers to specify their own custom schemes.

When a custom scheme is called, the corresponding application is executed, with any optional parameters that may be passed on. For example this is the way the Facebook app is called from inside other applications. So, a custom URL is the way to run an iOS application externally via a hyperlink, with the ability of passing along additional parameters.

Defining a custom scheme is pretty easy. All you have to do is add a few fields in the info.plist file of your application.

For Maya’s Dress Up we defined mayasdressup:// as the scheme name.

Passing data

The information we needed to pass through was an ‘outfit’. Outfits in the game are serialized in a format such as bgid|modelName|garment1|garment2|garment3. The custom url would then be something like: mayasdressup://?outfit=bgid|modelName|garment1|garment2|garment3. The part after the ‘?’ is the query of the URL.

Parsing data

When the user clicks on the custom URL or types it on the browser, our application is launched, carrying the query parameters. We can then parse the query string and extract the desired information. This happens in the application:didFinishLaunchingWithOptions: method.

- (BOOL)application:(UIApplication*)applicationdidFinishLaunchingWithOptions:(NSDictionary *)launchOptions {

	// Initialize the application
	[self initApplication];

	// LaunchParamManager is a class I created to hold launch information. It will be used later in order to apply the launch options

	launchParamsManager = [LaunchParamManager new];
	BOOL result;
	NSURL *url = [launchOptions objectForKey:@"UIApplicationLaunchOptionsURLKey"];

	// Check the scheme to see if the scheme is the one we have defined for our application (your app may use other schemes as well, for example if you have implemented Facebook connect)
		if ([[url scheme] isEqualToString:@"mayasdressup"]) {
			[
			launchParamsManager parseAndStoreAppLaunchParams:url];
			result = YES;
			}
		else {
		//	iOS 3.2 has a slightly different behaviour,so we need to take that into account
				if([[[UIDevice currentDevice] systemVersion] hasPrefix:@"3.2"]) {
					[self application:application handleOpenURL:url];
				}
			result = NO;
		}
	return result;
}

We had to unserialize the data and store the Outfit object somewhere, so that we can access it later in the code, when the app had finished initialization. So we created a class called LaunchParamManager that does exactly that. This helps keep things organized.

NOTE: One important thing to remember here is that the various delegate methods need to be implemented in a certain way, so that the code works well in both multi-tasking and single-tasking devices. Make sure you do NOT implement the applicationDidFinishLaunching: method in your app, but rather go with application:didFinishLaunchingWithOptions:. Apple recommends that anyway.

Also you’ll need to implement application:handleOpenURL: This method is called when the application is already running in the background, on multi-tasking environments.  Here’s what we did with it:

- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
		if (!url) {
		// The URL is nil. There's nothing more to do.
			return NO;
		}
	// Check custom outfit
	NSString *scheme = [url scheme];
		if ([scheme isEqualToString:@"mayasdressup"]) {
			[launchParamsManager parseAndStoreAppLaunchParams:url];
			return YES;
		}
	return NO;
}

This is the method parseAndStoreAppLaunchParams: inside LaunchParamsManager class:

- (void) parseAndStoreAppLaunchParams:(NSURL*)url {
	NSString *query = [url query];
	appLaunchParams = [[NSMutableDictionary alloc] init];
	NSArray *pairs = [query componentsSeparatedByString:@"&"];

		for (NSString *pair in pairs) {
			NSArray *elements = [pair componentsSeparatedByString:@"="];
			NSString *key = [[elements objectAtIndex:0] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
			NSString *val = [[elements objectAtIndex:1] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];

			[appLaunchParams setObject:val forKey:key];
		}
	[appLaunchParams setObject:[url path] forKey:@"path"];
}

What it does is store the URL data in a simple dictionary object, so that they are around when needed later on.

After parsing the custom URL params and storing that information, we should apply them. We do this in 2 places: 1) when the application has just being launched (as soon as the UI was ready) and 2) when the application has just become active, after going to the background, at the applicationDidBecomeActive: method, because this is the method that executes when the app resumes in a multi-tasking environment.

There is another post that explains all this pretty thoroughly.

Encoding

We didn’t want to show the exact structure of an outfit to our users, so we created a simple encoding function that created a non-readable representation of the outfit. We used a simple bit-shifting algorithm, which created urls that looked something like this:

mayasdressup://?outfit=jjucek%29ie%7CmnhHmdbt%60%7CJbh~%24%40f%60hmfAsmkgodxtFfd%7C%5BizC%60%7
Dg%2FCmj%7Bgn%60dQodi~god%7F%7BVlqpXwqq%60m.UnedgNhh%5BijsxtVf%60%60%24Gwiba
aP%60blcorp%5Bcge%60m%40qn%7Bf.QtjnnfCmo~Tie%7CgPlccg%27uoe3ghbald

I know this isn’t very pretty to look at, something that could probably alienate a user that finds this link in her email, but it is something that we couldn’t avoid.

One important issue to note here is the form of the URL after the encoding has been applied. As you may see, there are instances of the ampersand (&) and slash (/) characters. Unfortunately these characters are also used as seperators when parsing the query. Remember that a URL goes something like ‘…/foo/?param=value&param2=value2&param3=value3’.

In our case, the & was an actual character, not a separator. So we had to escape the string. We tried [NSString stringByAddingPercentEscapesUsingEncoding:] but this encoded some characters, while leaving the ampersands and slashes intact (this took about 2.5 hours to notice, because the encoded string was big and difficult to read…)

The solution came with a CoreFoundation function, CFURLCreateStringByAddingPercentEscapes().

CFStringRef encoded = CFURLCreateStringByAddingPercentEscapes(
 kCFAllocatorDefault,(CFStringRef)textToEncode, NULL, (CFStringRef)@";/?:@&=+$,", kCFStringEncodingUTF8);

his created a string that was indeed properly formatted and I could parse it when the custom URL loaded.

Conclusion

Implementing a custom URL scheme with an extra encoding layer was not very difficult but it wasn’t very straightforward either. I had to look up a lot of stuff online throughout this and I ran into a few issues. We are launching this sharing feature on our next app update (probably within 2 weeks) and we hope users will much fun with it!

It’s also no secret that most of us will be generally risk-averse, especially when times are tough and the economy is stingy. This pretty much describes our current situation here in Greece; the state of the economy is really awful. In my opinion, though, it is during times of recess that breakthroughs and new ventures can be made.

Being an indie, either as a solitary developer or part of a small team gives you a greater flexibility to just listen to your gut (and do what it says) for a change. Of course the risks are also there; there will still be mouths to feed, and utility bills to pay. The fact that you don’t pay as much as Ubisoft does, does not mean that your expenses are in any way less significant.

So, what to do? I think the answer lies in rapidly prototyping your ideas. And when I say rapid, I mean one week MAX. As a result, by knowing that your time (and money spent) will be limited, you can risk. Before I begin with the points as to why it may be good let me just say: World of Goo, Flight Control, Angry Birds all were side-off/experimental/rapid design products.

One Week Design Dash

Commit to it

If you’re too busy with other stuff, don’t start the Design Dash. If you really want to do it but don’t have the time, try a 1-day/weekend/3-day dash (see below). In any case, it should not be attempted if you, or others in your team, are under a hectic schedule.

Brainstorming meetings

Ditch them. It’s really difficult to have creativity on tap. Not everyone is creative at the same time every day. You can’t just schedule a meeting and say you’ll have a kick-ass idea/prototype by the end. On the contrary, brainstorming for specific stuff might well work i.e. a feature that you’re thinking to add.

Have everyone participate

It’s just a week so make good use of it. Instead of one prototype, ask for four/five –as big as your team is. Each one should have one. This would be good for friendly competition and since everyone would be working on something they have created, they will be having fun and go that extra mile!

Settle on a theme

I’m a bit on the fence on that, but I think it is good to have a focus ‘theme’ when doing the One Week Design Dash. Theme could be anything from “insects” to “noir”, “spooky”, “flying hero”, etc.

Notebook and pencil

Before you start making nice looking Gannt charts, try the old and trusted method. Jot your ideas on a notebook. It does not matter if you cannot draw well – make simple shapes to highlight the basics of the gameplay and the world feel. Use props (i.e. cuts from magazines) if you feel like it. Sketches on iPod/iPhone/iPad might work well for some, too.

If it’s not fun, be brave and throw it away.

The purpose of this experiment is also to know when to stop. If what you’ve created is not pure simple fun, no amount of snazzy graphics and elite code will save it. It’s better to forfeit and go for your next great idea.

All done, now what?

At the end of the week you should have a fairly good idea whether your fledgling prototype is worth investing any further time into. Whatever happens, I do not believe this week would be ‘a waste of time’ as the experience gained would be very important.

Shorter Dashes 1 day/48 hrs

Sometimes time is limited and we cannot afford the luxury of a week. A day/weekend dash would be just the thing to do. To make it even more fun, try and invite other game developers from your area and ‘jam’ together . You may be surprised at the outcome.

Want something to get started? Take part in the Global Game Jam 2011 supported by IGDA and  taking place between 28-30th of January. Find a location next to you or add your own.

Still not convinced? See the highlights of last year.

Some helpful links

This 2005 post on Gamasutra is a real gem and has been a huge influence on the way I think about rapid design.  It inspired the Experimental Gameplay initiative.  It is no chance that the overseeing /project co-ordinator was Jesse Schell, one of my favourite game designers. I believe it is a seminal piece.

Another great article on rapid prototyping with a good list of links to follow up.

Like everyone else who gets involved in application development for the iOS App Store we were very curious to see how it would perform.

To date we’ve had a bit more than 1,700 sales for both devices and we estimate it would take us at least 6x that amount before we recoup our original investment. At the same time we’ve already got planned a lot of updates and improvements for the game, which will hopefully help it perform even better in the coming months.

Monitoring the sales and ranks of both our applications on the App Store has been part of our every day routine, since they were released. It’s a nice thing to see when you get a spike (it’s true that on weekends sales go up!), but then you have to spend some time thinking what could have caused that spike.

Unfortunately Apple doesn’t provide any kind of insights as to what works and what doesn’t with one’s marketing efforts, something that people have been requesting for sometime now. In the end you’re left guessing…

The experiment

Although Greeks ourselves, we usually don’t pay much attention to the regional App Store, as we’d only had 9 sales from it in the first month. This Monday, however, I noticed a spike in sales for the iPhone edition, coming from Greece, in one of AppFigures‘ great reports.

What stroke me as odd was the fact that this spike was enough to send us climbing to #4 of the Top 10 of the Kids category and mind you, that spike was caused by less than 5 units of our app sold. It felft exciting to see our game at that spot, but soon it got me thinking. If such a low number of sales is required to jump that high in a category, what would it take for us to get in the overall Top 25 of the Greek App Store?

We set out to find out! Using Facebook and a couple of phone calls, we asked everyone we knew who had an iPhone or iPod Touch to buy the game and tell their friends to do the same (we promised we’d buy them beers, sweets and coffee in return ). At the same time we kept checking our rank on our devices.

Lo and behold, a few hours later we had climbed to #1 in Kids, #4 in Family, #12 in All Games and finally to #37 in the overall Top 50 of the Greek AppStore! We kept the promotion going stronger and at about 30 minutes before midnight we had reached #29 in the Top 50.

Seeing how not everyone had replied to our Facebook messages and that we’d ran out of contacts to tap to for support, we settled with the idea we wouldn’t be making it to the Top 25 that day.

I went home wondering how many sales had brought us to that position. I estimated 25-30. I would find out the next day, at about 1:30pm, which is when we usually get last day’s reports.

The day after

The number was small, sad and apocalyptic. Less than 15 units were enough to take us to the Top 50 of Greece’s App Store in half a day! I guess that covers “small”. But why sad and apocalyptic?

Well, one could assume that there aren’t many apps available in the Greek App Store, so it’s easy for one to climb high in the charts. To my knowledge there are hundreds of thousands of them for sale here and over 93,000 iOS devices owned, so it can’t be that. Well, then, there is only one explanation left; not too many Greeks purchase applications on the App Store.

That’s very unsettling, since it indicates that there’s so much piracy here that the top charts are formed by those few who actually pay to get an application. It wouldn’t surprise me to learn that most Greeks have jailbroken devices, in order to have access to everything for free. And that is sad!

Lessons learnt

If you were thinking of developing an application for just the Greek App Store I would advise you otherwise. Unless it’s free, of course. Then I’m sure it would be greeted with the utmost enthusiasm!

Making it to the Top 50 of a country’s App Store means nothing, if that store is weak to begin with. Although piracy is less common on iOS devices compared to other platforms, if Greeks are involved they’ll find a way to make the best of it; piracy, that is!

It is important to have people that will help out on the spot, in an experiment such as this, even if it takes some… bribing to get them to do it! (thank you guys and gals! )

Finally, if your experiment makes you less than $30 and you’ve promised drinks to over 20 people, then something’s wrong!

They say “better late than never” and this is very fitting for us finally starting a blog, after being active in game development since mid-2004.

There are a lot of people who simply have no idea of our existence (even in our own country) and it is due to our introversion these past years. We have, however, been actively getting out of our shell more often, especially since our first public talk in Open Coffee Athens (Apr. 7, 2009).

This blog will serve as a mean for us to publicly write our thoughts about the Industry, our games and those of other developers, our design process and generally share information that will hopefully help you all in a way.

Let the writing begin!