Optimism in development timeline estimations and User Stories

Game (and more generally, software) developers are optimistic people.  The act of creating anything requires a certain degree of optimism, as you start from a blank file and lay down code.  The reality of coding is to take pure concept and commit it to a working system.  This never goes as smoothly as planned.  In most cases, only by attempting the work do you find out the initial selected approach is not the correct one.  I’ve seen many experienced and inexperienced developers get caught on a “light” estimate for how long something is going to take.  Often the time quoted is simply development time and does not take into account the extra required time for debugging, performance tuning, documentation and proper testing.  The first major step to taking proper estimating is to agree on what needs to be accomplished.  We often called this “writing the spec”.  I’ve personally erred on both sides of the specification equation, providing too tight of a specification which doesn’t allow the developer to leverage his/her experience and the other side, which is almost a blank ticket to write anything.  The best method I’ve run across is using a “user story” format which details who the user is and what the planned user experience should be.  This method communicates the target without laying our too many hard requirements.  In most cases, even a junior developer (with a little technical oversight) can meet the requirements as laid and and have room for creativity.

A proper “User Story” needs to do a few things:

1) Describe the user

2) Describe the desired outcome

3) Detail any “hard” requirements

4) Outline the expected effort


So here’s my example:

As a mainstream game player I can select a character on the screen by clicking on that character.

When selected the the character should:

  • indicate selection by displaying a coloured circle beneath the character.
  • indicate selection by displaying a highlight box around the character portrait.
  • execute all input commands until de-selected


This should be a basic selection system based off the existing UI system.

The system must be able to integrate with the existing party system.

Any required input code should be maintained within the Input class.

The code should compile and execute under all specified target operating systems without errors or warnings.

This system is expected for delivery in two weeks time, including testing, documentation and initial performance tuning.


The above example is very arbitrary, but I have yet to find two people who write them up the same.  What I feel is important:

  • Be specific on desired outcomes
  • Give detail when it helps solve the problems
  • Be specific on hard requirements.
  • Ensure there is a timeline clearly associated with the work.
  • If the work is taking over a month, break it down into smaller deliverables.

The best work I’ve done in this area has been when I understand well what I’m trying to describe and I use a few descriptive lines to convey the desired user experience.  You will need to adapt your user stories to fit your personal writing style, but always try to keep your eye on the end user experience.








Patent Extortion.

So it appears the outfit behind the letters to app developers using the in-app purchases system has stepped out.  Here’s a link digging into the “other side” of the discussion. http://tnw.co/iCkLLq The big point they push is that because they only want to extort a little money off of everyone it is OK.  I think this also applies to school bullies and lunch money.  Extortion is extortion, whether it is pennies or millions.


To me this is still a bloody mess.  The best way to make money off an idea is to get off your ass and make a good product.  If the inventor had spent more time working on an actual good, working example of his “invention” and less time mucking about with the patent office he would undoubtedly be in a better financial place.  But, instead of doing something positive with his “idea”, (which was in my mind not a patentable concept anyway)  He sells his patents to Lodsys.  This fellow could have been the next Paypal or some other major corporation, but instead he sells it off to some Trolls soo they can go shake down some companies and developers.


This “inventions firm” Lodsys isn’t an invention company, they don’t build product, they don’t create jobs, they don’t create a positive effect for the economy or society.  Instead, they bought up an old patent and sent out extortion requests to small developers.   To me, this is a major problem with or society in North America.  Rather than use our heads and hearts to do something positive for our society and fellow man, groups like Lodsys band together and plot how to “get their cut”.  In my opinion, this is one of the key points of current and future weakness in our economy.  We spend so much effort doing zero-positive-effect work that even with rising productivity, our overall ability to produce is lower.  We need to re-think the patent laws and favor those who would do something positive with the idea as opposed to those who wildly file for patents in hope of hitting on something they can suck wealth out of at a later date, when the technology is actually viable.  I say give the person five years from filing.  If in five years you haven’t commercialized the patent it should be declared invalid.  This may not apply for everything, but it might put the effort in the right place, which is innovation for the improvement of the economy and our society.


On another side, part of me is convinced these fellows are just stupid.  Even if they get the dream scenario and everyone starts paying up, they’ll be getting tiny cheques from tens of thousands of developers, resulting in a deluge of overhead to attempt to track these payments.  Again, creating a lot of noise, but no substance.




A man tosses in his bed, his thoughts dominated by visions of ruin and destruction. Unable to sleep, he levers himself from his bed and finds a chair in the darkness. One week earlier, this was man was a hero in the recessional economy. An entrepreneur, one of the individuals creating jobs out of nothing. Tonight, he is a victim of a terror campaign. He sees the labors of his hard work torn apart, his future uncertain and he knows fear.

This man is an educated software developer and a few days ago he received legal documents accusing him of software patent infringement for using software provided by his platform provider. The accuser does not develop software, instead they are a predator, consuming the efforts of previous creators for pennies on the research dollars spent. They find the ruins of companies who strove to be first to make new discoveries, compaies that attempted to protect their right to monetize the hard work. All this positive effort, bought at a steep discount so the predator can build an intellectual property library which they turn into a revenue generator. Filing intimidation lawsuits far and wide, fishing with fear to force capitulation, the company extracts the lifeblood from the entrepreneurs who strive to create value.

The news lends coverage to the Somali pirates, a group of poor, desperate men who seize ships in passage and hold them for ransom. The patent Trolls of the US are worse. They are not poor, desperate men, they do not just prey on the large ships, but instead hold for ransom every small skiff or fisherman who passes. The terror is not fear of death, but fear of losing everything, fear the American dream is a lie. Having your name appear on an legal accusation inflicts the same feelings as the pirates do, Terror.

Every leap forward in technology has a negative side. As shipping brought pirates, and trains brought train robbers, Patents have brought out the patent trolls.

So, what is the solution? I propose a limitation on patents to limit the enforceability to active companies in the industry. There should be no marauding band of degenerate lawyers who attempt to extort from the positive work of others. To enforce a patent claim, the owner should be forced to prove a business reason for the suit and a legitimate venture which contributes positively to society.

Let us act to support our creators. Let us act to counter this drain on productivity. Let us disband these hooligans and ensure the legal system acts to protect the interests of the common man. Let us act to open the avenues for new entrepreneurs and shut down these IP extortionists.


Lousy tools can kill and a shipped engine is worth its weight in Unobtanium

I’ve seen some amazing tech demos.  I’ve seen some amazing in-game footage.

I’ve seen a lot of those promising titles fail to ship.  I sure there are a lot of reasons, but chief among those reasons is often poor tools.  The technologist behind the engine and the technical artist who slogs through the much to get content in can make some amazing content, but when it is time to scale up and actually construct a playable title, the wheels fall off.  Brilliant technical artist are hard to find, assembling a team of them that actually agree on how to create a game is an impossibility.

You need the tools to allow the artisans to create the content to fill out a video game world.  An artisan without tools is doomed to failure as they cannot produce content at a reasonable rate.

I did some quick calculations and wound up with a rough stat that at typical FPS movement rates, a user could run through over $100,000 worth of level art in under ten minutes.  Without the tools to make content quickly, this metric would be much worse and make the game completely uneconomical to produce.

A second area of concern is iteration.  From when you start making the title to when you complete the title will be a huge learning experience.  By the end of a title’s development, the artists and designers know what the engine likes, what looks best and how to build it quickly.  With poor tools, your ability to go back and iterate is radically reduced.  So make some good tools!.


Since that was short, I’ll hit the shipped engine rule as well.  Anyone who has ever shipped a game (especially on the PC)  knows how much pain is involved in shipping a game.  That pain just hits a new level once the game is released and thousands of untested hardware configurations hit your code for the first time.  Shipping a game means finishing the tools, building all the extra bits such as configuration screens, user options, control customization, not to mention testing every system as thoroughly as budget will allow.  Another big plus is optimization.  A shipped engine likely had the development team analyzing the performance and tuning everything they could touch.  think about how much effort that can save your development team.

On the other side, licensing an engine which has not yet shipped, you are dragged along with a moving target.  I’ve witnessed this as an engine was licensed before shipping a title, took an extra year to be completed and even kicked off a lawsuit While the engine was still under development the team needed specific features to move the game development forward.  The end result was systems which were written by the game developers which conflicted with those in the engine when completed.   This added a great deal of complexity and difficulty integrating the latest code fixes from the engine team.  By licensing a shipped engine, you can learn the techniques the engine was designed to support for content optimization and system development and keep your code modular and easy to update with new engine revisions.

So, if you are looking at the latest whiz-bang engine out there, take a step back, have a deep breath and look at the engines that have already shipped instead, you’ll save a ton of hassle and reduce a great deal of external risk to your project.


A Renderer is not a Game Engine.

A renderer is a crucial portion of any game engine, but it is not the bulk of the work involved.  Many game projects used to (and some still do) start with a programmer building some cool new rendering technique that looked superior (or simply different) to every thing out there.  Following the first demo of the new engine, the artist would get excited about the potential of the engine and the race would begin.  The base of every engine is a good tool path.  The artists and designers need to have the tools to effectively create content.


For the first major game project I was part of (“Shattered Steel”) we built our own tools from scratch.  This was not the smartest thing to do.  We had a whole list of tools which all did slightly different things.  The workflow was horrible and the tools were nearly unusable due to their programmer-centric design.  To get a robot into Shattered Steel you had to: Build a Polygon in PolyEdit.  Create a texture in some paint tool (we used Corel Draw 3) (thankfully we didn’t try to build a paint program too).  Put that texture into the 100 texture array the game referenced using TexLib.  Change the mapping on the polygon using TexEdit.  Load the textured polygon into BotEdit to construct a Player robot.  Load the Bot into AnimEdit to create a four frame walk cycle animation and then go into the code and add all the rest, like weapon mount locations, pivot locations, etc.  Contrast this to Neverwinter Night where all the art tools were contained in 3DS Max, a tool the artists knew well.


Once you have a tool path, you can actually put some content in the world.  The next step is moving that content, usually in the form of a player character or simply just a camera.  This requires an input handler.  The first kick at an input handler can be pretty simple, to use the joystick, you just grab the values and munge the data till you have the inputs you want.  Later, when you want to add configuration and customization, this turns into a couple months of work.  Now you need to start worrying about collision systems.   How do we create levels and how do we stop the player from falling through the terrain/level?  This is usually an art tool and programming challenge and involves a great deal of pain and iteration.  The end result is a game world that can display art and a character (or camera) without cutting through the world.  Now we’re going to need an animation system.  Yet another tool and engine combo, with export tools to identify the content and the engine code to replay and match it to the character movement.  After you have animation working, it is time for some enemy characters.  At this point we need an AI system, a pathfinding system and a basic gameplay update loop.  Once those parts are together it is time to start adding game mechanics such as health and game states such as death.  At this point you have something that might show the first glimmers of the game you imagined when you first saw the engine run.   Once you have characters interacting in some manner, you’ll likely need some form of particle system to do weapon effects or projectiles or smoke effects or whatever your artist insist upon.  A few more programming and technical art man-months later you have a particle pipeline.


The next stage is to push the engine to see what the real world performance is going to be like.  We can put in “Gold Standard” characters, level art, particles and see where it all breaks down.  This will show us where we need to start optimizing the content and/or engine to deliver an interactive experience.  We throw some particle systems in just to increase the load and fix what is slow.


Next is probably the Audio engine, which need to interface with the game events system, so we better build that too.  Once the audio is in and the events system is working we’ll likely want to play some music too, so another bit of work goes into the music.  What about when the track ends?  how do we loop it smoothly?  Do we want combat music?  if so, how do we transition from the normal ambient track?  Once that is all solved we are probably ready to make a prototype level and pitch our title.  The next few months are a panic of putting in content, fixing bugs and dealing with the fallout of guessing wrong about performance.


If you contrast the above with the act of licensing an engine which has already shipped a title, already gone through a comprehensive bug fixing regime, already had artists learn the tools and manage to develop final shippable content. the value of an engine is obvious.  If you can add to that a community of people who are modding the game which shipped it suddenly becomes much easier to recruit new artists and designers.


So, in summary, if you are looking at a cool new renderer and thinking “This is going to be awesome”, you need to back away slowly and start listing out all the work you have to put in to match an already shipped title.  If you think it still makes sense, proceed with caution and be very aware of the costs to iterate into a shippable game.



Iteration is Everything

For my first follow up to my game development rules I’ll hit on Iteration.

I was lucky enough to be at Bioware during the development of some pretty great games.  In most cases, we were doing new titles, without pre-existing engines or workflows and as such, we did a great deal of invention.  Sounds great so far, doesn’t it?

The sad thing is, most of our inventions didn’t work out as planned, in many cases the best design turned out to be missing a tiny component called “fun”.  The solution wasn’t to come up with a new design and start over from scratch, it was often to dig into the problem and understand what was sabotaging the fun.

The key to this was rapid iteration.  we made a change, tested it and then tried again.

I remember one case specifically:  We had an encounter in Baldur’s Gate where the party met up with a small group of “Kobold Commandos” in the Nashkell Mines.  Initially, we had the AI dialed up to be quite intelligent,  they would all team up and take out the spellcaster first, then the clerics and ranged combatants before moving into melee combat.  We had also equipped them with fire arrows, which did an extra 1-6 damage on every hit.  The end result was the player’s party was usually wiped out before they had a chance to engage the commandos.  We had to go back and re-tune the arrows, the AI and the toughness of the Kobolds quite a lot before they didn’t decimate even well-prepared parties.

I always viewed the first title in a series to be a flawed creation, just about the time you had learned how to create fun gameplay and the tools were up to supporting quick iteration it was time to ship.  The sequel was a magical project, a chance to use all the hard learned lessons, the polished tools and all the great new gameplay ideas spawned from previous iteration to create the best game possible.  In my opinion, Baldur’s Gate 2 was an excellent example of this.  Even today, with Mass Effect 2 you can see the power of iteration as a game can be refined and improved immeasurably by an experienced team iterating at what they do best.



Some of my game development rants/rules

I was thinking about some of the lessons I’ve learned (the bad way) over the years.   I thought I’d just throw a quick list together and post it up for people to have a look at.  Over the next while I’ll expand on the points as time allows.

  • Iteration is everything
  • A renderer is not a game engine
  • A great renderer with lousy tools makes a lousy looking game
  • No team should (or will) ever seriously consider using a game engine until it has shipped at least one successful title.
  • Never license software for the features in the next release. License for the current version.
  • Most programmers are overly optimistic about the time required to build a new version of and old system, especially if they didn’t write the earlier version.
  • Depth (or complexity) in a game is best engineered through the interaction of a few simple systems which give the desired result.  Unstructured complexity is just a nightmare
  • No design idea goes straight from concept to a good game mechanic without iteration. (see point 1)
  • You are not ready for production of a game until your team can create gold standard slices of all imagined forms of gameplay.
  • To make a great game you must love the subject matter and intuitively know what does and does not belong.
  • The key to a great game is a great team.
  • The key to a great team is respect and alignment.
  • Team alignment is best achieved through an early gameplay mockup video or animatic
  • If you ask five members of the team to describe the game you are making and they all describe something wildly different, you are on your way to game development hell.
  • A game concept you cannot describe in 2 minutes without using game examples is a game which will never be funded.
  • -Trent

    What makes a great video game producer?

    During my time at Bioware (I prefer to do Bioware with a lower case “w”.  I’ve always hated the “BioWare” thing) I had an opportunity to work with a large number of producers.  I’ve worked with developer side people and publisher side producers and noted the differences between the two.  The largest challenge I faced was recruiting good producers.  It seemed for every positive facet a producer candidate had they had offsetting negative traits.  In most good producers I never noticed a common trait or approach.  I did however notice a common missing component in the less successful candidates.  At the time I called the missing component “Tactical awareness”.

    To me tactical awareness is the ability to examine your surroundings and “feel” when something is off course or in trouble.  In a producer the only more valuable trait are excellent prioritization skills.  A good producer can talk to a few team members and from the common data and differing data discern a pattern of concern.  People rarely come out and say “X is off the rails and out of control” early enough to head trouble off before it becomes a large scale concern.  But if you talk to a variety of people on the project and they mention some minor concern about a common area, you have a pretty good idea what might be going wrong.  In the best case, you dig in and find the issue is miss-communication and get the involved parties together to fix the confusion.  In the worst case, you’ve uncovered a disaster before it gains a lot of visibility.  At this point I’d usually report up the point as an area of potential future concern and get hard to work fixing it before things got worse.  In most cases, the issue could be fixed before a major issue emerged.  Tactical Awareness, the ability to read the signs of a problem and track it to the source is of paramount importance to a good producer.

    The other part of tactical awareness is an understanding of where you are in a project and what the challenges you need to prioritize are.   In the development of Neverwinter Nights we ran into a number of issues which required completely different management due to the differing stages of the project.  Early on you need to focus on the technology and getting a stable pipeline up and running.  In the middle of production, you need to focus on improving workflow and asset quality.  At the end you need to focus on locking everything down to remove variability so the title can ship.  The same scenario is treated quite different in each stage of the project.

    I tried in a few cases to teach or mentor tactical awareness, but was unable to do so.  I tried sitting back and letting scenarios unfold and trying to nudge candidates in the right direction without avail.  In the end, I came to the decision that tactical awareness is much more rare than I had originally thought.  I think in the people who gravitate to work on games the social awareness required is hard to come by.   I also think too many people become comfortable in the day to day and lose sight of the big picture.  My best work historically has always been after some big picture reflection and a slight dose of paranoia.

    The best producers never seemed to care about the boss or reviews and how management perceived them.  They were driven by the project and did whatever they felt was required to get the game one day closer to ship ever day.  I’ve been trying to formalize how to recruit successful people.  So far, I’ve had little luck nailing it down to common traits or backgrounds.  The best people I’ve hired just had energy, some tactical awareness and a desire to make something great.



    Is your future PC a Tablet?

    I’ve been using my iPad quite a bit lately.  I have to admit I’m a fan.  I’ve spent every day for the last 17 years or so using a PC.  After using an iPhone and iPad you really have to feel the PC has been left behind from a user interface and software experience standpoint.  I often rant on about how much I hate the PC experience.  But could a tablet replace a PC?

    After playing around with both platforms, I’ve come to a basic understanding.  Tablets are a great content consumption platform, but not a great content creation platform.  In fifteen years at BioWare I created some great content on the PC and for a great deal of that content, the massive screen, precise mouse control and full sized keyboard were a mandatory part of the creation experience.  The strength of a tablet; portability, ease of use and simplicity are the exact reason the platform has a hard time with content creation.   Thinking about this move to dedicated consumption and creation devices lead me to think more about the PC.  I hate the PC experience for what it is and how it forces me through some arbitrary hoop jumping constantly.  I love the PC for the potential of the platform and the ability to create.   In the average game there are hundreds of thousands of unique component parts which make up the user experience.  Organizing those parts takes a great deal of effort and that is where the PC actually shows strength.  The complexity of the PC is a legacy of creating large volumes of small components and gluing them together into something substantial.  I’m confident there is a better method of organizing that data, but for the moment the PC offers a very simple method of dealing with them through the concept of small individual files.

    For most content consumers the file management doesn’t offer the same benefit, which is why the Tablet feels so slick as a platform.  I’ve tried using the iPad as a content creation tool, just for text processing and the experience was not great.  Whenever I messed up I found it difficult to quickly fix the issue.  I found formatting and “hacking up” the document to be a real pain, as the cut and paste interface is still pretty basic.  I’ve seen a few fellows use the iPad as a sketch tool and I think that is the one area where it makes a ton of sense.  With a special pen, the tablet actually seems almost magical.   After the image is done, a weakness shows up, getting files back to where you can actually use them.  I’m certain Apple will find a better way of getting content off the platform at some point and the “sync to itunes” dance can be improved.  So, for the foreseeable future, I’m a PC user for content creation, even though it makes me angry and you won’t like me when I’m angry.

    I recently looked back at our venture, Beamdog and I realized my political agenda in developing a digital distribution platform.   I wrote my two directives on my wall.  The first was “Fix the PC”.    We’ve managed to get rid of software installation and file browsing for games and we hope to take that further.  We feel this is a great first step in improving the PC software experience, but we are committed to poking into every dark corner we can to try to improve further.  My second directive was “Give credit where it is due”.  I want to build a place where the guy on the ground floor is the hero, not the guy on the top.  Admittedly, in North American culture we like figureheads and heroes, so this is going to be a real challenge, but one I really feel is worthwhile.

    Thanks for reading.