Clear, Simple & Wrong

I had to buy a new WLAN adapter, and after a bit of searching I settled on the D-Link DWA-140 because of its seemingly good Linux support. When the package finally arrived, to my dismay it wasn’t recognized by Ubuntu at all.

I tried to install the latest Ralink drivers, but it took a lot of fighting before they even recognized the adapter, and even then I couldn’t see any networks in NetworkManager. I finally got the card working by installing the Windows drivers for the DWA-140 with ndiswrapper, but that solution wasn’t without problems either: ndiswrapper kept crashing several times a day, leaving me no choice but to reboot to get back online.

The time I spent trying to get the Ralink drivers working wasn’t completely wasted, though. I found out that the problem with the stock drivers that ship with Ubuntu was that they were missing the USB device and vendor IDs for the DWA-140; Ubuntu had a driver for the adapter, but the driver didn’t know that it supports the device I had just plugged in.

Today I stumbled across a post on the Ubuntu Forums explaining how to add the IDs to the driver. Just follow the instructions, but use 07D1 3C0A instead of 1737 0078 (the instructions are for another adapter), and, if all goes well, you’ll have your DWA-140 working in no time.

Brian Carper wrote a very interesting blog post about his RPG written in Clojure. I’m hoping to write a game in Clojure myself (once I feel confident enough with Lispy functional programming) so I will keep a close eye on what will hopefully become a series of blog posts.

Here’s the comment I posted on his blog:

Thank you for writing this post! It’s interesting to see a game developed in a functional language, as at their core games are all about updating a huge blob of global state—the virtual world. Trying to break a game into (purely) functional pieces seems to be quite a challenge for programmers used to thinking in Object-Oriented terms. To make the culture shock even worse, many game concepts map very naturally to OO: you have a Player collecting Items into an Inventory and so on, so the temptation to write Java in Clojure is great for newbies like me.

Here are a few thoughts I had while reading this post (don’t take them as criticism—they just popped in my mind and I thought I’d share them):

• Sleeping 10 ms each frame makes the game run slower, but the duration of each frame, and thus the timestep of your simulation, is unpredictable. If you sleep just enough to make each frame take 1/60 s (capping your framerate to 60 FPS), many things become slightly cheaper and easier; for example, your characters can move at the fixed speed of n pixels per frame, you can advance the animations by a fixed amount of frames per update, etc.

• The term “map” has quite a lot of meanings in your codebase: the function, the data structure, and the set of tiles in the world. And I assume that at some point your player might even find a map of a dungeon. To avoid confusion, it might be good to distinguish between the meanings by using names like “hash maps”, “tile maps” and “map items” in comments and documents.

• I don’t think that threading the whole world through your functions is a good idea. It’s almost equivalent to storing everything in global variables that any function can modify. I think it would be better to only give each function just enough of the world as several explicit arguments, and then explicitly merge the result with the previous state of the world with assoc-in or update-in.

• Even though it’s still WIP, and written for C++, you might find the book Game Programming Patterns interesting. If nothing else, it gives you a glimpse into the way pros think about game development (AFAIK, the author works for EA).

Good luck with the project, and please do keep us updated as your game progresses!

—
Timo

Move along, there’s nothing to see here (yet)!