One of the challenges of working on an MMO as long lasting as the EverQuest franchise is decisions made today may still be having effects to the game 10 years down the line. And with a total of 53 game programmers who’ve worked on EQ2 so far, there have been many different cooks adding ingredients to the codebase that’s the heart of the game.
When implementing any new feature or system, programmers always try to make the code easy for future programmers to understand in case it needs to be modified in the future, and to predict where possible how it might be used in the future. But unfortunately, it’s not easy to predict the future, and sometimes a system that was implemented with one specific need in mind may end up being used far down the road for sometime entirely different.
A great example of this is the baby dragon. When EQ2 was first released, it included a collector’s edition that had, among other things, a baby dragon house pet in your choice of colors that would do a variety of tricks in your home. The baby dragon was completely unique, there was no other house pet like it, and since it was an exclusive collector’s edition reward, there was no particular expectation that anything would be like it again.
So the code for handling aspects of the baby dragon’s unique behavior was written, and when it came to certain behaviors, an “isBabyDragon” check was added so that if the item being checked was a baby dragon, the code should treat it in a certain way.
)
This worked perfectly well for launch and the baby dragon was enjoyed by many happy new EQ2 home owners.
However, some time after launch, the Bloodline Chronicles adventure pack was released. This added new dungeons underneath Nektulos Forest, and also added a new type of destructible wall that could be blown up by lighting an explosive barrel nearby. Adventurers would move the barrels into position, light the fuse, and watch as the wall shattered, opening up new areas to explore. And when the programming team implemented the destructible walls feature, they needed to check certain aspects of the wall that happened to be similar to things that were checked on baby dragons. And because the code that checked whether something was a baby dragon had been called “isBabyDragon”, the code now needed to consider that destructible walls returned “true” for “isBabyDragon”.
The destructible walls worked perfectly and adventurers had lots of fun blowing them up, but new programmers joining the team years after launch may still be puzzled to discover that, technically speaking, destructible walls are considered to be baby dragons from the code perspective.
