I’ve been doing some beadsprite decorating around the house and have needed some custom designs to load into the app I use for iPad.
Link and Zelda restroom sign
Mario flower, I could only find this as a photo of a made beadsprite not as an image
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.
So, I’ve been interviewed by The Examiner. I think this is the first time I’ve been written about… maybe there was something about Monkeybars around the time I spoke at Java One but this is definitely the first “personality piece”.
I had the idea to wrastle up some local game designers and lock them all in a room until they unraveled the deepest darkest mysteries of game design for all to understand. Or perhaps they were just in my living room. Either way, what resulted was a massive first episode, full of disagreement and often contentious discourse that cuts to the very nature of what we think of as games. Intrigued? Luckily for you we recorded the whole 3.5 hour extravaganza and it’s now available for you to consume at your leisure. Direct all hate mail to me.
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.
Blogging is a habit. Posting on Facebook and Twitter are as well, but blogging is much more difficult I find. It’s far to easy to tell yourself that what you have to say is not interesting or that it would be better served by a small tweet. So I became lazy, gave into that voice and stopped updating things here which basically meant that I wasn’t writing anything more significant than what could fit in 140 characters (I’m not really big on the Facebook).
So, to reacap the last (almost) 2 years.
Started tons of game projects. Cancelled most of them. Got divorced. Worked full time at ASU doing educational game development.
Students of mine were in the 2011 IGF Student Showcase for their game Dust for which I was super duper proud. Left ASU and am now contracting and doing my own projects a bit more full-bore. Spent lots of time with Xander. Met a wonderful woman. Finally found a great project that I think other people might actually be interested in playing. Released some assets on the Unity Asset store and made approximately zero monies when not part of a madness sale. Helped several local indies with their games which went on to make lots of monies.
Now I’m looking forward to my game being complete, or at least complete enough to Kickstart/Indie Fund. I’ll be writing more about that on the Happy Camper Studios blog. I’m also getting back into doing contract work, all Unity3D this time, which I of course hate rounding up as it’s lots of work for speculative returns. Currently though I’m working with the most awesome Archaeology Southwest on a 3d kiosk to be placed in Chaco Canyon. I’ve never worked on something that is a physical product, so that’s pretty dang exciting. That will be ending soon though, so then it’s back to the contractor (data) mines to find some new clients.
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.