About a week ago, Camilla, a true connoisseur of mathematical puzzle games, showed me her latest find, a planar mesh untangling Flash game, Planarity. I managed to kill a few hours with it before hitting a brick wall: It's slow and eventually trips Flash's runaway code detector. Apparently, on most systems, Flash pops a dialog along the lines of "abort this script?" with "yes" and "no" buttons. Under linux, it only offers "OK". How annoying.
The author is still actively developing the game and has made a number of improvements over the past week. However, the fatal timer problem is still there.
For a few months now, I've been looking for an excuse to play with Gtk's new direction: the Cairo vector graphics system. Gtk has integrated Cairo as of 2.7, and all the backend drawing in this new generation is Cairo based. I've got a widget theme I want to implement for Postfish, and Gtk+/Cairo looks like a good fit.
The only way to really learn a new system is to use it, and I don't want to jump into Postfish as the first project. A vector-graphics based game concept I want to clone and a new vector UI toolkit I want to learn looks like the perfect code storm. I haven't actually written anything completely new in a while, so something quick and constrained feels rather good.
The math behind the original Planarity is pretty simple (and no, there's nothing N^2 involved assuming some basic practical constraints on the meshes). Once built(building being a completely different story) , Gtk+/Cairo has been exceptionally well behaved; if this is alpha-grade code, it bodes well for the eventual final product. Only four hours of hacking had a complete mesh abstraction, board generation and manipulation code, a complete gtkWidget subclass implementing the game board and a build system (no Automake for me, thanks). For those wondering, here's what a typical 'solved' mesh in Planarity looks like:
... although there are a number of easy ways to trivially complicate the regular mesh to make it slightly harder to solve. In any case, the presolved mesh is scrambled and arranged into a pattern (in the original Planarity, always a circle, I'll be doing other things):
Obviously a few things aren't there yet.
The bits that have me intrigued are learning the new widget toolkit, which is performing well. The code driving the math is all very elegant; it feels like revisiting 6.170, but this time as a Jedi Master instead of a mere apprentice. Camilla, on the other hand, is intrigued by playing with more sophisticated arrangements; rather than simple randomly generated meshes we've been talking about unsolvable arrangements with known best cases, etc...
The hardest part of all of this was actually building Gtk+ 2.7; it should probably be the subject of another post as it might save others some pain. Building 2.7 and getting it to coexist with another Gtk install on the same machine required the better part of two days due to what can only be described as criminal insanity in the design of the build system. How is it that Automake never actually makes anything simpler? One can see the need for what it tries to do, but in practice it merely takes all the same old mistakes and spreads them out through three layers of impenetrable shell scripts.
The author is still actively developing the game and has made a number of improvements over the past week. However, the fatal timer problem is still there.
For a few months now, I've been looking for an excuse to play with Gtk's new direction: the Cairo vector graphics system. Gtk has integrated Cairo as of 2.7, and all the backend drawing in this new generation is Cairo based. I've got a widget theme I want to implement for Postfish, and Gtk+/Cairo looks like a good fit.
The only way to really learn a new system is to use it, and I don't want to jump into Postfish as the first project. A vector-graphics based game concept I want to clone and a new vector UI toolkit I want to learn looks like the perfect code storm. I haven't actually written anything completely new in a while, so something quick and constrained feels rather good.
The math behind the original Planarity is pretty simple (and no, there's nothing N^2 involved assuming some basic practical constraints on the meshes). Once built
... although there are a number of easy ways to trivially complicate the regular mesh to make it slightly harder to solve. In any case, the presolved mesh is scrambled and arranged into a pattern (in the original Planarity, always a circle, I'll be doing other things):
Obviously a few things aren't there yet.
The bits that have me intrigued are learning the new widget toolkit, which is performing well. The code driving the math is all very elegant; it feels like revisiting 6.170, but this time as a Jedi Master instead of a mere apprentice. Camilla, on the other hand, is intrigued by playing with more sophisticated arrangements; rather than simple randomly generated meshes we've been talking about unsolvable arrangements with known best cases, etc...
The hardest part of all of this was actually building Gtk+ 2.7; it should probably be the subject of another post as it might save others some pain. Building 2.7 and getting it to coexist with another Gtk install on the same machine required the better part of two days due to what can only be described as criminal insanity in the design of the build system. How is it that Automake never actually makes anything simpler? One can see the need for what it tries to do, but in practice it merely takes all the same old mistakes and spreads them out through three layers of impenetrable shell scripts.
