4. OpenGL Support on Intel Integrated Chipsets
We went into development on BG: EE with a clear goal to target the OpenGL 2.0 specification (from 2004) for all functionality, to ensure support on all devices. We did some quick testing on PC, on Mac, on iPad, on Android, and passed on all counts. Raspberry Pi, check. Raspberry-freaking-Pi OpenGL 2.0 support, check.
We expanded our beta testing group (and quite possibly due to the enthusiast nature of the participants in our beta) we had very few performance issues reported. (In retrospect, it makes perfect sense that gamers would elect for enthusiast video cards and, as such, have solid OpenGL support.) Close to ship we saw our first few reports of slow performance on Intel integrated hardware, specifically in older laptop systems. We did some digging and found many of the laptop vendors had not updated drivers in many years.
During this timeline, we shipped the game on PC. We started getting more reports of poor performance and graphic problems. We managed to find a few workarounds --such as force-updating to the latest Intel drivers (despite vendors not certifying them). In the end of our research, we came to a horrible conclusion. Many of the older Intel integrated video cards did not have viable OpenGL 2.0 support. In fact, many did not have viable OpenGL 1.0 support.
As a developer, we hit a hard situation. We've spent our development budget (and then some) and we have a portion of our user base who can not enjoy the game they paid us money to play due to a driver issue. We have a solution in mind and we will be spending further, significant, development resources to re-write the entire rendering system for BG: EE around the missing functionality in the problematic drivers.
By talking with the Intel fellows, we've learned where we fall off the good path in their implementation and we have a new plan on how to re-build the entire system around those issues. This re-write is large in scope and is going to take us some time to accomplish, so we are relying on our fans for patience as we attempt to resolve the issue.
In retrospect, the big lesson learned is even if you have a lot of testers, you will not get good coverage of hardware. You might get good coverage of enthusiast hardware, but not all hardware. What we initially thought of as a few odd issues on very old hardware turned out to be much more prevalent than we thought was possible. As well, just because a specification is from 2004, and understood as an industry standard, does not mean there is good driver support.
We should have tested wider on hardware earlier. The diversity of the PC platform is a key strength, as it allows many vendors to create components and it creates competition, keeping prices low. This diversity also creates nightmares for developers, as there are always surprises when certain hardware configurations do not meet your assumed performance standard. I've been doing PC development since 1994 (yes, I am really old) and on every project there has been at least one major PC hardware issue. I look forward to the next PC issues as I would look forward to finding a cobra in my bed.
5. iOS 6
Late in development we started testing on the upcoming iOS 6 beta build. We're not 100 percent sure what was changed in the core iOS graphics code, but we took a massive hit in framerate on all iPads. The iPad 1 and iPad 3 became completely unplayable, less than a month from our contractually-amended ship date.
We quickly diverted most of our key programming effort to fixing the performance concerns. We fought a war between hurting the visual upscaling quality and improving the framerate. In the end we lost a lot of key developer time to a completely unplanned task. The end result was that a great deal of our bug-fixing time was spent not fixing the bugs we wanted, and the quality of the shipping build suffered. The lesson learned here is to build in some slack in terms of performance for when you need it due to an unplanned change, and to budget some extra time for periodic performance testing on current and beta OS releases.
In summary, BG: EE was defined by the product it is built upon and the hard, respectful work of a small and caring team. We could have done faster development work and we could have had fewer bugs by making sweeping changes, but early on we decided to adopt the role of curator. We didn't want to change Baldur's Gate just to show off our development skills and leave our mark; we wanted to make a great game even better and in the process, bring it to new platforms. With the great commercial and critical success so far, we're very anxious to continue to improve the game even more and bring our newly leveled-up skills to bear on Baldur's Gate 2: Enhanced Edition.