I didn’t know much about data-driven design when I started working at FLS. Joe, our lead programmer, wrote a few articles on the subject from the programmer’s point of view. In a completely data-driven architecture, all tuning values are stored in human-readable files (INI, XML, TXT, etc). My job is almost entirely tuning right now, so I spent the past four months living with this system… and now I am going to tell you about that experience.

First of all, our game needs tuning. Lots of tuning. That’s true of any game that is approaching its release date. Tuning tasks are huge and time consuming because they are boundless. “Create 10 pieces of outfitting” is a straightforward task and it is easy to say that it is complete. “Ship Tuning” is a nebulous task that can go on forever. As the designer, I have to make painful decisions to say that tuning tasks are done even when I know there is more work to do, just so that I can move on to the next task. Then I gradually work through tuning different areas of the game until I end up back at that original task. This iterative process gives me more time to gather feedback and evaluate the impact of my changes, but it is still painful to stop a task when I have a long list of changes.

But that’s not what this is about. This is about data-driven design. See, most of the work I am doing would not be possible – or at least it would be much harder – without data driven design. I have just enough programming experience to understand simple code, but not enough to write code. With data-driven design, I can dig into the guts of our systems, tear them apart and then piece them back together without using up code time. I’ve done this to two major systems in our game: sailing and ship combat.

Sailing
Long before I joined the project, a concession was made that big ships would be slower than small ships. This isn’t historically accurate, but it was necessary for gameplay in order to make small ships useful. Unfortunately, this created two major problems in our game. 1) The more you leveled, the slower your ship got. 2) The biggest ships were so slow that they just weren’t fun to sail for most people. I wanted to change this, but I didn’t plan to change the general functionality of small ships being faster than big ships.

There are a few dozen stats on every ship that determines how it sails. We have numerous values for turning, speed, acceleration and deceleration. By the time I was looking into our sailing system, I had already done lots of ship tuning and I was familiar with how things worked. I wanted to make big ships faster without making them dominant, so I looked towards acceleration.

I spent several days changing every ship, adjusting the stats to make acceleration a major factor in performance. I experimented with different combinations of the values until they produced the results I wanted. Those changes have been in the beta for awhile, and I’m satisfied with the results enough to continue down this path. Now, the biggest ship is about twice as fast as it used to be but it takes longer to get started. There are added complexities (the good kind) in sailing some of the bigger ships because you need to manage your speed. Small ships will always be faster than the biggest ships, but a lot of that is gone. Frigates are faster now, and there are ships throughout the game that are fun to play for people who don’t want to sail a slug.

Ship Combat
When I spent time playing our game after joining the company, the most impressive part was the ship combat. It was fun and tactically interesting. Now I am heading the work on ship combat (a natural progression from working on ships) and things have changed. See, while our ship combat was fun, there were lots of problems. Most of these were tuning issues.

Range is a major component in damage. If you are point blank you do maximum damage, but if you are at maximum range you do about half damage. When a big chunk of my combat tuning changes hit testbed, we had ship combat emergencies. Everything was too slow. I came in to work and was told to look into it immediately. So, I played with the combat and found a bug: guns did maximum damage at maximum range and minimum damage at minimum range. It wasn’t a new bug. It had always been that way and nobody noticed. The reason nobody noticed is because our combat system was so poorly tuned. All fights took place at maximum range, where ships hit with entire volleys and quickly sank each other. I changed the way accuracy worked and I redid ship stats and cannons. Those changes hit at the same time as Isildur’s skill changes, and the combination of those made the damage bug painfully obvious. Combat was really, really slow. Fortunately we got that bug fixed and combat worked the way we intended.

Once things had time to stabilize, I was quite pleased with how much ship combat had changed. Sailing technique now has a major impact on fights. Timing your shots is important. All types of ships are useful in battle. Battles are more tactical and fun. Range and gun weight matter, but they are no longer the primary deciding factor in combat. We have ships to suit different play styles throughout the game.

Conclusion
I have to give props to Joe (data-driven design proponent), Heidi (the sailing dev) and Brady (the combat dev). With the way these systems are constructed, I was able to drastically alter both of them without touching the code. Sure, I often request code changes for new things to make combat better, but the core systems gave me all the control I needed to help shape our game. All I had to do was change a bunch of text files.

Okay, the truth is, I don’t live in a data-driven design world. I live in a spreadsheet. It’s not always the same spreadsheet, but there’s about a 95% probability that I’ll have one open at any given moment in the day. Hopefully, the next step in our architecture will allow me to modify things in a spreadsheet and export a text document directly into the game. Then I won’t usually need to touch the text files. What say you, Joe?