This is why I don't like Mines

I'll wait a second while everyone absorbs that screen shot. Just click it and look at it in full size. still waiting... You got it? So yeah, that's a game of Mines (that's minesweeper if you use windows) that I just finished. 99 mines, time is 5:12. That's pretty awesome. Except that I messed up on the last mine. Those who are familiar with Mines will see, though, that the square I picked is equally as valid as the other one. I did not lose due to a logic error, but merely because I was forced to guess.

And that just bothers me. I like Mines because it is a simple logic game that does not take much mind power to solve but does require some thinking. The problem with it is that most of the games I play end up requiring some guessing to finish. This is frustrating. One guess reduces your chances of winning to a mere 5o percent, due to no fault on your part.

Which makes me wonder, is it possible to generate minefields which are ensured to be solvable without guessing? How expensive is that?

pygame: decoupling rendering from game logic

The basic execution profile of any computer game almost always looks basically the same. The devil is in the details, of course, but the basics are always like this:

• listen to user input, change game data appropriately
• update game objects (move objects, do collision detection, etc.)
• render world to the screen
  

rinse and repeat that as fast as possible, and you have a game. However, there is a subtle problem with this approach. On faster computers, the game will run faster. If this seems desirable to you, think about networked games. Do we really want those fast computers to slow down just for the slow ones? and how exactly would we do that? And what about scenes that are harder to render? do we have to slow the game down just for that?

We can see that it is, therefore, desirable to make your game run at the same speed no matter what happens. With one caveat: We always want to render as many frames as we possibly can. More frames is a smoother experience, after all.

So we can see that it is in our interest to decouple the game logic updates from the rendering. The rendering should then proceed as fast as possible, but the game logic should proceed at a constant rate regardless of the frame rate.

The right way to do this, of course, is to look at the clock. First we must decide how many logic updates we want to do per second. For most games, about 20 to 25 will suffice. So the time between to updates should be 1/25 seconds. Then, every pass through the rendering loop (which still runs as fast as possible) we check to see how much time has passed, and, only if it is necessary, we make an update to the game. Then we proceed with rendering. If the update is skipped, we need the renderer to interpolate between the two logic updates, so that it does not just render the same world multiple times. This will result in a smoother game experience for fast computers, but will not slow down the game on the slower, older hardware.

in my gunge framework, there is a new Clock class in the experimental branch time-exp that handles this transparently for you. It watches over two things: real time, which advances continuously, and game time, which can be advanced by 1/(updates_per_second) by updating the game. It is worthy to note how game time advances in discrete units, since the game world is updated in steps every iteration of the main loop.

To decide whether the game should update, the Clock has the concept of game latency, or how far game time lags behind the real time. The continuously advancing real time increases the game latency, and it is decreased when the game updates, by 1/(updates_per_second). There are two strategies for deciding when to update the game:

• game_latency > 1/(updates_per_second) -- this updates the game if the latency lags behind more than one update_length
• |game_latency - update_length| < |game_latency| -- this updates if it reduces the absolute value of the latency, i.e. if the game time comes closer to real time because of the update.

The caveat of the second method is that it allows game time to be ahead of real time, with the advantage that this may allow the game time to get closer to the real time than it could if it must always lag behind. Another disadvantage of the second method is that it becomes harder to calculate the interpolation factor for renders, but it allows for updates at times when the first method must helplessly fall further behind real time.

“There is nothing wrong with change, if it is in the right direction”

So, the new semester's started, and there's some changes coming this way. First off, I'm moving out, away from the host family I've been staying with, and into to the dorms. This is at the same time a sad and happy tiding, but I believe it to be a necessary and good step in my program. Betty and I discovered that my social life was gravitating away from her house and in to the dorms. In short, I figured I was spending so much time there I might as well get myself a bed. They are way more comfortable then the chairs I spent nights in, in rooms not my own.

I haven't been doing a whole lot of interesting stuff since California. Classes are progressing normally, Chinese is hard, my algebra class is ridiculously easy (come on people, linear equations? It's a flashback to year one of my Vossius career), but getting more interesting every class. On the free time side of things, there's the regular multi player starcraft sessions like always (needless to say, I can kick the asses of a lot, but not everyone in the dorms. Ulukman is like a machine, unbelievable). Also, I've started to play the old Diablo games in anticipation of Diablo 3. While the original will get old in a matter of minutes, Diablo 2 is definitely a time-sucker. I recommend it to anyone who wants to play a good old hack-n-slasher.

The other thing soaking up my time (what I have left after taking off my social life) is Stargate: Atlantis. I have come into the possession of all five seasons of this sci-fi show. I watched the older Stargate: SG-1 a few years ago, and it was pretty good. Atlantis is a step up, however. I can recommend this series to anyone who is lamenting the absence of new, good star trek shows, and also fans of sci-fi in general. This is stuff worth watching.

So, tomorrow is move day. I do not know my room yet, but my roommate will most likely be Kersten, who is also moving out of Betty's house. We will still visit them of course, and call regularly. But it'll be a new and exciting semester.

Today's quote is from Winston Churchill. Couldn't find anything better, sorry.

Adventures in Mario Kart

This image (courtesy of xkcd.com) originally dates back to Mario Kart: Double Dash, for the gamecube, But I have found that it applies equally well to the new Wii version of the game. I must confess that they have made this new game a lot harder, and that's not just the controls.

This makes the game a lot more challenging and fun, but also a huge frustration to play. The wii's wrist strap is actually a good measure to have, 'cause I had the urge to throw my remote against the wall several times today, after being pounded with red shields and squashed by giant bikes over and over, pushing me all the way back to last place right before the finish line.

Nevertheless, there is something about the game that just makes you want to keep on playing. Despite the back- and neckaches I've been having (My TV is positioned too low) I've been playing it pretty much non stop for the past few days, cursing, swearing, and generally having a good time. I just completed 150cc this afternoon, and now all that's left is mirror mode and of course the delicious online. It's more than enough to keep me busy for a long time, at least until super smash brothers finally arrives (why the hell that game is not out in europe is beyond me). And of course I'll be playing this with my brother and sister for months to come (just like with the last mario kart).