Tim Barbara

My Projects

Mr. Game!

Mr. Game! is a board game I co-developed with a team of four people while I was at Stevens. The original concept began with a simple question. "What is a board game?" Well, most of the time a board game is about taking your piece at point A and getting it to point B. So we drew a single linear path of spaces from A to B. Then we moved on from there, what if point A became point B? What if the goal could change? What if there were multiple goals? What if the goal could be anywhere? What if the goal could be nowhere? How would players react? How does the goal change? Cards? What else can the cards change? The board? The pieces? ...the rules? If the rules are changeable, what happens when two rules seem to conflict with each other?

That last question led to the creation of the role of Mr. Game. Mr. Game's job as a player is simply to read and interpret the rules. Rules cannot be broken... but perhaps they can be bent and made to do your bidding... Players can attempt to do whatever they want but Mr. Game's word is law. The ever changing landscape of the game ensures that each session will be a unique experience. Mr. Game! challenges players to push the boundaries of what is acceptable within the confines of simple set of rules.

What kind of Mr. Game will you be? An upholder of law and order? Or a harbinger of chaos and destruction? The only way to know, is to play.


This was an interesting project from a user experience standpoint. We wanted to avoid "information overload" but at the same time clearly explain what the game was about. Many games struggle with this giving players paragraph after paragraph of intricate rules. The rulebook for Mr. Game! is only a few pages long and is full of colorful pictures and clear bullet points. Keeping the rules clear and concise was important because we wanted all players to have a very good understanding of them so they would get ideas on how to push the boundaries.

Creating a ruleset that was ambiguous enough to allow this kind of experimentation but concrete enough to create a cohesive experience was one of our biggest challenges. We tried many different iterations of the rulebook to varying degrees of success. We wanted to make sure that the game couldn't be broken by bad Mr. Game rulings or malicious players. Earlier in the project everything we tried felt far too restrictive to players or made the rules too complicated.

After some frustrations we went back to the drawing board and rewrote the whole rulebook. We wanted to pare the rules down to their simplest form. What are the real obvious game breaking loopholes? How do we fix them? We added the worst of these game breakers to the rules, for example a player is expressly disallowed from placing the goal underneath themselves to they win instantly, cannot traverse the null area on the board, and cannot move diagonally or waffle back and forth between two spaces when moving. Most other things that we once considered "game breakers" were left up to the discretion of Mr. Game.

When we play tested this new iteration we discovered something interesting. The game had developed a sort of self balancing aspect. People don't want to play a broken game. It's not fun. When people try to break the game other players will stop them. The final piece of the puzzle was regulating Mr. Game themselves. What if the arbiter of the rules, tried to break the game? We decided that the best way to combat this was to extend the natural “self balancing” aspect of the game. We added a clause to the rules that said that Mr. Game could be overthrown and replaced if they broke the rules or tried to reverse their own decisions. We didn’t specify how this would happen or exactly what conditions would result in an overthrow. That was left up to the players. To date, no Mr. Game in any game I've witnessed has ever been overthrown. The threat of being overthrown is enough to keep most people from ruining the game for everyone else.

The removal of many of the more nit picky rules also taught us an important lesson. There is no "wrong way" to play Mr. Game! as long as everyone is having fun. In playtests we watched as players came up with crazy scenarios and loopholes we never would have thought to test for or write rules for. We might have written some of these off as "broken" and written them out of the game but people had a lot of fun with them. Some of the most memorable rounds of the game came out of these crazy rulings and some of those rulings made their way into the "meta" of the game and were adopted by players in subsequent rounds. Mr. Game! is an interesting game because every player puts their own unique spin on it every time they play.


Tim Barbara, Frank DiCola, Kenny Goff, and Nick Pagano.


Website, Twitter, Facebook.


While at Stevens I took a software practicum class which gave students hands on experience with "real software projects for real clients." Our project was a piece of software called TaylorFit which had been developed by a Stevens professor for use in engineering classes. TaylorFit is a piece of software which helps a user develop Multivariate Polynomial Regression (MPR) models. These models can provide a mathematical representation of complex data to be used in various engineering, science, and business applications. The original TaylorFit was developed in C++ in the early 90s as a text based application. My team was tasked with updating this program with a modern graphical interface and additional functionality. I returned to TaylorFit again, this time as the project manager, for our Senior Design class. We further developed the program with new capabilities such as cross platform support, standard file import and export, and graphing capabilities. Over the course of these upgrades much of the original software had to be rewritten.


TaylorFit was not designed with the user experience in mind. It was cumbersome, it was outdated, it was slow, and required specialized knowledge to get it working. When we first encountered the software it wouldn't even compile on modern hardware. We designed an all new user experience from the ground up. We chose to work with QT due to its ease of use and excellent cross platform support. We worked to integrate the functions of the old math engine with the new interface. This was quite the task as the original codebase had zero documentation and no comments throughout. The core math engine was a 3rd party library written in obfuscated C code. We took care the document and refactor the codebase as we worked so future teams who worked on this project would have an easier time starting.

TaylorFit 2.0 Team

Tim Barbara, Kris Jordan, Chris Barry, Neal Trischitta, Brandon Schur, Adam Perez, and Mark Fleres.

TaylorFit 3.0 Team

Tim Barbara, Chris Barry, Brandon Schur, and Adam Perez


Project Poster, Project Presentation.