Cookies Disclaimer

I agree Our site saves small pieces of text information (cookies) on your device in order to authenticate logins, deliver better content and provide statistical analysis. You can adjust your browser settings to prevent our site from using cookies, but doing so will prevent some aspects of the site from functioning properly.

Programmed by Fellows with Compassion and Vision

We are almost halfway through our second milestone; the official halfway point is this Friday, when the team will present their work so far and discuss their trajectories for the second half of the current development period. It's really exciting to see so many threads starting to weave together to form the tapestry of the game. We are moving out of the mode of testing tools and defining processes, and into the real work of assembling the basic components of the game. This is a necessary and crucial step that needs to be completed before we can start tackling the really hard issues of game balance, features and options, and creating roadmaps for future development. The time invested now can pay big dividends in the future if we lay a strong foundation.

This is also one of the places where the development of the sandbox game starts to deviate from the development of a theme park game. At this point on a theme park project, the team would be really focused on making a suite of tools to build a huge amount of terrain, environments, NPCs, and monsters–the building blocks of the various dungeons, raids, zones, and other hand-crafted experiences that the players would be encountering. Since we're creating a sandbox game, we're focused right now on a game system, rather than a set of game objects.

Our Milestone 2 target is a first iteration of the escalation system–the skeletal framework of processes and procedures that will let the game create challenges in the form of monstrous incursions that force players to react. To reach this milestone, we have to implement not only the systems that spawn monsters and escalate their behavior, but we also have to lay the groundwork for how the players will react to their escalation—in other words, the basic combat system.

That means a lot of testing of core functionality. Testing implies making lots of small incremental changes. And small incremental changes can be the hobgoblin of development, potentially introducing all sorts of unintended consequences and hard-to-squash bugs. So, the team built a piece of technology to make it easier for the designers to introduce changes without forcing the engineering team to recompile the code.

This week, programmer Andrew Richter takes a look at how the designers' ideas get implemented in the actual game through the use of design tools.

Tools for Design

Thanks for the introduction, Ryan! A lot of the content you've seen on this blog has been from the art and design teams, so today I bring you something from the wonderful world of programming: design tools.

Tabletop games, just like MMOs, have an enormous amount of data. Just taking a brief stroll through Paizo's Pathfinder Reference Document can be a bit overwhelming. Not all of this information appears in Pathfinder Online, but plenty of it does. The problem with all of this data is how to get it into Pathfinder Online. And then, once it's in-game, how can we balance it?

I was tasked with devising a solution that worked well for both our designers and our programmers. Designers like using Excel, but Excel is not a viable means for supplying data directly to a game. Therefore, I created a tool which parses workbooks and converts them into usable game data. It then watches the Excel files for changes, and updates the data packages as necessary. This tool gives our designers the ability to update game data and have it processed in real time. It also allows our programmers to define how a sheet is parsed without needing to worry about strange Excel interactions.

After being packaged, Unity (our game engine) loads the data and supplies it to the necessary systems. Each system—combat, animation, AI, and so on—that is expecting data is automatically notified whenever data is loaded or reloaded. The game periodically checks for notices, keeping everything up-to-date.

Let's take a look at a simple example. Rogues are squishy, and when rogues stand face-to-face with fighters, they get carved up. One of the designers has an epiphany: "Hey, I think rogues shouldn't be so squishy. They would stand a better chance against fighters if they had 950 hit points instead of 870!" With the Excel workbook at hand, the designer proceeds to modify the base hit points of the rogue class in Excel. Our Excel-Unity export tool picks up this change, and the updated value appears in-game so the designer can then immediately test and see whether the assumption was valid.

Here's how that process looks for my favorite character (please keep in mind that this is sample data only!)

(Please note this is strictly a design tool. This is not an intended system for our production environment. We will not be manipulating data like evil masterminds in real time as real players are running around killing each other. Probably.)

Creating the right design tools is an important support step in game development that helps each department work as efficiently as possible. Giving our designers the ability to work in Excel and our programmers the ability to easily parse that work has already simplified our data management. With our small team and expedited timeline, tools like this are a necessity. I hope you've enjoyed this look at some of our behind-the-scenes effort to build a great game!

Discuss this blog on