Archive for October, 2009

The 24 Hour Game Experiment – Update 4

Wednesday, October 28th, 2009

Since I went back to work on Monday, my game development time is limited again, but over the last couple of days I did squeeze in about 4 more hours which brings me to 19 total.  This is the painful thing about being a part-time game developer.

Anyway… I added some production quality art into the game (but still need to redo Santa and the houses) and finished up the Main Menu with some flashy artwork and here’s what I have so far:



The 24 Hour Game Experiment – Update 3

Sunday, October 25th, 2009

I didn’t get a chance to work at all yesterday, but today I spent about 4.5 hours so its been a total of 15 hours and I’m starting to feel the crunch…

I have most of the game play worked out, but the game seems too simplistic right now.  It feels too much like one of those flash games that you play for a few minutes at lunch… so I guess that means I need to enhance the game play a bit.

Most of the artwork is still placeholder stuff, and there’s no audio at all, so I need to get moving on that.  I think I’ll concentrate on the in-game art next.

I added an end-of-level stats screen which turned out pretty nice:


The 24 Hour Game Experiment – Update 2

Friday, October 23rd, 2009

Another 4 hours have passed and I didn’t feel nearly as productive this time… in fact right now I’m realizing that I wasn’t very productive at all for the last hour or so… mostly muddling around on various royalty free illustration sites looking for good images.

That’s my cue to pack it in for the night and hopefully I’ll be ready to go for tomorrow and/or Sunday.

Not too much to show for myself this round, but I did fix a bunch of issues with the game play mechanics and here’s a nice screen shot of the credits:


The 24 Hour Game Experiment – Update 1

Friday, October 23rd, 2009

It’s been about 6.5 hours and I needed a mental break so I figured it was a good time to post my first update.

Here’s what I’ve done so far:

  • Design Doc (very quick list of screens and a few comments) – in progress
  • Bantam City Games splash screen with proper fading – done
  • Torque Game Builder splash screen with proper fading – done
  • Main Menu – functional, but no images
  • Credits screen – functional, but no images
  • Level Chooser – functional for the first level, but no images
  • Level 1 – basic game play mechanism in place with placeholder art

Here’s are the major things that are left:

  • Game Intro/Ending sequence (not sure about this yet)
  • Production quality artwork
  • Music and sound effects
  • More levels and an updated level chooser
  • Some kind of score or stats screen after each level
  • Some kind of overall high score page

All-in-all not too bad, but still a lot left to do… Here’s an early screen shot because I know you guys are all itching to see what it looks like:


The 24 Hour Game Experiment

Wednesday, October 21st, 2009

I’m going to create a game in 24 hours and then sell it by whatever means possible!

This experiment was prompted by one of my previous posts, “Casual Game Price Point: $6.99 and Falling“.  There are obvious price wars going on in the casual market and while consumers are always happy about lower prices, the developer and any affiliates feel the burden.  While my long term plan is to create an MMO (currently in the early stages of development), I thought it would be a pretty cool ‘experiment’ to see if I can create a game from start to finish in 24 man hours and then sell it via whatever channels require the least amount of effort.  If the portals want to sell all of their games for bargain prices, then I’m going to develop something that’s fitting of that price.  I’m certainly not going to spend $10,000 – 100,000 and 2 years of development time to have my product dropped in the bargain bin after a week! :mad:

I guess the purpose of this experiment is 2-fold…

  1. Can I create a game with acceptable production values in 24 hours?
  2. Will it meet publisher’s standards and actually make money?

I’m torn on this one… either I will not be able to complete a game with acceptable production values in 24 hours or I will and it will make about $5000.  Either way I’ll probably feel like a huge sell out at the end and go back to working on my MMO. :???:

Torque Game Builder Pro v1.7.4
Artwork/Audio that I can purchase royalty-free (creating the rest myself)

If you’ll notice above, I said 24 MAN hours.  I have a full time job and I’m fairly busy on the weekends, plus I don’t really think I can be productive for 24 hours straight, so I’ve decided to split up the 24 hours a bit.  I have a vacation day this Friday (10/23) and plan on spending at least 12 hours then.  The remainder of the time will be spent on Saturday or Sunday for as much as I can squeeze in.  I know… not as exciting as 24 hours straight, but I’m almost 30 and my Jolt days are over!

I will be posting my updates here after each work session.

I will be posting a final update here once I have completed all 24 man hours.

Wish me luck!

Developing Games In Your Spare Time

Sunday, October 18th, 2009

I’ve been developing games part-time for about 6 years now and at this point I’m only spending about 1-5 hours a week doing anything at all related to game development (including updating this blog).  I used to spend 10-20 hours a week when I was in college, but its tough these days.  When I come home after 8-12 hours of software development, I just don’t have the motivation to jump right into game development, but the more I procrastinate, the worse I feel about it and the less motivated I get… its a vicious cycle.

For all the part-timers out there, here are some tips that I’ve picked up along the way to help us break the cycle:


  • Pick a project you can see yourself working on for at least the next 2 years.  Let’s face it, you just can’t crank out games as fast as the full-time guys and if you get bored after a couple months and ditch the project, that’s a lot of wasted effort… believe me, I know! :sad:
  • Create a design document for your current game project… the more detailed the better.  Document anything you can think of that’s even remotely related to the game (it helps to categorize the design doc into sections).  If you are like me when I started 6 years ago, you might be thinking, “Design Doc?  That’s ridiculous… I know exactly what I want to do!”  Believe me, when you’re only spending an hour or two a week, you’ll be really happy when you can refer back to the design doc and remember exactly how the player shop interface should look… or whatever.  Think about how much time you could save by documenting a detailed interface design upfront versus debating over where to put each button/control every time you have an hour long work session.  Another thing to remember is that the design doc should be a living document.  Feel free to modify it or add to it throughout the project to clarify certain aspects of the design, but beware of Scope Creep (hmmm… sounds like a peeping tom with super powers :shock:   See the next bullet).
  • Try not to increase the size of the project’s scope after the initial design.  This is one of the things that leads to abandoned projects.  Keep to your design doc and don’t go adding in every bell and whistle you can think of.  If you find yourself doing this, add a section to the design doc (at the bottom) called, ‘Sequel Enhancements’ and add all of the superfluous crap you think of down there… the keyword is Sequel… meaning AFTER you release your game!
  • Work at least a little bit every couple days (or every day if possible).  Even if you’re not feeling very motivated, make the time to work a little bit… even simply reviewing the design doc is helpful.  I found myself doing this multiple times on my current project and each time I made needed clarifications to the design so it wasn’t wasted time and it also kept everything fresh in my mind.
  • Keep a log.  This is a great memory-jogging trick.  Make a few notes when you are finishing up each work session… enough so that you know exactly where to jump back in next time.  Task switching can eat up about 15 minutes of each session and if you’re only working for an hour, that’s a quarter of your time!  In Tom DeMarco’s book Slack, he goes into detail on the subject of how much time is wasted by task switching.
  • Don’t surf the web or check email during a development session.  Don’t get me wrong, you need time for those things too, but this is time you set aside for development… don’t waste it.  Think about how the task switching mentioned above plays into this.
  • As you’re falling asleep, think about the current task or problem you are facing.  I do this all the time and usually wake up with a solution to the problem or at least a new path on the way to solving the problem.  The mind is an amazing thing!  If you’re laughing at me right now, thinking I’m a few coins shy of an extra life… check out this book.

Keep with it folks and one of these days you’ll actually finish that MMO or RTS you’ve been working on!  If you think of any other good tips, post a comment.

Casual Game Price Point: $6.99 and Falling

Monday, October 12th, 2009

Some months ago, Reflexive (now owned by Amazon) decided to try to undercut the competition by lowering the prices of their games, most of which ended up at their new price point of $6.99.  This is a far cry from $14.99-19.99 which up until recently was the going rate for an online casual game.  Some of the other online publishers had already set a low price point for their ‘club membership’ offerings which works something like a volume discount.  I thought the ‘club’ idea was an acceptable way to lower prices and still increase revenue, but permanently lowering prices to $6.99! :shock:   That’s a hard pill for us game developers to swallow.

So Invadazoid was effectively put in the online bargain bin… “That’s OK.”, I thought, “It’s an older game and it had trailed off in sales anyway.”  What bothered me more was that my arcade site (which is almost entirely made up of games from the Reflexive affiliate network) was no longer profitable.  I complained to Reflexive, but they told me that the new price should increase the volume of sales so I may even see an improvement in overall sales revenue.  I believed them at first because I saw an initial spike of sales for that month, but within another month it was back to the norm, only now I was selling the same amount of units for less money while paying the same amount for advertising! :mad:   I finally decided to do what I could to make the site break even and keep it going for traffic’s sake, if nothing else.

More importantly than all that, this has opened my eyes a bit… Are the other online publishers going to be able to compete with these prices without lowering prices themselves?  Where does the cycle end?  In my opinion, this marks the beginning of the end of casual games being developed by lone-wolf developers or even small teams… we just can’t afford it any more.

So I say, “Screw the casual market!”  Remember why we (game developers) got into this business?…  to make the kind of games that WE want to play!  Let’s make games that we’re passionate about because this passion shows in our work and players notice.

To this end, I’ve recently started working on a new game in the MMO genre.  While there are plenty of offerings in this market, it’s something I’ve always wanted to make and I don’t think this market will climax as quickly as the casual market did because the barrier to entry is so much higher.  I’ll be posting more about the game specifics as time goes on, but its still too early in the development cycle to spill the beans.

Torque Game Builder Review

Friday, October 9th, 2009

I first started using Torque Game Builder (TGB) from Garage Games about a year ago.  I haven’t actually released a game developed in TGB yet, but I’ve created a few prototypes and my latest project will be developed in TGB (assuming I keep enough momentum to actually finish it :| ).  Also, I’m using TGB after having used my own home-brew C++/DirectX 6 engine which sucked in comparison, so keep all of this in mind as you read this post.

I own the full source version of TGB (currently v1.7.4), but since I’ve only made one engine change so far (to add SQLite DB support), I think this review applies to both the full version and the binary-only version.

Things I Like:

  • Rapid Development – This is the number one thing going for TGB.  I recreated one mode of Invadazoid in a couple weeks, which originally took me a couple months, and it looked even better than the original (even using the same image sets).  With the fairly recent inclusion of behaviors into TGB, the development time should be even less.  I love being able to drag and drop elements onto the scene in the level builder, apply behaviors to things where I can, and then finally script the rest.  The built in callbacks make it fairly easy to script everything as well.
  • Price – You really can’t beat the price for what you get.  I literally spent twice as many hours (creating my own engine) as dollars (buying TGB) and TGB blows my engine out of the water.
  • Graphics Capabilities – I like to use PNGs and TGB displays them very nicely with all of the proper alpha layer and anti-aliasing effects.  While these things are to be expected in any game engine these days, remember I upgraded from my home-brew engine that didn’t have these capabilities, so this was a big plus for me.  The particle engine is great too.  You can customize literally every aspect of the particles and their emitters to create anything from a jet’s contrail to a zombie’s blood splatter, all from within the level builder.  I wish they would include more prebuilt particle/emitter templates, but all-in-all, I’m happy with it.  One issue I noticed was that if my images were too big, the level editor wouldn’t load them.  I never figured out if it was a limitation of my video card or of Torque… I ended up just breaking up some of my tile sets into smaller images.
  • TorqueScript – A lot of people complain about TorqueScript, but I really like it.  Its very C like in syntax, plus it has a lot of built in functions.  I also like the the fact that it’s a typeless language, which is a great time saver for a skilled programmer.  I say ’skilled programmer’ because for novice programmers it can sometimes be difficult to debug ‘type’ issues.  I also highly recommend getting the Torsion IDE and this book.  I remember trying a demo version of Torsion when it first came out and I was very disappointed, but I re-downloaded their latest version recently and its pretty sweet!  The code completion and the debugger alone decrease dev time significantly.  Not as nice as eclipse for java development when I’m at work, but still much better than hacking away in a text editor (I know, you Linux guys are screaming “vi rules” right now, but seriously… get with the times).
  • Networking Support – Although the only networking included in TGB is event based (as opposed to real-time, ghosting systems), I’m enjoying working with the RPC style interface in my new project.  It’s simplicity prevents you from getting bogged down in networking protocols and sockets and all that.
  • The Community – The Garage Games community is huge and often very helpful.  You can find a lot of community-developed resources to add to your engine (assuming you have the full version), prebuilt behaviors, and the forums can usually answer your questions pretty quickly.
  • Cross-platform Support – I can’t really speak to this because I’ve never actually ported anything to Mac or Linux, but folks like Rake in the Grass Games (who have released multiple TGB games) say that it takes them about 1-4 hours to port to Mac, which seems pretty impressive.  GG also touts being able to ‘quickly’ port to the iPhone, XBox360, and Wii, but I definitely don’t have any experience with that.
  • Source Code – If you buy the full version, you are able to make engine modifications and also browse the source code to learn how things work.  There are tons of resources out there that tell you how to modify the engine source to add certain functionality.  Some are trivial and others require major source mods.
  • GUI Editor – It has one… see below.

Things That Need Improvement:

  • Documentation – Although the documentation has improved in the past year or so, it still leaves something to be desired.  I code in Java for a living and I’m used to the level of documentation provided by Sun’s Java Docs… I guess I’m spoiled :|   I often go looking for a Torque method in the docs and either I can find the method signature with no explanation for each parameter, or sometimes the documentation for an object is missing completely.  It slows down development time when I need to fiddle with an object method to get it to work.  In these scenarios I find the quickest way to figure out how to use the object/method is to open up the C++ source code and find out exactly how it works (one big advantage of the full version of TGB).
  • Occasional Bugs – Once in a while you will come across something that doesn’t work.  Did you make a mistake?  No problem, just go check the docs and see if your script call is right… oh wait… this is one of the many calls that isn’t documented :mad:   So you play around with your script for a while and you still can’t get it working… off to the forums to search for a user with the same issue.  If you’re lucky, someone has already posted on the topic and there’s a easy solution.  If not you post a question and hope someone answers it… and once in a while, after hours days of repeating this vicious cycle it turns out that there is a bug in the engine.  You have two options here.  Either you 1) open the source code and fix the bug (I personally don’t recommend this because if you like to keep up to date with the latest engine versions like I do, then you’ll have to do a bunch of code merging for every bug you fixed that GG hasn’t yet), or 2) you can work around the issue by potentially using another object type or coding a bunch of hacky type script that ‘hides’ the issue… either way its not fun and you just lost a ton of dev time.
  • GUI Editor – It has a lot of ‘widgets’ and it’s usable, but it’s not nearly as nice as the Level Builder.  You can drag and drop GUI controls from the ‘palette’ to the canvas and then modify it’s settings in the property editor… seems fairly simple.  Lets say you want to change the font/color of a label, you would just modify the ‘font’ property right?  Nope.  TGB uses what they call ‘profiles’ instead and you can only create these profiles from script :mad:   Another problem is that the most common controls have minimal documentation and the rest have none!  Lastly, its kinda buggy.  Its fairly common to crash the entire application when you do something it doesn’t like.  Things like this are the reason us paranoid coders wear out the Ctrl+S keys on our keyboards.

Overall, I’ve been very happy with Torque Game Builder.  The pros definitely outweigh the cons and the full version price is worth every penny.  Garage Games has posted saying that they are making a ton of improvements and re-releasing the engine as T2D sometime in the not-too-distant future.  They are also actively trying to improve their documentation from what I can tell.  GG has been very good about releasing major and minor updates to TGB… I just hope that its fairly easy to convert a TGB project to T2D… *fingers crossed*

When Genres Collide: an Invadazoid Post-Mortem

Wednesday, October 7th, 2009

I had so much fun writing the Trials of Werlin post-mortem that I decided to do one for Invadazoid as well.  For those of you that have never played Invadazoid, be sure to purchase a copy after you’re done reading this post ;) (or just download the free demo).  I remember sleeping in one Saturday after a week or so of debating over what game project I would work on next, when it hit me… A mix between Space Invaders and Arkanoid!  And just as quickly, the name jumped out.  Invadazoid!  The idea was so profound (at least I thought so), that I rushed to my computer and started whipping up a prototype.  Within a couple days I had something ‘playable’ (surely not by your definition), and I knew I was on to something.  The more I added to the game, the more fun it was!  “This was surely going to be the hit I was looking for”, I thought.  It wasn’t.  Don’t get me wrong, compared to the abysmal sales of ToW, Invadazoid was a huge success, but why wasn’t it the next Tetris or Snood?  I must have done some things right because it was more successful than Trials of Werlin by a mile, but what was preventing this game from being a smash hit?  I can’t say for sure, but here’s what I’ve come up with so far:

The Good:

  • It was a unique idea.  Mixing genres has always been a great way to bring new life to two stagnating genres.  I remember one reviewer made a funny Reese’s comparison to the effect of, “You got your Arkanoid in my Space Invaders!”… “No, you got your Space Invaders in my Arkanoid!”  It makes me chuckle every time I think about it.
  • It was instantly fun.  There weren’t long instructions to read or training levels to muddle through.  You hit Play and you were dropped right into the action like a virgin at the prom :shock:   Even if it wasn’t immediately obvious what to do, after a few successful bumps it became almost instict (…talking about the game, not the prom).
  • Graphics… Although I decided to do my own artwork again, I really spent alot of time getting it right this time and overall I was pretty happy with the outcome. I upped the resolution from 640×480 (for ToW) to 800×600, added some particle effects and better alpha blending.  I also created most of the objects in a 3D modeling program and then rendered them to 2D… this helped a lot!  Programmers that don’t have much art background (and no cash) could benefit from this technique; mainly because the 3D models just have to look decent so you don’t have to worry about keeping the poly count to ridiculously low levels.
  • The Portals… some indies would argue with me here (and with good reason lately), but I used most of the big-name online portals (Real Arcade, Big Fish, Reflexive, etc) to get the game out to the masses.  For a casual action game from a company with hardly any of its own traffic, this was the best way I could think of at the time.  Through these publishers I sold thousands of copies where I probably would have only sold a couple hundred on my own.
  • Marketing… I learned my lesson from last time and decided to do a press release.  This alone put Invadazoid into the hands of publishers and editors that would have never even heard of it otherwise.  I was contacted shortly after the press release went out by PC Zone (UK) to do a spot on Invadazoid.  I can’t even tell you how good it feels to see your game covered in a big gaming mag!

The Bad:

  • Marketing… I definitely did more this time, but not even close to the amount that I should have done.  I put too many eggs in the Portal basket and didn’t do enough of my own marketing.  I’m still kicking myself over this one.
  • Too many game play modes.  Invadazoid has 4 modes, but when you play for the first time, its not really obvious which one you should start with.  Alot of players ended up clicking ‘Classic’ mode first (I guess because it sounded the most like ‘Normal’) which was nothing more than a Space Invaders clone and not nearly as exciting as the other modes.  I should have provided at least a visual cue as to which mode to start with or locked the other modes until certain progress was made.
  • Too much time spent in the engine.  I used most of the same ‘engine’ code from ToW (C++ and DirectX 6) and despite not having to start from scratch, I spent alot of time fixing engine bugs and adding things like particle effects instead of working on GAME DEVELOPMENT.  I think I spent the most time trying to get the ball to move smoothly without jittering (if you’ve made a breakout game then you know what I’m talking about).  I said this last time, but I can’t state it enough, “Don’t reinvent the wheel!”  Your customers aren’t going to care that it took you 100 hours to add anti-aliasing to your graphics engine!  They just care how good the finished product looks.  Unless you want to write game engines for a living, go find some tools that already do what you need.
  • Too late on the second revision.  I added some cool features like an online high-score board in the second revision, but unfortunately this was after the big spike of sales from the portals and most of them didn’t republish the new version because the game had dropped in sales at that point.
  • Flash Version.  I contracted out help to create a flash version of Invadazoid to help convert web site visits to downloads (and then sales).  The problem was that I should have done this as soon as the game launched instead of many months later.  The other downside was that its hard to reproduce the fun of a REALLY fast paced action game in Flash (v7 at the time).  The flash version definitely lost something in translation and in that respect may have even prevented some sales… not to mention it cost a good chunk of change.  Hmmmmm… I’m not really sure why I still have this up on my website.

The Ugly:

  • Difficulty…  I did it again!  Although more fun and more attractive than ToW, the game was still too hard for the casual crowd.  When I was a kid, I used to play the same levels of Castlevania a hundred times until I beat them all, not even taking a breath in between.  These pansy-ass casual gamers obviously don’t have the same mindset.  I did allow restarting a game from a location once the previous location was completed, but I didn’t allow restarting from each individual level.  For some of the later locations this meant fighting through 8-10 intense levels with an onslaught of invaders each launching massive amounts of missiles at you, all with about 5 lives… ouch!  In hind-sight, I probably should have allowed restarting on each level.  :roll:

I hope this was helpful (or at least a good read).  After proof reading this a few times, I wish I had written it a long time ago because I think I just taught myself a few things!

How to Make Your First Game

Friday, October 2nd, 2009

This post should probably be called ‘How NOT to Make Your First Game’, because I’m going to approach the topic more like a post mortem than an actual ‘How To’ guide, but read it anyway and I’m sure you’ll find some helpful tips for when you make your first game.

My first commercial game was called Trials of Werlin.  My inspiration for this game came from seeing the successes of Steve Pavlina with his game called Dweep.  If any of you have read Steve’s articles or his book, you know how reading a few of his game’s success stories could be so motivational.  Although Steve has a new career as a motivational speaker, this specific inspiration came a bit before that.

I was a college student, I was all psyched up by Steve’s story, and I was living at home without a job… the perfect storm for a budding game developer!  Through Steve’s forums (which later became the Indie Gamer Forums), I learned about a book called Tricks of the Windows Game Programming Gurus by Andre LaMothe.  I have to say, without this book I probably would have never gotten started in game development.  Game programming was something I tinkered with in high school, but couldn’t even figure out the basics and had since given up on it.  Thanks Andre!  Ok, on to the post mortem.

The Good:

  • I learned so much about game development because the TotWGPG book was a great mix of concept and examples.  It was also very low level so I learned alot of the hard nuts-and-bolts type stuff (like how to manually alpha blend individual pixels… ouch).  I even had a kick-ass college teacher that let me read the book and develop a game prototype for college credit!
  • It gave me hands-on experience in taking a fairly large project from design to completion and even in marketing a finished product.
  • It was FUN!  Not just the game, but seeing your vision come to life and tweaking it here and there until you are so completely proud of it.

The Bad:

  • I was so caught up in the implementation of the game that I didn’t bother to realize that the market for brain-teaser puzzle games had almost dried up.
  • The graphics were good, but not great.  I’m not an artist, but I did take art classes all through childhood and even a year of commercial art in college… even still, the game could have benefited from a makeover.  The fact that the game was 640×480 and didn’t have any anti-aliasing didn’t help either :(
  • Marketing… like I said, the game was doomed from the get-go because I chose an already saturated niche.  Hey, this was my first game; what in the world did I know about marketing games?  I didn’t do a press release.  I signed a deal with one publisher that fell through (Scholastic, you sons-a-bitches).  I really didn’t do much in the way of marketing at all and this should be a take away for any would be game developers out there.  Spend as much effort marketing your game as you put into making it!!!

The Ugly:

  • The number one reason (IMHO) that ToW was unsuccessful was the difficulty curve.  The game started out simple (if you read the popup tips), but before the player even finished the demo levels, the puzzles started getting insanely hard, plus, one mistake and you had to do the whole level over again.  Hey!  I came from the Nintendo days with games like Contra, where you had 3 lives to beat millions of baddies and bosses.  I didn’t realize that there was a new breed of gamer out there that liked to be coddled and pampered until they ‘won’ the game.  I even re-released the game to be easier (slightly), but just couldn’t bring myself to ‘dumb it down’ too much.  “If this game is too hard for you, then don’t buy it!”, I thought… and that’s exactly what happened.

How to Make Your First Game (Summary):

  1. Make sure there’s a market for your game.  A sustainable niche is the best market for an indie (from what I’ve read), but at least make sure there is a demand for the game you want to make.
  2. Don’t reinvent the wheel.  Unless you are hell bent on learning how to blend individual pixels or coding your game so that it works with every different type of graphics card or monitor, use a third party engine or better yet some kind of game builder.  I coded ToW with C++ and DirectX 6, but these days I’ve moved on to using Torque Game Builder.  Remember that one kid in your math class secretly solving quadratics with his graphing calculator (yeah, the one with the big grin on his face).  THIS ISN’T MATH CLASS!  The teacher isn’t looking over your shoulder!  Bottom line, use the best tools you have available to you.
  3. Make sure it looks nice.  The days of shareware games being able to make money on game play alone are over.  If you can’t create your own really nice artwork, find someone who can.  It can be a friend or you can hire someone if you have the dough.  There are alot of really talented artists on the forums mentioned above that can help.
  4. Make sure the game play is balanced.  Unless your audience is a bunch of hard-core gamers, don’t make the game too hard and even still, make the difficulty curve very gradual.
  5. Market your game like there’s no tomorrow.  Most indies estimate that you should be spending about 50% of your game development cycle doing marketing.  Its tough and I’ve never spent nearly that much, but then again I’m not successful either.