The Advantages of Algorithmic Design

This past weekend, I ended up engaging in what I think was a bit of folly while working on the game.  I wasn’t in a coding mood, but decided I could manually place walls on the grid lines for Quadrophobia.  The idea there was I could easily turn the walls on and off when designing a level.  This is a good idea.

However, placing the walls took a loooooooong time.  There are, IIRC, 81 walls on a 5×5 grid (this includes the exterior/perimeter walls).

I’m sure there was a quicker way to do it, but I was doing them individually.  Now that I think about it, I could have setup a “container” for each column and row then I’d just have to copy that container and drag all of them across the proper amount to their new column/row position.  Nope – I ended up doing it individually.  Whatevs.
But my other concern right now is expansion/expandability.If I want to make more rows/columns in future levels I’d have to continue to add more walls manually, which sucks.  Had I done an algorithmic method I would expand easily.But, that would mean that the walls would only exist when the game was running, not necessarily in the editor.  I’m sure if I dicked around with Custom Editors and shit, I’d find a way to have my cake and eat it too, however, I’m trying to get a damn game out, and the more I dick around with all these tools that Unity provides (even as powerful as they are) the less I get on making the game itself.  I can learn some of that more later, but right now – getting a game finished comes first.So – manual it is.I’ll just leave a 5×5 grid


The next bit is to figure out how to get the walls working.  I was able to get the collision detection via raycasting from my piece (one of the great things about Unity is the wealth of code just laying on the net, simple examples you can mostly plug and play right into your code with minor modifications).  I’m not talking a whole game, just a little algorithm here and there.So I got that working and was going to implement my code to alter the movement accordingly to whether a wall was obstructing it.However, in my initial design, I had architected the code for movement to basically return a value on keypress.  I then have a separate move function that moves based upon that return value.  I separated the concerns so I could have better modularity in design and implement touch screen input along side my keyboard input.  Nice clean separation of concerns. However it means that I can’t just do a simple raycast when I move the piece (via swiping or key down) and then set its move-ability, as I first need to detect the move direction and then modify the move amount (and since I set the direction separately from the move amount, it means I’m going to have to set the move amount beforehand).My line of thinking right now is, when I place the piece on the board, it scans the rays out, determines if there is a wall, and if so, where it is located.In order to determine where to place the piece if it hits a wall, there are two potential options I’m thinking.The first is a bit silly when I think about it, but it’s one solution:A) Each wall has 2 values.  Since a wall is either horizontal or vertical, these values represent each side of the wall which could be hit.  If my player detects a wall when it is below/south of a wall, it would pull the information on that wall indicating it’s southern point (that is, the square in the grid on which the piece should be played).  This requires hand-coding a value into all 81 walls, and not just one value, but two (a top/bottom or left/right)The second makes more sense.  It’s another algorithmic method.  B) Here I determine what the wall’s location is (if I’m travelling along the y-axis (i.e. up/down), it will be detecting the walls y position; conversely if I travel left/right, I would detect the wall’s x position).

I would have to check whether the wall sits between me and the target position.  If it does, then it would I would have to alter the target position before I move the piece.  The new target position would then be equal to the location of the wall plus an offset (which would be half the height of a square in the grid).  The sign of the offset would be determined by the direction of travel.  It would be an inverse of my direction.  That is – if I am moving Downward, that means I’m moving negatively on the Y axis.  This means if I cast a ray in that direction and hit a wall, I would be adding the inverse of my movement vector (which was negative), which means I’m adding a positive offset (i.e. it would be ABOVE the wall) whereas if I’m coming from below, it means I’m traveling in a positive vector on the Y axis, and thus, the inverse of that is negative, which means I would be subtracting the offset value (thus making it under the wall, not on top).Now that I have this written down, tonight I will have to compress this all into the sweet syntactic sugar we know as “C# code” 😉


But, Dave, you ask… Why don’t you just hit the wall and stop?Well, dear reader, the problem is that I’m using the iTween library.  While this library allows you to do nice things like transition easily between locations across a specified amount of time (which is what I’m using it for in Quadrophobia — though I realize I’m having the movement always be the same amount of time now and to be more realistic, it might be best to create a fixed amount of time per square and multiply that by the move amount so it takes just a wee bit longer to travel 5 spaces vs 1, but that’s a derail)…To get back on the track, since iTween uses a manual positioning, it means you’re not using the physics engine (though I suppose it might be possible, but I’m not using it that way, as I want precise positioning of my unit).  This means that detecting whether I hit a wall at the time I hit it and having the piece “bounce back” isn’t quite as feasible.  I could be wrong on this.  But I think this incurs more cost (in this way – learning the specific feature of iTween that might allow this possibility – I believe my cursory check showed that this isn’t possible at all, but it might just be difficult).. This means that it’s quicker just to come up with a quick and dirty algorithm to do this since I will know what I’m doing and how I’m doing it.

Syntactic Sugar As a Form of Compression (and sidenote on typed language evolution)

All languages evolve over time.  This include natural language (primarily spoken, evolving into written) and other formalized sets of notation that indicate some notion or concept that has arisen in the human mind.  I am excluding non-human animal languages/communication systems from this for the sake of brevity and ease of discussion.

Over time, the language agluttinates to itself more and more detritus from the surrounding landscape, becoming ever larger, more dense, more complex… more detailed.

There are two ways to lighten the burden, both involve “desigilization” of the core language.  Both work in different ways.  Both deal with syntax.

1) The first is a less formal desigilization process whereby the written word is “compressed” by removing letters, alternating spellings (becoming more lax). Things like “Elite” become 1337.  Whole phrases like “Laughing Out Loud” get compressed into LOL — AKA: TLA: Three Letter Acronyms.

2) The second deals with programming languages (though I’m sure one could find examples in other systems of communication/languages).  This type deals not merely with syntax and compression of minor semantics, but can be used to compress large blocks of text into smaller chunks that ultimately mean the same thing.

In programming a common term for this is “Syntactic Sugar” — It’s just a feature in a language that can be used to make typing something easier since it reduces the complexity and number of characters to type.  It’s easy to imagine that at a certain point syntactic sugar can be harmful.  So language designers have to be very careful about how they implement syntactic sugar and how much they give the user.  But the basic idea is that I can take something like:

Here’s a nice simple example that any C/C++/C# (and maybe Java? Javascript? and other C-Style languages, I’d imagine), would know.

You might initially do something like this:

That’s all find and dandy, but it’s a bit wordy for a simple yes-no choice…

You can do something like:

One line – compressing 5 lines (add in 2 more lines if you put your starting curly-braces on a line by itself — not to start any holy wars over style — heh, now I’m picturing a techno-future holy war between followers of various parentheses styles).  OK, so there you’ve “compressed” your language visually, you’ve made your expression more concise and terse.




(NOTE: I hypothesize a slow evolution of the typed language (so long as the keyboard continues to generally remain qwerty-based) such that certain words will have their spellings modified due to the ease with which certain letter combinations are easier to type than others.  In the English language, the simple example of “Residential” can suffice.  To type the word, in the middle, you have d-e-n-t.  This keystroke combination is not a natural stroke.  Here are the following difficult transitions:

a) d->e – requires (again – on a QWERTY keyboard) the user to use the same finger to tap two keys in a row.

b) d->e – further, not only does the same finger tap two letters, but it moves the finger in a way that is slightly more strained than my theorized evolution.

While typing, then certain other patterns emerge.

c) The first of which is realizing that alternating hands and trying to avoid the same finger tapping 2 different keys in succession is faster and more efficient.

d) realizing that d-e-n can be alternated handwise by switching the e-n such that one types d-n-e.  You have given the shifting middle finger of the left hand more time to move, which is less stressful, and faster due to the quickness of alternating hand.)

The Power of Visual Editing

I’m sitting here working on Quadrophobia, trying to figure out how to incorporate walls.  I’m thinking algorithmically here, trying to grok a way to set the location of a given wall in code.


You’re using Unity.  You have a fucking visual editor.

I was worrying about how to get shit aligned perfectly, thinking about numbers and doing it in code, when really, all I need to do is drag drop and round the numbers so they’re nice and even in the x,y axis.

Then, all I have to do while making a level is turn any given wall on or off as I desire.  How utterly fucking easy.

I believe I made my “edge of the board” detection code just detect whether I collided with an object tagged “wall”.  OK, I have not done that.  I did a manual coding of position.  Clearly need to fix that.  I’ll make a wall/edge setup on each edge of the grid that can be turned on and off.

This hopefully can reduce complexity in my code as well.  Currently I’m doing a big long check (non-optimized, mind) if whether i’m above or below the center point, and then if I’m greater (or lesser than) the max value (i.e. distance of edge of  board from center).

In theory “all I’d need to do” (that’s something you learn to never say — “oh, all you need to do is…” because it’s never as simple as that, but I digress):

Attempt to move, cast a ray and see if it collides with anything in the path I am trying to move to.  If that ray collides with a wall, set the position to move to to be the closest node near the wall along the direction you’re moving.

If I’m moving north, I know that my options are the y axis, and it’s always increasing the value of my move by the distance between each node.  if the piece says I have the following options to move it can scan them all, then determine when the player swipes which node to move to.

Now I feel like I’m overengineering it.  So I guess I’ll just dive in tonight and see where I end up!