disruption.ca

The typical post to this blog is either a minor update about my life or a mention of the availability of some bit of code that I’ve been working on. This post I’m going to try something different. I’m going to ramble a bit about programing and a problem that is on my mind. You have been warned.

In my experience, when writing a game I end up with a lot of constants in my code that determine how the game plays. The values for these numbers are typically not derived by any sort of logical process, instead they arise through a guess and test process that is apparently known as tuning in the industry. I think that the quality of a game’s tuning is one of the major factors in determining if it is any fun. Of course I want to make my games more fun, so I come to the question of how do I improve my tuning?

Should I be more rigorous and put more effort into the logic of the numbers that I chose? To some extent I think that I should. It would be nice if I could look at the numbers in my code and actually understand roughly what they meant in terms of units that I use in the real world. With the extremely rapid game development environment that typically drives my projects, it is far to common that the numbers are pure magic. So I should work on that. But I think there are limits to the benefits of this approach. If I take it to it’s extreme, I’m trying to build physically accurate simulations. While good physics can be a lot of fun in a game, there is a big difference between a racing game and an accurate car simulator. I’m more interested in making a fun racing game.

How then, do I make game engine tuning more effective? I’ve been asking google this question and came across one very useful tip in a Gamasutra article on physics tuning (bugmenot required). Integrate live parameter tweaking into your game, so you can try different values as you play, without having to edit the source and restart. I picture a python object that I can somehow initialize with my constants, which would then allow me to tweak values live in game, and store the results back to a config file. All with minimal pain. I discussed this with Jay a bit, and he had some interesting input. He mentioned that while working on Steamrollers he sometimes would load a level, test it, back out to the menu, edit the engine source code, and then load the level again to see the changes, without ever fully exiting the program. As well, he thought that the place to interact with constant tuning would be the terminal window, not the main game window. This is contrary to my initial thoughts, but it makes a lot of sense.

So I want to use the terminal to interact with my running program, load changed source code on the fly, and test out tweaks to constants while I play the game. I think that this sort of dynamic program interaction is starting to sound a lot like what Lisp people talk about with the Lisp shell environment. Fortunately Python has it’s own shell, and it is apparently quite powerful. Ipython sounds interesting as well. The only downside is that I really don’t know how to use the tool effectively, or if it is even possible to do what I want within the framework of PyGame. So now I’m reading a lot about the Python shell. Or at least I was until the whim to update my blog hit me.

I’m quite intrigued by this path. It should be good to learn some more powerful tools than just the text editor. I keep reading about the power of Python’s introspective abilities. I hope that learning this sort of thing will make me a better programmer. I tend to focus too much on the power and ease of use of a language, and completely ignore any tools that could save me time or solve problems for me. I think that it’s time that I stop missing out. Or at least finally break the habit of using print statements instead of the debugger. Changing habits and learning new tricks will probably be a hard slog, but I’m enthusiastic. At least for the moment.

So hopefully with some research and some practice I’ll soon be tweaking my gameplay using all sorts of insane ninja Python dynamic language-Fu. Which should help make my games more fun. I hope. But I wonder. One of the problems that I encounter is that after a while I become too close to the code and it becomes very difficult to tell if the game is enjoyable to play. Fun and playability are a hard thing to judge. In fact I think there is another whole rambling bloggy essay in that last sentence alone. I’ll leave that for another day though, and try to stick with tuning.

What if I could test and measure the results of trying different game engine tunings? When Valve developed the first Half-Life they had playtesters play their levels. Valve recorded all sorts of useful statistics, and set up rules to tweak their level designs. If the numbers showed that players were going for long stretches without firing their weapons, monsters were added to relevant parts of the levels. If the players health was always very high or very low, the level difficulty was adjusted. If a player took a very long time to get past a puzzle, a hint might be added to make the puzzle less frustrating. If you want to know more, the details come from this Gamasutra article. (again, bugmenot is your friend.)

Unfortunately I’m never going to be able to do this sort of playtesting for a 48 hour game project. But I will have to spend some time thinking about the possibilities of having friends try my games, and getting usability information that would let me tune the game appropriately. Of course there is the standard feedback. “It would be better if you could move faster.” “I can’t control it.” “Your game sucks.” This sort of thing can be valuable and helpful. But what I would really like to see would be some numbers that pinpoint the problem areas. I just don’t know if it is doable in a general, reusable sort of way, or if I would have to write measuring tools on a case by case basis.

I don’t seem to be coming up with anything sensible at this point, and I’m getting tired, so I’m going to leave this thought here. Making a game measure the amount of fun it’s player is having seems to be a non-trivial problem.

So, this was a fun exercise from my point of view. I updated my blog. I enjoyed writing it. I explored some ideas that are on my mind. Fun. I might have to try this approach again. My only question is, how does it read?