Feed Me: Game Podcast & Website RSS

Before making games, I enveloped myself in as much professional and enthusiast coverage about games as possible. To efficiently collate all of this written and audio information, I used applications able to aggregate multiple RSS feeds and display their contents. In doing so, I built a personalised window into the industry, constructed from a diverse collection of handpicked stained-glass.

The same is true today, only my content choices have changed over time. In becoming a game developer, the information I seek has skewed towards the business of creating games, rather than consuming them. There has also been a shift towards selecting sources that efficiently deliver the information that I need.

It is important for a game designer to be aware of, if not experience, as much of the cutting edge as possible. There is not enough time to make games and play everything that is relevant or innovative, so critics opinions are still a valuable resource.

Most websites' written game criticism is heavily watered down with press releases, previews and other op-ed. Those sources that do allow reviews to be filtered into a single feed do not exclusively cover games that push the medium forward. There is a lot of cruft to sate an ad-driven business model.

With limited time to indulge in nonessential coverage, I mostly rely on podcasts for player criticism of contemporary releases, and to identify trends in consumer tastes. The limitation of recording only a few hours of audio a week results in a condensed format, discussing notable games with brevity. There is also the added benefit that a podcast can be listened to, sped up, whilst performing grokked menial tasks.

Finding podcasts that consistently deliver high quality, edifying editorial is nontrivial, as their content is not marked up in a meaningful way for search robots to crawl, and for listeners to rate.

In a previous post, I summarised those podcasts that made up my weekly smörgåsbord of listening content. The majority of these have either been retired, or have disappeared with their defunct parent websites. Those centred around the culture or design of games will remain relevant as long as their archives are intact. However, the medium's evolution continues apace, and new podcasts have emerged to beat the march.

Instead of summarising a snapshot of my current listening habits (to become a tragically outdated graveyard of content sources), I have made a Google Doc that will be pruned and updated:

Downcast is an excellent podcast aggregator for Apple products, and exports its list of podcasts in OPML (a data format underpinned by XML). By passing this document through an OPML to CSV converter, the list can easily be imported into a spreadsheet.

I have added a comma-separated “tags” column to categorise and sort podcasts, so that they can be usefully filtered based on the listeners' requirements. However, I offer no subjective assessment, other than whether I am actively listening to each episode produced.

As for written, web-based content, I consider there to be far less of a discoverability problem. Although Feedly (my chosen successor to Google Reader) has OPML export functionality, my consumption is highly developer-centric, and easily replicable. Most podcasts in the Google Doc have a parent website that also produces worthy written content, and the game developer blogs that I follow are linked to from their owners' Twitter profiles.

I will mention Gamasutra, Develop, Techmeme, iOS Board Games and Pocket Tactics, which are all stalwarts I that read daily, but do not appear in my podcast list at the time of writing.

Happy feeding!

f(utility): Evaluating the Cost of Solo Entrepreneurship

Stargazy Studios is an independent micro developer in the truest sense. I am the sole designer, programmer and business lead, with art and audio assets for my projects created by talented contractors. This structure was necessitated by my means and contacts when I started making games in 2009. However, after having operated in solitude, I would elect to work with colleagues in the future wherever possible.

The differences between working alone and working in a team extend beyond creative control, and are not obvious without having experienced both. There are notable solo developers who have made significant works, but their individual processes are rarely dissected. I suspect they will have encountered some of the negative effects of solo work that I have, and their knowledge would have been useful when I started out.

Any entrepreneur should weigh the implications of team size in their business model, so I will summarise my observations here for consideration.

To frame the following advice I offer context, by describing the specific work that I do. Game development is a broad spectrum of endeavour, which is defined primarily by the scope of the target product, and the tool chain used to create it. In my case, the majority of my time is best classified as research and development. This is because I was unable to find off-the-shelf tools to craft the game that I wanted to make, and have had to write my own engine to build it. This has been an enormous effort, and not one that I had originally envisaged undertaking.

I strategically chose industry standard technologies, such as the C programming language and XML data encoding, expressly to leverage shared code. What surprised me more than the dearth of code sharing in the game development sector, was that more general libraries, which I would consider broadly rudimentary, were missing from the public domain. I wanted innovative features, unseen in games before, so had expected to have to write some proprietary code. However, the only shared libraries that I have been able to reuse are OpenGL and LibXML, which comprise only a fraction of the functionality of a video game. Data structures, an asset management pipeline, dynamic storage of assets at runtime, rendering and pathfinding are all scratch-built features of my engine, which I am sure have all been written many times over behind closed doors.

What typifies an environment in which research and development takes place is the feedback bubble that encompasses it. The bubble contains only those who are working on a project, so all motivation must be drawn from introspective evaluation. This is why deciding a team's structure is so important. Until your process yields a product that can be evaluated and patronised by consumers, your feedback from external parties is nil. All energy expended between start to release is imperceptible to most people, either because the undertaking is unknown to the target audience, or because those who are observing the process do not have the domain-specific knowledge to parse it.

A practical example of this type of working environment is the academic research involved in attaining a PhD. Research areas tend to be highly specialised, perceptible only to those working in the same field, and individual candidates must conduct self-directed study for several years before submitting their theses.

In the case of a PhD, candidates have the support of their departmental peers, as well as their experienced supervising professor. This mentor-lead structure has evolved over hundreds of years in our academic institutions, refined to yield successful research. So, if adding members to a research team boosts individuals' motivation and success, then why work solo?

Complete creative control over a personal project may seem attractive, but I have found it to be outweighed by the effects of being the sole occupant of a feedback bubble. Feeding off of your own energy and enthusiasm for long periods of time is exhausting, and when you run dry, burn out sets in. Productivity suffers until you have rested enough to rebuild your motivational reserves, costing you an entrepreneur's most valuable commodity: time to market. In a team, individuals' troughs can be offset by other members' asynchronous energy levels, as the desire to perform in line with ones peers takes effect.

Also, unlike PhD research, making a game is a multi-discipline endeavour that lends itself to parallelisation. A team may attempt to make a game with a larger scope than a solo developer, even with the efficiency drag of communication and coordination. As the market only subjectively evaluates the final product, there is no regard paid to the resources spent to create it. The majority of consumers will not be aware of, or be concerned by, the size of the team that made a product. Limiting the scope of your output can make you less competitive in this marketplace, which is another argument for teamwork.

So, again: why work solo? In my case, and for a lot of other independent developers, it is not a choice. It is a matter of risk adoption. Unless you have access to risk-hungry entrepreneurs, willing to work for equity in your product, then you will need resources beyond most people's personal wealth to incentivise employees. If you have the skill set to make games in a small team, then you are highly employable in a range of well compensated technology roles. Game development, and other private sector entrepreneurship, suffers from not having the established support structures and ring-fenced funding of our academic institutions.

I graduated from college in computing with friends, and had worked in technology until I formed Stargazy Studios. I had many in my professional network with the ability to make games, but the issue was that they were of an age that they had begun to take on liabilities, making them risk averse. Salary-backed mortgages, and dependent family mouths are standard societal concessions made in your late twenties and early thirties. As I had no experience with game development, I considered it disingenuous to promise a suitable return to those who did not make natural entrepreneurs. Although new funding avenues have become available with which to pay regular compensation, these require a minimum viable product for application, and do not underwrite the crucial research and development phase of creating a game.

Start something early in your life, as soon as your professional circle includes those with applicable skill sets. Stay involved with organisations that naturally attract entrepreneurs: academic institutions, local interest groups, and co-work and hack spaces. Bootstrapping with fellow entrepreneurs, unburdened by personal liabilities, minimises start up costs, and the risks of failure.

Another way of reducing entrepreneurial risk is to have a successful track record. If you are an alumni of the traditional game development industry, then you are more likely to be able to form an independent team. Unlike the vocational skills attained through many higher learning courses, the only effective way to train to make games is by making games. In addition to being able to attract first round funding earlier, by being a better investment, your peers form a pool of experienced professionals who can be productive from day one of a project. Resultingly, the scope and success of games built independently by alumni teams is enviable.

Those who are young, risk-hungry and highly trained, combined with the veterans of a small, often employee-hostile industry, represent a sliver of those with something valid to contribute to games. However, for the remaining majority, we are unlikely to have resources to build a team.

So, without access to colleagues to bolster productivity and morale, what factors improve an individual entrepreneur's chances of success? They are the same as for those who work in a team, but are more acutely felt without augmentation. After several years of solo work and introspection, I identify the following key sources of sustenance during a project:

Ego

Every day you will be challenged to achieve technical feats, be creative, consume vast quantities of applicable material, meticulously execute clerical tasks, and solve problems made for you by others. This must be done day in, day out with the exclusion of any external feedback. No-one will recognise your utility until you have a product for them to consume. Going into a project like this, you must carry enormous personal reserves of energy, and an unyielding resolve to finish. You must believe in yourself absolutely, with no allowance for second guessing the value of what you are trying to achieve. There will be ancillary drains on your time and effort that will attempt to distract you from your goal. You must be single-minded and selfish, immediately cutting down the tendrils of procrastination or distraction as they sprout. Ultimately, you must do anything necessary to succeed.

A Community of Peers

No-one will truly understand the exertions of the process you are going through without being there to experience it with you. However, if the product you are creating is worth your time and effort to create, then it is likely there are others who are attempting a similar enterprise. Seek them out, and give each other support by offering understanding and aid in your shared challenges. When possible, demonstrate what you have created to your peers for valuable feedback, during what would otherwise be a drought. Solidarity and positive criticism are powerful forces for replenishing energy levels and improving productivity.

Unconditional Love

Friends and, especially, family will want you to succeed. Their emotional investment can be a source of motivation for you to finish your project. As well as any inherent trust that they have in your abilities, it is also important to explain your motivations to them. Without necessarily understanding the process required for its creation, they should be able to see the value in your envisioned product. However, be wary of time pressure exerted by those around you who do not understand the work involved. Continually being asked, “When will it be done?” is not a positive motivator. It devalues your exertions, encapsulating the groundless assertion that you are working too slowly. This is often unintentional, but as time spent on a project is the only perceptible metric to most people, expect it to dominate conversation.

Some days, you will undoubtedly feel beaten up by the seeming insurmountability of your task. Putting the project out of your mind and seeing friends and family can be an effective antidote to this. Remind yourself that it is possible to be happy without having to cross off another item on your to-do list. Also, observing that the wider world won't stop spinning on the basis of your success shrinks your problems. You can then carry the positivity you gain from being valued externally of your work back into your process.

Good advice always seems like common sense when read. Though, practically implementing it is non-trivial, as I found when I relocated Stargazy Studios.

Development was going well, and I had the experience of working solo from a home office for some time. I thought it would be trivial to move to another metropolitan area and continue my operations. However, I did not have the above factors in mind when I committed to a move.

The pool of entrepreneurial risk-takers in a society is small, and is even further diminished when considering a single, niche industry. There are two hubs where you can find a significant community of independent game developers in the United Kingdom: London and Cambridge. In relocating, I moved away from one of these to a city without an indie scene. The lack of peer solidarity, shared interest and positive feedback was further compounded by being distant from friends and family. Weekly meetings with my support network, familiar with my work, and invested in seeing its completion, became quarterly or annual.

In isolation, my energy levels were quickly diminished. This left me vulnerable when antisocial neighbours moved in next door to us, shortly after we had arrived. They destroyed my home working environment with their constant noise, which ate away at my productivity. Eventually I was so burnt out that I took a sabbatical to start another business. My confidence was completely undermined at the time, and I was unsure as to whether my inability to continue with development was a personal failing. I looked at the new business as being a potential transition if this was the case.

However, away from the tainted home office, I was able to recuperate and refocus, finding my energy return with a fresh entrepreneurial challenge. In this clean air, I realised that game development was the path that I wanted to take, and resolved to finish what I had started. Identifying our neighbours as the root problem, I moved into a quiet co-work space to resume Stargazy Studios' development. In the new environment I found my programming productivity return, which was a tremendous relief. The workspace provided a stopgap whilst moving house, where I re-established a professional home office, and was able to continue with my business unfettered.

The time lost to this distraction is lamentable, and was also avoidable. I should have identified our neighbours' disruption as unacceptable upon their arrival. Insisting on moving home immediately upon relocating to a new city seemed costly and selfish at the time, but now I see it would have been the right course of action.

I must continue to be vigilant, and find ways to bolster my energy levels so that I can take action when it is required.

Although the distance from my peers, friends and family is currently immutable, I am finding ways to improve my process to compensate. This is why I have decided to resume writing articles: to increase others' understanding of what I am doing, and to find solidarity with those who have had similar experiences. I am also open-sourcing the code that I've developed to plug the void in the public domain. This offers the dual benefit of allowing peers to avoid unnecessarily replicating my work, and for them to gain a deep knowledge of the challenges that I have overcome.

Without a fundamental change in the way that independent game development is supported, I feel that my struggles are due to be replicated ad infinitum. There are examples in other research-lead sectors of creating resilient environments to foster nascent entrepreneurial enterprise. In the private sector these take the form of incubators, and are prominent in the contemporary Silicon Valley startup model. Incubators offer startups operational resources, the experience and contacts of successful grey-hairs, and subsistence funding. Given that video game development is ideas driven, it is surprising that the asset-rich, pre-digital distribution era publishers have not invested heavily in portfolio-broadening think tanks such as these. It seems like the natural role of a publisher after the democratisation of game development.

At the time of writing, the incubator framework has started to emerge naturally in the independent developer community. Game development cooperatives are forming around prosperous indie studios who are willing to seed startups with their knowledge and financial success. I have always thought that this would be the future of the industry, as is solves many of the problems that I have highlighted with solo entrepreneurship. Mentoring, and a community of peers are baked in, resource sharing can take place quickly and organically, and cooperative members can work on multiple projects, avoiding burn-out and becoming invested in a wider product range.

It is my intention to eventually build such an environment. Great game ideas should be born, regardless of their creators' ability to conquer avoidable operational hurdles.

Game Data Tools: Object-Oriented Design, but Data-Driven at Run-Time

About twelve months ago, I had a vertical slice of Huscarlas running, and, up until this point, had been able to create the small amount of game data required, by directly entering it into the IDE. However, I now needed to author large amounts of content, expanding the scope of that vertical slice.

Most games have complete levels hand-authored, in their own, game-specific level editor. Each atomic element in the game engine must be placed, and then customised by a level designer. These elements may vary: from interactive objects, like enemy spawn points, to static props, like background textures. At its most basic, creating elements may involve typing lines of data into a text file, which can then be read-in, and parsed at run-time by the engine. This approach is sufficient for game prototypes that require only a small amount of data. The benefit of this approach is that only a simple text editor needs to be incorporated into a game's tool-chain.

A text (or hex) editor is a very general, off-the-shelf data-entry application, but there are no data-entry checks to ensure that data is correctly formatted, or that it is within a range of acceptable bounds. Also, a text editor does not offer you guidance on what that data will mean in the context of a game's engine. Without any contextual information about how the game will treat the data, qualitative judgement can not be used by a designer. For example, how many milliseconds should there be between two adjacent frames in an animation sequence? This is a subjective value that requires the resultant animation to be observed, whilst it is tweaked. Without visual feedback showing how a data-set manifests in a game engine, we are left to pick numbers out of thin air.

A more sophisticated approach is to build a custom, visual editor, which exposes a toolbox of graphical widgets to level designers, each widget representing a game element. These widgets can be placed onto a canvas, and then the editor outputs the represented elements' data into static files, derived from its own, internal model of a game level. The bespoke editor can be coded to sanitise data entry, and the widgets' appearances can be used to provide contextual feedback, showing how the data will be treated within a game's engine.

The amount of contextual information can be improved further, by having the editor interface directly with a game's engine. By allowing an element's data to be placed into an engine's run-time memory, the designer can observe exactly how the data manifests.

Whatever form the authorship tools for a game may take, they themselves must be written. If you are able to repurpose a packaged tool as your editor, then this will save you a great deal of effort. However, I have found the existing tools available to me to be inappropriate, as they are either: too general (not providing me with enough context about how my engine will interpret the data), or too specific (are tightly coupled to a related engine, requiring its use).

Coming from a software engineering background, this seems odd. There are several ubiquitous, contemporary data formats on which to build our game editors. My preference is XML, which has been around for over 15 years. It allows for the expression of most object-oriented concepts, is human-readable, and has had its veracity tested in a large number of applications. It would be logical to assume that these commonplace data formats are widely used to store game data.

In addition, as there are similar, atomic elements shared between most game engines (sprites, 3D models, animations etc.), it follows that the data representing these elements could be manipulated for most games with a single editor. Reusable tools should exist to author similar data, across a range of game engines, storing it in an open format.

This is not the case.

For example, I trialled dozens of editors in order to compose 2D sprite animations from a texture atlas, but found none fit for this commonplace task. Despite this, tools that could be reused across a wide range of game projects must exist; I just think that they have been created multiple times over, behind closed doors. This was frustrating, as it means that we have to replicate this work once again, for our own purposes.

Huscarlas' levels are procedurally generated; an algorithm determines the terrain and enemy placement each time a new level is started. However, there are still manually defined, atomic elements that the engine needs to be provided with. These are the building blocks for the engine to piece together at run-time. In essence, what I needed was an editor that allowed me to control which GUI widgets should be used to input each elements' data (for most data, this would be a simple text entry box, with validation). Specifically, using XML terminology, I should be able to define a schema for a document, and then have an editor configure itself by parsing that schema.

After using extensive search-fu, and systematically working my way through xml.com's list of XML editors, I found just two existing projects to create a self-generating GUIs:

• XAmple (developed by Felix Golubov in Java, distributed in the public domain)
• A Dynamically Generated XML Editor (developed by Marc Clifton in C#, distributed under a permissive licence)

Although neither contained GUI widgets to contextualise game engine elements, both offered a starting point, and had the potential to become the editor that I needed. Also, as I have described above, they could become an editor for the wider industry. Currently, I'm working with XAmple, as it was built with extensibility in mind, is well documented, and I have experience with Java.

Why, though, am I so focussed on storing game data in XML? Why should it be the data format of choice for the games industry?

My preference is mainly due to XML's ability to represent object-oriented data models. It is easiest to describe a game's elements as objects, listing their attributes and interactions. This approach is grounded in how we describe the world around us, in our own natural languages. XML has a grammar that we, human beings, can use to communicate easily with one another, whilst still being a useful representation for computing.

However, the considerations we have when composing our data are different to those when we are computing the data in our game engine. The data will no longer be used to communicate amongst humans, and so we can store it in a format that is better suited for computation only: optimised for walking, accessing and manipulation. It doesn't often make sense to instantiate the data at run-time as objects, with all of their individual attributes held adjacent in memory. If your code processes large sets of objects, accessing only a small number of their attributes at any time, then it would more efficient to break out similar attributes into their own data structures. In Huscarlas' code, attributes of the same type are stored in arrays. By tailoring our data structures, based on the logic that will process them, we improve the run-time performance. This is a data-driven approach.

When storing objects' attributes in their own, break-out data structures, each must have an index, to indicate which object they belong to. Once an object has a unique identifier, then all of its attributes can share this index wherever they are stored.

We humans tend to give our objects names that are descriptive, and easily remembered, but these are costly to use as indices. If we use strings as identifiers, they must go through a hash function, in order to reveal their underlying index values. When using arrays, it makes sense to assign a group of objects unique identifiers from a sequential range of numbers, starting from zero. This way, each of an object's attributes can be accessed directly in their respective arrays, using the object's numeric identifier as an index.

Manually maintaining sequential, numeric identifiers is unsustainable for a moderate to large data set. In order to facilitate a data-driven model at run-time, one of the first extensions I needed to make to my XML editor, was the ability to generated unique, numeric identifiers for objects.

However, our memorable names for objects must also be preserved. This is so that specific objects can be referenced in-code, without having to know their numeric identifier. By storing the identifiers as named values, using the native syntax of the code base, objects' indices can be easily recalled by name. In the case of Huscarlas, the code-base is written in C, and named values can be stored in enumeration blocks, output to header files.

I continue to add functionality to my XAmple-based editor, and intend to distribute it for wider use once it has matured. In the meantime, I've written Perl scripts to assign numeric identifiers to XML elements, as described above, and have uploaded the code to GitHub. If you would like to implement data-driven, run-time structures, derived from static XML documents, then you can find these helper scripts here:

• xmlInjectUids (generate UIDs, storing them in known XML element attribute)
• xmlToHeader (generate UIDs, creating a pseudonyms in a C enumeration block)

When is a $60 Game a $0.99 Game?

There has been a lot of discussion about the erosion of game prices. Most of the blame has been levelled at smartphone marketplaces and free-to-play games, which both offer play experiences at a disruptively low price point.

Unsurprisingly, the most outspoken of all companies has been Nintendo, who've had the hand-held market sewn up for the past 22 years. It seems like every single executive got the memo to go on the defensive about their games' value. There is an element of irony to this, as part of Nintendo's success with its portable consoles has been their cheap and cheerful pricing. It's telling that they had to slash the price of their latest console, the 3DS, when they broke this low-cost model.

However, it's not just those businesses who are directly in the firing line who are worried. Epic Games' president, Mike Capps, publicly registered his concern that this value proposition shock-wave will change the whole industry.

I agree that change is inevitable, but I think lower pricing is only a secondary effect of the true cause of this disruption. Digital distribution is the actual driver of the entropy we're seeing, as it eliminates any type of physical delivery. Without the risk of having to eat the up-front costs of manufacturing and distribution, more developers are able to compete in the marketplace, and this competition is what's driving prices down. These new operations are much leaner than the old-guard, and are doing it cheaper, faster and better. Your ability to write a large cheque doesn't guarantee your place at the table any more; having something valid to say determines whether you can sit and be heard.

This got me thinking about the comparative costs of the content delivery methods used on each of the competing platforms: download for smartphones, and physical media for consoles. Is there that much difference between the 'real', like-for-like price of a game sold using bricks and mortar distribution, and one sold in a digital marketplace? The headline figures are: $60 for a console game, and between $1-$5 for a smartphone game.

From a developer's perspective, delivery cost in a digital marketplace is simple to quantify: 30% of the sale price goes to the vendor. That's it. Done.

The retail shop route is considerably more complex. A contemporary article by Forbes puts the friction costs of manufacturing at 5%, distribution at 1.5%, console owner's fees at 11.5%, and retailer margin at 20%. That totals 38%, which isn't a million miles away from the 30% a digital marketplace rakes (which suggests Apple, Valve and other providers take too much, but that's a discussion for another day).

If the costs of the routes to market are similar, then what other factors are there that can explain how the price of a smartphone game can be a fraction of the price of a retail game (2-10%), and still be sustainable?

Let's consider the population of people who play a retail game: how many of them actually pay the full retail price for it?

It's telling that I had to look up a typical retail price for a game before writing this post; I can't remember the last time I paid full whack for a title. In the US, Brink for the Xbox 360 was priced at $60 for release in May. Using camelcamelcamel.com, I can see that even before the first week of sales, the price had dropped to $45. The price then fell again after 6 weeks to $30, and after 10 weeks, it's now around the $25 range. Of all those who have bought Brink new, how much did they pay for it on average? It's difficult to say without the sales data, but another online charting tool, VGChartz, indicates that 88.3% of lifetime sales were made between weeks 1 to 6, 6.4% between weeks 6 to 10, and 5.3% thereafter. This implies a rough average sale price of $43.

Of course, this is one game among thousands, but it's a fair example of a title with an average critical reception, decent sales, and whose multiplayer population appears to have waned after the first couple of weeks, precluding significant Long Tail sales.

We're still nowhere near our smartphone game price yet, but the average price of a retail game drops dramatically if we consider the population who play the game borrowed, second-hand or rented. This is an inherent factor for games delivered on physical media, and in these cases the developer will see no revenue. There are large numbers thrown around quantifying those that rent games (50%), and those that buy used games over new games (53%). Even discounting players who borrow games from their friends, the impact of rentals and used sales implies that only one quarter of those playing a retail game will have paid the developer. Comparably, everyone who plays a digitally distributed game will have purchased it in the primary market, paying the developer directly. Adjusting for paying player populations, a physically distributed game's like-for-like price now falls 75% to $11.

There is another significant difference between the population of smartphone and console games players: the size. Not including iPad 2 sales, Apple has sold 189 million iOS devices... This is the same number as the Wii (88M), Xbox 360 (55M) and Playstation 3 (50M) combined. Due to hardware differences, it's common for a developer to sell their game on either the Wii, or both the Xbox 360 and Playstation 3. Each approach addresses roughly 50% of the retail console market. If you're only reaching a market 50% the size of a larger market, then your sales potential is only 50% of that larger market's. Let's scale our like-for-like price again, down to $5.50.

Suddenly, a $4.99 price for a smartphone game isn't sounding unreasonable at all.

You may say that you can increase sales of a traditional, $60 game by releasing it on the PC too. However, that would only give you a market population boost of around 30 million. Easily offsetting this, Google's Android devices contribute another 130 million to the smartphone user base. For simplicity's sake, let's assume that we're investigating the feasibility of taking a non-PC retail game, and only releasing it on Apple's iOS devices.

There's another factor that can affect your sales potential: the quality of consumers in each market. How many games does a player purchase a year? Tie ratio research suggest that iOS owners buy a similar number of games as console owners. This isn't surprising given the recent analysis that indicates a typical iOS device owner has downloaded 75 applications. It's highly plausible that a small portion of these are paid games, so assuming parity between the quality of smartphone and console consumers seems a fair.

We've come a long way from the vehemently defended $60 price point. Like-for-like, we're all the way down to $5, but how do we get from there to $0.99? It's simple actually: no-one is spending $10 million to make a smartphone game.

We've got like-for-like prices, but not like-for-like products. A particularly large budget on a smartphone game is tens of thousands of dollars, whereas a $10M budget is considered relatively small for a console game. Being generous, let's assume that a smartphone game costs $100K to make. That's still 100x less money needed to be recouped in sales than an average console game. Perhaps it's a good thing that Apple stipulates a 99c minimum price on the App Store. Accounting for product budgets, our true like-for-like price is a ludicrous 5c!

The fact is, most traditional, heavy-weight game developers aren't making big-budget titles for smartphones, but it's entirely feasible for them to do so. Want to keep you're multi-million dollar budget? Charge $5 for your game; EA is already doing this. Better still, create freemium games whose revenue is driven by in-app purchases; research indicates that you'd be able to triple your budget (IAP total spend per game averages $14).

It's little wonder that these publicly owned companies are coming under fire from their investors for not getting involved. With all the new development talent joining the fray, can they afford to simply cross their arms and pout?

Huscarlas: Old Plurals are not Created Equal

What you see above is the Old English word huscarlas ("hooz-karl-as"), written in Anglo-Saxon Futhorc. This runic alphabet has its origins in the Scandinavian runes, and was used before the the Christianisation of England.

The word's above form embodies the evolution of my own understanding of Anglo-Saxon culture, language, and religion throughout the development of my game, Huscarlas.

I'd formulated the game's core mechanics before deciding to enrich it with Dark Age English themes. My self-imposed brief was to distil the tactical turn-based genre, and wrap it in a lean, modern interface. During this pre-production phase I'd spent time in London's museums and galleries, hunting for a spark to ignite my concept. It came from the British Museum, whose Sutton Hoo collection lit the kindling of my intrigue with my own past.

Surprisingly, despite being raised here, my education in the history of Britain was somewhat patchy. Beyond a primary school project on the 1066 Battle of Hastings, I'd inadvertently dodged a formal introduction to my country's forebears. Luckily, after this brief spell of learning, I retained that Harold's army included his bodyguards, his huscarlas. They were a highly-trained, standing body of household warriors, who were tasked with the protection of the Anglo-Saxon king. A huscarl was a free man who gave his oath to protect his charge, and could own land and chattels, strengthening his position in society.

I knew that these would be the perfect men to walk the stellar planes in my game, wielding their axes in battle. I set about delving deeper into the life and times of this warrior cast.

The term Dark Ages was well chosen for this period of history, as there are few primary sources that have survived to guide us in its study. Written records appear to begin around the Christianisation of England, when the Latin alphabet supplanted Futhorc. As a result, the sources are late, and mainly ecclesiastical. Physical evidence is also scarce, as the post-Roman British used timber and other perishables in their buildings, rather than the Roman's heavy stone. It would take a lucky encounter with a historical novel to really drive my understanding forward.

By chance, I began reading Bernard Cornwell's Saxon Stories on holiday, and, as its main character is fond of saying, Wyrd bi∂ ful aræd (Fate is inexorable). The series dramatises Alfred the Great's attempt to unify England into a single country during the 9th century. The books rely on meticulous research by the author to imbue them with historical authenticity, and they seared the Anglo-Saxon people's identity into my consciousness. Although factual accounts of the age exist, I absorbed Cornwell's story, which is spiced with these truths, far more readily than the original sources.

The most striking realisation I took away from the Saxon Stories was the stark distinction between England's settled Anglo-Saxon population and the Scandinavian interlopers who came during the Viking age. Before, I had a muddy notion of generic tribes moving across Western Europe to displace the native Britons, followed by their subsequent conquest by the Normans. This has been replaced by the understanding that, although early Germanic and Scandinavian religions and alphabets are similar, their societies were very different during Britain's Saxon age.

Knowing this, I revisited what I thought I knew about the people I'd based Huscarlas' characters upon. I looked for specific facts about the Anglo-Saxons, delineating between them and their Scandinavian cousins. I had to make a rare foray beyond the bounds of Wikipedia to mine as deep as needed for this information.

It was a relief to find my conception of early Anglo-Saxon theology was not invalidated; as with the Scandinavians, they worshipped the gods of continental polytheism. Where Odin and Thor governed Valhalla for the Norse, Woden and Thunor did the same for the Saxons. Though, there is an interesting morphing of some mythology dependent on the territory in which it was told. For instance, The Wild Hunt, who trace their mad, ephemeral pursuit across the skies, includes King Arthur in some British accounts. The Germanic Pantheon has thousands of years of story built on its rich foundations, and I'm pleased to be able to plumb its depths for inspiration.

A somewhat more revelatory discovery was that my initial working title, "Huscarls", was spelled incorrectly. Although this is the most commonly used plural of huscarl in Google's search results, it is neither Old English, nor Old Norse. There are five cases within Old English, all of which can change the ending of a noun and its plural. The technicalities of the grammar took some time to research, but the correct pluralisation of huscarl is huscarlas, as with all strong, masculine nouns in the nominative case. I would like to thank Professor Muir and Professor Drout for corroborating this.

So, the title was changed to "Huscarlas".

The final evolutionary step discernible from the Huscarlas title above, is my re-discovery of Futhorc. In all the novels and primary sources that I'd read, the text was written using the Latin alphabet. However, I had a recollection from my childhood studies of writing runes with a feather quill. Following a trail of examples, through a series of research websites, I unearthed the use of runes by the Anglo-Saxons before Christianity took hold. To me, it seemed to be the script of the old gods, and its use fitting if Huscarlas was to play out in their domain.

I've been left with a deeper understanding of my subject, and a closeness to it that I'd been entitled to, but had not possessed before taking the time to understand our ancestors.

Huscarlas will be laced with my discoveries, and I hope that you'll join me amongst these legends of yore.

Spring Cleaning: Lessons Learned in Indie Development

Although I've been keeping everyone up to date, through Twitter and Facebook, as to which iOS games have been eating into my productivity, I haven't blogged for a few months. This was by design, as part of my master plan to duck my head below the parapet, plant my face firmly on the grindstone, and get a significant chunk of Huscarlas coded.

It has been a mixture of successes, intermingled with what I would term as "lessons learned". The most useful revelations to come out of my Winter coding exile have been about two things: project scoping, and time planning. Before your eyes wander away to click on something shiny, and not at all like a wanky management term, let me explain why these epiphanies could be interesting to you.

Before sauntering up to the indie-developer table, and presenting my jib for inspection, I'd spent many years consuming developer-written articles on websites such as Gamasutra, Edge and develop. A good number of these focussed on the very two concepts that I present today: scope and time management. Even those articles ostensibly about something else would somehow manage to slip a paragraph or two in about these subjects, just for good measure. How, then, after so much on these topics having already been written, could I possibly have anything new to say? Surely you can just read the same articles and be done with it?

The point is that I'd read these articles, found them fairly dull, and went away thinking that I'd understood what the authors wanted me to learn. I hadn't, and I don't think you can unless you've walked on your own precipitous path of an unscoped, unplanned project.

In reading them, I'd always thought that the principles discussed were only applicable to game projects with large teams with intimidating weekly overheads. The examples given were almost always framed by such projects, which is unsurprising given the dominance of big-budget studios over the last twenty years. As a one-man micro studio, I found it difficult to bring their lessons to bear on my own day-to-day operations.

Here then, I distil my own practical advice from these well-worn topics, filtered through the unusual perspective of a lone wolf.

Scoping

• Lesson: Do not invest any time into achieving something unless you know exactly what the finish line looks like.
  

  
  Learned: I knew that I needed an artificial intelligence for Huscarlas that could move optimally through procedurally generated levels. After reading some enticing articles that vehemently insisted that "navigation meshes" were the future of space representation, I thought I'd try to implement this type of structure. This technique had no published practical examples, and so I started from just the basic theory, with no notion of what the final logic should be. Inevitably, I wasted a couple of months theorising and working on it, before finding out that the examples the articles had cited were couched with provisos, making the technique impractical for my game.
  
  I will never work from hearsay again. Before diving into implementation of an unfamiliar concept, I now need to have read and understood a source that gives a complete explanation.



• Lesson: If there is an existing, complete solution to what you're trying to achieve, then use it. Don't try and reinvent the wheel, no matter how interesting a diversion it might be.
  

  
  Learned: After the punishing distraction of trying to implement navigation meshes, I realised that plenty of games must have, and must still, use a different approach. Nav meshes are a new concept, so something must have pre-dated them. After a small amount of digging, I found well documented, top-to-bottom solutions for using a regular grid of waypoints over a level. This technique is theoretically not as flexible, nor as efficient as using a nav mesh, but it's tried, tested and completely suited for my purposes. I managed to build a working implementation in a couple of weeks.
  
  As a small operation you've got to pick your battles. If you offered me the time I'd wasted indulging in unnecessary R&D in return for having never heard of a navigation mesh, I'd take your arm off at the elbow.

Time Management

• Lesson: Wake up each day knowing what needs to be done, and precisely where you're going to start.
  

  
  Learned: Procrastination will unnecessarily elongate your project, increasing your costs and eating away at your fragile ego. As both project manager and implementer, you should know exactly what you should be doing at all times though, right? Nice in theory, but I've found that without an up-to-date, relevant, and manageable "TO DO" list, the sheer scope of what I'm trying to achieve can fix me in its headlights.
  
  As well as a whiteboard list of tasks to reference, every morning I conduct a project-wide code search to turn up "TO DO" comments that I've left for myself. This search will always contain a unique line that begins, "TO DO: Start Here...".
  
  If I'm ever in doubt, I just do what the man says.



• Lesson: If you are unmotivated or stuck on a part of your project, understand what can be done in parallel and waste no time in shifting your sights to a more appealing target.
  

  
  Learned: There should be no quiet days at the office when you ARE the office. Inexplicably, sometimes it's impossible to get revved up about parsing XML files, or optimising rendering algorithms. Unfortunately these sorts of mundane tasks will befall anyone attempting to create a game by themselves. Instead of pouting, or trying to wade through your disinterest like treacle, it's best not to take such a bloody-minded approach, and just do something different. I openly prefer design to programming, and when I feel a malaise coming on from the lack of reusable code that's available to me, I've learned to switch tasks.
  
  It's both daunting and empowering to have to perform all the roles required to create a game. On the downside you'll have to do the boring stuff at some point. On the upside, you don't have to do it right now.

Looking over these lessons, I realise they can be applied by anyone who multi-tasks, and I'm sure they've been incubated throughout my career.

I battle daily to take my own advice, but if I've lost momentum, or lack motivation, then these simple rules have proven to rejuvenate me.

Changing of the Seasons

The last couple of months have been stuffed to bursting for me: my parents' ruby anniversary, two stag weekends and two weddings (including one best man's speech), Stargazy Studio's first tax return, the Eurogamer Expo, a couple of #LondonIndies meets, and the organisation of the inaugural BoardGameCamp.

It's a commonly observed phenomenon that tasks tend to take as long as the maximum time allotted to them. Not wishing to actively disprove this, I've allowed any coding time that I may have found in-between my commitments to be consumed by whatever flanked it. Although I've had a jolly nice time over the last nine weeks, Huscarlas is rightfully feeling neglected.

With the coming of the Siberian geese to Britain's shores signalling the onset of Winter, I'm beginning my own social Winter. Whereas I may have felt a little guilty hiding behind thick curtains from a glorious Summer's day, the dank, dreary Winter skies hold no such sway. I'm going to harness my seasonal hermit tendencies and take the opportunity to bury myself in coding Huscarlas.

To those that know me, it's been a pleasure, and I'll see you for the first antihistamine run in the Spring!

I will make one concession during this voluntary exile: the adventurous may enter my cave if they come bearing a copy Power Grid, Dominion or Carcassonne. Playing board games with friends is a perennial cornerstone for me, and the offer of a game is guaranteed to break my isolation. Where Summer dalliances fall to the wayside, I wouldn't give up board game evenings for all the spice on Arrakis.

BoardGameCamp was an unbridled success, and well attended by board gamers old and new. I never doubted it would be a triumph, as I've seen time and again how groups of people can be brought together by a shared play experience. It's always a thrill to introduce a new player to this world of round table gaming, and if you don't have board gaming integrated into your weekly social calendar, now is a great time to start. As the days grow shorter and the evenings stretch on forever, here are some of my favourite games to ward off the Winter months:

• Dominion
  
  Build a deck of cards from a shared pool and beat your opponents by producing the most victory points using the cards you draw into your hand. Each card may be used in conjunction with others in your deck, whose contents is continually changing throughout the game. There are 3,268,760 distinct shared card pools that can be created in the game, meaning it's impossible to play every permutation in a human lifetime. Dominion-night is the new Bridge-night.
  
  In one line: "I'll play a village, a festival, a militia, another village, a woodcutter, and a copper, which gives me... 7 treasure, God damn it!".
  


• Puerto Rico
  
  Plant crops on your land and use your income to expand your city or accrue victory points. Predicting and influencing the communal production line is the key to winning. Production from crop to goods to shipping is rarely unfettered by your opponents.
  
  In one line: "Don't you dare start a shipping phase until I've built a warehouse you git.".
  


• Power Grid
  
  Build a network of cities over a shared map, attempting to maximise your reach whilst blocking your opponents. Each city must be powered on your grid, so you bid in open auctions against other players for power stations. You must take it in turns to source raw fuel from a communal market, changing the price of each type of fuel in the process. Actions taken early on in the game can have a knock-on effect that doesn't become clear until the end of the game.
  
  In one line: "I knew I shouldn't have bought that uranium in turn 2.".
  


• Carcassonne
  
  Players take it in turns to place adjacent square tiles, creating networks of city walls, fields and roads. The exclusive rights to each structure are secured by placing a member of your pool of people on any adjoining tile you lay. Once a structure is completed the owner scores points and their claimant is returned to their pool.
  
  In one line: "And with this tile I condemn thine Meeple to eternal limbo.".
  


• Last Night on Earth
  
  Four heroes must navigate a square-tiled board to fight a zombie hoard. The two teams take it in turns to draw bonus cards, move their pieces and roll dice to determine the outcome of combat. Board randomisation and multiple scenarios lend tactical depth to this battle of the slow versus the few.
  
  In one line: "If I roll a 6 to move Jake to here, give the gasoline to Becky, she runs into the mansion with it, and Billy shoots her with his flare gun, I can win this thing.".
  


• Ticket to Ride
  
  This seemingly thoughtful family game is actually the most effective way to channel the ferocity of a 19th century rail-tycoon. Each player draws a set of random destination nodes that must be linked together on a communal map of interconnecting rail links. The rub is that once a link is claimed, no-one else can cross it. The resulting collision of interests can turn a family Christmas into a knock-down, drag-out brawl.
  
  In one line: "Vegas. You had to take Vegas.".