Sponsored By

Part 7 of 10: Foresight

Jacek Wesolowski, Blogger

February 2, 2010

3 Min Read

Part 7 of 10: Foresight [previous parts]

 

Somewhere there is an encyclopaedia-sized book on how the history and the future of the world are shaped by those who Didn’t See It Coming.

 

Once upon a time, an idea for a game was conceived, and a non-interactive demo was pitched to a publisher. It was impressive. It was novel. It had style. And it got greenlit! But the one thing the demo didn’t have was gameplay. Everything it showed was a fake. No one bothered to see if the idea worked, because, hey, who needs a working game mechanic for a non-interactive demo?

So when the lights turned green, and we rushed to build that game we knew was going to be so good, we were surprised to discover there was no game at all. We didn’t know what it was that we were trying to build. Eventually, after many iterations and failed attempts, we managed to build something playable – but it looked nothing like the idea we had loved so much.

Some other time, a unique new weapon was built. It was so cool it would stop the global warming. We hurried to get it done as fast as possible. Though there were many difficult technical details to take care of, we just wanted to let everyone see all the cool, right here, right now. We made our job easier with hacks and silent assumptions, because, hey, they would make the cool new weapon work. Why on Earth would anything else possibly matter?

Then we moved on to other features, and it wasn’t until a year later that we approached the weapon again. We decided to give it to enemies, and not just the player. And then our world fell apart, because the weapon wouldn’t work in the new context. All the hacks turned into bugs, and many of the assumptions were proven wrong. Eventually, we managed to create an enemy who could wield that weapon, but it was nothing like what we had hoped for.

I once witnessed construction of a level for a co-op game, that was only tested in single player. After the switch to co-op, it turned out all corridors were too narrow.

I‘ve heard many a programmer curse poor architectural design of licensed engines we used. Sometimes the software had built-in restrictions that didn’t fit our project. Sometimes it wasn’t flexible enough to support the unique features of our game. We would spend hundreds of hours adapting it. In that case, we were hit by someone else’s lack of foresight, rather than our own. Who prototyped those engines, anyway?

Let alone all the prototypes we never built regardless of how much needed they were, because the project’s manager didn’t understand what their purpose was, and refused to allocate the time.

After all, hey, we all know this is going to be a great game, so why bother building something we cannot put in it anyway?

 

Lesson Learned: Think ahead. Always keep a list of things you’re going to need in six months’ time.

Read more about:

2010Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like