Since 8 hours really isn’t a lot of time to build a game, I did a bit of prep work the night before by building a set of blank playing cards to use as templates. The design is based on the layout of cards from Dominion, with a card name across the top, a short description across the bottom, and the rest of the space divided evenly between a picture and long description.

I printed the templates on white 199 g/m^2 card stock from the local office supply store and cut out 216 blank cards by hand. Real playing cards seem to be a bit heavier (around 320 g/m^2), but the card stock seemed to work well enough for prototyping purposes. I also used a set of card protectors usually used by Magic players to make it easier to handle and shuffle my home made cards. It also prevented players from seeing what their opponent was holding, since the thin cards are slightly transparent.

Before creating any cards, I wrote a bit of python code that would let me simulate my card game, so that I could try and make sure the game was fair. The contents of the card game are defined in a separate JSON file, which I was hoping would let me reuse the python code for future card game design work, but I ended up writing so much game-specific code into the python that it’s not really feasable to reuse it.

If you’re interested in building your own version of Monster Mages, you can get a deck list and rules from the project’s github page.

Winter-een-mas is a holiday for gamers, spanning from January 25th through the 31st, and celebrated by spending time playing games with friends and family. We hope you’ll join us for this free event – featuring twelve hours of gaming goodness – playing classics from Settlers of Catan to Halo.

There’s a rule of thumb in the hackerspace community – hold your open house on Tuesday. It’s completely arbitrary. No matter what day of the week you do pick for your open house, there will be someone who just can’t make it. Many just pick Tuesday by convention and no more thought is needed. Unfortunately, it makes it hard to visit other spaces since members generally want to be at home base for the open house. But since I was out of town with no hopes of making it to Kwartzlab, I had a perfect excuse to take a Tuesday to visit Hacklab.to.

Tucked away between two shops in the north end of Kensington Market, it’s an easy place to miss. It’s one of those mysterious doorways in the city that appeals to my inner child (who has a love of the paranormal, secret passageways and hidden worlds). Whose door is it? What’s behind it? There are a few clues that suggest there’s something more to 170 Baldwin Street. A simplex push-button lock and RFID reader guard the door while an infrared LED-lined camera provides overwatch.

I arrived just after 7 to a full house. Rent in the big city isn’t cheap and space is at a premium, meaning seats at the main work table fill up fast. At less than 500 square feet, Hacklab isn’t a space for manufacturing big things, either. They’re much closer to the stereotypical description of “hacker” than most of the other spaces I’ve visited, with a strong emphasis on electronics, software, and information security. But even with the limited floor space, there’s still a wide variety of projects going on. A model railroad hangs from the ceiling. A box of locks for locksport enthusiasts can be found in the lounge. There’s even an ’80s Mac Classic hanging out in a closet.

At 3 years old, Hacklab.to is the oldest hackerspace in Canada. In the big picture that’s not a long time, but it’s long enough that Hacklab can claim at least partial credit in helping establish a few other hackerspaces in the province such as Site 3 and Kwartzlab. Being the first, they’ve also been able to attract some media attention from places like BoingBoing and Discovery Channel.

Hacklab has a number of great tools available to the membership. A workbench constructed over the bathtub holds an Epilog ULS (my bad) laser cutter – a cheap craigslist find that some lab members brough back to life with extensive hardware and software rebuilding. A tricked-out Makerbot 3D printer lives on a shelf near the main work table, and evidence of it’s capabilities cover the short wall next to the stairs.

In addition to the oddles of thermoplastic gizmos and doodads next to the stairs, there are member projects scattered everywhere in the space. One of my favourites was a touch-screen computer hanging on a central support near the main work table. The display oozed with data and information, such as the date and time, and news feeds. Other mostly complete projects seem to collect on any available flat space. It’s not clutter – they’re evidence of learning and education. For many, hacking isn’t about the end product, it’s what you learn on the way. These leftovers, then, are trophies of accomplishment. Of conquering the unknown.

Hacklab.to is located at 170 Baldwin Street in Toronto, Ontario. They run an open house on Tuesday from 5:30 PM to 11:00 PM every week.

I remember reading an amazing article in National Geographic back in the early ’90s about lightning. There were a handful of brilliant photographs, but the one that really grabbed me was a night shot overlooking a city as a storm front moved in, capturing 30 or more forks of lightning over a 30-second exposure. I’m no photographer (as I am happy to admit at every available opportunity), but when I saw an incredible storm front moving in on the evening of the 24th, I couldn’t resist trying to create some of my own photographs of lightning.

I grabbed my camera and tripod and set up for a simple 5 second exposure under the cover of the patio. It became obvious pretty quick that this wasn’t going to work. With the storm already on top of me, any forks (sparks?) that found their way out of the clouds were illuminating the whole area, leaving a washed-out, white mess.

I dropped to 3 seconds, but it was still too long. Though it was interesting to see how the lighting on the treeline changed depending on whether the lightning was happening behind me or in front of me.

Eventually, I set the exposure time for 1 second and managed to catch my first clear spark.

But with a 1 second exposure, it became much harder to capture lightning. I couldn’t just pull the trigger and wait anymore. Well, I could, but the chances of actually capturing anything in that time was pretty low. And even when I did, things were still getting washed out.

So I finally tried a half second exposure, and that seemed to get some decent results.

By this point I had taken about 260 pictures and filled up my SD card. With only 1 or 2 worth showing by this point, I had developed a much greater appreciation for the quality of the pictures on the Wikipedia page for lightning.

I dumped the card to my laptop and ran outside with an umbrella to see if I could get some pictures with fewer trees in the way. The lightning at this point was incredible. I could tell when a good one was coming because it would start from behind me, lighting up the trees. Then, from a hole in the clouds, tendrils of lightning burst through, like the tentacles of an octopus, and spread out in a circular pattern, crawling and dancing along the bottom surface of the clouds, spreading out like the spokes on a bicycle wheel.

Thinking back to that National Geographic article and comparing it with my experiences during this storm, I’ve got some clues to improve my pictures for the next time. First, I need to get up to a higher spot of ground so that I can get clearer pictures of the sky with fewer obstructions. I’m not going to go stand on a bare hill with my metal tripod of anything, but something like an apartment balcony would be great.

Second, it seems that once the storm is on top of me, it’s going to be a lot harder to get a good picture. I should set up so that I can get a clear shot of the front as it approaches. There are a couple of advantages to this – shots from further away won’t light up the entire sky as much, making it easier to capture clear pictures of lightning. It’ll also keep me ahead of the rain, and safer from the sky.

Finally, I really need to learn how to work my camera properly. At one point I managed to mess up the focus meaning there’s a series of 3 to 4 shots that are pretty blurry. I was also shooting in shutter priority mode on the D40. I believe there is a way to get control over both the aperature and shutter speed at the same time, but I’m not sure how. I think a smaller aperature would have let me do much longer exposures without having the whole scene washed out. But then again, with the reflections due to the clouds, it may not have helped that much. More experimentation is needed.

I’ve been having some trouble with my Lenovo T400 laptop recently. When under a heavy load, such as playing a game or watching a full-screen video on YouTube, the computer would spontaneously shut down without warning. I finally got fed up when it happened while playing a game, causing the saved game to become corrupted and losing several hours of progress.

I had seen these kinds of spontaneous shutdowns before on a desktop, which I eventually traced to an overheating graphics card, but had never seen this show up on a laptop before. Still, suspecting some overheating, I decided to investigate.

Some Background

The first thing I tried was turning off the video card to try and reduce the amount of heat inside. Since I can’t just remove the card like in a desktop machine, I found a BIOS setting that allowed me to disable the discrete graphics card and run the Intel integrated graphics only. I booted up and tried playing a game, but within 5 minutes the system had failed again.

The next thing I tried was running a program called HWMonitor from CPUID. HWMonitor collects all kinds of handy information about your computer, from the temperature of the CPU to the capacity of the battery, letting you quickly identify thermal issues on a machine. Running HWMonitor and starting a game, I saw the CPU temperature jump up from around 55 celsius to 86 celsius. Playing for a bit longer, I eventually saw the CPU temperature break the 90 degree mark.

Some additional background for people unfamiliar with heating issues in computers: The processor (CPU) in a modern computer is hot. Hot enough that if uncontrolled, the CPU could likely get hot enough to melt itself, if it weren’t for the built-in thermal protection circuits. Modern CPUs measure their temperature, and if things get hot enough to cause damage, will automatically shut itself down for safety. I don’t know what that threshold is, but from my previous experience with some overheating video cards, I’ve noticed that seems to happen around 90 degrees celsius.

Generally, CPUs are kept cool by attaching a big metal block (heat sink) to the processor. The metal block is shaped into fins, which increases the total surface area of the block, and allows the surrounding air to more easily absorb heat from the heat sink. Usually there will also be a fan that continuously blow the warm air away from the heat sink, since cooler air is better at absorbing heat. In between the heat sink and the processor, a conducting putty (thermal compound) is used as a kind of seal to help the heat flow from the processor into the heat sink.

I suspected the cooling fan was not running at a proper speed. Normally, HWMonitor can measure the speed of a system fan in RPM, but it seems to be incompatible with the fan controller in the Lenovo T400. I blew some compressed air into the vent to try and clear out any dust, but it didn’t have a noticable effect. With nothing else to try, I decided to pull off the heat sink, clear off the crappy thermal compound that manufacturers like to use, and apply some high-quality Arctic Silver Ceramique, to see if that would help.

The Repair

I started by disconnecting the laptop from the A/C adapter and removing the battery for safety.

Disassembly of the T400 requires removing 5 screws from the underside. The 5 screws are labelled with pictures of the keyboard, trackpad, and/or memory.

I flipped the machine right-side-up, and pulled away the trackpad from the chassis.

With the trackpad removed, the keyboard lifts right up.

There is a ribbon cable connecting the keyboard to the main circuit board of the laptop. I disconnected it, and set the keyboard aside.

There is another ribbon cable connecting the trackpad to the main board. I pulled this one out as well, and set the trackpad with the keyboard.

The thin black plastic shield that covers the speakers and runs across the back of the laptop is held in by three screws, and some troublesome plastic clips. It needs to be carefully pried away from the chassis to remove it.

With the shield removed, the left speaker needs to be unscrewed (2 screws) to get full access to the heat sink assembly.

The heat sink assembly is held in by six screws in total – 4 around the CPU, 1 near the southbridge, and 1 above the GPU, near where the LCD connects to the circuit board. Minding the wires for the Bluetooth modem and antenna cables for wifi and GSM, the heat sink can now be lifted up and removed from the chassis, revealing the CPU, GPU, and southbridge.

In the above picture, the grey goo is thermal compound. You can see that it has oozed all over the CPU and GPU, meaning way too much compound was used. The compound that is on there is no good, so I removed it from both the heat sink and processors using isopropyl alcohol and a cotton swab. Cotton swabs aren’t ideal for this kind of work because they tend to leave little fibres behind, but I didn’t have anything else handy.

I removed all the old thermal compound, revealing the mirrored finish of the GPU.

Finally, I applied the Arctic Silver Ceramique to the processors. A good rule of thumb is to apply a blob of compound that is about the size of half a grain of cooked rice. I used a bit more on the southbridge to get good coverage. The goal is to cover as much of the metal as possible without having any compound ooze out the side.

I put everything back together, powered up, and booted into Windows. Checking HWMonitor, I saw that the CPU was sitting around 40 degrees celsius, meaning I hadn’t screwed up anything too badly. The next test was to try out a game. After a few hours, there was no crash, and the highest recorded CPU temperature was 60 degrees celsius. Mission accomplished!

JavaScript: The Good Parts by Douglas Crockford is a short, dense, humorless outline of a safe subset of JavaScript, targeted at programmers who already hang a few languages on their toolbelt and who find themselves curious about this newfangled “web programming” thing. This book is packed – packed – with key details on the many quirks and foibles of this less-than-perfect language, but ultimately misses its goal of being a strong first stop for new JavaScript developers.

At 100 pages (not including the rather informative appendicies) of 7″ by 9″, JavaScript: The Good Parts is the thinnest programming book in my library, which is commendable. Crockford, like a true coder, seems to have great skill at avoiding any verbal diahrrea throughout the book, resulting in a clean and clear presentation of pure data. However, this “only the facts” seems to trim away too much. For one, it’s completely dry. There is no humor to break up the information, meaning JavaScript: The Good Parts is about as entertaining as a 3-hour PowerPoint presentation on office procedures. But more importantly, the author spends little time elaborating on some of the key issues of the language, where I believe more detailed explainations would help with comprehension.

For example, I’m still a bit unclear about all the nuances of functions in the language. In JavaScript, functions are objects, and are created in function literals. But then there are function statements and function expressions thrown in as well, which have different meaning. There’s a heading devoted to each of these subjects, but the examples are so thin – 13 lines total across all these headings, with 5 of them being comments – that I’m still having trouble processing these terms and their differences.

One of the most frustrating oversights in this book is the lack of any look at the Document Object Model (DOM). There is no chapter, sub-heading, or even appendix discussing what the DOM is, or how to use it. I appreciate that Crockford was trying to show that JavaScript can be a beautiful language on its own without needing to depend on DOM modifications, but any serious web development with JavaScript depends on that API. Crockford writes in Chapter 1: “This book touches only very lightly on the DOM. I think writing a Good Parts book about the DOM would be extremely challenging,” which clearly demonstrates the author’s motives. This isn’t a book about practical applications of the language; it’s an academic look at its design features. Even though DOM manipulations are critical for web deveopment, Crockford appears to ignore them because they are not well designed.

In general, the examples presented in the book are anemic (even for variable names, which are often a single letter), and mostly only useful for getting syntax right. There are few in-depth examples that show how common design patterns would look in JavaScript. And without any reference to the DOM, most examples don’t even have a way to print anything to the screen. A few examples use document.writeln() to print some information, but too many examples end with a one-line comment explaining what the final output would be in theory. For example:

// Capture 3 digits within parens

var oldareacode = /\((\d{3})\)/g;
var p = '(555)666-1212'.replace(oldareacode, '$1-');
// p is '555-666-1212'

Examples rarely stand alone. It’s left up to the reader to craft more elaborate examples to experiment with the provided code snippits.

If these complaints have turned you off, then it’s because I’ve chosen to focus on the bad parts. The good parts of The Good Parts speak for themselves, which you can see when you read it for yourself (which you should do!). It may be thin, but it is heavy with great details, and generally presented in a clear, matter-of-fact voice that I wish more books would adopt. It’s the least expensive book on O’Reilly’s JavaScript bookshelf, and it’s over before you have a chance to get too bored with it, so there’s no reason not to add it to your library. But if you are looking to learn the language and begin applying it, make sure you pick up a companion book that discusses the DOM, and explains how to implement some common design pattern conventions in JavaScript.

A review copy of JavaScript: The Good Parts was provided by O’Reilly.

On Victoria Day Monday, I joined a handful of folks from the Hamilton hackerspace Think|haus in Mount Nemo to have a look at one of the leading location candidates for SoOnCamp 2012.

SoOnCamp will be an outdoor hacker meetup, modeled on the popular European hacker camps like the quadrennial Chaos Communication Camp held in Germany. The idea of hacking and camping is a curious juxtaposition, not only due to the classic stereotype of hackers living in unlit basements, but for more practical concerns as well. Our makerly society is largely dependant on the infrastructure of our cities, especially electricity and internet access – two utilities that are scarcely found in nature.

SoOnCamp, then, will be less like camping and more like Everest Base Camp. A temporary city, complete with utilities, infrastructure, and 1500 artists, makers, and hackers, plopped down in the middle of the Canadian wilderness.

The similarities between the European hacker camps and the famous Burning Man, as a vehicle for counter-culture community development and self-expression, are hard to ignore. But the hacker-centric events also bring a strong influence from information technology and small-scale manufacturing. At mini Maker Faire Toronto, I noted how strange it was that 3D printers have become so popular and widespread in the hacker community that they outnumbered traditional printers (in fact, I didn’t see any paper printers at the event). Even stranger it will be, then, to see these production capabilities in the middle of nowhere, Canada, churning out ABS knick-knacks in SoOnCamp’s prototyping building.

SoOnCamp takes place July 5 through 9, 2012. Tickets, when they go on sale, are expected to cost $200 for the 5 day event. If you’re interested in helping make SoOnCamp a reality, check out the SoOnCamp wiki.

On April 21, a delegation from Kwartzlab made the trek to Toronto to check out fellow hackerspace Site 3 – and in particular their laser cutter!

The ground floor of Site 3 is dedicated mostly to a large, open workshop filled with big tools and large, well-lit workspaces.

The electronics workbench has a few Weller WES-51 soldering stations and a Madell bench power supply, all set up and ready to go. There’s also convenient access to parts bins right from the work space. The only thing missing is an ESD-safe table surface.

In the back corner sits a Makerbot 3D printer, hiding on a shelf and surrounded by little knick-knacks that have been printed out on it. But as Seth Hardy, one of the founders of Site 3 tells us: “A Makerbot isn’t a tool, it’s a project. You buy a Makerbot to spend time fixing a Makerbot, and contributing to the open source 3D printing world.” I’m paraphrasing a bit, but that’s the jist.

And here’s the reason we came. Gus gets a lesson on the operation of the Site 3 laser. This unit was purchased from China for about $4000, all in, including a bunch of extra parts to replace pieces that wear out. The total cost of ownership for one of these units comes in at less than half of one of Epilog’s entry-level “Zing” units, and Site 3 is quite happy with both the unit’s performance and the supplier’s customer support.

The laser in action.

Before using the laser, members and guests are required to take a training course on the proper use of the machine. At the end of the course, students cut out a sample image to demonstrate their knowledge – many of these samples are hung on the wall next to the laser.

By carefully adjusting the power settings, it’s even possible to etch a pattern into cloth or paper towel!

The upper level holds a clean workspace and lounge area for members. There’s also tons of storage space.

There was also a Portal 2 release party happening at the same time. All the computers and projectors were being dedicated to this awesome game! And… is that cake?

Yep, there’s cake. No lie. As Darcy has shown at the Ubuntu release parties hosted by Kwartzlab, you can’t have a release party without cake.

It wouldn’t be Site 3 if there wasn’t some kind of fire effects going on.

With that key change in mind, we set out our goals for Day 9:

• Get the in-game targeting system running for targeted spells
• Create some textures for the player, enemies, and items
• Develop a particle system to show spell effects
• Complete as many cool spells and abilities as possible
• Make some effort to balance the game (currently too easy)

Much of the targeting system was fairly straight forward. Thanks to the code cleanup I had done over the past few days, taking control of the camera independant of the player was pretty quick, and Ryan’s code for managing input was easy to tie into.

Textures were a bit more challenging. I created a texture for a stone wall using The GIMP, but once I got it into the game, I noticed that it looked muddy when we weren’t up close. I’m not an artist, so it is unfortunately probably the best we can hope for. When it came time to do textures for the player and enemies, we were getting close to midnight. Instead of creating them myself, I found a Creative Commons licensed texture set on Deviantart, and did a little bit of tweaking. I only created one texture for the enemies, but we got some colour variation in them by assigning them a randomly coloured material in OpenGL to tint them.

I also created a mesh for stairs – in the game, a set of stairs takes to up to a fresh batch of more skilled enemies. I defined the verticies of the mesh by hand since that was faster than creating them in a 3D modeling program and writing an importer for a file format like OBJ (though on reflection, I could have used the STL loading code from my 3dc project).

Ryan was able to get a handful of new skills implemented, such as drain life, eagle eye, cripple, and haste.

After finishing up those skills, Ryan moved on to some basic game balance. He started by decreasing the amount of health the player starts with – we originally had inflated it to help with testing. He also decreased the chance that a health potion will drop from 100% to around 10%, since they were far too easy to aquire. Around this time, he also implemented an leveling and experience system. For every enemy that the player kills, they get a small amount of experience points. When they get enough points, they gain a new level, which increases their basic attributes and refreshes their health and mana.

Day 9 is over, and so is our little experiment. It’s been a great nine days, and I learned a lot. I’d even consider doing it again, though I don’t think I would do it from scratch. It’s a great way to learn, but if the goal is to build something awesome, I think it’s better to start with at least a simple 3D engine. But these discussions are best saved for our wrap-up blog post – stay tuned for that!

Finally, here are links to the Linux binaries and the GitHub repository.

• Finally finish up the in game menu system
• Create the options and home screens
• Add the ability to target locations for spells
• Add some new spells to show off targetting
• Add some different dungeon features, like doors (time permitting)

I am happy to say I finally got around to doing that in-game menu system for item management. That’s been on the to-do list for so long it’s embarassing; but it’s done now, and I can move on to other things. We decided to cancel work on the options and home screens. We’re in a huge time crunch for Day 9, and we’ve decided to switch gears and get back to focusing on building really cool, educational stuff. Windows and screens need not apply!

Ryan had great success in developing new skills and the targeting system on the ASCII side of things. Complementing the spin attack, we now have: precise strike, giant swing, flaming hands, and heal. He also threw together this demo video of the new skills:

I also revised our design doc a bit, to account for the amount of remaining time. I cut out a lot of features that we won’t have time to add. I also added in a bunch of new text to describe in more detail some of the features we have already added. Better late than never, I guess?

Design Doc, Day 8