Darkened Software


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...

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...

Waterfall, ISO 9000, CMM, Agile, Scrum, what fad is coming next

by on Apr.06, 2011, under Development, Lessons

Seems like every 3 years I am asked to learn a new system of project management that ends up being a 98% complete waste of time.  Why have there been so many systems created and thus so many books written about this single topic.

  • Projects are hard to manage because they are often complicated ( Budgets, locations, schedules, resources, cross group coordination, feedback, testing, customer satisfaction, marketing support )
  • People are hard to manage because they are always complicated ( Interests, skills, communication styles, personality, work habits, schedules, needs )

So “Project Management” is thus complicated * complicated = really dam hard.

The first factor is “really dam hard” problems take a lot of time to fully understand, plus even more time to develop a good solution and then several iterations to practice the solutions enough times that one will always get it right.  In terms of large projects this means people are going to fail at some level for many years before they get good at it yet less get it 100% right.  But we humans are not that patient of a species and we tend to treat big problem like small problem in terms of expecting resolution far too quickly.  If we do not get the results we want right away we conclude that the approach must have been wrong and there must be an easier solution.  Very rarely do we do enough research to predict what a reasonable path of improvement milestone would be and even if we do we commonly get sidetrack with just the rumors of someone else getting better results.

The second factor is every tech director’s misguided need to standardize across the company, they wants each group using the same systems so people are transferable within the company and their job of monitoring is easier.  But given that each project is very likely to be somewhat different than the rest of them this will only end in pain as square pegs get forced into round holes.  Still they try and after awhile a each solution fails to work across the entire company so they go looking for the next one instead of trusting their managers to build the solution each project needs.

The third factor is fear, fear that we are getting left behind in terms of process, fear that people will not want to work with use if we are not using the latest and greatest system, fear of not getting it right so covering your butt by taking a name brand solution.  Companies are more than willing to throw away all lessons learned by their teams just for the false hope of that some method will make the scary unpredictability of software development go away.

Thus millions of dollars get spent on books, courses, software consultants and seminars only to have each company end up roughly were it was before the last project management system came along.  Parts of the company will still be doing really well while other parts will still be under performing.  Not surprisingly it will be alone the lines of people have an understanding of the principles that influence development and those that do not.  So stop wasting time forcing processes onto your groups and just ensure they have the base knowledge needed to figure out what should be happening.

Our group just had Scrum shoved on it so each day the good little “scrum masters” we are gather around the whiteboard to update our color coded post it notes with what we are working.  Everyone declares what they got done, are working on next, what changed, and if they blocked on anything.  From this one tiny part of the bigger scrum process we can quickly find issues with trying to apply it to our project.

  1. We only have 8 people and this already takes 45 min – 1 hour ( wasted $’s ).  This is not going to scale well when we are 30 plus people in a year.
  2. Our dev manager and many people are out of the office quite a bit, why are we putting all our important information on a whiteboard were it can only be seen or updated by people standing right in front of it.  Microsoft spends a ton of money to give us great remote access to all our data which we have just rendered useless.
  3. Why is all our important information in paper form so it can not be shared, tracked, have versions or be compared to other groups.  I get it that it is more visible to the management people that might walk by ( also has to be a security risk ), but the price is not worth it.
  4. If anyone on my team waits an entire day to bring up someone that has him blocked I would like him removed, if your blocked there should be an email to the entire team about it instantly.

Seems if we had looked at the principles of communications we would have realized this system of post its would not work with our distributed and multi time zone team.  If we had looked at the principles of project feedback and constant improvement we would have realized that not being able to easily update and trend our data would be a issue on a long term project like ours.

“As to methods there may be a million and then some, but principles are few.  The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble”.  — Ralph Waldo Emerson  (1803 – 1882)

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...

Reboot your machine before you install software

by on Oct.13, 2010, under Development

Last week I got hit with an issue were after installing a very innocent SDK my machine decided it would no longer boot and I had to bring it up in safe mode.  Thankfully Microsoft has made it very easy to roll back installs with the “System Restore” option under Control Panel -> Recovery.  The interesting thing System Restore showed me was how many patches, critical fixes and other things were automatically installed inbetween my manual software installs.  99% of the time this is a great thing as many issues are fixed before I ever get a chance to notice them. 

But when installing software this can be a bit of an issue as it seems not all these installers play nice together.  Some installers detect the system update installer working and will properly shut down but most do not.  But even that is enough, if two installs want to update the same file that is currently in use they will both schedule a replace on reboot. In the case that your second install wants one that is older than the one from the first install but still newer than what is currently installed very bad things will happen.

Until all installers can detect that the files they want to update are scheduled for replace on reboot and not run the user have to be extra careful.  Easiest way to avoid the issues is to always reboot your machine before installing software.  This may never hit the average user but if you always re-boot before installing a program and right afterward you will avoid a lot of risk.

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...