If you’ve come here for a humorous collection of pseudo-quotes from a variety game development projects, then you’re probably in the right place! Also expect to find a list of excuses you can reuse and apply straight into your studio — whether you need to buy yourself some time, offload the workload to someone else, or simply blame other members of your team for a change!
Of course, if you have any personal favorites or additional excuses that you use when developing artificial intelligence in games, feel free to post them in the comments below.
Designer Relations
As a programmer, the first place you can turn to for excuses is the design document, or whichever medium you use to write down the project’s requirements. So when someone asks you about a potential bug, here’s what you can say:
It’s what the design says the behaviors should be.
There’s no design for that part of the AI.
Why would you want it to behave that way?
That’s actually a new feature!
Data Driven Bugs
With the advent of data-driven game engines, there are also plenty of opportunities to blame parts of the game that are not compiled source code. Here’s what you can tell your producer or project manager:
That’s a scripting bug; check the logs for warnings.
It’s a problem with the animation data.
Someone messed up the level annotations.
Not sure where the problem is, but chances are it’s the data.
The assets weren’t exported correctly.
Third Party Problems
With developers using middleware increasingly and larger teams building game engines, it becomes much easier to blame other programmers for any kinds of bugs.
It’s known bug in a 3rd party library.
Ask the animation or tools team!
The physics simulation doesn’t support this.
AI Logic
When you start diving in to the logic behind the AI, there are lots more excuses you can rely on as things get complex pretty quickly. Use that to your advantage:
The underlying theory is sound.
It’s too complicated for you to understand.
How did this ever work?
It just can’t be done!
This can’t be fixed without that breaking.
Testing
With game worlds becoming more open and sandbox like, the AI also becomes more emergent. That makes it increasingly hard to test in practice. Here’s how you can make the most of that:
I can’t reproduce that problem.
It’s not a bug, it’s an emergent behavior!
It didn’t need testing since it was such a simple change.
Build & Deployment
With large teams, building and deploying projects can get difficult too. It takes time for other team members to get up to date. This is how you leverage this fact:
It’s not in my build.
That’s weird, it’s never done that before.
It worked yesterday!
Hardware
With game development increasingly focusing on the concurrent architectures inside consoles, and PC hardware becoming increasingly exotic, there’s lots of room for excuses here too:
There’s just not enough computation power to solve this problem.
Too little memory is available to store the required information.
It’s a synchronization problem between the cores on the Xbox 360.
Nobody else gets SPU programming right on the PS3 either.
Workflow
What’s left? A few excuses relating to working methods and daily routines:
That’s been fixed already; try getting latest.
I was busy reading AiGameDev.com’s amazing RSS feed.
If you have any additions, feel free to post them as a comment below and they’ll be added into the list too!
2 Comments ↓
Those excuse are not exactly AI related, they are universal!
The only one pure AI related is 19. and to some degree 4. (Difficult to explain hole in the head as a new feature)
These seem remarkably common as well:
http://www.possibility.com/epowiki/Wiki.jsp?page=ProgrammerExcuses
Leave a Comment
You can also reply to this thread in the forums.