custom_complete_maze_with_solution (pdf)

complete_with_solution (graphviz dot file)

Here’s how the system works:

1. Solve the maze forward using breadth-first search, propagating acquired “satisfiers” forward to child nodes (ie if your parent had a given satisfier like “SHIELD” then the child node has the same satisfier). The only trimming I do at this point is making sure I don’t add any child nodes where I don’t have the satisfier required for a given edge.

2. Backtrace from the endpoint of the maze by only following parents that meet the “requirements” that have been discovered so far. If a transition along an edge requires something, I add that requirement, and then only add subsequent parents who have that satisfier. For example, if the final node in the maze is 399->400 and it requires “DIAMOND”, I add “DIAMOND” as a requirement. Because we are only working with the possible parents available from the forward solve (meaning, it can only be a parent if at least some path arrives at the parent node with the DIAMOND) we know that at least some parent will have the required DIAMOND. If we discover at some possible point, lets say 397->399 and 398->399 that only 397 has the DIAMOND, then we can prune 398. It turns out this is sufficient to provide a single possible path (well, when I avoid all unnecessary battles) through our maze.

The complete map as pdf: deathtrap.pdf
The complete map as .dot (change extension): deathtrap.txt
The solution as pdf: solution.pdf
The solution as .dot (change extension): solution.txt

Deathtrap Dungeon Solution

They are very similar to the “Choose Your Own Adventure” books, but with some really clever extensions to that basic concept. In the Fighting Fantasy series, for example, an adventurer would encounter monsters along his journey, and the outcome of the battle was decided by dice and hitpoint (and your honesty, of course), carefully tabulated by small hands scribbling with pencils in the front page of the book.

Sad to say, I never finished this book. The maze is too large, there are too many fights, and I wasn’t smart enough or patient enough back then to carefully construct a map in the hopes that on repeated playthroughs I would gradually discover the correct path through the maze.

I can’t remember why, exactly, but sometime in 2009 I was cruising Amazon and rediscovered this book. I was trying to learn Python and decided to make a solver to figure out the path. That Python solver came to naught, but I did end up laying the foundation by encoding the book itself.

I first needed to encode the pages (I call them nodes), the pathways between nodes (I call them edges), and a few other details. First I wrote “nodes.txt” like this:

188 155 224

and so on, for each page of the book.

One of the interesting things about this book is that the maze encodes the concept of state: Only certain edges were useable (if you were playing honestly) if you had encountered items previously. For example:

“The tunnel starts to slope downwards and finally comes to an end at a deep pool enclosed by the tunnel wall. If you can remember the spirit girl’s poem, turn to 155. If you have not seen the spirit girl, turn to 224.” So I also had to encode the concept of “dependencies”, edges that were traversable only when you had the appropriate item in your inventory:

dependencies.txt:
188 155 SPIRITGIRLPOEM

One can only travel from 188 to 155 if one had encountered the “SPIRITGIRLPOEM” at some previous point in the maze. I encoded the acquisition of the necessary items as:

satisfiers.txt:
229 SPIRITGIRLPOEM

And of course there were places you really didn’t want to go, so I eventually encoded such nodes as:

exclude.txt:
#Dont want to fight the guard dog
148

My interest in solving this problem was rekindled through an algorithms course I took last semester. I tried to think of appropriate graph traversal algorithms on to which I could map the concept of dependencies and satisfiers. In the end, I just decided to implement a modified Breadth-First solution. Breadth-First search is well understood, but while it can handle cycles just fine, BFS can’t handle dependencies! These modifications make this an interesting problem.

In a straight BFS maze solver, one simply takes ALL the steps available at each opportunity. So, on round 1, if node 1 has edges to nodes 2 and 3, nodes 2 and 3 are added to an “open” list. In step 2, the open list is consulted, and the nodes there (2 and 3) are explored, and their children are now added to the open list (for example, 4 and 5 from 2, 6 and 7 from 3). In this way, all nodes are explored in the maze, and the first complete path to the end also happens to be the shortest (optimal) path. However, this approach doesn’t capture the concept of satisfiers. If one hasn’t previously encountered the spirit girl and heard her poem, how then can one add node 155 to the open list?

The modification is to add a satisfier set to each node. This list is initially empty for the majority, except for nodes like 229, which start with m_satisfiers = { ‘SPIRITGIRLPOEM’ }. As the list of open nodes is expanded, any node added to the open list has its satisfiers set updated with the satisfiers of its parent(s) so that when we are attempting to expand a node that has a dependency for one of its edges it can consult its satisfier list, which reflects the satisfiers it has acquired through it parents. Now we can imagine a scenario where parent A contributes satisfier A and parent B contributes satisfier B allowing our child node to incorrectly follow an edge that requires both A and B, but it turns out this doesn’t happen in Deathtrap Dungeon. And that, in the end, was more important to me than endless algorithm tinkering. It’s just not where my passion lies.

The problem with all this of course is that a node will occasionally acquire more than one valid parent node. There are a couple ways to improve this: Each node could acquire a set of satisfier sets, which each satisfier set representing the contribution of a given parent. This is a pretty reasonable improvemenet, and one I would have made if required, but as it turns out, it was easier to simply modify my solver to find a valid path forward from start to finish and then enter an interactive mode where I could conduct the backtrace myself. I spent a lot of time noodling about ways to fully automate the backtrace but in the end run up against the fact that a backtrace algorithm will also have problems with cycles and dependencies. In the end I concluded the effort wasn’t worth it.

My final solution represents this hybrid approach (automated forward solving, manual backtracing). The tabulated files, including my solution, are attached at the bottom of this post. My solution largely matches this guy’s solution, and he constructed his the “hard” way by manually exploring the maze. He also provides a link to FightingFantasy.com which appears to be having some sort of renaissance. I can offer you a link to Tin Man Games, an Australian outfit bringing this type of game (and indeed, the Fighting Fantasy originals themselves) to Android and iOS.

Files:

Solution.txt

DeathtrapDungeonFiles (zip)

The Minkowski Difference

The basic tool of GJK is the Minkowski Difference, explained in more depth and to far greater benefit by Wikipedia and Paul Firth’s website http://www.pfirth.co.uk/minkowski.html. The Minkowski difference is an inherently graphical concept. To see it is to know it immediately; To read about it is a lot less useful. Here goes: Think of it as an object where each point is the result of a point in object A – a point in object B.

Minkowski (x, y) = (Ax – Bx, Ay – By)

For the purposes of finding collisions one can simply consider the vertices of each object, but it is important to remember that we are talking about the infinite number of points that make up the 2D area (or in 3D, the volume) of each object. It is also worth drawing out a few to get the concept fixed in your brain. Heres a screenshot of Paul Firth’s applet:

The weird object is the Minkowski Difference of the triangle and heptagon. We also note that if two objects are overlapping then there exists at least one point on each object A and B are the same, so the equation becomes:

Minkowski point (x, y) = (Ax – Bx, Ay – By) = (0, 0)

This means that if two convex hulls collide, then the Minkowski Difference of the two objects contains the origin. GJK is how to implement the question: Can I draw a simplex using only points on the surface of the Minkowski Difference object that contain the origin? If so, I have detected a collision. If not, then there is no collision. In 2D, a simplex means a triangle and in 3D simplex means a tetrahedron. Both are the smallest set of points that can contain another point in 2D and 3D, respectively.

The Support Function

The key to using GJK is to be able to compute the point on each object A and B that lies farthest along a search direction. I said earlier that although the Minkowski object is composed of all possible combination of points, we can solve GJK using only the vertices of of our polygons. In addition, although it is mathematically perfectly reasonable to pick a point not one of the vertices of the polygon, programmatically it is more sensible to only consider the points that make up the polygon. The way we do this is with the Support function, which given a direction to search along returns the vertex on an object that is farthest in that direction. Let’s see some examples:

In case one, point one is the farthest point on the object along the search direction. If you are wondering why we didn’t choose the point on the line where the arrow crosses the square, tilt your head so the arrow is pointing straight up. See? The corner really is the farthest point in that direction.

In case two, the search direction is normal to the side so both points 3 and 4 are valid. The algorithm will work regardless of which point you pick.

Here’s the awesome part. Rather than explicitly compute all the points of the Minkowski object and then calling our support function on that, we can simply call the support function on each of our two simple polygonal objects and compute the appropriate Minkowski point using the relationship below. Here’s the pseudocode for my support function:

VERY IMPORTANT: Observe that we use “-D” in the support function for object B.

Evolving the Simplex

I’ve tried to write this consistent with the Molly Rocket presentation which you should really watch if you are serious about implementing this algorithm. The way it works is:

That is seriously all there is to it. Well, not quite. What does “DoSimplex” actually do? Remember, we are trying to find the set of simplex points that contains the origin. To do that, we evolve the simplex to always contain those features closest to the origin, and to pick a new direction for us to search for the next candidate point to add to the simplex. Thus our DoSimplex function examines the existing simplex and then sometimes updates the simplex (by removing a point) and always picks the next direction for us to search in. In our formulation we never call DoSimplex on a simplex of size 1, so let’s consider the 2-point simplex.

Evolving the Simplex: Two Point Simplex and Voronoi Regions

In all the pictures, we consider the point A to be the most recently added point. In this case, we picked B and then went searching in our new search direction and found A, the farthest point on the Minkowski difference in that direction. Evolving the simplex means looking for the next search direction and simplifying our simplex. The origin can be in one of the three Voronoi regions defined by this line.

1. The origin can’t be in region 3. If it was, there was some other point in region 3 that we would have found instead of point B, because we picked B by saying the farthest point in that direction. Thus we never examine region 3.

2. If we overshot the origin, it is somewhere in region 1. In 2D simply find the perpendicular to the line AB in the direction of the origin because we know the origin still lies in the plane of the line. in 3D, you need to use the triple cross product to get the perpendicular to the line AB in the direction of the origin. The test “Did we overshoot the origin is simply the dot product of vector AB with A0. If the dot product is greater than 0, then the angle between AB and A0 is less than 90 degrees, putting it in on the region 1 side of the plane divided by the dotted line at A, which could be region 1 or 3. As we know it is not region 3, it must be region 2.

3. If we went as far as we could in our search direction and couldn’t pass the origin, we know the origin is still somewhere farther than Point A, so it must still in region 2. We can drop B from our simplex because it is not useful and set our new search direction to be from A towards the origin.

Evolving the Simplex: Three Point Simplex and Voronoi Regions

This looks a lot more complicated, but it isn’t, not really. It is essentially two line simplexes with a bit of reasoning about the other regions. First, observe the white regions to the left of the drawing. We can reject those by the same reasoning we rejected the region behind B in the line simplex case: We are only considering this point A because we already decided it was more in the direction of the origin than anything on the other side of the line BC, so why would we waste work looking regions we already know are farther away from the origin?

We evolve our simplex in the following manner: First we check to see if the origin is on the side of the AB line away from C. If so, we can ignore everything on the C side of the AB line, and then just check to see if the origin is in the yellow part or the pink part of that side of the line. Because C can’t be part of an optimal simplex, we remove it from the simplex.
In the same way, we can check the area on the side of the AC line away from B, and if it is, decide if the origin is in the blue or the pink side of that area. Because B can no longer be part of an optimal simplex, we remove it instead.

If the origin is not in either the yellow, blue, or pink regions, then it must be in the central green region. If it is, we have surrounded the origin, thus detecting a collision.

Actually, we are only done in 2D. In the 3D case the origin may still lie above the plane or below the plane. The MollyRocket video covers it but I do not. It is an obvious continuation of the simplex evolution strategy, but now using a tetrahedron (a 3D simplex).

One important thing to note is that the MollyRocket video and these notes use ABC to denote the triangle normal. The cross product checks that use the triangle normal need to be the vector that points to the outside of the triangle (shown in the image above). The triangle normal ABC is computed as AB x AC. Draw a couple triangles to convince yourself no matter how you assign the points A,B and C, you will compute vectors pointing “out” in this fashion.

EPA: What to do after a penetration is detected

The second part of a physics engine, after collision detection, is collision resolution, where we use the information about the collision to correct the velocities of the objects. This is a considerable subject in its own right, but for now, I will limit the discussion to only the problem of “How do you use GJK when you want to know the contact point and collision depth?

When we detect a penetration (the case where we return true in the pseudocode, region (2,3) in our triangle simplex), then we must use another algorithm to find that information. One good one is Expanding Polytope Algorithm (EPA). Another is Separating Axis Test (SAT). SAT can actually replace GJK entirely, but it is not quite as fast and doesn’t scale well to 3D objects so it is less commonly used. I will cover neither of these here but will provide a link to an example of 2D EPA.

Code listing

I have included a gjk code listing. It won’t compile to anything meaningful out of the box because it uses the Havok SDK but it should be fairly readable and demonstrate the concepts shown here.

References

I’ve discovered a lot of great resources online while researching my own implementation of GJK. The best explanation of GJK is at the MollyRocket link, but the others also contain useful information. There is a mostly correct GJK explanation at codezealot, but the author takes a couple of shortcuts like not checking his triangle normals that will trip the unwary observer. His simplex.getA(), .getB() and .getC() methods return the appropriate vertex to preserve the orientation of the triangle normal which is an inappropriate simplification in a pedagogical exercise such as this.

GJK

EPA

gjk

The challenge was the following: Given a URL, implement (in PHP) a hashing function that produces a fixed length, approximately unique key that can still identify some of the “tokens” that created it.

To understand the problem, consider the following:

www.my-yahoo.com contains the tokens {www, my, yahoo, com}

So $key = hash(“www.my-yahoo.com”);
contains($key, “yahoo”); should respond TRUE but
contains($key, “google”); should respond FALSE

It might make sense to use the URL as its own hash, but it is pretty easy to find URLs that don’t work well with this approach (either too long or with lots of small tokens).

My solution uses a 16-byte key composed of a 4-byte preamble and a 12-byte Bloom filter. The 4-byte preamble is the first 4 bytes of the md4 digest of the entire url. I used md4 because it comes standard in PHP and is fast compared with the other standard hashes. The cryptographic aspect is irrelevant except that a good cryptographic hash will also show a very good uniform distribution over the keyspace. For my application, this means I can take a substring of the digest and still have a good uniform distribution. It would make sense to use a faster, simpler hash like FNV but as I was just starting with PHP and nervous about my poor grasp of its weak bit manipulation abilities I decided to stick with something reliable.

The Bloom filter is more interesting. Once again, Wikipedia is your friend, but the short version is that a Bloom filter is a bitfield, populated with the outputs of a number of different hash functions on each token inserted in to the Bloom. To add a token, one computes a hash or set of independent hashes for the token and then adds them in to the bitfield. As more tokens are added and more hash functions are used the bitfield “fills up” with ones, resulting in higher false positive rates because all the bits that would be set for a given token are already set by a combination of other tokens. That becomes a design tradeoff influencing the bitfield length, the number of hash functions used, and the number of tokens stored.

In the end, my keys are 16 bytes long, unique over the million URLs I tested, and have a pretty low false positive rate. I note in my writeup that although the general false positive rate is low, the worst Bloom filters have high error rates so in practice it makes sense to reduce the number of tokens added. I also tried using multiple different Blooms to increase the number of tokens contained (three 4-byte filters, two tokens each). As you can imagine, each filter is less “full”, but over the whole key the false positive rate goes up. I eventually discarded it.

It was interesting writing in PHP, something I had never done before. It was also a challenge to write a program that would really benefit from low level bit manipulation and strong typing in a language that doesn’t really make that sort of programming easy. PHP is sweet for string manipulation, though, and I ended up with a compromise I liked well enough. This compromise actually use a character to store each nibble (for conversion back and forth from strings to bytes), so it’s underlying representation is at least 32 bytes long. It should be straightfoward to pack these nibbles smaller, obviously, but I wanted to concentrate on getting the filter to work.

I’ve included my hashing class, my test apparatus, and my writeup. I’ll get around to adding some relevant links below as well. Be advised: the test code takes a long time to run and consumes a ton of memory, as I made my life simpler by keeping everything in memory, rather than sorting and merging on disk.

php_bloom

Now that I’m back on the job hunt, I wanted to get my “web presence” back up so I decided to spend some time fixing the site. This involved tinkering in an ignorant and dangerous way with WordPress and then calling my hosting service where “Justin” (I didn’t quite catch his name) told me that I needed to upgrade my account to be eligible for helpdesk support and then went ahead to find and fix my problem anyhow. So, thanks Justin! And if anyone needs a bangin’ web hosting (and wordpress troubleshooting) service, I am one satisfied Lunarpages customer.

Click here to view the embedded video.

I was studying compilers and Babbage and got a bit obsessed with “Victorian Computing”. So I made a clockwork man outfit.

IGNORE ALL THE TUTORIALS ON THE WEB.

People want you to set up Eclipse to look for X11 binaries, or to install stuff with MacPorts, etc, etc. TERRIBLE. Do this instead.
First we’ll get Xcode up and running.

1. Go to http://www.libsdl.org/download-1.2.php
2. Download the latest Mac OSX dmg.
3. And the dev tools. (EDIT: With the recent MacOS version, the SDL group is unable to provide the dev tools for the Mac. They no longer provide the XCode projects but the Eclipse setup still works).
4. Read the READMEs of course, but the following steps will work.
5. As the SDL README says, Copy the “SDL.framework” to “/Library/Frameworks”. Note the README will help you to get it running if you don’t have admin privileges but as far as I’m concerned you’re screwed.
6. As the SDL-DEV README (more or less) says, Copy

   SDL-DEV/Documentation Docs/XcodeDocSet/org.libsdl.libsdl.docset

   to

   /Library/Developer/Shared/Documentation/DocSets

7. Copy the Xcode templates (not the containing “TemplatesForSnow…” folder) to a folder named “SDL”.
8. Copy this “SDL” folder to

   /Library/Developer/Shared/Xcode/Project Templates/Application/XcodeTemplates/

9. Open Xcode. Go to “Create new Project”, select “SDL OpenGL app” from “Other”
10. Xcode will start a project with some example code in it. Hit “Build and Run”. It should fail, complaining about “an SDK with the name 10.4″. Now do this:

The initial build will fail until you select "10.6" in the pulldown menu

1. Now hit “Build and Run”.

It should run and show you some OpenGL cetaceans swimming around. Awesome!

Now back to work on Eclipse.

1. Open Eclipse.
2. Create a new C/C++ Project. I named my project “SDL_Test”. The ABSOLUTE path to this location is important. My absolute path here is:

   /Users/mrfurious/eclipse/SDL_Test/

3. Right-click on the project and go to “Import”.
4. Import the SDLMain.m and SDLMain.h files from your SDL OpenGL project template or from your Xcode SDL project. These have to be included with EVERY SDL project you do. If you were following along in the first part, they are also at:

   /Library/Developer/Shared/Xcode/Project Templates/Application/XcodeTemplates/SDL/SDL OpenGL Application

5. For the purposes of this tutorial, grab all the .c and .h files as well (ie the stuff in the Atlantis folder).

Apple has organized all the important stuff that can happen in computers in to Frameworks, which is just a directory that puts headers and binaries (precompiled libraries) in the same place. For SDL, you need OpenGL, GLUT, Cocoa and SDL. All this stuff comes built-in. Don’t install anything with MacPorts. Don’t go adding “/usr/X11R6….” to your path.

1. Right-click on the project. Select “Properties”. Go to “C/C++ Build”. Go to “Settings”.
2. At the top of the settings window where it says “Configurations:”. Set the chooser to “All Configurations”.
3. In “MacOS X C++ Linker > Libraries”, add your absolute path to the “Library search path (-L)” window. For me this was:

   /Users/mrfurious/eclipse/SDL_Test

4. In the linker arguments line, write

   -framework openGL -framework SDL -framework Cocoa -framework GLUT /Users/mrfurious/eclipse/SDL_Test/SDLMain.m

Here’s a picture:
Now your linker knows where to look for the binaries it needs at linking time. Now we tell gcc and g++ where to find the headers.

1. Add this text to both the GCC C Compiler and the GCC C++ Compiler “Includes” window:

/Library/Frameworks/SDL.framework/Versions/A/Headers
/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers
/System/Library/Frameworks/GLUT.framework/Versions/A/Headers
/System/Library/Frameworks/Cocoa.framework/Versions/A/Headers

Your setup should now look like:

And

1. Click “Ok”.
2. Almost there! One last thing. This code is written as if the libraries were tucked away in folders called “GLUT” and “GL” and “OpenGL” so you had to include headers with directives like

   #include <GLUT/glut.h>

   but with Frameworks, there is none of that. We need to clean up the source files a bit.

3. Go to atlantis.h. Add

   #include <gl.h>

4. Alternatively, you can add that to each of the “atlantis.c”, “whale.c”, … etc, but since they all include “atlantis.h” then adding it to that file alone will propagate the change through the codebase.
5. Go through each of the “.c” files and change instances of

   #include <GLUT/glut.h> to #include <glut.h>

   and instances of

   #include <OpenGL/opengl.h> to #include <opengl.h>

6. DO NOT CHANGE SDLMain.h.
7. Strangely enough, in SDLMain.m I had to change the “#include “SDL.h” to “#include “SDL/SDL.h”.
8. Click “Build” and then “Run”. Behold, Leviathan!

As an aside, whenever I think about the way my parents looked on the day I informed them I needed a 5^th year at my very prestigious, very expensive university to complete my engineering degree I have no problem whatsoever getting out of bed early Saturday to do math. Thanks, Mom and Dad!

Here is a graphic showing how the Iron Gym hangs in a doorframe. The doorframe is rendered transparent to show the pink cross beam hanging on the internal door trim, while the yellow bar rests against the outside. You hang on to the straight section of the green “handles” to do pull ups.

Iron Gym Total Upper Body Workout (Non Extreme Edition)

Here is a cross section with the relevant loads and distances labeled:

Iron Gym Free Body Diagram

When we sum the moments around 0 (the black dot) we see the following:

W*L3 – Rx*L2-Ry*L1 = 0

We also know Ry is the frictional force generated by the normal load Rx:

Ry = u*Rx

where u is the coefficient of friction for “rubber on wood”.

We also sum the forces in the Y direction to see:

Oy + Ry – W = 0

We substitute for Rx and solve the first equation for Ry:

Ry = W*L3 / (L1 + L2/u)

Plug in some rough numbers:

W = 1000N
u = 0.5
L1 = .20m
L2 = .20m
L3 = .25m

And observe that Ry is roughly 416N, or ~40% (see what I did there?) of the overall weight W. We may wish to vary the estimate for the frictional coefficient, or to include the moment from the force in the x-axis on the pink cross beam, but it turns out they don’t influence the answer very much. From this analysis we may conclude that although there is a lot of weight on the door trim, not all of it is borne there. A more useful analysis might calculate allowable loads on a residential door trim but that isn’t necessary to prove Tim wrong! I’ll stop here, then, and savor this rare moment.