Over the past few years the mainstream has moved further towards sequels, playing it safe and limiting creativity.  It seems indie game developers are reacting to this by becoming “more indie”.  A case in point is the IGF.  Many of my indie friends complain that it’s impossible to win the IGF without making a controversial game that has no chance of making money.  Surely we can find a middle ground between these two opposed views.

Let’s look at key parts of game development and see where Mindie developers fit into the mix compared to pure mainstream and indie developers.

Profits – Money is the root of all evil but the source of all Twinkie’s

Most indie developers I know don’t have the luxury of making games just for the love of it.  At the end of the day, we all need money to live.  Mindie developers are mindful of making a profit from their games but not at the expense of the game itself.  The current landscape of game distribution is the perfect time for this lofty ideal.  Digital distribution, micro-transactions and huge user bases on platforms like Facebook mean that we no longer have to make a boxed product that sinks or swims based on the first few months of sales.  This gives Mindie developers the freedom to flex our creative muscles and then find a sales model that fits our product.  There are many options to take opening up many more possibilities for game design and creativity.

Competition – Competition creates better products, alliances create better companies – Brian Graham

The general consensus is that indie developers don’t focus on their competition while mainstream developers are obsessed with them.  Where does the Mindie game developer fit in?  This time, we are closer to our indie roots.  While it’s important to be aware of the competition and create something new and interesting, it should not drive development.  Indie developers begin with their own ideas and creativity and adjust their plans based on competition.  Mainstream developers begin with their competition and adjust their plans slightly to create their own game.

Publishers/Investors – Time is more valuable than money. You can get more money, but you cannot get more time – Jim Rohn

The traditional indie developer is defined by not having a publisher or large investor, hence the term “independent”.  They are usually self-funded or take on small amounts of angel investment.  The general consensus from mindie developers is that they would take on money, so long as it doesn’t water down their game.  This is often shown by their realistic expectations of money required rather than the “more is better” attitude of most mainstream developers.

Project Size – It’s not the size of the dog in the fight, it’s the size of the fight in the dog – Mark Twain

Mainstream loves big, multi-million dollar games.  Every year the cost keeps going up.  Indie developers either through love, or more often than not, through necessity go for simple, small projects.  Mindie developers need to find the middle ground again.  Projects that are of a substantial size that they can make a profit while keeping development costs low at all levels of development.  From team sizes to feature lists, they focus on finding the fun with the least possible features.

Art – If you think a game is ‘Madden 2008,’ then hey, games probably aren’t art – Jonathan Blow

Many indie developers make art.  Mainstream developers are skilled in the art of spending copious amounts of money making a game that is 10% better than the previous game or competitor.  Mindie developers are pragmatic.  They focus on making a fun, deep game and letting everyone else decide whether it’s art.  Pragmatism over pretentiousism*.

*Yes that’s not really a word, but neither is Mindie

Conclusion

So that’s my attempt to bring some unity between the mainstream and indie developers.  I look forward to seeing what the coming years bring for mindie’s and particularly in Australia where the collapse of the mainstream game development industry has left most of my friends turning indie in hopes of fame and fortune (or at least recognition and Twinkies).

What do you define as a mindie and are you one?

The current landscape

After my last blog post I was asked my thoughts on FrontierVille.  I fired it up and started playing.  I immediately hit a snag as I needed energy to continue playing.  Energy is used to perform most actions in the game.  There are three options for acquiring energy:

1. Waiting – Energy replenishes over time
2. Asking friends for energy – Spam your friends to request energy from them
3. Spend real money to get more energy

None of these are very inviting to me.  In fact, they all make me want to switch off the game and play something else.

I decided to investigate how much it would cost if I chose the third option.  I found that 7 points lasts me about one minute.  This equates to:

• Smallest payment – $60/hour ($1 = 7 points)
• Best value payment – $40/hour ($199 = 2,100 points)

And that’s just for energy alone!  You can also buy other items in game which don’t add to your energy reserves.

The Problem

This kind of cost is not sustainable long-term.  People will either end up spamming their friends, paying ridiculous amounts of money or letting the game dictate when they can play.  While current Facebook developers may be happy to cash in on this it is not going to last.  There are two options for gamers from here.  Facebook gamers will find better alternative Facebook games, or they will stop playing Facebook games entirely.

Why Sustainability?

Game developers have the perfect opportunity to reach a massive audience with deep and meaningful gameplay.  This audience also has an extremely large disposable income which can be tapped.  If we don’t take advantage of this, the droves of mainstream gamers entering the market will disappear as quickly as they arrived.  Giving a deeper experience than these expensive, spam-driven games will help to capture and grow the audience.

The Solution

There are a number of steps we can take to make Facebook games more sustainable.  I’m not suggesting we stop micro transactions and wall posts entirely; we just need to be more respectful with how we use them.

Players should get a solid reward for their time and money investments.  This expenditure should be treated more as an investment than just the cost of playing.  Players should be encouraged to spend as much as they like, but should also be rewarded in valuable ways.  By adding value to the gamers experience they are more inclined to continue paying as they see a direct correlation between enjoyment and money spent.  Currently the only correlation is between game time and money spent.

Wall posts and “spam” are a necessary evil of viral and social marketing.  The current drop in numbers has shown that they are an ideal way of advertising the game (the limitation on spamming ability of games directly relates to decline in number of players joining).  This viral marketing should be done in interesting ways that add value to the player, rather than being superficial requests for or sharing of items.

Rather than wall posts simply asking for things, or “sharing the good news” developers need to look at the core gameplay mechanics of their game and have a thread of continuity to their posts.  The main problem with existing games is the lack of deep and meaningful gameplay means there is little the gamer wants other than more of everything in the game.  Game designers need to factor wall posts and the like into their game design at a foundational level if they want any meaningful effect on gameplay to be seen.

Conclusion

With the right attitude and a good portion of respect for the player, we can turn this large audience into large revenue for the games industry.

What are your thoughts on sustainable Facebook games?

The existing list of items in the agile manifesto are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

And below is my item:

• Fun over features

What does it mean?

Basically, it means finding the fun first.  The fewer features you can add to your game to get the required amount of fun the better.  Focus on the core gameplay that gamers will derive the most fun from, rather than adding outlandish features that make your game stand out.  Don’t just add features for the sake of having them.

Some examples of games that have a low or high amount of fun and features include:

Low fun, low features – Cheap failure (e.g. many unknown flash games)

Low fun, high features – Big budget flop (e.g. Spore)

High fun, high features – Big budget success (e.g. Mass Effect)

High fun, low features – Low budget success (e.g. Canabalt)

Relationship between features and fun

Features and fun are tightly related.  You can’t have fun without a feature.  Fun is derived from experiencing a feature.  However you can have a feature without it being fun.  This is the whole reason we need to focus on the fun rather than just the feature.

Fun Amount vs Feature Size

What’s better, adding a small feature that isn’t too fun, or adding a large feature that is extremely fun?  On the face of it, the former seems better.  It’s not absolutely certain that a feature will reach a certain level of fun.  However it is certain that a large feature will take a lot of resources and a long time.  Completing the smaller fun features first seems like a logical extension of iterative development – ascending iterative development.  Add features an iteration at a time starting with the smallest features first.

I’ve previously spoken about the cost to benefit ratio.  My suggestion for which features to add is an extension of this concept.  Look at the Feature size to fun ratio.  Unfortunately this can be quite difficult to quantify, however you can do some simple calculations:

1. Rate your feature on “fun” from 1 to 10 – how much fun players will derive from it
2. Rate your feature on “size” from 1 to 10 – how large the feature will be to implement
3. Divide fun by size for each feature – fun / size
4. Order the features from largest to small (descending)
5. Work from the top down

The obvious caveat to this is if you have core features that must be added to your game.  However if they are quite low on the list I’d question the motives for why this is such a core part of your game if it isn’t fun enough.

Conclusion

So that’s a little investigation into a simple concept I came up with on the fly.  I highly recommend Clinton Keith’s Scrum course which lead to this idea.  I also highly recommend GDC to anyone thinking of going next year.  I learnt more than I could ever have imagined and made countless critical contacts.

What do you think of this idea?  If you could add an item to the agile manifesto what would it be?

What is Fluent?

Fluent interfaces allow game designers to write more fluid and readable code.  Through the use of method chaining, English like sentences can be written to express game functionality.  Fluent interfaces can be implemented in any object oriented programming language.  Below is an example of a line in the game design document, a standard implementation example and a fluent example:

Game Design Document:

“Do 5 damage to all enemy tanks within range 2 of an entity”

Standard Example:

foreach( var unit in player.UnitsWithinRange(2) )
{
    if(!unit.IsType(Enemy) || !unit.IsType(Tank))
        continue;

    unit.Damage(5);
}

Fluent Example:

player.UnitsWithinRange(2)
  .Where(UnitIs.Enemy)
  .Where(UnitIs.Tank)
  .DoDamage(5);

This fluent example closely matches the design document and is easier to read.  It also uses less language constructs like loops and conditions.  With Intellisense, designers are given a context sensitive list of operations they can perform.  Designers simply build up the expression that describes the original line in the game design document they are implementing.

How to implement Fluent Interfaces

Fluent interfaces are actually quite easy to implement.  Objects expose methods that return a reference to the object itself allowing method chaining.  The best way to describe this is by showing the implementation required for the examples above.

First, we create the object we will be working on (I’ve called it UnitsList in my examples).  This gives us the first part of the fluent call (Get.UnitsWithinRange(2)).

public class ScriptObject
{
    UnitsList UnitsWithinRange(int range)
    {
        return new UnitsList(range);
    }
}

The UnitsList object must have a set of methods that return references to the object itself allowing method chanining:

public class UnitsList
{
    public UnitsList Where(UnitIs condition)
    {
        this.conditions.Add(condition);
        return this;
    }

The fluent expressions are terminated by returning void from a function.  This lets the designer know they have no more options and often that the actual operation will be performed.

public class UnitsList
{
    public void DoDamage(int damage)
    {
        foreach( var unit in this.mainUnit.UnitsWithinRange(range) )
        {
            if(!PassesConditions(unit))
                continue;

            unit.Damage(damage);
        }
    }

    private bool PassesConditions(Unit unit)
    {
        foreach( var condition in conditions)
        {
            if(!unit.IsType(condition))
                return false;
        }
        return true;
    }
}

There are a couple of key things to notice:

1. This last code example looks a lot like the original standard example
2. A lot more “engine” code is required to setup a fluent interface than a standard interface

So, in effect, an extra layer of abstraction is being placed over the original code.  Rather than designers working on loops and conditions, they are calling (well named) methods.  This makes their life a lot easier and simplifies maintenance of their gameplay code.  It pushes the burden of maintenance down from the gameplay to the engine level and therefore on programmers, who are better suited to maintaining code.  If there is a change in the engine or game, this extra level of abstraction serves to buffer the designers and reduce the amount of code that needs to be written.

Good Interface Design

Care needs to be taken when designing the interfaces and exposing methods to the designers.  Rather than exposing all functions off a single object my recommendation is to define different objects for different situations.  The example provided starts with the player and retrieves a list of units around it.  Filters are then added before the final operation is performed on the resulting list.  By limiting the methods available to the designer to simple filters there is little risk of them making a mistake.  Also, the fact that the “DoDamage” function returns void stops them from chaining anything further.

Other Syntaxes

One small point is that designers can structure their fluent “sentences” in any way they please:

player.UnitsWithinRange(2).Where(UnitIs.Enemy).Where(UnitIs.Tank).DoDamage(5);

player.UnitsWithinRange(2)
  .Where(UnitIs.Enemy)
  .Where(UnitIs.Tank)
  .DoDamage(5);

There is no difference between the above two examples.  It’s simply a matter of coding style preferred by the writer.

Conclusion

What do you think of Fluent Interfaces?  Have you used a similar technique before?  Do you think the extra engine code and maintenance is too much hassle for the gain in clarity to designers?

As an experiment, try exposing a small set of functionality through a fluent interface and see whether your designers like working with it.

What are virgin play testers?

A virgin is anyone who has never played nor seen someone play your game before.  That second part is important.  If Bob is watching Jim play your game then both Bob and Jim are no longer virgins.

They are equivalent to someone downloading the demo of your game and firing it up for the first time.  They should come from your target audience and preferably be scattered throughout this demographic.

Why do you need virgin play testers?

People have a short attention span these days.  You only have minutes to convince someone your game is worth buying.  Watching a virgin play your game lets you watch the experiences every player will go through when they first play it.  This is absolutely vital if you want to make your game playable and get a conversion.

Gladwell in Outliers has the 10,000 hour rule: the time it takes to become proficient in an activity.  I have the 1,000 hour rule.  After 1,000 hours working on (and playing) your game you can’t objectively determine its quality. The only caveat to this rule is that after a year of not having anything to do with the game your virgin status is reset.  This doesn’t really help in the world of game development as you can rarely take a year off.  It’s much easier to just go out and find virgins. The bottom line is that the only way you can experience what your game is like for a virgin is watching them play.

What’s the best process?

Here are some simple rules to help you:

• Video tape everything – If possible, try and get the game and their hands in the shot at the same time.  This lets you see what buttons/sticks they are pressing at different stages, particularly if they get stuck
• Don’t help – If you have to help them your game needs some major changes.  Imagine that same person sitting at home without you there; they will most likely give up on the game.
• Get them to say what they are thinking – The best way to find out when they are stuck, bored, excited, surprised or confused is to get them to tell you what they are thinking as they play through the game
• Don’t dismiss anything – No matter how trivial a comment is you need to take it on board.  Even if the person dismisses their comment later you should take notice of it.  On a number of occasions people would say a particular part of the game wasn’t a problem after having it explained and it’s easy to then ignore that issue.
• Fix the problems – This is vital.  There’s no point getting virgins in to play the game if you don’t fix problems they find.  This might seem like a simple idea, but it’s important you keep a record of every issue and resolve them.

Where can you find virgin play testers?

There are 4 main places you can find virgins to play test your game:

1. Within your company – If you work for a large company, start internally.  This reduces NDA and other issues, helps build community within the company and encourages other teams to start virgin play testing if they don’t already
2. Friends and family – The next best step is people you know and trust.  You’ll still want them to sign an NDA, but there’s less chance they’ll break it.  This is also a great way to catch up with your partner who you haven’t seen since before crunch started.
3. Local game development education institutions – Go to your local game education centre and put up a sign on the notice board reading “Get your name in the credits of a game, right now!”  I guarantee* at least 90% of them will jump at the opportunity.  This also has the secondary benefits of letting you scope out talent and you might even get some good suggestions for your game.
4. Everyone else – This is the most important and largest group.  Grab random people off the street or from your local video game shop.  You want to be taking a large cross reference of people here.  It’s also a good idea to find some people outside your target audience.  You may find the game appeals to a larger audience, or that making some small tweaks will broaden your audience substantially.  Free beer and/or pizza is usually payment enough for people to sit and play games for a few hours.

*Not a guarantee

Conclusion

I’d like to say a big thanks to Matt Ford for a lot of the ideas from this post.

I was blown away by how important it was to watch virgins playing our game each and every week.  It does take time and resources, but it’s well worth the effort.  It helps keep you on track and focussing on the initial user experience, the most important part for making the sale.

Go out right now, find someone that hasn’t played your game before, sit them down and watch them play.  I guarantee* you’ll learn something about your game that will make it better.

*This one is a guarantee (unless you’re a lawyer)

Is it for you?

Indie game development isn’t for everyone.  The pay is low, you typically need a “day job” and you need to work extremely hard for little reward at the beginning.  It’s not all bad though as you are your own boss (and project manager), the monetary rewards can be higher and the reward of creating something of your own is overwhelming.

If you’re passionate about making games then the negatives might seem inconsequential, however I’d recommend taking some time to think them through.  You need to be well informed about how long indie games take to develop and you need to be realistic with the goals you set.  My biggest advice is to talk to people who have done it before.  These guys can tell you where the stumbling blocks are, and give you a realistic view into what life will be like once you take the plunge.

Set Concrete, Realistic Milestones

Many indie games are killed by a lack of interest after a few months or years of development.  By keeping your goals realistic and achievable you are reducing the chances of failing in the worst way, by not completing the game.  Always have one primary goal you are heading towards (e.g. alpha, beta, release).  The primary goal should be made up of smaller, measurable goals (e.g.  implementing level 5).  Finally these smaller goals should be broken up into a constant “to do” list.  If you have any spare time, you should know exactly what you should be working on next.  This cuts down on procrastination and helps you have a clear direction for the coming days and weeks.

Find a Great Team!

Realistically, there are few games that can be created by a single person.  Your team needs to cover all the bases – programming, design, art, audio, project management.  Even if you have all these skills, having at least one other person will half the amount of work you have to do and double the number of people contributing to game ideas and “finding the fun”.

Find people who are passionate about game development.  Passion trumps ability when it comes to independent games.  As long as the team member is good at their job, it’s more important to find someone who’s passionate then the very best in their field.  The lack of short and medium term rewards from indie game development means the team will be rely on their passion to make it to the end-game.

Don’t expect to “fill the gaps” at the end of a project by slotting someone in once everything else is done.  You need a well rounded team from the outset so all areas of the game get enough love and attention.

Different people have differing levels of time they can invest.  Work this out up-front and all agree on your level of commitment.  Roughly schedule the entire game so everyone is area of expectations and can commit to the duration of the project.

Get a day job

Most people will need a “day job” to pay the bills while they live the dream of being an indie developer.  Be careful if you plan on living off your savings as they disappear quickly, and there’s nothing worse than having to go back to working full-time because you ran out of money.

Find the highest paid job you can, no matter how boring.  Think of it as a short-term solution to the problem of funding your own indie game.  You can probably find a higher paid job outside the games industry by looking at similar industry that also use your talents.  Programmers can take on business contracts, artists can go freelance, designers can become technical writers and project managers can work on “normal” software projects.  Use your imagination and focus on having as much time as possible to work on your game while still paying the bills.

Learn project management

Love it or hate it, project management needs to be done.  Indie teams rarely have one person dedicated to project management, and so the task is shared throughout the team.  This includes scheduling, planning and making sure they are met.  A great way for people to lose focus and motivation is not have a clear plan for the project.  Look at one of the many agile development methodologies (e.g. scrum) as a great way to keep from bogging down in project management.

There are plenty of great tools available to help with project management, here are a few I’d recommend looking at:

Acunote

Jira

FogBUGZ

Get pragmatic

Be pragmatic in everything you do.  Aiming for perfection will give you a great tech demo that no one will buy.  People will pay for a great game, not great technology.  Since working for myself I’ve stepped into what I call “Fanatical Pragmatism”.  Do the absolute minimum required to achieve your current goals without digging yourself into a corner.

Overestimate time and money

Everything always takes longer and costs more than you expect when you turn indie.  All the indie developers I know have spent far more money and have taken over double the time they first expected.  Constantly update schedules to keep a realistic target for your milestones.  When the schedule starts to slip, be realistic and evaluate if everyone is happy continuing.

My recommendation is to estimate how long the game will take to create and how much it will cost and multiply these values by three.  Either you’ll be happy working on the game for this long (and can afford to) or you need to cut back the scope of the game.

Make constant playable builds

Aim for a playable prototype as early as possible.  It’s difficult to be objective with your own game, so you need to reply on other people’s opinions.  Listen to their feedback and stop if your game is no good.  There’s no point spending months developing a game that’s no good.  Constantly create playable demos and show everyone you know.

Keep it small and watch feature creep

Keep the design tight and focussed.  Find the fun parts first and build only what’s necessary.  You’re an indie developer so people won’t expect a AAA title.  Aim for a lower price point and people’s expectations will be lower.  All the indie developers I’ve spoken to have had major feature creep causing their schedules to blow out.  The smaller you can start your design out, and keep it that way, the more success your project will have.  Your platform choice will help you keep things small…

Pick the right platform

The best choices for an indie developer are PC, iPhone and web.  The specific choice comes down to risk versus reward.  PC games are generally larger and therefore higher risk, however they also have a greater chance of making good money.  Web games are particularly good for a first game, just don’t expect to make much money.

There is a lot of debate at the moment about monetizing flash games and unfortunately the platform still seems a little too immature.  People just aren’t prepared to pay for a flash game.  There are numerous ways around this (like micro-payments), LostGarden has a great series on this.

Conclusion

So this is a general list of things to prepare you for becoming an independent game developer.  It’s a long, slow slog, but it’s worth the effort.  By staying focussed and making intelligent decisions as you go you’ll put yourself in a great position.  Are you working on an indie game now, or would you like to?  Leave your thoughts and experiences in the comments.

Firstly, could you introduce yourself, tell us what games you’ve worked on, how long you’ve been designing games and what you’re favourite games are?
My name is Simon Neech and I’m a Game Designer at Fuzzyeyes Studio, creators of the upcoming Edge of Twilight.  I’ve been officially involved in the game industry for around 4 years (within 3 separate studios) although I have been following its development and products, in one way or other, for decades.  Titles I’ve contributed to so far are: Destroy All Humans 2, Fury and Battlestar Galactica but as a hobby I’ve played, modded and tinkered with hundreds of games before these.
My list of favorite games is in constant flux; the release of new titles has me swinging between genres varying from simple puzzle games to detailed RTS’s. The platforms I play these on are similarly varied: from PC, to Xbox 360, PSP and recently the iPhone.  My favorite game at the time of writing is Anno 1404 but this could easily slip to Battlefield 1943 in the next few days.

You started out as in QA right?  Can you tell us a bit about the transition from QA to game design?  Is this a path you can recommend to people wanting to get into the games industry?
QA was a fun and rewarding experience which, although I didn’t know it at the time, allowed me to acquire skills that would assist me in my future career. I gained first hand experience with the production process that included stages of game development, asset pipelines and even commonly used jargon.  The transition period between the two careers was fairly smooth; I basically went from identifying and documenting bugs within games to creating the bugs myself!
But yes, I would have to agree that working in QA is a great way to break into the industry. Of course, game companies employ testers to assure the quality of their product and not to lay groundwork for a potential career in design; so you need to start down this route with the correct attitude.  When I was first employed, I was overjoyed just to have a role within the industry, in whatever capacity.  I dedicated myself to this position until I found myself in the right place, at the right time and with the right level of experience to start down the design path.  Realistically, I could have continued to do QA for a lot longer and would still be regularly skipping happily to work to this day.

When we worked together you came up with a pitch for a game design almost weekly.  Talk us through the process you take when turning an idea into a document you can pitch to the team.
A simple way to develop a pitching method is to practice on anyone with the patience to listen.  Feedback is your friend, even though it can be devastatingly honest.  My personal process starts with a broad idea. I mentally play through this game idea; over and over until I’ve clocked it on hard difficulty and unlocked all the achievements. When I’m satisfied that it’s something worth developing further, I then document it.  This is the stage where major design flaws become apparent; the relationship between the games constituent parts can often reveal fatal inconsistencies.
My pitch documents consist of two parts: an introductory overview followed by descriptions of the individual features that make the game unique.  The overview should address the basics, such as genre, perspective, platform, intended audience etc. The feature list includes the elements that truly define the idea. These need to be refined into easily relatable terms, while avoiding the trap of micro-explanation; something that will quickly lose peoples interest. The end result should be a few condensed pages, using examples of similar games to clarify points if necessary.

Many people I talk to aspire to becoming a game designer.  What recommendations would you have for game designers who are looking to break into the industry?
In preparation for a design position within the industry, there are many avenues of study that will teach you the tools of the trade.  But before this, I would advise potential designers to simply analyze the games they enjoy playing.  Scrutinize the graphics, sound and gameplay; immerse yourself in the nuances of story and narrative and imagine ways in which you could improve them.  Like most products, the technology and art of games are built upon the many iterations that comes before them.  Having a firm understanding of these, to see what’s been done well in the past and what has not will prepare you for the design challenges ahead.

You’ve used a number of game engines for the various games you’ve worked on.  Could you tell us a little about what you like and dislike in an engine as a game designer.
Overall, Unreal 3 is the engine I have the most experience with.  It’s a powerful design tool for developing games such as Edge of Twilight.  Prior to this, I’ve worked with propriety engines and have even used the accessible editing tools that often get bundled with commercially available games.
As a designer, I consider versatility as the most important attribute of an engine; the ability to accomplish unforeseen tasks at a scripting level really assists the smooth flow of design.  Currently, I work on many facets of the game, but mainly concern myself with camera implementation used to observe the game world. The Unreal engine has allowed me to implement a wide variety of camera techniques, despite its freecam FPS roots not being generally designed to achieve this.

Do you think the growing team sizes and budgets for games is good for the industry?
I think the growing budget of games is a double edged sword.  On the one hand, a large budget contributes to high production values, enhancing the gameplay and narrative experience.  On the other hand, huge budgets carry inherent risks and these risks create a tendency to mold games into predictable, clichéd and ultimately safe titles that achieve little in breaking new ground.
Fuzzyeyes, as an independent developer, balances big budget production with the freedom to explore new possibilities, especially in regards to mature themes. Our storyline, aimed at an adult audience, would probably be toned down in a more mainstream studio.
Of course, as in other creative industries such as film, there is a niche to be filled for games with a wide range of budgets; anywhere from many millions of dollars to free!

You’re currently working on “Edge of Twilight” at Fuzzyeyes.  Can you tell us a little about it?
Edge of Twilight is a third person, action adventure game set in alternate, steampunk themed, universe.  For those not familiar with the term;  ‘Steampunk’ is an aesthetic style based on a modern interpretation of  Victorian-era society and engineering.
The player will assume the role of Lex, an outcast bounty hunter who is a cross between two opposing races; the industrial Athern and spiritual Lithern.  Game play will be split between combat, puzzle-solving and exploration. These elements will in turn be split between two parallel planes of reality that only Lex can traverse; the Lithern influenced night realm, and the industrial, Athern dominated day realm.

What would be your perfect project to work on?
For me, the perfect project would be to develop a game that I truly wanted to play on completion. In this regard, all the games I have worked on can be classed as ‘perfect’ projects! As a long term personal goal, I would like to work on a game from my own repertoire of ideas; taking it from the very initial concept stages right through to release.

Below is a breakdown of the hours it took to create:

I’m quite impressed with HGE’s ease of use and will be looking to do a few more small games like this in the coming weeks. The features of note are:

- Dynamically generated levels using a seeded random number generator. This means that there are an unlimited number of levels that play the same way for every player.
- Online scoreboard. Your scores are uploaded at the end of the game and you can compare with other players. Simple encryption was used to stop abuse.

If anyone is really interested in the source code please add a comment and I may look at releasing it in the near future. I’d be interested in any comments or bugs. My main aim was to keep the development short so I missed out a few features I’d like to have added. These include audio and animations when the objects die.

Download the game below and let me know what you think.

Game 1

Controls:
wasd – movement
LMB – fire
RMB – shield
All enemies are red.
Reflected bullets become change to the reflectors team.
The uploaded score simply uses your computer name.

Thanks to Drealmer’s comments there are now a few more keys:
arrows – also for movement
zqsd – also can be used for movement on AZERTY keyboards.

Below is a table of features that both games have and the number of each (figures are approximations):

As you can see, Paraworld has far more of everything than CoH, except for fun. I highly recommend trying out the CoH demo to see what I’m talking and to have a lot of fun playing it. If you’re a game developer then I recommend downloading the Paraworld so you can see how not to make an RTS these days.

More options, less strategy

As is shown in the table above, Paraworld has far more options for buildings, units, resources and main upgrade levels. The problem is that the complex web of strengths and weaknesses is too overwhelming and doesn’t necessarily add depth. I was amazed how well CoH handled unit strengths and weaknesses with only a handful of different units. Even if completely outnumbered by the enemy, making the correct strategic decision will give you a fighting chance to either make a big enough dent in the enemy to give you time to reinforce or even the tactical advantage to win the battle. I was told that the game was simply ‘a race for the first person to get tanks’ however this is far from the truth. In fact, racing to get tanks can be your downfall as they have many weaknesses. Attacking a tank from the back does extra damage (and has on-screen text to let you know what happened which is always a good idea) and a handful of cheap infantry if upgraded properly will often bring a tank to its knees. By keeping the number of units small and focusing on them, a deeper strategic game comes out.

What does Paraworld have? ‘Archers are long range and extremely weak in close combat’. Wow, what an amazing concept, never mind that this has been done to death. This simplistic single-strength, single-weakness for RTS units was fine 5 years ago, but we’ve come to expect more these days.

More stolen ideas, less originality

In CoH nearly all of the micromanagement is taken away or abstracted into a single number. In Paraworld you must build cottages to build more units and you need storage space for the wood, food and stone you gather. What happens if you run out of storage space, your guys just sit there, like idiots, waiting for you to do something about it. How does this add value to the game? It’s just frustrating that’s what it is! CoH on the other hand has simple ‘strategic points’ which you capture and your resources goes up meaning you can create more units. This is far simpler, yet adds so much more depth to the game. It forces you to move out to capture more points, while still being able to defend the ones you have. Unfortunately, Paraworld feels like a complete rip of the Age of Empires series. If anyone’s read my letter to the editor about Age of <insert cash cow name here> you know I can’t stand this. Let’s move on from the past and start making fresh original games that add value to the genre and to the player.

To prove my point I’m going to leave this blog here, short and sweet. Again, go out and try CoH, it’s a great game and I’d be happy if RTS games in the future start using it as their building block.

P.S. Less is more also applies to good GUI design, check this blog out for more info.