Tag Archive | "Development"

The Big List Of Game Development Resources

Posted on 07 September 2010. Tags:

Big resource for game development related things…
Enjoy :)

Game Programming

Game Design

Graphics

Music & Sound

Game Programming

GAME ENGINES

SOURCE CODE EDITORS

PROGRAMMING TUTORIALS

USEFUL TOOLS

Project Management Tools

GAME DESIGN

GAME DESIGN

GRAPHICS

IMAGE EDITORS (PIXEL)

IMAGE EDITORS (GENERAL)

ONLINE IMAGE EDITORS

PIXEL ART TUTORIALS

PIXEL ART FORUMS

PHOTOSHOP TUTORIALS

PAINT.NET TUTORIALS

GIMP TUTORIALS

MUSIC & SOUND

ROYALTY FREE MUSIC

(note: read licences before you use the music)

FREE SITES

COMMERCIAL SITES

ROYALTY FREE SOUNDS

(note: read licences before you use the sounds)

FREE SITES

COMMERCIAL SITES

INDIE MUSICIANS

CREATE YOUR OWN MUSIC & SFX

DIGITAL AUDIO WORKSTATIONS

This list was created by PixelProspector.com © Copyright 2009-2010. This work is licensed under a Creative Commons License.

Posted in DevelopmentComments (0)

Self-publishing on XBLIG

Posted on 18 August 2010. Tags: , ,

Fritz from Triple B Games prepared this excellent guide to self-publishing on XBLIG. Triple B have just self-published the rather superb looking NLL Lacrosse 2010 on XBLIG, and prior to that Fitba, also on XBLIG…

XBLIG is an open channel on the Xbox 360 that allows indie developers to sell their games through the Xbox 360 dash without requiring any platform holder approval. Games developed for XBLIG must be developed in C# using the XNA libraries provided by Microsoft. In order to develop & release on Xbox 360 a Creators Club membership is required, priced at £65/$99 per year.

The Good Stuff

  • Open channel, no platform holder approval required.
  • Channel not flooded, currently just over 1000 games available on the channel.
  • Reliable sales tracking and payments from Microsoft, games can be priced at 400,240 or 80 Microsoft points, ($5/$3/$1) with Microsoft taking a 30% cut. Sales and trial download figures are available daily, a day after they have occurred.
  • No ESRB or PEGI ratings are required, although Indie Games cannot be purchased by child accounts.
  • Development is done on retail Xbox 360’s – no devkit costs.
  • Active and friendly community at http://forums.xna.com/forums/
  • Use of avatars in game, although there are restrictions as to what you can do with avatars, you can’t dismember them, dress them, have them talk etc.
  • You are issued with codes to distribute review copies for your game once it has passed peer review.
  • C#: Once you’re used to C# going back to C++ feels primitive.
  • Releasing games developed in XNA is possible on XBLA, there are extensions available for registered developers that add support for Leaderboards & Achievements.
  • Conversion ratios are good – over 30% for the best titles.

 

The Middling Stuff

  • XBLIG aren’t for sale in all territories, they are currently only available in the U.S., Canada, United Kingdom, France, Italy, Germany, Japan, Sweden, Singapore and Spain.
  • Localisation is supported, but it slows down the approval process as each language submitted has to be separately approved before the game can be released.
  • The Peer review process can be frustratingly slow, around 2 weeks per submission, with an enforced weeks delay before resubmitting if your submission doesn’t pass.

 

The Bad Stuff

  • XBLIG are treated a bit like the red-headed stepchild of the Xbox 360 family, shunted off into their own channel in the dash, they don’t show up if you search All Games. Potential players have to navigate to the indie games section of the dash to find your game.
  • No achievements.
  • No support for Live Leaderboards, although various peer to peer leaderboard methods have been developed to get round this.
  • In game advertising is prohibited.
  • C#: if you’re thinking of porting an existing game you’re going to have to convert to C# & XNA, if you’re writing a game specifically for XBLIG then you’ll most likely have to convert to C++ if you wish to target another platform.
  • Sales numbers don’t compare to AppStore numbers – the best selling game (I MAED A GAM3 W1TH Z0MB1ES!!!1) has gone over 200k units @80MSP.

PC development using XNA is also possible, although you are not allowed to use avatars or the Live Networking functionality, and Windows Phone 7 game development is going to follow the XNA\C# route.

Sales figures are posted by developers in this thread http://forums.xna.com/forums/t/28044.aspx or if you don’t fancy wading through the 60 odd pages of that you can see how the top 20 games of 2009 did in this thread http://forums.xna.com/forums/p/45585/272243.aspx#272243

Posted in Self-publishingComments (0)

ReplicaNet – Game Networking Middleware for Indies

Posted on 18 August 2010. Tags:

We are looking to start a series of articles from Middleware Companies & Contractors offering indie specific services at a realistic and affordable price point. So first off we have ReplicaNet and RNLobby, so over to Martin at ReplicaNet…

With online games becomming more complex the need for well behaved bandwidth saving technology increases. ReplicaNet and RNLobby are two network APIs designed to tackle two different areas of game networking, session management and lobby. 

ReplicaNet is a session management and object description API that enables C++ game objects to be described as a collection of class member functions and class member variables with network update filters. Each C++ class is treated as a potential network shareable object on the machine that allocates it. This machine has control over the C++ classes and can change variables or call member functions as normal. Once the object is ready to be shared to other machines the object is published on to the ReplicaNet network session. The underlying ReplicaNet software detects changes in the object and automatically updates the replicated classes on the machines connected to the network session. Any changes made to the member variables of the C++ classes can be extrapolated by ReplicaNet using several pre-defined filters to reduce the amount of network traffic when transmitting changes in the object. As network games tend to have increased in complexity a visual debugger (RNVisualDebugger) is included to aid the developer to spot network bandwidth spikes and drill down to which class members are causing the problem. Armed with this debugging information tweaking the class member’s filter parameters can help reduce the network bandwidth used by the session.

RNLobby provides lobby functionality and the tools needed to maintain a persistent online space for online games. Features include binary difference file patching, CD/license key verfication, NAT detection and punch-through, advertising of game sessions, user account creation, persistent user data storage and statisics for game sessions.

The creator of ReplicaNet, Martin Piper, has spent a long time in the games industry since Argonaut Games was on the scene writing Star Fox and knows what it is like as an indie trying to get a project off the ground.

So for the indie developers if you mention Indievision when talking to Replica Software you can receive a discount on their libraries and other services. Martin also contracts out his services for helping with multiplayer game coding.

http://www.replicanet.com/

Posted in DevelopmentComments (0)

Suisoft’s Gravity Core – Game Project Postmortem

Posted on 04 August 2010. Tags: , ,

Game Project Postmortem by Gary Marples

Gary Marples, the owner of Suisoft, a small development studio based in Wakefield, UK put together this excellent Post Mortem for his game Gravity Core. A very illuminating read about the development process and how things went after release.

Gravity Core

Game Information:

Released: November 2007
Publisher: Suisoft Limited
Website: www.suisoft.co.uk/gravitycore/
Genre: Retro Shoot-em-up / Inertia
Platform: Windows PC
Budget: Tuppence*
Project Duration: Too Long**
Team Size: One Developer
Software: Microsoft Visual C++, Cinema 4D, Goldwave, Jasc PaintShop Pro (prehistoric edition)

* Realistically if assuming a small salary and business setup costs, around 20,000 dollars (10,000 pounds). In reality, I didn’t pay myself anything during development.
** 12-15 months, although only around 10-12 months full time.

Background

Ikari Warriors The initial spark of Suisoft (and Gravity Core) stems back many years to an eight year old obsessed with computers and arcade games. The concept of being able to write code into a machine and make it do ’stuff’ by itself was a concept much too intriguing to ignore. The typical modus operandi for family holidays would be to spend too long in darkened arcades playing the latest games (Ikari Warriors and Tiger Heli spring to mind) then arriving home clutching scribbled game designs and constructing imitations of the games.

Many years later, following an IT Qualification and 15+ years in the Information Technology trenches, a corporate takeover (with associated disgruntlement and voluntary redundancy) provided a time to reassess direction and ultimately choose a new path. Gravity Core already existed as a multiplayer gameplay prototype. Playing the game was a regular lunchtime pursuit in which normally peaceable colleagues brutally gunned each other down and rammed each other into walls. The gameplay was inertia based, in the spirit of home computer favorites such as Thrust and Oids, albeit with a more combatative, violent nature.

After much soul searching and weighing of Pros and Cons, I decided to form a company and develop my prototype game into something to sell. My very supportive wife agreed (and indeed encouraged – more on this later) my lunatic plan to take out the best part of a year and try to launch my company and first game.

What Went Right

Iterative Development Process

A core principle I stuck with throughout the entire project was to maintain a working, playable game all of the time and add one feature at a time. This really paid off because code quality problems were kept to an absolute minimum and playing a working game is fun. I would have lost heart with the project very quickly if the game had been in a broken state for most of the time.

Procedural Level Generation and Artificial Intelligence

Blueprint From the very start, I set out to make the maps random. I’ve been fascinated by procedural generation of maps for many years. I created a dungeon game on the BBC during my school years. It was pretty flawed, as the map was generated as you moved around and corridors didn’t join back up. You reached the next level of the dungeon after travelling through a certain number of rooms. I love games that have random elements and emergent gameplay. My favorite game genre is FPS (first person shooter) but the majority of these games are scripted to a ridiculous degree, in that you can draw a bead on an enemy before he even walks around the corner. I could pretty much play the first few levels of Quake 2 blindfold.

With Gravity Core, I started out with a blue print generated from caverns (circles) with adjoining corridors and a mechanism to prevent overlaps. The map structure is then converted into a tilemap with contour tiles applied. Enemies can then be spawned into the rooms (caverns/tunnels). Some caverns are marked as special (for example Factories, Sphere etc) and are populated with more enemies. The number of enemies in a ‘room’ can be tracked to prevent them from clustering too much.

The blueprint is retained for enemy navigation. This allows the enemies to roam freely around the environment, rather than sitting and waiting for the player to turn up. The enemies randomly patrol around when they aren’t chasing the scent of the player.

Overall, I’ve been really pleased with the way the level generation turned out. I’m sure I will be able to take the concept much further in a future game.

Rendered Sprites

Ship Render My approach to sprites (ships, bullets, explosions etc) was to create them in a 3D package and render them using a ray tracing engine. You may ask “why, oh why didn’t you just make a 3D game?” This is a perfectly valid point… for me, making a 3D game is much more time consuming and complex. The skills required to make realistic looking models and maps that will be efficient enough to be usable in a realtime 3D are far too specialised. As a sole developer, building every aspect of the game, I didn’t want to bite off more than I could chew.

Creating the sprites using the 3D package, led to nicely shaded ships and spectacular explosions and particles that were complimented in some reviews. A fringe benefit, is the ability to resize the graphics very easily by adjusting the outputs and also render some of the graphics for use on the title screen.

Sound Effects

Although some reviewers criticised the lack of in-game music in Gravity Core, the reception to the sound effects was good. This is amazing really, considering I created all of the sound effects from samples of sounds in my home environment. Cap guns, fireworks, thunder, electrical motors from vacuum cleaners, gas rings, blowing into the mic, you name it. Looking back, this was pretty bloody-minded. My mindset with Gravity Core was to keep expense to an absolute minimum, to the point of avoiding spending a few hundred dollars on some sound effect libraries. I’ve enjoyed messing with tape recorders and sampler software since I was a kid. I think I enjoyed it a bit too much…

I recall getting up in the middle of the night and recording rain and thunder. This came in very handy when adding depth to explosions and gunfire but didn’t greatly amuse my wife at the time. (By at the time, I mean at the time of recording, rather than ‘wife at the time’ – she hasn’t left me… yet).

Support and New Contacts

I had a huge amount of support from my wife, Rebbekah. She had a lot to put up with, as I endlessly rambled on about the game and later stressed out during business setup and first release, not to mention financially supporting me. Friends and family were also extremely supportive. My Mum and Dad had fuelled my computer obsession since I was seven years old and continued to support my crazy endeavour. Paul “Guffaw” Turner played Gravity Core until his eyes melted and his fingers curled into crippled claws. My inlaws in particular never lost faith in their wayward son-in-law.

I received plenty of support from online gaming review sites, download sites and blogs. Support also came from unexpected quarters, such as other Indie’s giving me suggestions and feedback and Micro Mart printing several snippets of news and ultimately a review – my only review in print, I believe. Hopefully I will be able to build on this support with my future games.

What Went Wrong

Market Misjudgement

Gravity Core My greatest failure with the game has been my complete misjudgement of the gaming market. Gravity Core (in particular the first release) requires a certain amount of effort to become comfortable with the controls. This has led to many players giving up very quickly and never reach the point of enjoying the game. The conversion rate (sales versus downloads) of Gravity Core has been very poor, though there are some hardcore fans out there.

My next game will be much more immediately gratifying. I intend to start with simple, easy gameplay and pile on the toughness further into the game and on higher difficulty levels.

Mainstream Coverage

With Gravity Core, I have really struggled to get any mainstream coverage (i.e. printed gaming press). I think this is due to the traditional retro style of the game (i.e. it is not a quirky or original game that stands out) and distinctly average production values. These elements coupled with the lack of immediacy has made for a very pale blip way under the radar.

I’ve had far more success with niche Indie review sites and somewhat bizarrely (but much appreciated) in the gaming section of Micro Mart.

I think even if Gravity Core had received a four page spread in PC Gamer, an interview and a run of full page ads, the game would still have been a slow seller.

Inability to Give Up

Once I had released Gravity Core and a couple of online reviews had been published, I acted on the feedback received and began a series of releases with selectable difficulty levels, alternative control schemes and significant work on balancing the difficulty. I spent months improving the game but without making fundamental changes to the style of play I never managed to make it accessible. I had gone way beyond tenacity and drifted into obsessive (something of an OCD computer programmer stereotype).

In retrospect I should have written off Gravity Core and started another game. Even now, more than two years after the first release, I am still tempted to create a sequel and tackle the shortcomings. That way lies madness…

Multiplayer Complexities

Because Gravity Core grew from a multiplayer game / engine experiment into a full game, I put an enormous amount of effort into coding and testing the multiplayer aspects of the game. Testing a multiplayer game is much more labour intensive, as the number of situations and glitches are much increased. Additionally, in order to carry out proper testing, you need to pull together a group of players. Throwing this into a test/fix cycle really drags out a release. Unfortunately, the majority of players never tried player versus player or co-op and the game received much criticism in reviews over the lack of matchmaking, internet and wireless performance. My efforts would have been much better redirected to content and variety.

Too Many Hats

Gravity Core Every bit of code, graphics and sound in Gravity Core was my own (with the exception of music – I love listening to it, but Rob Hubbard I aint). Additionally, I had a business to set up, website, marketing, support and anything else that goes with developing and releasing a piece of software. This lead to a lot of stress and 3am moments. On several occasions I laid awake in the middle of the night with my head refusing to switch off, wondering why I would want to do this to myself and not just crawl back into an office job.

Having battled through to the bitter end, I feel a sense of achievement having finished Gravity Core and booting it out of the door. The weakest area (aside from immediacy) is probably the art direction, both music and visuals. The ships and explosions look nice enough but the title graphics and backgrounds and pretty plain and underdeveloped. The maps were described as ‘lacking a sense of use’ in one review, which is pretty apt. I had piles of sketches and ideas for mining equipment, buildings, crystals and wall decorations that never made it into the 3D package or paintshop.

The Future…

In terms of commercial success, Gravity Core has been a misfire. On the plus side, there are a number of fans out there enjoying whizzing around the caverns and revelling in their skills and that’s something I really get a kick out of.

The end result has been a huge (often brutal) learning experience for me, proof to myself and others that I can get a game out there and a stack of re-usable code and business bits.

I have lots of ideas (more ideas than time, like most game developers) and have a hybrid retro game coalescing in my brain. Something may well emerge next year.

In the meantime, you can try out Gravity Core here: www.suisoft.co.uk/gravitycore/

Posted in Development, InterviewsComments (0)

Game Design using The Quad

Posted on 19 June 2010. Tags:

What is a game? Evolution embedded play into the very fabric of being human, so this is a question that has been pondered since the dawn of man. It may be somewhat baffling, then, that we are still unable to reach a consensus.

Searching the web for the “definition of a game” will unearth many different explanations, each described by someone who sees games in a disparate context. The more diverse definitions you read, the more it becomes clear that “game” is one of those words that’s overloaded with meaning. If you consider that we derive what a game is from our own personal perception of play, it’s not surprising that there are as many definitions as there are individuals.

The flexibility of the term becomes a problem if you want to analyse an existing game, or create a new one. In order to design a game, it’s essential to understand the building blocks at your disposal. We can model a game in an infinite number of ways, all different, and all valid. But to be useful, a model must be complete, whilst remaining simple. It needs to be elegant.

While at this year’s PAX East I attended a panel presented by the creators of the GeekNights podcast, Brandon DeCoster and Scott Rubin. It was called “Beyond Candyland”, and sought to explore the theory behind the best German-style board games. They identified “Decision” as the distinguishing factor between games rooted in “Randomness”, like Monopoly or Trouble, and games of skill, like Puerto Rico or Dominion.

Both Randomness and Decision can determine who will win a game, as an event of either will alter the probability space of the game yet to be played. The difference is, you have complete control over the decisions you make, and can take gratification from your performance if you’re victorious through Decision. This is why we favour games that are more heavily weighted towards Decision over Randomness.

As well as Randomness and Decision, the GeekNights duo completed their model of a board game with “Psychology”. Psychology consists of the elements of a game that can not mathematically change the outcome, but augment the rules, like story. A player could choose to completely ignore the Psychology in a game, as it does not alter the probabilistic outcome of the decisions they can make. Poker is an example of a game that is almost pure Psychology. The cards you are dealt are determined through Randomness, and the probability of your hand winning against an arbitrary number of hidden hands is a solved problem. In theory you should only bet on hands with a probability of winning of more than half, so the Decision is made for you. Poker would be a pretty boring game if everybody followed this strategy, simply becoming a game of the luck of the draw. The fun of Poker is in reading and bluffing your opponents, trying to beat the odds. It is a game of accruing or falsifying information outside of the rules of play, which is achieved by reading and influencing human Psychology.

Randomness, Decision and Psychology comprise an elegant model to describe board games, but it needs a bit of work to be able to be applied generally to all games. Brandon and Scott observed that if you add Physiology as a fourth component, we are able to extend the model to include sports. They proposed that when a game rewards dexterity, strength, speed or stamina, it becomes a sport, and that perhaps videogames can be considered sports. I would draw a semantic line between videogames and sports, but agree that both are categories of games that can be classified by this simple, four-axis model.

The model is intuitively complete. All human faculties are addressed, any rule system can be specified, and we can describe all environments in which a game can be played. We now have an elegant model for the entire universe of games. Every game can be constructed from four components, and four components only: Randomness, Decision, Psychology and Physiology. This is an incredibly powerful observation, as it gives us a vocabulary we can use to accurately describe a game and compare it with any other game.

I’ve dubbed this model “The Quad”, and find it particularly useful when dissecting videogames. It’s a common crutch to say that you like a game because it’s fun. However, fun only describes what you feel when your body produces the chemicals to reward achievement. In order to understand how this state of elation is induced, The Quad can be used to identify which aspects of a game lead to you having fun. You can then look for these components in other games, or aim to recreate them in your own.

To summarise, the four elements of The Quad are:

Psychology
The aspects of a game that do not form a part of the rules, and so do not directly influence the outcome. They can have an indirect effect however, if the the player chooses to let them prejudice their decisions. These aspects can include story, character, and environmental themes.

Decision
The rules of a game whose execution are governed by player decision. The probability space of the remaining game is tangibly altered by the branches of its decision tree the player chooses to navigate. That is, the chance of a player winning or losing a game perceptibly changes with their choices.

Randomness
These are the parts of a game’s decision tree that are traversed randomly, without player input. The probability of one decision occurring over another is either specified when the game is created, or is seeded by a dynamic source during play.

Physiology
This describes the portion of a game whose outcome is influenced by the player’s physical ability. The chances of winning or losing are impacted by a player’s dexterity, strength, speed or stamina.

Let’s consider the practical application of this model to a game that a large number of contemporary titles are based on: Quake. Quake’s core gameplay requires the player to position and orientate a 3D camera, and fire a variety of projectiles along that camera’s line of sight. The targets given to the player in the game comprise of either other players or enemy controlled AI. We can break down the sequence of events in a typical piece of play to see which aspects of The Quad Quake is built from.

First, the player must decide where to position their camera to best target their opposition. This decision will be affected by the player’s memory of the map, and the dynamic information that’s being fed to them through the display and speakers. Once a decision has been made, the player must execute the correct sequence of inputs to move the camera, and release their projectile. Their success will be determined by the appropriateness of their original decision, and the speed and accuracy of their execution. The same measure of success is applied to the player’s opponents, and the winner is calculated in a straight comparison.

Decisions made in Quake can dramatically alter the result of an encounter, but do not trump a player’s superior dexterity. Good decisions alone can not overcome an opponent’s dominance of Physiology. This is mainly because the various guns in Quake require more than one hit to kill an opponent. Although making the superior tactical choice allows you to position yourself to fire the first shot in an exchange, as soon as you do so, your location is revealed, and your initial advantage gives way to who can land the most subsequent hits. Quick reactions and the accurate execution of prescribed firing patterns will dictate the result from the opening salvo. It’s interesting to note that this equation is turned on its head in other games of the genre, like Counter-Strike, where the increased power of the weapons makes landing the first hit more influential.

As well as Decision and Physiology, we must consider the other two elements of The Quad: Randomness and Psychology.

Randomness governs very little in Quake. There may be a slight variation in the spread and damage of a weapon’s effect, but the importance of this in a battle is superseded by Decision and Physiology. The only significantly random aspect of the game is in competitive multiplayer, where the opposition’s skill level is unknown until the time of play. Although this can be frustrating if faced with an inappropriately superior foe, the continually changing experience of these varying encounters results in longevity.

id Software employed sparse Psychology in Quake, as it had done in the Doom series that went before it. Without any notable storyline, context is given through the visualisation of your camera as a gun, and by presenting identifiably hostile targets to aim at. The lack of Psychology did not diminish Quake’s popularity, but provided an opportunity for other developers to evolve the genre by bulking out this aspect in their games.

By combining all of these observations together, we can conclude that Physiology is the primary influence in Quake, followed closely by Decision. Randomness and Psychology are both present, but are proportionally diminutive.

In order to visualise our analysis we can weight each of these elements subjectively. This allows us to draw a waffle chart, whose shape represents the genre of a game. We’re able to compare this type of diagram to those for other games to determine their similarity.

Waffle Chart showing the elements of Quake as classified by The Quad.

Other first person shooters would have a very similar chart. As mentioned above, most extensions of the genre concentrate on creating unique Psychology to set themselves apart. These variations have done very well commercially, but for me the most valid successors to Quake innovate through their Decision mechanics. Good examples of this include Counter-Strike and Left 4 Dead. Counter-Strike rewards strategy over dexterity, diminishing the power of a talented run and gunner, and Left 4 Dead dramatically changes your foe, presenting multitudes of weaker targets who can overrun an isolated player. The difference in the balance of Counter-Strike’s Decision and Physiology to Quake’s can be seen when comparing their respective charts.

Waffle Chart showing the elements of Counter-Strike as classified by The Quad.

There are videogames that have a very different shape when mapped with The Quad in this way. To illustrate the visual difference between genres, I’ve created a waffle chart for Guitar Hero. Guitar Hero’s gameplay can be described as requiring a prescribed sequence of buttons to be pushed in time with a piece of music. With minimal Decision to be made, except for discerning when to use Star Power, and no Randomness to speak of, the game would seem to be almost pure Physiology. The twist in Guitar Hero is that it offers the player extremely compelling Psychology, casting them as rock stars. From the licensed music providing the beat, to the heavily stylised visuals and plastic guitar controller, the game works very hard to abstract away from its simple gameplay. Few would argue that the combined experience is not successful. By drawing a chart of Guitar Hero, we can see that it looks considerably different to one of a first person shooter.

Waffle Chart showing the elements of Guitar Hero as classified by The Quad.

Although these “genre maps” are able to quickly portray the proportional influence of each part of The Quad in a game, the perceived success of each aspect is not apparent. However, this information can be conveyed by weighting each area with a score. For instance, Gears of War 2 is a highly acclaimed first person shooter in the same genre as Quake. Below is a chart constructed in the same way as we have seen above.

Waffle Chart showing the elements of Gears of War 2 as classified by The Quad.

Notice the Decision, Physiology and Randomness lobes (blue, green and yellow) are balanced similarly when compared to Quake’s or Counter Strike’s. Yet the scale of these elements has been considerably reduced by the notable increase in weight of Psychology. This is due to the effort afforded to the visualisation, characterisation and depth of the world in Gears of War 2 far outstripping that made in either Quake or Counter Strike.

Working with this chart, we can then scale it by an additional “success” factor, or “score”. If we glance at the Metacritic review average for Gears of War 2, it provides a rough scale factor of 93%. Applying this to each of the four elements in the chart results in the below diagram.

Waffle Chart showing the elements of Gears of War 2 as classified by The Quad and Metacritic score weighting.

Now imagine that instead of using a total score to scale all of the elements, each is assessed and scaled individually. Using the vocabulary of The Quad, these charts can be used to accurately describe a game’s genre at a glance, as well as giving the analyst a method of independently rating the success of each its aspects. The granularity of the information portrayed is not suitable for delivering in-depth analysis, but it’s a considerable improvement over rating a game with a single overall score.

The Quad provides a unified terminology for what we’ve already been communicating in our discussions about videogames. We lose nothing by using the terms Psychology, Decision, Randomness and Physiology in our analysis, as it doesn’t change the subjective nature of it. The benefit is a common language from which we can build and share ideas. To illustrate this I’ve created my own Gears of War 2 review chart, representing my personal reaction to the game.

Waffle Chart showing the elements of Gears of War 2 as classified by The Quad and my own score weighting.

As you can probably tell, I didn’t really enjoy my time on Sera. My preference is to play something innovative, and Gears of War 2 certainly was not that. These are some of the notes I made when deciding the scale factors to apply to each element:

Psychology
I enjoyed the artwork and visual effects, but found the story hokey, and the stereotypical characters bland.

Decision
I was disappointed with the variety of tactics that I had to apply during the game. Each arena had obviously optimal locations from which to fire obviously preferred weapons. The set pieces could be approached in a similar manner throughout, with no incentive to change tactics. Ultimately, the majority of the depth of Decision in Gears of War 2 had already been explored in the original game.

Randomness
The online matchmaking was competent at grouping me with similarly skilled opponents, but was not as good as Halo 3’s implementation.

Physiology
The controls gave me a wide range of options to manoeuvre in-game, including an excellent cover mechanic. My own movements were accurately translated to my avatar’s movements, and the reward for being more dexterous than my opponents was satisfying. I enjoyed the conflict between having to watch the arena in front of me, and switching my attention to the reload gauge positioned at the edge of the GUI.

My bias towards games that introduce interesting and varied Decision makes my chart significantly different to the Metacritic chart. We could interpret this as the average contributor to Metacritic finding a game’s Psychology more important than I do, and having a reduced requirement for depth of Decision. Of course, they may have simply enjoyed what was in the game more than I did; it’s difficult to tell from just a headline number.

I hope I’ve shown that if we start using The Quad to describe videogames and display our analysis with more transparency, then the quality of our communication will be improved. We all have an interest in understanding why we like or dislike a game. Armed with this knowledge, we’ll spend less money on games that we won’t like, and spend more of our precious time with the ones that we will.

Vocabulary begets understanding, understanding begets discourse, and discourse begets progress.

Jeffrey Sheen is the founder of London-based Stargazy Studios. His newly-formed indie one-man band is currently developing Huscarls, X-COM and Final Fight’s illegitimate love child. Combining A-Team style welding and a design nous built up over decades of play, Stargazy Studio’s mission is to create new, genre-bending games for an audience hungry for innovation.
www.StargazyStudios.com
Stargazy Studios on Twitter

Posted in DevelopmentComments (1)

Android Gaming on the Rise

Posted on 14 May 2010. Tags:

Android gaming rises in March, nearly matches 2009\’s yearly revenue in Q1 2010.

As per the released report by Forecasting and Analyzing Digital Entertainment, LLC (FADE), the Android marketplace jumped grew by 60% in March when compared to February of 2010. FADE LLC estimates that the Android market is within just 10% of matching 2009\’s revenue.

Gaming revenue in March reached an estimated $798,000 – a new record for the market, beating February\’s record of an estimated $500,000. 1st Quarter results yielded an estimated $1.7 million. By comparison, the whole of 2009 grossed just $1.9 million, lending to both the weakness of Android\’s revenue in 2009, and the rapid growth of 2010.

Comparing to March of 2009 against March 2010, FADE estimates that the market has seen a 814% year over year increase during the month, and looks to continue its growth in the months ahead. \’The Android market looks to continue robust growth throughout 2010, as users continue to adopt the platform at record rates.\’ said Benjamin Schlichter, Director of Research & Analysis at FADE LLC.

New Handsets Fuel User Adoption

 

The notable increase in revenue should come as no surprise. Recent quotes by Eric Schmidt, CEO of Google put the OS at 60,000 new activations per day, or 1.8 million handsets per month. During the quarter, seven new handsets were delivered to consumers, including the Motorola Backflip – AT&T\’s first Android phone, HTC Legend, and Google\’s Nexus One.

A caveat exists with feverish handset sales, as per the in the March report. According to Google, 38% of all Android devices using the Android Marketplace still run OS version 1.5 or earlier as of early April. Due to the nature of the 1.5 market place UI, many users cannot interact with the store as efficiently as users with 1.6 or above, causing lower revenues per user. FADE LLC estimates that revenues will be mired in low revenues per user until new updates bring users to newer operating systems, and handset manufacturers drop the production of models with 1.5. During March, new smartphones such as the Motorola Backflip, and CliqXT launched with the old operating version..

FADE LLC Top 10 Estimates by Revenue - 1st Quarter, 2010
  1. Robo Defense by Lupis Labs – 46,000 downloads ($2.99)
  2. SNesoid by yongzh – 21,000 downloads
  3. HOMERUN BATTLE 3D by Com2uS – 14,000 downloads ($4.99)
  4. Armored Strike by Requiem Software Labs, Inc – 14,000 downloads ($3.99)
  5. Nesoid by yongzh – 16,000 downloads ($3.49)
  6. GameBoid by yongzh – 13,000 downloads ($3.99)
  7. Fishin\’ 2 Go by CyxB – 22,000 downloads ($2.25-$2.50)
  8. Farm Frenzy (various versions) – 10,000 downloads (roughly $4.50 USD or 3 UKP)
  9. Space Physics by Camel Games – 12,000 downloads ($2.99)
  10. Jewellust by Smartpix Games – 12,000 downloads ($2.95)

Other Estimates:

  • Estimate of free & paid gaming downloads in 1st quarter: 40 million
  • Estimate of free & paid application downloads in 1st quarter: 131 million
About Forecasting and Analyzing Digital Entertainment, LLC

FADE is a strategic market research and consulting firm focused on electronic entertainment and the emerging download and mobile game markets. With very little information currently available in these markets, FADE allows smaller developers to investigate these new potential sources of revenue and make informed business decisions moving forward. Currently, FADE produces monthly and annual reports for Steam, Xbox Live Arcade, WiiWare & Virtual Console, and mobile markets including iPhone, Android, Windows Mobile, and Blackberry. For more information, please visit http://www.fadellc.com.

Posted in DevelopmentComments (0)

Xbox Indies: The champions of the hidden marketplace

Posted on 27 March 2010. Tags: , ,

Often dismissed as a failed venture, the Xbox Indie Games programme has earned successful man-and-his-dog developers tens of thousands of pounds from sales of their homebrew games. Wired explores the success stories of this hidden marketplace.

An investigation by Mark Brown

Compared to Xbox Live Arcade, a dazzling supermarket crammed with consumer-friendly treats and familiar brands, the Xbox Indie Games store often feels more like a back alley marketplace or a dingy pawn shop in Camden. Filled with intriguing curios and mystifying knick-knacks, from massage simulators to retro-styled platformers, this almost hidden corner of your Xbox 360 is home to over 800 games made by the Xbox community.

Opening for business in late 2008, the Xbox Indie Games programme (then called Xbox Live Community Games) was announced by Microsoft as “your ticket to fame and possibly fortune as millions of Xbox Live users now have the opportunity to view, buy and play games that you create.”

But despite Microsoft’s best efforts, the service didn’t exactly offer the fame and fortune it had hoped. The Community Games launch was a bitter disappointment with boring games, bug-prone software, no way to sniff out worthwhile games and, before long, a nasty image problem.

“I think XBLIG generally has a hard time getting people to take it seriously,” says James Silva, creator of highest rated Indie game, I Maed a Gam3 w1th Zomb1es!!!1. “Unlike Xbox Live Arcade, there’s no bar for quality and people tend to judge it by the lowest common denominator. Getting a reputation for massage games didn’t help either.”

Click Here to read the full article…

Posted in Self-publishingComments (1)

BizSpark Program from Microsoft

Posted on 09 March 2010. Tags: , ,

If you are a start-up studio (less that 3 years old), I can heartily recommend the Microsoft BizSpark program. As well as a lot of help & support, and networking opportunities, it gives you free access to pretty much ALL Microsoft software (incredible but true).

Here are a few details, but to get the full picture visit http://www.microsoft.com/BizSpark/ now - you probably won’t regret it :)

What is BizSpark?

 Source: http://www.microsoft.com/BizSpark/

Program Overview

BizSpark is an innovative global program designed to unite Startups and resources to support them into a single community. BizSpark is uniquely designed to help Startups engaged in software development, by offering Software, Support and Visibility:

• Software: BizSpark provides fast and easy access to Microsoft tools and technologies, for their immediate use in design, development, testing, demonstration, and hosted application production and deployment;

• Support: Professional Technical Support from Microsoft, including, for entrepreneurs working with early adopter technologies: access to unlimited email support, online training and invitations to local technical events. Examples of early adopter technologies: Windows® 7, Microsoft® Silverlight, Windows® Azure and Microsoft® SQL Server 2008 as well as a connection to Network Partners, organizations that provide programs, mentoring and other resources to Startups;

• Visibility: The opportunity for global visibility on the MicrosoftStartupZone Website via the BizSparkDB, an online Startup directory, hosted on http://www.microsoftstartupzone.com\bizspark.

Eligibility

1. Startup Eligibility Requirements:

An eligible startup must have the following characteristics at the time of joining:

• Actively engaged in development of a software-based product or service that will form a core piece of its current or intended business1,

• Privately held,

• In business for less than 3 years2, and

• Less than US $1 million in annual revenue3.

To be eligible to use the software for production and deployment of hosted solutions, startups must also be developing a new “software–plus-services” solution (on any platform) to be delivered over the Internet. To meet this requirement your software must:

 • Add significant and primary functionality to the integrated Microsoft software.

 • Be owned, not licensed, by you.

 Dashboards, HTML editors, utilities, and similar technologies are not considered a primary service or applications.

2. Term: Startups can participate in BizSpark for up to 3 years. On the first and second anniversary of initial enrollment, they must update their enrollment (e.g., confirm they haven’t gone public and their ownership hasn’t changed). 

3. Fee: A USD $100 Program Offering Fee is due when the Startup exits the Program. As part of Microsoft’s commitment to Startup success, there are no initial costs for Startups to join BizSpark.

4. Special Offers: BizSpark Startups may also be eligible for additional products or services offerings (from Microsoft or others) from time to time during their tenure in the Program. Startups enrolled in BizSpark will be notified of special offers when they become available as well as the terms and enrollment process to take advantage of them. Special Offers are not part of the BizSpark program benefits and Startup’s participation in Special Offers will be governed by the separate terms and conditions for each Special Offer (including licenses, and fees if any).

Posted in Development, NewsComments (3)

Publisher Budgets for Downloadable Games

Posted on 07 March 2010. Tags: ,

I read an interesting discussion on this recently, and wanted to see if I could get some further opinion on it – so please comment below or over in the forums if you have any info to share.

What I am hearing is…

  • Publisher budgets have dropped, and they are becoming more risk averse at the moment (i.e. more choosy about what D/L content they sign)
  • PSN & XBLA are the platforms they are keen on – budgets range from €400,000 at the top end, to €250,000 at the lower end. The experience of the team has a fairly large impact on the budget too – a new team, unless they have a killer product would be looking more toward the lower end of the scale.
  • For multiple platforms (i.e. PSN & XBLA) look to add an additional 10 – 20% onto the budget.
  • For the above budgets the publisher should be covering the devkit costs, QA, marketing & submission costs.
  • Cost out a range of options, such as with or without multiplayer content, online services such as leaderboards, DLC support, etc… DON’T promise the world on an unrealistic budget or you really will enter a world of pain.
  • WiiWare – the sales numbers are appalling, and apparently most publishers now won’t even consider a WiiWare title. There are some that may though – such as Hudson who have built up a big catalogue of WiiWare titles.
  • PSP Minis – not a lot of info on this, but looking at the service most titles are either self-published, or internally developed publisher titles using established big IP names.

And that’s it – again I’d really like to hear any further feedback on this, as costing/setting budgets is one of the darkest arts of game development. Without prior knowledge it can be impossible to come up with a realistic figure that a publisher will accept, which just looks bad for the developer.

Posted in Business, DevelopmentComments (2)

Indie Fund Announcement

Posted on 04 March 2010. Tags: ,

Potentially very exciting news, a brand new fund for indie game development:

http://www.indie-fund.com/

What is Indie Fund?

Indie Fund is a brand new funding source for independent developers, created by a group of successful indies looking to encourage the next wave of game developers. It was established as a serious alternative to the traditional publisher funding model. Our aim is to support the growth of games as a medium by helping indie developers get financially independent and stay financially independent.

We will soon be announcing the names of the projects we are already backing. Additional details about the need for Indie Fund and the rationale behind it will be shared at the Game Developers Conference in the talk titled Indies and Publishers: Fixing a System that Never Worked.

Who is Indie Fund?

·       Ron Carmel & Kyle Gabler

, 2D BOY (World of Goo)

·       Jonathan Blow

, Number None (Braid)

·       Kellee Santiago

, thatgamecompany (flOwer)

·       Nathan Vella

, Capy (Critter Crunch)

·       Matthew Wegner

, Flashbang Studios (Off-Road Velociraptor Safari)

·       Aaron Isaksen

, AppAbove Games (Armadillo Gold Rush)

Contact Indie Fund?

For general inquiries, please send an email to contact {at} indie-fund.com.

[UPDATE: We are not currently accepting game submissions. A public process for applying for funding will soon be made available. Also, we're getting a lot more email traffic than we expected and will not be able to respond to everyone, please be patient with us!]

Interview with Ron Carmel: http://www.gamasutra.com/view/news/27446/Independent_Game_Luminaries_Announce_Indie_Fund.php

Thoughts from Jon Blow: http://the-witness.net/news/?p=80

Posted in Development, NewsComments (1)

State of iPhone Development

Posted on 04 February 2010. Tags: , ,

[This excellent article by Brian Robbins of Riptide Games covers everything you need to know about iPhone development. Read on...]

There’s no doubt that the iPhone is one of the most talked about platforms in game development today. While there is a lot of great information available for developers looking to get into iPhone development, there is also lots of misconceptions and misinformation that can be difficult to filter out for anyone not actively doing iPhone development. Originally presented as a lecture at the recent IGDA Leadership Forum this article will cover the overall process of developing an iPhone game from start to app store and beyond. The goal is to separate facts from myths and give give developers an accurate idea of what to expect.

Overall, iPhone projects follow a fairly similar process to that of most console games. Start with an idea, go into development, perform some final testing, then submit to cert, launch and then follow up with ongoing marketing. Developers who approach their titles anticipating each of these steps will be the ones that have the most success and least frustrations in the process.

There are a couple points in this process that are fairly unique to iPhone development. If this is your first iPhone game, then there is a crucial business & legal step to go through before completing development. The submission process is also a little bit unique, and finally marketing is perhaps the single most important aspect of having a successful launch.

Dev Program Application

Assuming this is your first iPhone game then the first step in the process is getting accepted to the iPhone Developer Program. Enroll for the program at http://developer.apple.com/iphone/program/ You will want to sign up for the Standard $99/year program, not the Enterprise program. The important thing to realize here is that whoever applies to the iPhone Developer Program will automatically become the Team Agent once accepted. While accounts can have Admins which can do almost anything, the Team Agent is the only person that can approve contracts with Apple, and it is the only account that can generate Promo Codes for released apps. It is possible to change your Team Agent, but it is a manual process that you need to contact Apple to do, so it is much easier to start with the proper person from the beginning.

Once you complete the application, Apple will take some time reviewing your application before accepting it. This process is likely just a few days now, though in the summer of 2008 it could take weeks or even months to get approved. You CAN start developing your iPhone game before you are approved. You will just be limited to only being able to test against the software simulator and will not be able to deploy and test against actual hardware until your application has been approved.

Contracts / Banking

As soon as you are approved into the dev program the Team Agent should log in to iTunes Connect (http://itunesconnect.apple.com/) to ensure that all contracts and bank account information is setup.  The default contract only allows developers to submit free apps to the app store. If you plan to charge money to purchase your apps you will need to have the Team Agent approve the Paid Applications contract. At the same time you should also make sure the bank account and tax information in iTunes Connect is completely filled out. Your paid app will not be able to be released until all of this is completed properly so it is much better to do it early so this doesn’t become the reason your launch is getting delayed.

Also pay attention to specific tax treaty information on iTunes Connect, and be sure to complete any additional forms that may be necessary depending on your location.

Development Hardware

Developers will need Intel-based Mac OSX machines with OSX 10.5+ I highly recommend 10.6 / Snow Leopard as the Static Analyzer alone is worth the minimal upgrade cost. For hardware there are a few variations in platforms to be aware of. This Apple KB (http://support.apple.com/kb/HT1353) article gives ways to tell which version of iPod Touch you have.

iPod Touch

  • 1st Gen – Processor and memory identical to iPhone and iPhone 3G
  • 2nd Gen – Processor faster than iPhone and iPhone 3G, memory identical to iPhone and iPhone 3G
  • 3rd gen / Late 2009 – Processor and memory same as iPhone 3GS, 3D Graphics chip identical to iPhone 3GS

iPhone

  • iPhone. Slowest processor and memory
  • iPhone 3G. Identical processor and memory to iPhone
  • iPhone 3GS. Faster processor and more memory. Better graphics chip.

For performance testing purposes the 1st gen iPod Touch, iPhone and iPhone 3G are essentially identical. The 2nd gen iPod Touch has a slightly faster processor so be aware of this if it is the primary development device. The iPhone 3GS and 3rd gen iPod Touch are identical to each other, and significantly faster than the other devices, they also come with 128MB more memory.

While it’s tempting to focus only on the newest platform with the highest specs, this is a bad idea. Consumers can still by an iPhone 3G new for $99 and the smallest capacity new iPod Touch in stores today is still the 2nd gen iPod Touch platform. If your game only targets the newest platform you will be missing out not only on the 50+ million installed devices already out there, but also missing out on a consumer who goes into the store today and buys a brand new device.

Similarly, unless your game requires an iPhone-only feature, you should make sure that it works well on iPod Touch devices. iPod Touches are a very significant part of the marketplace, comprising nearly half of the available hardware. Depending on the game, iPod Touch users could be as high as 75% of the playerbase.

Programming

The iPhone SDK from Apple assumes developers will be using Xcode, Apple’s compiler and programming toolset. While it may be possible to avoid using Xcode, doing so is beyond the scope of this article.

Most iPhone examples from Apple and elsewhere are written in Objective-C, a set of extensions to the C language based on Smalltalk. As such if you are willing to learn Objective-C you’ll have the easiest time finding source code examples, tutorials from Apple, etc. Since Objective-C is an extension to C, you are also free to write C code within the same source files and even functions.

The Xcode environment also fairly seamlessly handles C++ though it’s not quite as straightforward to do as plain C, and there’s far fewer C++ examples available to learn from.

The iPhone Simulator that comes with the iPhone SDK is incredibly useful for development. It almost perfectly emulates most aspects of the iPhone OS and in the past 18 months, I’ve only found a couple situations where the simulator would handle things differently than actual hardware, outside of some very specific limitations. Namely in the simulator processor speed and memory are based on your computer hardware, and as such the simulator is useless for performance testing. There’s also no accelerometer input in the simulator (though there are 3rd party libraries that aim to assist in this problem). Finally with the simulator multi-touch input is somewhat awkward to do, and it is impossible to input more than 2 touches at one time. For most functionality and core logic tests the simulator will be identical to the hardware and your build, deploy and test times will be significantly less than deploying and testing on actual hardware.

The bottom line is that for most development needs, outside of performance testing, the simulator will let you have a much quicker rev and testing time, with very little need to worry about incompatibilities when you run on actual hardware.

Testing

When it comes time to test and polish your game prior to submission, be sure to test against a variety of hardware. At a minimum you should have at least one 1st gen iPod Touch or iPhone or iPhone 3G to make sure that your game runs well on all hardware. You should also make sure that you test against a clean install of the app. This is very easy to miss in development, but critical to ensure you aren’t assuming default values that don’t exist in a clean install. Similarly when working on an update, be sure to test against both a clean install as well as an upgrade install over an existing previous version build.

You also need to make sure your game can handle interruptions at any time. As a phone platform should be assumed that your game will be interrupted with no advance notice, and players will become very frustrated if they lose progress as a result. The general rule is that your app should be able to save and restore to any state in the game. Resetting back to the beginning of a level may be acceptable for quick levels, but having to start over on anything longer than 1-2 minutes will likely frustrate some number of players.

Similarly you must ensure your game properly detects and handles Internet connectivity state. The iPhone can connect over WiFi, 3G, EDGE or have no connectivity, and your app must be able to detect this and respond appropriately. It is generally not acceptable to simply time out if the phone is not connected to the network, rather you should proactively notify the user that they need to enable an Internet Connection for that feature. This is a key point for Apple and improper detection or lack thereof will generally result in a rejection upon submission.

Submission

When everything is complete, an Admin user on your account will submit the app to the App Store via iTunes Connect. It is recommended that you walk through this process before preparing to submit so you are aware of exactly what is asked for at submission. You will need to have your app description, keywords, screenshots and logos all ready to go along with the binary to be uploaded.

The binary that will be uploaded is a distribution binary, and it is not possible to test this binary prior to submitting it to Apple. Unfortunately it needs to be signed differently than any other version built previously, and as a result you will not be able to install it on any devices. There have been a very few reported instances of developers who found their final build had a bug that appeared to only exist in the distribution build, but this is very rare.

Pricing

Pricing an iPhone app correctly can be a significant challenge to get right. Most games are currently priced between $.99 and $2.99, with a few at $4.99 and very few at $9.99. In general there is a feeling of a “race to the bottom” in pricing among many developers which has lead to the huge number of $.99 apps. It can be difficult to successfully generate sales at a higher price point without the advantage of having a big brand like Rock Band or PopCap to drive interest and visibility. Recently Apple introduced Top Grossing charts into iTunes, which has helped for games and apps that do charge a higher price point and can actually gross as much as cheaper apps, but do not get the same number of downloads or purchases to compete on a 1 to 1 download basis with $.99 apps.

In late October Apple began allowing free apps to have In App Purchase content, where previously this was only available to paid apps. The advantage with this is that free applications can easily have 20-40 times as many downloads as paid applications. It is still a bit too early to see if this model will be lucrative, but some of the first games developed for this business model have hit the app store. Our own game Gravity Sling was one of the first to do this and the first couple weeks of availability show that around 2% of free players purchased in app content.

Launch

Recently apps have taken around 2-3 weeks to be approved, but there are no guarantees of timing. In early 2009 approval times were around 1-week, while just after WWDC in June, many apps took 4-5 weeks or more for approval. There is no known way to speed this process up, and your best guidance is a status report on the iPhone Dev Center that Apple has posted which states how long typical approvals are taking (at the time of writing this says that 95% of apps are being approved within 14 days).

When the app is approved the Team Agent and Admins will get an e-mail stating that the application has been approved for sale. Someone should IMMEDIATELY log in to iTunes Connect and change the application release date to the current date. This should make your application release date in line with the actual release date of the game. The logic for the release date shown is currently the earlier of the date set in iTunes Connect and the date Apple approves the app. This means that if an app is approved on December 15th, and the release date set in iTunes Connect is December 5th, the app will appear (and be sorted) with a release date of December 5th. Conversely if the app is approved on December 15th, and the release date is set to December 20th, the app will become available on December 20th, however it will appear (and be sorted) with a release date of December 15th. The only way to be at the top of the New Releases list is to set the release date in iTunes Connect to the same day the app is approved. Until recently this logic held true for updates as well, but that is no longer the case. Releasing an update will cause your app to say that it was Updated on the date the update is approved, but you will not appear at the top of the New Releases again.

Marketing

The key to marketing on the iPhone is generally to get as much and as wide of a marketing push all at the same time as possible. This way each promotion will stack on top of each other, ideally with an end result of pushing your game into the Top 100 charts. These charts are based on a weighted average of either downloads or revenue depending on the chart, and appear to be heavily weighted towards the most recent 48 hours.

The challenge for traditional publishers is that the release date for a game typically isn’t known ahead of time, as it becomes whatever day Apple approves the app. Developers can pick a specific release date after that point, but doing so will result in a complete dependence on external marketing since the game will not be listed in the New Releases.

Fortunately, most iPhone review sites are familiar with this process and very good at working around these limitations. If you plan to do media buys, most will let you lock down the time once you know your app is released. You can also send review sites advance “AdHoc” builds of your app prior to release so they can potentially have a review ready ahead of time.

In addition to advance copies, Apple provides up to 50 promo codes for each application version (submitting an update will reset the promo codes available back to 50). All review sites will accept these promo codes to review apps. Prior to launch marketing should have been in touch with sites to know who will be receiving the initial batch of promo codes.

Twitter and YouTube are also proving to be very popular channels for iPhone app promotion. Trailers on YouTube can be viewed thousands of times, and nearly all iPhone review sites are very active on Twitter as well.

While there are a few major iPhone review sites, there are hundreds if not thousands of individuals and tiny sites also doing app reviews. While no single one of these is significant, in aggregate they have a significant impact as each person may influence 10-50 people. The most successful long-term marketing and promotion will realize this and will try to do things to take advantage of these micro channels.

Typical Problems

Contrary to the seemingly prevalent stories about the horrors of iPhone development, I have found the process to be fairly straightforward and easy to manage. However, there are a few problem areas that you should pay particular attention to:

No Contracts or Banking. Apple will not remind you that you do not have the proper contracts signed, or that your bank accounts are not properly setup. If you are not proactive about this, then you may not even realize that this is not completed until your app has been approved, and cannot appear on the app store until these are done.

Failure to follow guidelines. Apple will reject apps that do not follow their guidelines. I have never had an application submission rejected, for any reason. If you read the guidelines and you follow them, it is far less likely that you will run afoul of any of Apple’s policies and get rejected. There are some gray areas that are open to interpretation but most of their policies are fairly straightforward and it is easy to know you are in compliance.

Keywords / App Description. A few months back Apple started monitoring keywords and app description with application submissions. Apps that mention other apps in their keywords will get rejected, as will misleading descriptions.

Testing & Error Handling. As previously discussed be sure your app properly handles various error states, particularly around network connectivity.

Release Date. Remember that the release date of your app will be shown as the earlier of the day you have set in iTunes Connect or the date that Apple approves your app.

Conclusion

It is absolutely possible to build a profitable business developing games for the iPhone and iPod Touch. To be successful developers must focus not only on creating great games, but they must also devote time and energy to the business and marketing side of game development too. Developers who believe they can simply make a great game and wait for the money to roll in are destined to fail. There is a huge amount of competition and noise in the marketplace, but the space does reward savvy developers, and the upside can be very significant.

Resources

The following sites and tools can be very helpful with aspects of iPhone game development.

MajicRank – http://www.majicjungle.com/majicrank.html – Mac OSX, Free w/ $20 requested donation. Automatically downloads, tracks and charts app rankings for all app stores worldwide. Very useful to see historical ranking data for yours and other apps.

MajicRank screenshot near here alternate location

AppViz – http://www.ideaswarm.com/products/appviz/ – Mac OSX $29.95. Will connect to iTunes Connect to download daily and weekly sales data as well as financial reports. Great for quickly visualizing many different aspects of product sales.

AppSales-Mobile – http://github.com/omz/AppSales-Mobile – iPhone, Open Source. Very similar to AppViz but an Open Source iPhone app.

AppFigures – http://www.appfigures.com/ – Web service. Combines a lot of MajicRank and AppViz in a subscription web service.

Analytics – PinchMedia, Flurry and Localytics are the leaders here. All are very easy to implement and have no cost to use. There’s no excuse not to include analytics in your app.

MobileOrchard – http://www.mobileorchard.com/ – Lots of great developer focused content, tips and advice.

Posted in DevelopmentComments (1)

All Publishers Are Thieves!

Posted on 26 January 2010. Tags: , ,

Actually, they’re not – but, you have to admit, the headline did get your attention…

[Tim Christian kicks off a series of articles about the auditing process for royalties. This is essential reading for anyone working with a publisher.]

I’ve been in the UK computer games industry since 1991, initially on the publishing side as the head of the European operations at Accolade, Microprose and finally Hasbro Interactive and I’d like to think that during that time I ran a tight ship and certainly didn’t intentionally defraud the developers on whose creative talents we depended to make a living.

Fast forward from 2000, when I left Hasbro Interactive, to the present day as the owner of TC Associates Ltd, part of which has become the games industry’s leading independent royalty auditor, through an earlier involvement with Media Forensics Ltd., which I also founded, and an unhappily-ending flirtation running my own development business, and what do I have to report? Well, the good news is that the games industry continues to thrive, albeit in an ever-changing and very dynamic guise. Those early days of the Commodore 64 and 5 ¼ inch PC floppy disks are unrecognisable as the technology-changing times that they undoubtedly then were. In 2010, all the talk is of apps, mobile, digital download and the end of retail as we know it. However, somewhat depressingly, the majority of publishers’ accounting systems haven’t advanced as fast or as far as we could have expected. In fact, from a royalty audit point of view, I can still boast a 100% record of having discovered previously unreported royalties in almost every single royalty audit I’ve ever undertaken. In other words, almost every single royalty audit throws up errors and, interestingly, those errors are almost always in favour of the developer.

Now, as I said earlier, it’s not that (with the exception of a very tiny minority) games publishers go out of their way to short-change the developers, but it’s important to remember three things. Firstly, royalties are a cost, and the publishers will always interpret the contract to their best advantage. Secondly, the people who put the royalty statements together are only human and, yes, they make mistakes. Lastly, whilst the finance department may well rely on a multi-million dollar accounting system, the end royalty statement will almost always be generated on an Excel spreadsheet, which is not always the most sophisticated or error-free way of doing things. In the 8 years I’ve been in the audit business, I can only name two companies which I would say had deliberately set out to misrepresent the performance of a title to their own financial benefit. So, all the other royalty finds – which ranged from several thousands to a few millions of dollars – were down to questions of contractual interpretation or weaknesses in the financial systems.

So, where am I going with this? Well, over the next few months I hope to follow this article up with further detailed advice on why, when and how to carry out a royalty audit, as well as some observations on the games industry itself – its ups, downs and developments. In the meantime, with regard to the thoughts above, think about the following good business practices to get into the habit of following.

  • Have your development contract professionally reviewed before you sign it (no, really, there are stories I could tell!). There are a number of experienced – and reasonably-priced – law firms with a specific games practice. If you can afford it, have your lawyer help you through the negotiation process too. Spending a few quid here could save you a bundle later.
  • Make sure there is a right-to-audit clause in the contract (no, really, there are stories I could tell!). Again, no lawyer worth their salt would overlook this.
  • Make the net receipts/royalty calculation clause as clear and as transparent as possible. A worked example of the royalty report layout can always be included in the contract as an exhibit. Again, time spent on this will save money later. If there’s no room for misinterpretation, there’s little room for argument other than over the maths. In my experience, when errors in the maths are found, there is no defence.
  • Don’t fall for the publisher saying that unless you formally object to a royalty report within one year of its publication, the report can’t be challenged. This is designed to stop you from auditing. Hold out for two years at least – unless you do intend to audit within one year of release. If you do intend to audit every year, make sure you put the relevant dates in your calendar. Time flies …… and suddenly it’s too late.
  • If the title recoups, or is close to doing so, or if you really think there’s something wrong with the royalty calculation and your questions aren’t being taken seriously, then audit the publisher. Trust me, they’re used to it and far from taking it badly, the publisher will actually respect your seriousness and professionalism. The costs of the audit are always negotiable and sometimes can be far less than you think – and if there’s an error in excess of 5% or 10%, the publisher will be obliged to pay for the audit (assuming you negotiated that in the first place).

So, a few do’s and don’ts with which to kick of this series of articles – they’re common sense, I know, but it does no harm to draw attention to them every so often.

As I said, I’ll be back over the next few months (assuming I’m invited!) to share more thoughts on royalty auditing in particular and the computer games industry in general. In the meantime, feel free to contact me at tc@tc-ltd.com or via www.tc-ltd.com

Comment on this post in our forums

Posted in BusinessComments (3)

BBC Move Back Into Games

Posted on 21 January 2010. Tags: ,

Broadcaster’s commercial division Worldwide wants to turn key IPs into DS, Wii, iPhone and online games MCV can reveal

After spending years sat on the fence, the BBC is returning to games in a big way, MCV can exclusively reveal.

Via its commercial arm BBC Worldwide, the broadcaster is courting both publishers and developers to turn Doctor Who, Top Gear, In The Night Garden and many, many more into games for all audiences.

No stone will go unturned: the BBC wants to see its brands on iPhone and Facebook as much as it wants to see them on DS and Wii.

“We are open to conversations with anybody in games about all kinds of business models to see how we can extract more value,” said Neil Ross Russell, MD of children’s and licensing.

“Outside of Disney we have the most well-known line-up of children’s characters around the world.”

It’s a big about-turn for the broadcaster. The BBC closed its Multimedia division in 2005 after sales crashed in its boxed product business, subsequently aborting an attempt to get a PS2 game of spy thriller Spooks
off the ground.

“We’ve been reactive to the market in the last few years,” explained Dave Anderson, head of multimedia development at BBC Worldwide.
“There were a few opportunistic licensing deals, but we were largely aggregating and holding on to our properties to wait and see how the market developed.”

The new effort will push key kids’ IPs towards games for DS and Wii, while more long-running brands find their feet on all sorts of platforms.
But the move goes beyond just licensing out properties.

Said Ross Russell: “What we’re trying to do is build the brands here – this is not about opportunistic licensing. If we wanted to do that we would have done more with these key brands over the last few years.”

As part of the move, BBC Worldwide has hired former EA and Yahoo exec Robert Nashak as EVP of digital entertainment. More details on his appointment will follow tomorrow.

MCV will reveal more on BBC’s new strategy to fund new titles based on its properties and work closer with games publishers and developers next week.

Source: MCV

Comment on this post in our forums

Posted in NewsComments (2)

Indie Game Design Do-s and Don’t-s: A Manifesto

Posted on 05 January 2010. Tags:

[Edmund McMillen presents his opinions and manifesto on making indie games, with 24 design do-s and don't-s.]

One of the most common questions I’m asked in interviews is, “Do you have any advice for independent game developers who are new to the scene, or tips for developers in general?” Well, I actually answered it this time: I came up with this list of indie do-s and don’t-s.

Now, I’m going to make clear that I’m not perfect and I’m sure as the years go by this list will change. But from where I stand right now, having made independent art/games for a living for the past 10 years, the advice below is crucial to all indie game designers, and all artists for that matter.

Also note that when I refer to a “designer” or “artist,” I include programmers. All aspects of art have a fine balance of the technical and creative; just because programming is viewed as a technical field does not mean it is void of creativity. The creative is visible in the work as a whole rather than in the specifics. Light and shadow are vital technical aspects of illustration, but without creativity the piece is nothing more then a photocopy of the subject, void of any personal touch or presence.

This is a list for the creative designer who strives to be independent. This isn’t advice on how to monetize your Flash game or survive financially by copying existing trends and juicing the public for their cash. This is a list for artists who are driven by the desire for creative freedom and/or to “just make some cool shit people will love.”

Anyway, here’s the list. Take what works for you and leave what doesn’t:

1. Be honest.
When I say “be honest” I mean to speak from your heart. Don’t be manipulative or condescending in your work; treat the player how you’d wanted to be treated. Honesty is extremely valuable when making art.

2. Realize you’re making art.
Game designers are artists and have advantages over non-creative jobs; think about what they are and exploit them. Your goal shouldn’t be to make tons of money. If it were, you would have gone to business school or become a doctor. This is a creative field and should be treated as such first and foremost. Financing your art comes later. This is probably your greatest advantage as an indie designer.

3. Design from the heart.
Write / design around things you’re passionate about. Put yourself into your work and show the world who you are. What do you love? What do you hate? Why? All notable film makers have a stamp, something that appears in their work and speaks to who they are. These themes will always come through to your audience, giving your work a sense of your self.

4. Take big risks.
Try to innovate the hell out of anything you make. From how your game plays to how it looks, be unique and you’ll stand out. Push your personal limits, try new genres, mechanics and aesthetics. Experimentation and risk are the keys to growing as an artist. Don’t be scared of failure; you don’t have much to lose and you’ll only learn from your mistakes.

5. Don’t bite off more then you can chew.
If you’re just starting out, think small, then think smaller. If you start on something big you won’t finish it and if you do you’ll be burnt out and probably won’t make another. A filmmaker never starts his career with a blockbuster movie. One of the easiest mistakes to make starting out is letting ambition drive you down a path you’re not ready to travel. Slow down, take your time and start simple. Prototyping is crucial for all designers.

6. Practice (make lots of small games).
Make lots of small ideas quickly; build on the ones that work. If you look at any successful or “fully realized” game in the indie scene you’ll note that it began as a simple prototype. If you get an idea that feels right, simplify it. Strip it to its core element; this element will become the glue that holds your work together. The stronger the glue the more you can add. On the opposite end, if the glue isn’t holding, move on. Don’t waste your time trying to fix something that won’t work. If it’s not interesting or fun in its primitive form, it’s not going to be when it’s finished.

7. Make the games YOU want to make.
Go with what moves you. If you’re no longer feeling something, put it down and work on what you want. I’ve found that all of my best games were ones I made quickly and felt passionate about. The ones that sucked were ones I lost interest in but forced myself to finish. If things have gone sour and you feel yourself losing interest in a project, try looking at it differently. A simple change of perspective or reinvention of an existing mechanic can make all the difference when you’re losing motivation.

8. Stand out.
Don’t make something that looks or feels exactly like an existing work. When people experience something new they’re more forgiving of its design, and in the end your creation will get more attention. This should be obvious, but somehow goes over the heads of most designers. If you notice a trend in aesthetics or play mechanics: DON’T DO THAT. Avoid trends; innovate and break new ground. Stop making goddamn ninja and zombie games and if you’re making a shooter don’t put it in space. Seriously.

9. Think critically.
99% of game design is critical thinking. Try to find holes in your designs: if you can’t fill them, move on to something else. Before you set out to work on your project you should have already given plenty of thought to how it might NOT work. Start asking how these core elements cpi;d be exploited and how might things come back to haunt you in the future. Thinking critically is the key to avoiding later conflict; always look before you leap. Take a step back from your project. Consider it the same way you would someone else’s work. If you hadn’t made it, what would you see as its strengths and weaknesses?

10. Play games.
You can’t expect to learn anything if you aren’t playing what’s out. Even if they suck, games that sell well in the mainstream do it for a reason: pick them apart and find out why. If you don’t play them, you won’t know what NOT to do when you make your own.

11. Dissect existing formulas.
All game “genres” are formulas. Level design, teaching rules, jumping patterns: it’s all according to a formula. Pick apart those formulas and see how they work. Play a shit load of games: find out what elements you like, decide why you like them, then redesign them. It’s as vital to be able to deconstruct a game’s formula as it is to be able construct one. In most cases you’ll learn much more from deconstruction. You already have thousands of existing formulas at your disposal.

12. Grow up.
Chances are you’re not a fucking kid anymore, so if you feel like making a more adult game, do so. When you’re indie you don’t have to answer to anyone, so stop designing games like you have to have to pass ESRB. I’m not saying everyone should make porn games, but why do all video games seem to have immature themes? People aren’t stupid: stop treating them like they are. Speak through your work like you would to your friends, design for yourself and don’t censor your ideas.

13. Go outside.
The world outside your room is important. It can also be very inspiring. Go take an adventure, then come home and write a game about it. That’s what Miyamoto did. I believe that you can’t be inspired without living. Life is what every artist pulls from; how could you pull from something that wasn’t there? We all strive to be great, and most of us tend to obsess over our work, but it’s important to have balance. Go do things that don’t involve video games and computers. Don’t become stagnant.

14. Stay balanced.
Many designers are prone to depression or other mental disorders.
Take care of your brain and, most importantly,
yourself!

15. Stay Grounded.
No matter how good you think you are there’ll always be someone better. stay humble and accept that you’re not perfect. A designer’s ego can easily put up walls that will stunt his growth just because he doesn’t want to admit he might be wrong. The moment you think you have nothing to learn is the moment you should quit. Be honest with yourself, admit your flaws and shortcomings and accept that you’re probably wrong.

16. Be open to feedback.
If a bunch of people say your game is lacking in some area, but you insist it’s perfect, chances are you’re wrong. It’s hard to take critical feedback, especially when it’s right. Loosen up, stay humble, remember you’re not as great as you think you are. If players agree that something’s wrong, you should probably take a step back to reconsider what you’re doing. But don’t make the mistake of just doing what your audience expects. If they have an issue with something, figure out why. If people don’t like how your game controls, this could mean one of hundreds of things, from how things move in the game to what buttons it uses. When responding to feedback, ask specific questions and try to find the root of the problem. Don’t attempt a quick fix by just cutting out the problem.

17. Work with people.
People are nice. Some are good at things you aren’t. Game design uses your whole brain; chances are you’re lacking in some area. Find someone who can fill your hole. In my experience, there’s a yin/yang dynamic between a person with a technical mind and one with a creative mind. I’ve found in this a perfect marriage of ideas and approaches. That’s not to say this will be everyone’s experience. But I do think it’s important to work with at least one other person. The indie game designer can easily become a hermit and having someone else in the room to validate an idea can be the one thing that stops you from becoming that recluse who bathes with bleach.

18. Network.
Talk to other designers, fans, the media about what you’re doing. You might gain some perspective on how others view your work, maybe even make a few friends. There’s no shame about wanting to talk to people about your work. The biggest misconception is to assume that people don’t want to hear about creative folks. They do. Writers love to write about you, fans want to know about your next project, and designers want to share their ideas and experiences with you. Talk!

19. Be excited about your work.
If you can’t get excited about something you’ve done, how can you expect others to be? Talk about your work and sell yourself as well as your game. If your work doesn’t excite you, why are you doing it? If you’re not happy doing what you do, stop. It’s impossible to be properly motivated unless you love what you’re doing; don’t be scared to let that passion spill into the press. Being indie means making your own rules: if your own rules don’t excite you, rethink them.

20. Join communities.
Indie game communities are booming: join one. You don’t have to post anything, but reading them will give you an understanding of the dos and don’ts of beginning game development, as well as insight and opinions about design in general.

21. Learn a little about business.
Business sucks ass, but it’s important to know something about it so you’ll know if you’re getting fucked over. This goes hand-in-hand with networking: ask like-minded people about business situations they’ve been in. Find out how much things go for, percentage cuts, sales numbers and the best places to sell your wares. It’s easy to get caught up in a seemingly amazing publishing deal if you have no perspective on how things work, and just as easy to get totally fucked over and lose your intellectual property in the process.

22. Don’t worry about being poor.
Indie game designers are starving artists. Be frugal and humble. Again, your goal shouldn’t be financial gain first and foremost, If it is, you will most likely fail. A profitable indie game designer is a rare thing. If you value money over “a job well done” then this isn’t the field for you.

23. Try to make money.
Selling your work, getting your games sponsored, using online ads or asking for donations are all means of making money from your work.
You need money to eat, so try to make some.

24. Have fun.
If you’re not having fun then quit.
You only live once; there’s no reason to keep doing something if it’s not making you happy.

Edmund McMillen is an independent game designer & illustrator based in Santa Cruz, CA. Best known for his work on Gish, Braid and the upcoming Super Meat Boy. Edmund has also spent the past 6 years working on honing his craft by releasing smaller, more personal online projects like Coil, Aether and Time Fcuk.

Comment on this post in our forums

Posted in DevelopmentComments (2)

OLDER ENTRIES »

About indievision

indievision is here to help promote the interests of indie studios, and provide information, advice & contacts essential for running a successful studio.

What We Do

Ask I.V.


Ask I.V.




Contributors Needed

We are looking for contributors to provide content for the site - articles, useful resources & information, business advice, etc.

You will be fully credited for all contributions you provide, along with email & web links and our eternal gratitude!

Contact Us