Educational Games

We got our new clients for the next four weeks today.

As promised, Bob Roemer came in and wanted a game about Thermodynamics. This is a hard problem, and there are a lot more issues with creating a game that requires calculations than I had thought before I came into the EAE program.

First, mandating that a game requires calculation presents problems. The biggest problem is that requiring calculations is essentially game-ified story problems that are presented slightly more fun than just beating your head against a calculator. This problem leads to the second problem, which is that no matter how you present them, story problems about thermodynamics aren't fun. At all.

Now we're stuck holding the bill of a game that is doomed to be marginally fun at best, but this seems to be the fate of almost every one of the mechanical engineering presenters that we had today. This isn't surprising. Coming from a mechanical engineering background, I'm sure that they gave us as many constraints as possible to help guide us to the kind of thing that they wanted. This was intended to help, I'm positive, but the result is several already finished products that basically need some better art slapped on top of them. Despite their best intentions, the practically finished game concepts that we've been told we can't work out of are already not fun.

On the positive side, these games don't require being as inherently fun as the Beehive Cheese game, say. People won't be playing any of these educational games for fun, they'll be playing the games because it's part of their homework. This additional incentive means that we don't have to make the games fun enough to want to keep playing for the sake of playing, but requiring calculations is still a remarkably limiting factor.

There are positive approaches to requiring calculation. I feel that games that would be optimized with calculation should start off in a ballpark estimate that tends to work. As difficulty increases, the allowable tolerances for acceptable answers would decrease so that the player could either spend several dozen tries trying to get the exact answer or simply try to calculate the exact answer by hand. This concept of "if I were clever enough to eyeball this I could do it" makes the player feel like they're *choosing* to calculate, which in reality is the only feasible solution to the problem. I think this would be a great way to ease students into a calculation-intense game.

Dry Runs

We just got finished with dry run presentations today.

This past week we've been working to get our game working, and its surprising how accelerated game development becomes when youre familiar with the language. I'm not terribly excited to move on to another language because I finally feel like I'm understanding MOAI, but having a language with *any* documentation should be a lot better. Starting over from square one with a new language won't be exciting.

AJ presented and everyone ripped his presentation style apart, which I didn't totally agree with. It's true, he could have more eye contact, but I really think that his enthusiasm outshines every other producer that presented. Its the kind of presentation I would have given--with less eye contact.

I'm excited to see what Katie says when she gets here. I think that our game has nailed the demographic game style more than any other game--fun instantly, infinite replayability, and almost mindless control (the kind that you can play in a grocery store line). This should be pretty good.

I don't know if I'm allowed to go onto tangents on this blog, but recently story in games has approached the forefront of my musings. With Laurie's fascination with minecraft and the player-generated stories that crop up and Dad's fabrication of several religions on the private server, I really think that deep, interesting story is the key to making a complex game enjoyable and satisfying. I'll keep thinking about this.

PAX and MOAI pounding

I think I may have forgotten to post last week.

Whether or not this blog is supposed to be exclusively about game development, I can't sit idly and not mention my incredible trip to PAX this past weekend. Seeing game development through the eyes of a future programmer makes things that much more exciting. I'm definitely in the right place.

Earlier today we met to combine code for the different things that we've been working on. Chris pointed out a boolean condition to the mouseUp/mouseDown detection problem (namely, swap the boolean upon lifting or pressing the mouse only) and things are going really smoothly. Jason's collision code merged with my flight and background code without any trouble at all.

Sherly is doing a whole lot with the menus and is currently writing code to save a high score to a file and retrieve it. It seems like every time we get together, we always make progress. It's slow, and the lack of documentation on MOAI makes it difficult, but there are examples to work from. I've completely stopped trying to find documentation in lieu of just mucking through already working examples, and even half of those are obsolete due to how new MOAI is. Its very frustrating, but we're making it work.

The intro to C++ programming relies heavily on tortoise SVN. It seems extremely useful, but I never seem to know if I'm using it the way that its supposed to be used. Almost every time I try to complete an assignment by uploading it to the repository I end by saying "Um.... I think that's what I was supposed to do...". Joe's teaching style is a little bit of a brain-dump, but I can't think of a concise way to criticize it. Once I figure out exactly what is difficult about his teaching style, I'll fill out a suggestion card. He's a really great guy, and I'm confident any suggestions I think up will benefit us both and he won't take it the wrong way.