In this lecture, we'll talk about game configuration data files. So files that hold information about how the gameplay works? Here's our problem. Our problem is that we want game designers, not programmers necessarily, but game designers to be able to tune our game. You should go do an in-video quiz about that before we continue. So we really don't want game designers to be touching our source code. We want them to be able to tune the game without actually firing up mono developer visual studio to do it. So the solution to this particular problem is to store that game configuration data into files, and that makes it so the game designers can tune the game. And it also makes it, so that we can release tuning patches for our games as necessary without releasing sort of the whole, full version of the game. In Peak Game Studios and in Burning Teddy, we have used a couple of different file format for our gaming configuration data. So the first format that we've used is comma-separated value or CSV files. The benefit to using CSV files is, you can just export them from spreadsheets. So people are pretty comfortable with dealing with spreadsheet, and you can just fill in the game configuration data in the spreadsheet in multiple worksheets if necessary. And then export those as CSV files. The downside of using CSV files, is that it's hard to read the raw data file. And you might think, well, that doesn't matter, the computer is going to read it. But you'd be surprised how many time you might want to actually go look at the actual file to see the configuration data in it. The other kind of file that we've used is extensible markup language or XML files, and it's nice because it's easy to read the raw file. But it's really necessary to write a tool that will let people edit those XML files, rather than having them modify the raw XML files, because it's to get rid of one of the less than and greater than signs and suddenly you've crashed everything. So having a separate tool is a good idea, so you should go do an in-video quiz about XML. And now we should go look at a couple of the game configuration data files that we've used in our commercial games. This is the configuration data file for the game I'm currently working on called Balloons Extreme. And as you can see down here at the bottom, I have a number of different worksheets within my spreadsheet. And I'll have a medium level configuration data and a hard level configuration data sheet when I'm done as well. The big idea is that I just fill out the spreadsheet with tuning values and save it as a CSV. And in fact, I will save each of these sheets as a separate CSV that I process within my game. The game configuration data at this point just contains how many levels there are, and there are two for my development testing. I do have a separate sheet that describe or will describe each of the data value, so that someone who is using this sheet knows what these numbers mean. The easy level configuration data has more information like, how many second each level will be? What the maximum number of balloons will be in the level? How much damage those balloons inflict on the player? And the playfield screen width and height percentages. So as we make the playfield wider, that makes it harder. I guess I should tell you the point of the game is that you drive this arrow shooting vehicle around, and you're keeping balloons in the air by shooting bursts of air. So the wider the playfield is, the harder that is to do, because there's more area you need to cover. And the less tall the playfield is, the harder it is because you have less time to shoot air at a balloon before it hits the floor, at which point it destroys and damages you, and so on. This other configuration data file I'm showing you is from a game called Battle Paddles, which Peak Game Studios almost finished before we shutdown the company. And I am in the process, the long term process of converting this to a Unity game, but I already know what the configuration data looks like and there are lots of pieces of configuration data. This is an XML file. So I have formatted this, so that someone who wants to edit this XML file knows what each of these values means. This is a comment and it tells the valid range. And so, somebody could in fact, manually edit this XML file in practice before we distribute the game. We will probably build a tool that makes it easier to edit this, without actually having to go edit the raw XML, but there are many, many values in this file. So those are two examples of game configuration data files. One of those is CSV files that we can export from a spreadsheet, which lots of people are comfortable with manipulating. And the other one is this XML file, which is just another mechanism for capturing game configuration data that we can import and use in our game. I used to use XML files much more commonly. And I have started moving to comma separated value files just because people are more familiar with manipulating spreadsheets. And for both of these games, we'll distribute the games with the game configuration data editable, so that players can mess around with it and see what happens to gameplay when they play with the values in the game configuration data file. To recap, we've learned that we can use game configuration data files, so that game designers don't have to touch source code to tune our games. And that also enables us to release tuning patches. Another thing it actually let's do, is let the players mess around with that game configuration data to explore how that changes gameplay. Given that, I'm personally moving from XML files to CSV files, but there are many other possibilities, as well. But sort of persisting that game configuration data somewhere outside of source code is the big idea. Of course, both of the formats I've discussed today, the player can easily go modify them and that's by design from my perspective. But if you want to game configuration data that the player can't change in any way, then you need to use some other format, so that it's not obvious from the raw text in the file what that data is.