I recently ran across CodinGame which is similar to CodeWars but is framed as a series of games you’re writing the logic for instead of textural problems to solve. Needless to say this appeals to me. Happily they support Haskell so I dove in and started in on the tutorial. Blammo! No problem. Onwards to problem #1 in the easy category… two hours later, I finally had a solution that worked. Now if this had been C# it would have been a 5 minute problem tops, but the point of this kind of exercise is precisely that I’m not working in something familiar. I’ve done a few of the katas on CodeWars in Haskell and while somewhat challenging, the easy problems were indeed pretty straightforward. This problem however was much more difficult because it was framed as an imperative problem and that has a much higher impedance mismatch with the normal way of doing things in Haskell. I figured this might be a good example to point out a very different way of approaching what should be a very easy to visualize problem.
So in this scenario, you have Thor who must be guided to the light of power. At the beginning of the program you’re provided with Thor’s starting x/y coordinates as well as the x/y of the light. You write to standard out a direction in the form of N, S, E, W, NW, NE, SE, SW over and over until Thor reaches the destination (or the run times out after 100 moves). So this seems pretty straightforward, you could keep track of your x/y, increment or decrement it as you move and each iteration compare where you are to the target and output the correct direction accordingly. Easy peasy.
I did start out somewhat in this vein, I knew I wasn’t going to be mutating a global variable but my idea was to have a function that took the current x/y and target x/y and did the comparison and outputted the correct direction. This is doable in Haskell just like in C# although you would use recursion instead of a while loop, but otherwise it’s pretty similar. Thinking about this problem for a moment though, I realized you actually know right from the start how many moves in each direction you will need. Using that you could construct the entire list of moves to get to the target and then all that’s left would be to iterate over that list printing out the values one at a time.
Here is the code listing (also in the screenshot at the bottom for reference). The structure of the functions and the all the input!!xyz lines were provided at the start of the problem.
import System.IO import Control.Monad main :: IO () main = do hSetBuffering stdout NoBuffering -- DO NOT REMOVE input_line <- getLine let input = words input_line let lightX = read (input!!0) :: Int -- the X position of the light of power let lightY = read (input!!1) :: Int -- the Y position of the light of power let initialTX = read (input!!2) :: Int -- Thor's starting X position let initialTY = read (input!!3) :: Int -- Thor's starting Y position -- my code starts here let startToTargetX = lightX - initialTX let targetToStartX = initialTX - lightX let startToTargetY = lightY - initialTY let targetToStartY = initialTY - lightY let count = max (max startToTargetY targetToStartY) (max startToTargetX targetToStartX) let vertical = replicate startToTargetY "S" ++ replicate targetToStartY "N" ++ repeat "" let horizontal = replicate startToTargetX "E" ++ replicate targetToStartX "W" ++ repeat "" let pairs = zip vertical horizontal let directions = map (uncurry (++)) (take count pairs) loop directions loop :: [String] -> IO () loop [final] = putStrLn final loop (current:rest) = do putStrLn current loop rest loop  = return ()
Each move is potentially some combination of vertical and horizontal movement and I did not know which direction would contain more moves, so I used Haskell’s lazyness to not have to care. I calculated the total number of moves to get to the target, which is simply the maximum of the horizontal and vertical distances. Then I built up a list of instructions for both directions and appended infinite empty strings to the end. I passed both the horizontal and vertical instruction lists into a zip function that paired them into an infinite list of tuples, and then I took from that list of tuples a number of elements equal to the count I had calculated earlier. Finally for each pair I took the two elements and combined them to build the final string using map. Uncurry for reference, takes a function that normally takes 2 params, and converts it to a function that takes a pair (tuple), that way I can use the standard ++ function with the tuple that got built up by zip.
The main loop function then was just responsible for printing out each value. The first case is matched when there is only one element in the list, which simply outputs that element. The second case is matched when there is at least 2 elements in the list. The final case of
loop  = return ()
is there just to satisfy the compiler that can’t know that we will never call loop with an empty list, however it will never be executed in this solution.
I’m not claiming this is the best way to do things in Haskell, but it seems vastly more idiomatic than copying an imperative style. Hopefully it’s interesting to see how different a solution can be when you’re working with a different toolbox.
There don’t seem to be many NUnit test runners that will monitor your project and automatically re-run your tests whenever your assembly changes on OSX. After some looking around I settled on using the plain nunit.exe that comes with NUnit itself. This requires me to fire off a command line to boot it up each time instead of it just being an app. I figured there had to be a way to get a simple app bundle to wrap the command so that it could be launched like a normal app via spotlight or Alfred or whatever your launcher of choice is.
Enter Platypus, a drop dead simple way to wrap up a shell script, Ruby, Python, Perl, or other “needs to be launched from the command line” utility you might have. Configuration was extremely simple, I created a shell script to kick off NUnit
mono nunit.exe &
Then I told Platypus what script to run and included all of the requisite NUnit files that are needed and hit create.
Make sure to uncheck the “Remain running after initial execution” or the Platypus process will hang around.
If you just want the NUnit app bundle you can get it here.
You wouldn’t think this would be a very complex topic. Something every web server should be pretty good at is letting you see the activity on your server and most importantly the exceptions your app is sure to run into in production. Without that, it’s rather difficult to hunt down your problems. From what I’ve found the typical way this is done is by your frontend, be that Thin or whatever redirecting stdout and stderr to their log files. I find myself in a rather odd situation though, as I am deploying on Windows using Helicon Zoo. No, Linux deployment is probably not an option for this particular situation. Ok, so now Helicon does its thing pretty well, makes your Rack app show up in IIS as an app, etc. Padrino logs its files ok, but exceptions are mysteriously lost to the void. So what I came up with was to redirect $stdout and $stderr to the Padrino logger (at info and warn levels). The idea came from this thread.
In my boot.rb file I add the following
Padrino.after_load do info_wrapper = IOLogWrapper.new(Padrino.logger, :info) warn_wrapper = IOLogWrapper.new(Padrino.logger, :warn) $stdout = info_wrapper $stderr = warn_wrapper end
This wraps up the Padrino standard logger into something that can be assigned to $stdout, namely a subclass of IO. Here’s the IOLogWrapper class
class IOLogWrapper < IO def initialize(logger, level) @logger = logger case level when :info @method_to_call = @logger.method(:info) when :warn @method_to_call = @logger.method(:warn) end end def write(str) @method_to_call.call(str) return str.length end end
Voila! Your exceptions are now logged as info and warning messages in your Padrino log file.
The aforementioned project that I found that I think other people might actually be interested in finally got a name and a writeup. It’s named Star. Ship. Story. and the basic gist is skill based co-op with a procedurally generated world and short form gameplay so you’re always in a unique setting and the game only expects 30 or so minutes of your time. There’s lots of details at that link so I encourage you to head over there if you want more info.
Another Phoenix IGDA game jam has brought forth yet another game. This time around the theme was much more open ended with 5 options to choose from (you had to pick at least 2). An artist, Blake Bjerke, was “assigned” to me by the jam’s organizer Tyler Coleman and for which I was very grateful to have. Blake turned out to be quite a competent artist and he was able to produce assets at a rate that often exceeded my ability to get them into the game (and looked quite good to boot!).
The themes we chose were torque and wholesale. The original design involved launching a taxi full of customers through a city in order to deliver them with as little force needed as possible. The eventual design strayed from this a bit, as the city setting was not very interesting and the concept of customers in a taxi was too hard to get across in such a short time frame. So we settled on a capsule full of colors delivering to stations that matched the same color. With a bit of extra time those colors could easily become passengers, or widgets, or energy, or whatever fluff was needed for the final presentation.
I ended up wasting about 6 hours trying to get the capsule pathing around corners to look good and work consistently. In the end I opted for my original solution, which had some problems that could be covered up by level design and a hacky little “fix up” script that looked for errors in the capsule placement and corrected them. In the end, I thought of a solution that would actually work in all situations and be free from the issues that plagued each of my 3 prior attempts, but there was at that point no time to implement it. So if you see the capsule stray from inside the tube and then snap back, that’s my hacky solution at work.
On the design front, the variety of puzzles we were able to create felt a bit limited. We had several hours at the end to just make levels, which was a fantastic change of pace for my normal game jam timeline. The problem was, we needed another special type for one of the tubes to add some more tools to our palette. It’s easy to come up with a handful of ideas, we just were constrained by time. I believe the first and last levels of the main game are the best we created, but even those feel quite basic and easy to solve. With a few more components I believe we could have some devilishly difficult challenges, as befits any proper puzzle game.
Overall I’m quite pleased with how this one turned out. It’s certainly the most polished game I’ve created in a game jam and it feels nice to have something playable and mostly complete. My goal this jam was to build the tech part as fast as possible so I’d have a long time to polish and refine. My capsule pathing issues sort of held that goal back, so that’s something to consider for next time. I should have just taken my hacky solution and stuck with it from the beginning. That would possibly have bought me the time to implement a new pipe type that would have provided a lot more interesting puzzle design.
Well I’ve been rather silent on this blog for quite some time so I wanted to post a bit of what I’ve been working on.
This game includes:
- Sailing around and shooting stuff
- Procedurally generated worlds
- And of course, buried treasure
Target platform is online gaming portals such as Kongregate. ETA is still unknown but now that the game is moving along again at a good pace I expect it to be within a month or so. I know, famous last words…
In case anyone didn’t notice, I’m not doing updates as blog posts here anymore, but on a page dedicated to the visual editor. Also, I’ve stopped maintaining my own unity package and have just been releasing new versions to the asset store.