Monday, October 15, 2012

Gridiron Solitaire #25

For the first time last week, I think I understood what happens in a beta test.

I worked for a long time to make the game end-to-end playable. It was a big moment the first time I could play a season, go through the off-season, and keep playing.

Let's call that the "trying to make it work" phase.

Now, though, people are playing the game with a goal not of getting it to work, but to break it.  So this is the "trying to break it" phase. People (thank goodness) are trying all kinds of things it never would have crossed my mind to try, and some of these things break the game.

Plus, there's the downright strange stuff.

One of the very best testers is from Germany, and he has consistently reported a problem with the options file, which is a comma delimited .txt file that saves different values, including sound effect and music volume. None of his changes to the volume controls saved properly, though, and sometimes making changes would cause the game to crash the next time he loaded.

He sent me his options.txt file, and I immediately noticed that there was one field too many. And there was absolutely no code that would write a value to the file in that manner.

I finally remembered that European versions of Windows  handle decimal points differently. So in the "American" Windows, "0.2175", for example, is a single value in a comma-delimited file. However, in some other versions of Windows, that value would be written "0,2175" because decimal points are replaced with commas.

Well, that kind of entry will blow up a comma delimited file, so I have to convert the decimal value to an integer (basically, just converting the number to a string, removing the "0." in the front, then converting the remaining string to an integer), then "rebuild" the decimal value when the file loads (reversing the process). That should work fine, but it's a good example of something I would never have found on my own.

Now that testers are getting to the offseason mini-game, it's become apparent that the AI just isn't robust enough. I specifically avoided writing playcalling AI that would adapt to the user during a season game, because if someone wants to run on every play, I'm fine with that. The playcalling AI is robust enough that it will still have a solid percentage of correct playcalls.

However, I want the offseason to be different.

Here's what I'm in the process of doing. If the user wins more than 10 games in the regular-season, the offseason AI will look at their season stats, determine the most dominant aspect of their team, and adjust the chances of the CPU improving the rating that will counter that style.

That's supposed to model the NFL. If a team in the NFL has a unique style, no one cares unless they're good. So if some crazy offense is going 2-14, no one cares. But if that same team went 14-2, other teams would start drafting guys to counter, and they would adjust their schemes as well.

Let's go back to the guy who runs on every play. He went 13-2 in the regular season. 95% of his yards on offense are from running plays. Because of that, the chances of teams trying to improve their running defense is significantly higher than it would be otherwise.

So if you come up with an unbalanced scheme that works, that's great, but in the offseason, teams are going to adjust, and it's going to be a struggle to continue that way.

For those of you who are in the second wave of beta testers, it's going to be delayed for 2-3 weeks. There's no point in getting you guys involved when I have so many items outstanding from the first group, because you're going to notice the same things, and overlap is a waste of your time. I'm going to fix everything from this group of testers first, and you'll both have a better experience and be finding different issues than they did.

Site Meter