Pixel Press

After a wildly successful Kickstarter campaign, the Pixel Press team is hard at work, building out their new baby. Such a radically new concept begs a lot of focus from Robin Rath and his team at Pixel Press, but the upside is huge. We balk at calling it a game, because it’s so much more than that.

For the uninitiated, Pixel Press allows us to take a drawing, scan it, then play it. With only a few swipes of our pencil on specially designed (and downloadable!) graph paper, we’ve got a game. When the game itself becomes a game, things take on a whole new meaning, and Pixel Press is getting ready to take us down an exciting new path.

We spoke with Robin about all things Pixel Press. When a concept this wonderful comes out of left field as it has, we just have to know all about it.

AA– What brought up the concept for Pixel Press? What was the inspiration? It’s gotta be a huge undertaking.

RR – I still spend a lot of time with same group of friends I grew up with, and that means frequent discussions of all the fun (and often stupid) things we did while growing up. Playing video games was a big part of our childhood – lots of all nighters. Reminiscing on drawing old video games seemed to have come up a lot of the years too – this last Christmas it came up again and it finally clicked that it’s possible (and also would be really cool) if we could have actually had a way to play those games we drew. Once the discussions started flowing around that it was pretty clear we had to act on it.

 AA– Why Kickstarter? This is a pretty great idea, and groundbreaking. Why not seek venture capital, or fund it through some other means?

RR – Kickstarter was a validated learning and marketing play for us. While we didn’t spend too much time seeking VC or angel money, we quickly learned that those groups (at least the ones we had access to) needed to see more data that people actually wanted the product. In the end, Kickstarter validated Pixel Press, but more importantly opened a lot more doors for us to additional funds.

 AA– You decided to back iOS first. I won’t beat you up for that, since you’re making an Android version as well. How did your kickstarter go, and where are you at with an Android version?

RR – Haha, thanks. Right now we are focused on creating a playable prototype of the platformer type level, and we are building this device agnostic from the onset, so while we have not technically started on any of the native Android stuff, we’re laying the groundwork to bring it to that platform in a timeframe that is hopefully much sooner than June 2014.

Pixel Press

 AA– What challenges are there for Android development? Specifically, what unique challenges are there for Pixel Press when dealing with Android development?

RR – I hate to harp on it but the fragmented device set and the lack of dependency on operating system is the biggest issue – Apple is obviously much more dependable on both fronts. Quality Assurance testing always ends up being the most expensive aspect of any software development project, and even more so on a project like this when there are so many components involved. It’s pretty much guaranteed that on Android (and even on iOS) there are going to be a number of devices that it just doesn’t work on, and then a number of devices that you can only play the game on, but not create. The latter situations (play only) will in most cases result from devices that don’t have camera’s with a high enough megapixel rating.

AA– Tell us a little about the tech behind Pixel Press.

RR – There are a lot of different things going on within the Pixel Press platform including capture, render, interpret, design then publish as well as the entire gameplay and community experience. For the capture portion of the experience we are utilizing Computer Vision (think Xbox Kinect) for real-time feedback and error handling. For the actual render and interpreter portions we are taking cues from the OCR (optical character recognition) community which is highly focused on language translation and document text scanning and applying these paradigms to our situation, which is the Pixel Press Contextual Short-Hand “language”. In other words an X placed on a platform could be interpreted as a spike whereas an X placed above a pit could mean a fireball. Conceptually it’s really a mix of OCR and Pattern Recognition. Then there is the Plane Recognition that needs to take place in order to “draw” the lines as collision points in the game. From a game development level editing point of view, our rendering engine is recognizing and drawing collision points as well as generating entities (items, platforms, characters, etc…) for our games to utilize. All of these processes are being written in C++ currently. Once the rendering engine learns the sketch it will then output it as a data object (JSON) to be consumed by the in-app level editor, thus giving us the ability to theme the levels and integrate them into our physical worlds. The games are being developed in a way to pull this level data in as well as give the user a method for adjusting physical attributes like gravity, velocity, acceleration, etc…The community portion of the application will be powered by a web-based API built on Sinatra[Ruby] (at least right now!) but we have been heavily considering Node.js for a lot of different aspects of the project including the Web API itself. While the tech itself is extremely exciting, we want to pay very close attention to performance and user experience, so all tech decisions we make will be heavily influenced from a “how does it feel” perspective. We are heavily into the rendering and capture portion of the technology, but the gameplay is top of mind as well. We have been experimenting with various languages and frameworks for the game dev portion specifically and are very impressed with some of the HTML5/JavaScript engines out there, particularly ImpactJS, especially from the point of view of being platform agnostic. We are also of course playing with Unity, Cocos2DX and Corona (among others). Specifically, we are creating the first level of our platformer concept in all of these various environments to see what ultimately has the best balance of scalability and performance.

 AA– Obviously it depends on how complex the design is, but how quick could someone be playing a level? If I can draw it in ten minutes, could I be playing in 15? 20?

RR – Great question, had not thought about it in those terms. Capture of the image will be quick (sub 30 seconds), and then assign a design could be done in 30 seconds too. The drawing piece is the most time consuming, but I’m sure people will become quick at it.

AA– Can more advanced developers use their own design for the look and feel of a level? If someone had, let’s say, bricks or some sort of graphic layer already established, could they plug that into their Pixel Press level?

RR – I touched on this a bit before, and the answer is yes. This is the feature I am most excited about for Pixel Press, it let’s people control all aspects of the creation within our framework (level design, art, audio)