Archive for the ‘Development’ Category

Is it possible to make an MMO in Torque Game Builder (TGB)? – Part 2

Monday, September 27th, 2010

You might remember my more optimistic part 1 post.

Well, I’m about 300ish hours into my MMO development (part time over the past year or so) and the other day I decided to finally do some performance testing… way too late to be doing this sort of thing btw.  I didn’t think too much of it before because the GG engines are touted for their networking layer, so I figured it should be able to handle the tiny packets that I was sending back and forth with no problem.

I started my testing with what I thought was a modest number of players for an MMO… 1000.  Not too high, not too low.  The server grinded to a halt! and suddenly I got that ‘Oh shit! What have I done?!’ feeling.  So just to get a better measurement, I dropped it to 500, then 100 and finally to 50 before things started to perform normally.  Ouch!  Now, I’m not trying to get EVE Online numbers, but 50?!?!  My stomach sank a little as I thought about all of the wasted work and all of the work I would have to do to rewrite the server.

How could something awarded for its networking ability come up so short?  Well, it wasn’t the networking causing the bottleneck at all.  What I failed to consider was not networking, but the processing cycles needed.  Apparently, TGB doesn’t make the greatest server for a synchronous MMO.  The inherently single-threaded processing and the speed of torque-script were drastically overestimated on my part.

I can probably performance tune the TGB server more and move some things into native C++, but in the end I decided it would be easier to rewrite the whole server in Java which is my native language ;)   While most people still have a negative impression of Java performance-wise, 1.6 is quite fast and it can usually be further performance tuned.

Moral of the story: performance test early so that you can change technologies if necessary and not have to rewrite a ton of code.

I haven’t finished writing the server yet, but I will post an update once I do some early performance testing.

How to Write Maintenance-Free Software

Wednesday, January 6th, 2010

In my full-time job as a software developer I encounter a ton of code that is not only hard to read/understand, but is very high maintenance as well.  It doesn’t matter how quickly you can write code if it’s bad code, because over the lifespan of the software you are probably going to spend way more time debugging/fixing code than you spent writing it in the first place.  In this post I hope to give you a few tips that could drastically increase the readability of your code and decrease your project’s short/long term maintenance.

Standard Techniques:

  • Object Oriented Programming (OOP) – concepts such as encapsulation, cohesion, and coupling are key concepts to understand.  Modeling data structures after real world objects has been around since the 60s, and widely used since the 90s but you still find people that refuse to do it.
    • Tight Encapsulation – this is a way to separate the public, potentially user-facing interface from the internal implementation of an object.  This is achieved by using different access modifiers such as public, private, etc.  It is very common to find public variables in an object that get accessed by other objects… this is bad.  If you then need to add new variables or change the way an object works internally (and you will), it creates a ripple effect and you now need to update all of the code for each of the objects that access the changed object.  The objective with encapsulation is to develop a stable public API for a particular class such that you can change the internal workings of that class (private methods and variables) without having to update the public interface.  What this accomplishes is that now you don’t have to update any of the other objects that are calling into the changed object… this equates to lower maintenance.
    • High Cohesion – this basically means that all of the responsibilities (methods) of a particular class are very closely related to each other.  The more focused a class’s purpose is, the less it will need to be maintained and the more reusable it will be.  For instance, if you had a Computer class, it could have a turnOn method and a compute method, but it shouldn’t have a print method.  Instead you would have a Printer class that has a print method that the Computer object may call.
    • Loose Coupling – this means that one class should not know too much about another class, more specifically, class A should not know anything about the implementation of class B.  This is achieved through tight encapsulation and good API design.  Class A should only know what class B wants the public to know about it.  Think of each class as strangers to each other class… you only give access to things (public methods) that you want the stranger to have access to and you never show the stranger your privates :shock:   When classes are too ‘friendly’ with each other (exposing things that should be private) it causes the same kind of ripple effect mentioned above.
  • Class/Variable/Method Naming – names that you use in your software should clearly reflect their purpose and for the love of god, please don’t abbreviate unless its a well known acronym.  ssPos could be anything from space ship position to seriously stupid piece of shit… ok, its probably not that, but you get the point. spaceShipPosition would be a more appropriate name.  You would know exactly what it was when you look at it a month/year from now.  Some argue that the long length of these variable names will slow down your coding process… it wont… especially with most IDEs having some form of code completion these days.  Class names starting with an uppercase letter and variables/methods starting with a lower case letter and both continuing with camelCase is quickly becoming the widely accepted standard (IMO), but even if you don’t follow this at least be consistent.  Don’t use ufoCount in one place and alien_count or BulletCount in another.
  • Don’t Hard-Code – its very easy while programming to start ‘hard-coding’ values directly into your code.  For instance, you have an condition that looks like ‘if(userCount > 100)’ in 3 or 4 places.  When in reality it should be ‘if(userCount > MAX_USER_THRESHOLD)’ and setting a constant called MAX_USER_THRESHOLD = 100.  Now if you want to allow more users, you simply update the constant value (or even better, put this in a config file as mentioned below) instead of updating it everywhere and potentially missing one.  Your code shouldn’t contain any hard-coded values unless they are what I call ‘universal truths’.  For instance, ‘if(userCount > 0)’, there’s no need to replace the number 0 with a constant called ZERO_USERS. 0 is 0… its never going to change.  This includes array sizes too.  You should try not to  make your arrays a constant size unless the size is dynamically created.  Instead you should try to use objects that can expand as entries are added (in Java – ArrayList, etc).  If for some reason you need to use a fixed size array you can then create one by using the size of the list (in Java – ‘new String[arrayList.size()];’)
  • Commenting – we all hate to do it, but you would be surprised at how foreign your code looks a year from now (even less time if you don’t follow some of the stuff mentioned above).  I’m guilty of leaving my code comment-free from time to time, but I try to comment anything thats not immediately obvious to me.  Also, make sure your comments clearly describe what is happening, not just ‘//do stuff’.
  • Refactoring – we all have deadlines and time crunches to worry about so there are going to be times when you need to write a quick and dirty piece of code… it works, but it irks you to your core (the good programmers out there know what I’m talking about).  When you write code like this, mark it somehow (for instance, Eclipse/Java uses FIXME comments) and this will be an indicator that you need to come back to it when you have more time.  When you do come back to it, write it in a nice low maintenance way and test it to make sure it does the same thing that the old code did.  The more of these little bits of ugly code you leave in, the harder to maintain the software becomes!

Advanced Techniques:

  • Configuration Files – there are times when you have a ton of small little pieces of code that do pretty much the same thing except for small differences here and there.  Extract out the commonalities and write one piece of code that does the common parts for everything, then extract out the differences and put them in some form of configuration file (I prefer XML).  Now when the piece of code that is common runs, it can read from the configuration file to act on any differences.  An easy example is if you often have to change a hard-coded start/end date in your code in 4 different places, put the start/end dates in a config file and add code in those four places to read from the config file (which can be cached for speed).  This cuts down the number of places from 4 to 1 and removes the need to recompile.  The down side to using config files is that most of the bugs you find will end up being typos in the config file.  Also, don’t go crazy and extract everything otherwise you will end up writing your own scripting language.
  • Reflection – this is a fairly new concept to most programmers, but this allows objects/variables/methods to be used/called just by knowing the name/signature of it at run-time (as opposed to design-time when you would normally do this).  This combined with the Configuration Files section above could cut down on code drastically and virtually eliminate needing to update/compile your code.  For instance, you write a game that has user definable player characters (different look, different actions, etc).  Using the above mentioned techniques you could let the user create a config file that describes the player.  This config file could have one entry for a jpeg file for the character’s look and another entry that has a class/method name for the character’s action.  Now using reflection you could actually create the class that the user wrote and call their method… Nice!  Most newer languages support reflection and even a lot of scripting languages used in game engines support it (but probably don’t call it reflection).  Its a powerful thing to have in your mental toolbox.
  • Inversion of Control (IoC) – this concept basically entails the reusable parts of your code calling your customized code instead of what is traditionally the other way around.  I can’t really do the subject justice, so you can read more about it here:  What I can say is that it will increase the reusability and extensibility of your code quite a bit.  The most common forms of this are Factory Patterns and Dependency Injection.  This paradigm will make your software easier to unit test and easier to replace modules.  This should replace the need for static classes and singletons (for the most part).

Mindset Shift:

  • Maintenance on the Brain – writing low-maintenance software requires a mindset shift.  Every time you design a piece of software or write a line of code, you need to be thinking, “Have I designed/written this in a way that will require future changes?”.  If you’re answer is something like, “Yeah, I’ll need to change this whenever the PayPal API changes or whenever the total user count exceeds 1000 or whenever I write a new mission, etc”, then take a step back and figure out how to accomplish the same functionality in a way that doesn’t need to be changed in the same scenario.  Rinse and repeat until you’ve removed all of your maintenance problem areas.  You may not be able to get rid of all maintenance areas, but using this process you should be able to minimize future maintenance.
  • Make the Time – It’s hard to get into this mindset because initially you’ll be thinking, “I’m already behind schedule, I don’t have time to rewrite that code.”  See the refactoring section above.  You need to get past this short-sighted attitude and make the time.  In the long run you will reap the benefit of this extra effort many times over.
  • Be a Rockstar - This mindset is something that separates the superstar developers from the button-mashing, copy-and-paste coders.  Adopt this mindset as a way of life and be proud of your maintenance-free code!

Hopefully the above tips have shifted your thought process in the right direction and I won’t have to look at code like this from you:

// time it
if(nElpsdTm > 16400) {    <--- really hate the brackets here btw ;)
      Tmp = nElpsdTm;
      nElpsdTm = 500;

Is it possible to make an MMO in Torque Game Builder (TGB)?

Tuesday, November 24th, 2009

I hear this asked here and there throughout the Garage Games forums and once in a while in various other game development forums. So what’s the answer?

Honestly I can’t say for sure, but my current project is an MMO(RPG) and I’m using TGB to develop it.  Anyone who has used TGB might be thinking, “That’s suicide!”, but I think its possible and sooner or later (at the rate I develop games, definitely later) I’ll find out for sure!

I know TGB can be used to make quality games, so what more is there to consider in making an MMO?  Besides the sheer size of the project, the biggest thing that comes to mind is networking/data architecture to support thousands and thousands of players.

With that, here are some of the things I’ve already considered:

  • Will TGB’s “turn-based networking” be an obstacle? The networking that comes with TGB was initially referred to as turn-based networking which to me implies that it is kind of slow/laggy, but in reality its more of an RPC-based networking so as long as you don’t need real-time ghosting for something like a twitch-based game, I think TGB may be able to hold its own.
  • Can TGB handle that many concurrent connections? I asked this question a few different ways on the GG forums and the big shots tell me that the only realistic limit is the bandwidth and server hardware.  I guess if they are wrong then by the time I find out for myself it would be way too late to change to a different engine and you’ll surely find me hacking away at TGB source code to try and make it work.
  • Does TGB have DB support? No, but there are some community source code mods that make it pretty painless to add SQLite support and it took me all of a couple hours to get this working. I hate making source code mods to TGB, but this one was definitely worth it… you simply can’t make an MMO without DB support.
  • How much bandwidth will the server need? This is one thing that worries me because its not something that I can easily test.  As far as bandwidth goes, EQLive published EverQuest’s usage years ago as being about 1 KB/s per user download and .25 KB/s upload.  While I’m sure today’s MMOs (WoW, etc) use way more than that, I’m also estimating that my MMO will use quite a bit less than that as it doesn’t require as much information to be sent as often (in theory).  TGB also has a way to ‘tag’ strings between the server and each client such that subsequent sending of the same string gets sent as a tag ID rather than continuing to resend the same string over and over again.  This should cut down on the bandwidth usage.
  • How will I scale up the server as more players join? Most likely I will host the TGB server myself until the beta is underway and then scale up to a VPS or Dedicated server as needed.  The server will need to be Windows based (mostly because that is my development platform).  I also need to be able to scale up quickly in case I get an honorable mention on one of the big gaming news sites, but I also don’t want to break the bank while I’m anxiously waiting for that to happen.

All-in-all I think I’m going to have my hands full for a long time, but I wouldn’t even try this if I didn’t think it was possible.

If you’re considering using TGB or another GG engine to make an MMO, check out this awesome list of discussions on the subject:

Even if you’re not going with TGB, here is a huge list of things to consider when making an MMO:

New Look and Feel for Bantam City Games

Wednesday, November 11th, 2009

Sorry for the lack of posts in the last couple weeks… The 24 Hour Game Experiment got me thinking about what it would be like to be a full-time game developer.  What would I do first?  What’s most important?  When I thought about it, the first thing I would do is redesign the main website to be more customer friendly and less ‘corporate’ looking.  I also wanted to get a better way to gather newsletter customers.  Lastly, I wanted to get some kind of up-sell system going.  After realizing that these are the first things I would do, I stepped back and said, “Well, why don’t I just do these things now!”  It’s not like they are huge time-consuming tasks like creating an MMO :)

So, I haven’t done the newsletter part or the up-sell part yet, but I’m just about done giving the site a face lift (some of the ToW pages still need to be revamped).  So take a look around the Bantam City Games site and let me know what you think.  For those of you too lazy to click the link and browse around, here’s a screen shot of the main page.


The 24 Hour Game Experiment – Conclusion

Tuesday, November 3rd, 2009

Well… the experiment is over.  I’m sure it comes to no surprise to most of you, that I did not finish the game in time.  I think realistically I would need another 72 man hours to make this game sell-able.  The problem is that it took me about 2 weeks to get in just 24 man hours and by the time I put in another 72 it would be way too late to get the game out for the holiday rush.  Not to mention some of the publishers I’ve contacted say that their queues are already jam-packed for the rest of the year.

With that being said, the project wasn’t a total waste.  Here are my observations:

The Good:

  • I was able to include mouse-controlled game play, splash screens, menu, credits (all with screen transitions and some with final artwork), in 24 man hours.  That’s a huge accomplishment and quite frankly a credit to Torque Game Builder.
  • I think a Christmas-themed game was a good choice from a sell-ability standpoint.  My thought here was that it should be easier sell a ‘less complex’ game when it is properly themed.  I don’t think anyone buys a Christmas game expecting to play it for months and months.
  • I found a really cool site for generic vector graphics that can be reused in games (I found out that not all royalty-free sites have this type of licensing option).

The Bad:

  • 24 hours is obviously too short a time to finish a game.  I half knew this going in, but ‘The 96 Hour Game Experiment’ just doesn’t have the same ring to it :grin:
  • I started the experiment way too late in the year to get a Christmas-themed game to market (especially with me being extremely part time).
  • I underestimated the amount of time it takes to test the game’s fun factor and throw away parts that aren’t fun and come up with/test new ideas.  This is where I spent the final hours.

The Ugly:

  • Another unfinished project gets put on the shelf :mad: (at least until next year)

Overall, I’m glad I did the experiment and I hope to do another one at some point next year (with more realistic expectations).  This project made me realize how much I really can get done in such a short amount of time and that maybe being a part-timer isn’t the best way to go.  I’ll be putting some serious thought into how I can devote more of my time to game development in the near future.  For now, its back to working on my MMO…

I hope you enjoyed following along with the experiment and decide to stay tuned to see what’s next!

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.