Darkened Software


Interviews: Pay attention to the instructions.

by on Nov.14, 2012, under Industry, Interviews

This might be the funniest interview I have ever conducted.  After introductions and a min of baseline conversation I give him the back round for the problem and 3 instructions for the question.

“Topic is X, there is usually around 4 issues that arise from it, for each”

  • Write down the issue on the whiteboard.
  • Write down the data you would collect to track and understand each issue.
  • Write down how you would display the data to the user so they could solve each issue.

I ask him if he understands which he nodes to and then I hand the kid the marker and prepare to be amazed.

He stands there for a few seconds and then says the first issue must be “Y” and starts telling me how someone on the last project solved it.

So I get up and take the marker from him, step over to the whiteboard, write the issue on it and hand him back the now open marker and cap.  He says “Oh right” and then continues to talk.  Not an amazing start, I hope this kid is just a little nervous and gets it together.

He finally runs out of things to say about how someone else attacked that issue before so I prompt him think about what other issues there is with topic X.  He again goes silent for a little while and then says it could also be “W”.  Tells me he has never had to deal with it but thinks it could be solved and starts rambling on.

I get up and pick up another marker, walk to the whiteboard and write down issue “W” right under issue “Y”.  I again hand him the uncapped marker so now he is holding two open markers as he continues to talk.  This time he says nothing as I hand him the marker.  Eventually his mumbling goes silent so I ask what the third issue might be?

He loudly declares there is no more possible issues under the topic “X”.  WTF kid it is not likely I am giving you trick questions.  So after I ask him a few questions he gets to realization of the next issue and declares “well I guess there could be an issue Z”.

This time I am going to see if he eventually figures it out and I just wait in silence for him to write it down.  A full 2 min of mumbling later out of pure amusement I go get the last marker, uncap it and write issue “Z” on the whiteboard.  Then I go to hand the marker to him again but he is standing there with an open marker in each hand already.  So I put the cap back on it and attach it to the bottom of the one in his right hand.  He just stands there silently for a few seconds, so I ask him to go onto the next part of the question and “Write Down” what data he would collect to resolve the issue.

He then loudly declare there is no way to resolve it and thus it is not worth worrying about.  Your right kid, it is quite likely I am giving you problems I really don’t want you to solve.

As amusing as this is it is time to walk you to the door.


Leave a Comment : more...

Book Review: Sparks of Genius

by on Feb.26, 2012, under Development, Industry

This book hits on a topic a friend of mine and I have been arguing about for years, do people need to be multidisciplinary or should they specialize in one skill set and focus their time learning to do it perfectly.

I took the theory that our worlds of knowledge are growing way to fast for one to have time to become skillful enough in the other fields that it would help your main career that much.  My friend took the theory that it was still possible to learn multiple different skill sets and that they will make your main discipline much strong.  A few years back I realized that after learning new types of poker my Hold’em game became significantly stronger.  Then I started collecting new programming languages and my C++ code became much cleaner.  Thus I started to believe my theory was on shaky ground and I might soon be sending someone a bottle of scotch soon.  After reading this book though I realized just how wrong I was, but at least the book was nice enough to fully explain why and what I could do about it.

Their theory is to take your mind and problem solving abilities to the highest level you need the following 13 skills:

  • Observing
  • Imaging
  • Abstracting
  • Recognizing Patterns
  • Forming Patterns
  • Analogizing
  • Body Thinking
  • Empathizing
  • Dimensional Thinking
  • Modeling
  • Playing
  • Transforming
  • Synthesizing

Looking at this any my own game programming career thus far it actively trains maybe about 5 of those skills really hard and another 3 of them moderately.  Thus my career is not providing very much practice time in about 1/2 the skills needed to really excel in this field.  Unintuitive as it seems I need to spend less doing software development and more time in another field that is mainly about these other skills.  Looking at this list it is clear I have to either pick up music, drama or  painting to complete the tool set.

Leave a Comment :, more...

Companies, aim for the win instead of aiming to just stay alive

by on Sep.06, 2011, under Industry, Lessons, Start ups

Here is a hypothetical question, imagine that you own a small game company that is just getting started, and you have been offered 2 contracts.

First contract: Standard 1.5 year slightly aggressive schedule to take an IP from company X and do something with it at basically cost plus a small profit.  It is pretty safe, the publisher needs to have something out with the movie / book / whatever and thus it is almost guaranteed your company will have the money to survive for contract period.  If you play it right you might build a relationship with the publisher and even have more work lined up for when this contract is over.

Second contact: Not so standard 4 month very aggressive prototype to see if you can either take or create and IP that the company can use to fill one of their publishing slots.  This will take everything your little company has got and when it is over if the publisher does not pick it up you are 95% likely to go under as there is really not enough time to line up anything else up.  If you succeed in impressing them with the demo they have the resources and are willing to go big with it which could make your company a known entity.

Many CEO’s would take the first contract as they believe it less risky, they know they will be able to pay their employee’s for the next 1.5 years and keep the company afloat.  They will not have to go through the painful process of laying people off or shutting their doors and all those other fears that keep CEO’s up at night.  The sigma of having to close down your studio is often too much and most CEO’s will take many tradeoffs to ensure the long term survival of their company.

Few CEO’s would take the second contract as they believe it is reckless to take such a high chance they will be shut down in 4 months.  While true it might not be the contract a CEO would want to take if they just signed a 5 year office space lease and put their house up as a deposit.  It’s higher short term risk is more than made up for by its much lower long term risk.  Now, how to back up this theory.

A pattern I see over and over again is small companies start out with tons of energy as they believe they are going to take over the world.  That first project is tough as they are just starting out and have a shoe string budget that they make up for by putting in their blood, sweat and tears.  Now that first project is a safe project which is much more likely to not sell 3 million copies ( > 90% don’t ) and does not make them all billionaires.   So the company starts their second project but this time it will not be with nearly as much energy.  The tools and tech are still just as crappy this time around but with the new found reality check from shipping a dud this time it really starts to bother people.  People quickly get upset that things are not vastly improved this time around and they are still being asked to put in a lot of hours to compensate / compete with bigger budget development houses.  Its not that people don’t want to fix things but the company does not have the money or means to do it so everyone is forced to live in frustration.  Soon people start to leave and the churn just makes the situation worse.

How many good people are still working there after the second project also fails to sell crazy numbers and the third project starts?  It is typically a very small number.  So the big risk is not so much starting a company and going under in 4 months when everyone can still get jobs again.  The real big risk is starting a company and struggling in misery for 8 year before finally going under because even college graduates know better to work in your sweat shop.  When you own a small company your only goal is to get from broke to well funded before all the good will of your employees is used up.  In the highly competitive game world that means going after the high risk but high reward situations that can get you to the big time.

As much as I dislike the term it is very true, the game industry needs to learn to “Fail Faster”

Leave a Comment :, , , more...

Design does not yet rule in game development

by on Jun.30, 2011, under Development, Industry, Lessons

This debate has been raging for ever since I joined the industry, lets just end it right now with the results of the Gamasutra Salary Survey for 2010.

Programmers: $85,733 ( Avg.  4 year degree )

Artists: $71,354 ( Avg.  4 year degree )

Designers:  $70,223 ( Avg.  High School Diploma or GED  )

You can argue as an industry based in entertainment we should value designers more than artists and programmers but the facts clearly state we currently do not.  Now stats like this are tricky, it is hard to say if they are the cause or effect.  Are designers paid less because the market is flooded with great designers and thus do not need to be paid as well?  Or are designers getting paid what they are worth but do not yet provide the same value to the industry that the other disciplines do?

To me it is very clear just by playing games out there that we are not even close to having an over saturated market of great game designers.  Most game designs are just painfully derivative, most levels are unimaginative and the game play systems we are forced to learn are repetitive and far to basic.  The level of thinking these games require is often minimal, often it comes down to just pure memorization or repetition.  If there is any fun in the game at all you either have to sit through 1/2 the levels before you run into it or you have to fight with so many other bad systems that it is just not worth going after.

So I am going with the theory that designers are not yet providing the same value as other disciplines, in fact when I saw the survey I was blown away by how much they were getting paid.  Know many other careers were people with no formal training can end up making 70k a year?  For what the game industry is getting the average designer salary should be much closer to 45k than the current 70k we are seeing.  That delta of 25k is just how desperate the game industry is to attract good people into the game design field.

If game designers want to rule the industry like they should then they need to get some training in skills that would really help ensure every game is great fun and worth buying.

Currently it seems the curriculum for game designers is:

  • Play a lot of games
  • Come up with a big list of reasons why any game mentioned sucks.
  • Declare they could do better and should already be working  at blizzard.

New curriculum you could get at any university:

  • Study psychology: stop guessing why things may or may not be fun and learn what really makes people want to accomplish goals, drive for payoffs and stay interested in the pacing of rewards.
  • Study human learning: stop making games frustrating by being to easy or overwhelming.  Learn exactly what people can handle, how they process information, how they attempt to solve puzzles, how long it takes to makes skills permanent.  There are many different learning types but most games are only set up for one.
  • Study biology:  go learn exactly what information people process out of images, sounds.  How the brain shuts down or speeds up by stress, sound, threat and reward.  Build games that are paced to work with the body instead of taxing it to much and being a drain.
  • Introductory writing,  game theory,  coding, art just so you know what the other disciplines are doing.
  • Play a lot of games from all time periods and categories.  Understand were they have been, why they have evolved and were they are going.

When designers have the skills sets that they can consistently take even primitive tool sets and build great levels for their target audience then they will be the highest paid people in the game industry like they should be.

Leave a Comment :, , more...

Why game development Middleware pitches are wastes of time

by on Jan.31, 2011, under Development, Industry, Lessons, Programming

I am a really big fan of Middleware as there are many things I never want to be an expert on and just want to pay money for them to work.  I really wish that during the process of trying to obtaining said software I did not have to sit through the dreaded “Middleware sales pitch”.

Why do we have to sit through them at all:

Unlike other industries most game middleware companies will not just let you download their SDK, see if it works for you and then let you pay them money if you so desire.  They insist on coming and giving you a presentation before they even allow you have access to a time limited trial version of their SDK.  This makes very little sense, if I am coming to you to download your SDK then it is very likely I do not need to be sold on it.  What I need is time to integrate it and see if it solves my problems, you forcing me to meet with you is actually slowing down your eventual goal of selling me anything.  The only good thing you could do is bring with you so much information about best way to integrate it and other best practices that saves me time in my investigation.  But sadly these sales pitches do not contain this type of information…

Even worse sometimes we are forced to sit through them even when we are not interested in the middleware being presented.  For example someone above you in the org chart decides they like middleware X and unless you want it to be forced on you and your team you need to go to the presentation and ask the right questions to get it shut down.  These are the worst meetings possible as you have to piss off the presenter by asking “bad” questions and also make your boss feel like you are effectively dumping on his idea. 

How can we make them better:

Its unlikely we can make such meetings go away but maybe we can convince middleware providers of what they really should be providing in these meetings to make them a little less painful or more useful. 

A way too standard middleware presentation:

  • Most middleware presentations start of with a great little store of how middleware company x came to being.  Some guy in his mother basement had a mission to solve problem X and after years of blood and tears he has grown solution Y into the coolest company ever. 
  • Then they tell you just enough about how they solve the problem to sound impressive but not really give you enough information to see if it will work for your case.
  • Next they show you a bunch of really bad demo’s because they are not game developers and are too cheap to hire real game developers to build them examples that might prove anything at all.
  • They tell you about a bunch of companies that are using it but have not shipped any games on it yet.
  • They answer any questions about features with the standard “That is in the next version coming out this summer”.
  • They answer any tech questions with “It is easy”, “Send us an email, We will get back to you” or “Can’t answer that as it depends on the level”

But does this do us any good, they are telling a story of thier accomplishments and how wonderful everything is which makes them feel good but does not really help us in our struggle.  They need to remember that in order to get our money they need to tell us a story that makes us believe everything in the furture will much better than it is now.  The only way they are going to do that is by understanding our problems and convincing us they can and are dedicated to helping us solve them.

What are our problems:

  • Time ( the complete lack of it )
    • We don’t have time to write all the software we would like to
    • We don’t have time to find and hire all the people to build all the software we would like to
    • Most of us have very unmoveable milestones that we are under contract to hit.
    • Most of us have teams of people that are waiting for software to be done so they can be productive
    • When we have issues or questions we can not wait on answers we need them a long time ago.
    • Games are highly iterative and anything that slows down the pipeline is scary ( crashing / reliability / slow builds ).
  • Resources( aquire &  managing )
    • People with specific skill sets are hard to find.
    • People in general are hard to manage.
    • Large amount of hardware and software resourcs is a huge maintance cost
  • Money ( the complete lack of it )
    • There is not a lot of profit margin in most developer contracts so the team can not afford to be wrong very much.
    • Developers do not just get 20 million to do a game up front, we get a little bit each milestone which is usually just enough to each the next milestone.
    • Also our requirements change quite a bit over the project so we do not like to spend a lot of money up front as we can not get it back when things change.

So if they were designing a presentation that would tell us how they can solve our problems it seems like they would start the presentation off with a few questions:

  • Is there any experiences in your games you feel need improvments?
  • Is there any parts of your game development process that you would like to improve?

Then instead of giving us a shot gun overview of everything the have ever built they could focus in on solving our problems and concerns.  Now that they have our goals in mind how can they make us believe they can solve our problems.  The last part of the their problem is how to take us down the path between our problem and believing they can solve it in a way that is worth us paying them money. 

Most presentations really fail in this area as they might start off by showing us a very limited demo that only proves that their system will work in a most limited case.  Then they jump back to the very start of the process and show you how to set up the tools, build the assets and get into their simple test level.   The problem is from the very start I am not convinced it will work in my case so I am not going to give you my full attention to your demonstration. 

The improved presentation:

  • Show me that produce X can solve the problem at the scale and complexity I will be faced with.   This might mean going out and getting a game developer to build real world levels for you to demo with and not just showing us your internal test levels.   
  • Next show the real run time costs, be able to bring up memory, cpu stats.  I am not going to listen to the rest of your details if I do not believe that what your showing me could ever co-exist with my game.  Absolutly nothing turns a developer off faster than hearing “I do not know” to our critical runtime questions. 
  • Working backward show us the pipeline that gets the goods into the game.  If we do not know that it will not turn our finely tuned pipeline into the bottle neck of production we are not going to listen to anything else you might say.  Remember Time is our #1 development problem
    • How long does it take to run and how much will it add to our iteration time?
    • Can it be distributed?
    • On average how long does it take to integrate into a tool path?  Provide both examples and references.
  • Next part is the content generation iteself, again this must be shown on a real world examples.  I need to be able to determine total time for my game and how this might change the makeup of my development team.  If I can not figure out how long it would take me to process our assets then I am not going to risk switching my system over to something that is suddenly going to require massive outsourcing or hiring.  Remember Resources  is our #2 development problem
  • Support, turn around time, escalation procedures, avalibility ( I work nights & holiday, are you guys there too? ), ability to help debug, bug patching, source if needed, how often releases, how far back in releases do you support, how quickly do you upgrade to new console libs? 
  • Total Cost and payment schedule, what is the price for everything between now and when we are scheduled to ship.  There is way to much hidden costs in these presentations and we are always hearing things like $40k per platform.  But then 2 weeks later we send an email and get informed that email support is another 10k per year and god forbid if you ever need to get someone out to help you do last min debugging during ship.  Also can we pay over time so that is it does not completely restrict our budget?  Lastly Money is our #3 development problem

 These changes to a more customer concerns focused presentation would move middleware meetings off my list of least favorite development activities and might even make them finally useful.

Leave a Comment :, , more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...