IMA Capstone Documentation Martyr: An Exploration of Hybrid Board Game Systems

Presentation Slides:

Documentation Video:

Writing Assignment:

My project explores ways that technological computation can enhance the experience of playing a board game and aims to push the genre of hybrid digital board games forward. In my vision, hybrid board games will integrate sensors into the board to track player actions and movement. This information is relayed to a small computer which can then output relevant information to the players via a built in screen and/or speakers. This technology should be unobtrusive, allowing players to interact with the game almost exactly as they would any other board game.

The advantage of a system like this is that it allows players to focus on the gameplay and social experience rather than getting caught up in the minutiae of calculations. One of the defining traits of board games over video games is their ability to enable social interaction, and I believe this framework accentuates that strength. This is particularly true in co-operative games, where players discussing strategic plans in depth and negotiating with one another to decide what to do is the core of the game.

To demonstrate how hybridization can work in practice, I created a co-operative game called Martyr. The game board has 12 squares that players can occupy, and each square has a photoresistor built into it to track the movements of the players. Each square’s content is also procedurally generated, and when the computer detects that a player has landed on a specific square and wants to perform an action, it triggers the appropriate audio for that square’s content. The computer also keeps track of how many actions players have left in a turn, allowing them to focus more on planning out a strategy together instead of just trying to figure out what moves are valid. This also has the advantage of simplifying the written rules, one of board games’ largest barriers to entry. Video game rules are managed by programmable logic hidden from players, but understable through intuition. This intuitive understanding is also present in hybrid games, allowing for more complex games without overwhelming the player with as many written rules.


Reactive User Interfaces Final Documentation: Games Portfolio

Live Site:

Github Repo:

In general, I wanted to use this project, one that I will present to the world beyond the NYUSH community, to think harder about design than I have in the past, as it has always been one of my weaknesses. The two aspects that I focused in on were the presentation of information in relation to my target audience and the text styling and color. After doing research in online game development communities, I came to the conclusion that my number one goal should be to get the information that employers want to see in front of them as quickly and cleanly as possible. I believe this comes through best on the individual project page. The specs column clearly lays out an overview of the production, including what technologies I’m capable of using and my place within a team.

Additionally, I originally planned to only have my projects under the Games and Multimedia sections and the Home page reserved for my bio. However, I realized that would require extra clicks before my audience would actually be able to see my work and decided

My color choice was mostly inspired by trying to make the website more personal to me. While sleek black, grey, and blue designs look really nice, I think that green is a fun color that also pairs well with the colorful nature of my projects. On the pages themselves, I used the green mainly to differentiate titles vs details. Although I don’t know too much about different typefaces, I also tried to use sans-serif for the titles and serif for body text to further delineate and group information. I think that I’ve also improved upon lining up the margins of different divs, but I still need to work on how I limit and organize the white space on my site.

Another component to my project that I would like to mention is the process of getting my portfolio onto the web.

This was entirely new to me and I went through tons of tutorials on how to use A records, installing Node and other tech to my VPS, and setting up Nginx and config files. The only part of deploying a website that I was familiar with already was using Cyberduck to get the files from my computer to the server. It took me a few days to finally get everything set up, but it felt amazing once my website was actually online! Now that I know everything involved in deploying a website, I feel much more prepared for any web based project I do in the future. In fact, I would rank this knowledge as the most valuable thing I’ve learned during this course besides React itself.


Image slider component:

Virtual Private Server: Digital Ocean

Final Project Proposal (Krom)

For my final project, I will create a new artgame. The purpose of this game is to explore issues of the environment, especially how capitalism incentivizes the destruction of the environment.

The player will take the role of a ranch owner who invites NPC adventurers to their property and can issue challenges to the adventurers in the same spirit as mmorpg quests; kill x number of a certain monster, collect a bunch of a specific herb. Unlike an mmo world, however, the ecosystem in my game will not regenerate after a few minutes. Instead, it will be simulated through actual environmental models. The player will have to balance maintaining the environmental stability of the ranch property with making money off of the adventurers and maintaining customer satisfaction.

The player may choose to issue plenty of quests and make tons of money from the people coming to prove themselves at the ranch, though the environment will quickly deteriorate. Once the ranch starts to deteriorate, the player will have the option to import flora and fauna from other places. Of course, there will also be a negative ecological impact on these places. The game will continue into the player has completely ruined the environment of this world.

The second way to play the game is to tend the ranch and nourish the environment without handing out many quests. Developing this way will be very slow in comparison to maximizing profit, though I can imagine a player getting the same kind of relaxed enjoyment out of this as from a game like Stardew Valley.

This game is extremely ambitious, and I know that I definitely won’t have all the systems working in time for the final. However, there are a few basic mechanics that I believe I can have completed. My goal is to have at least one quest that the player can give out as many times as they like and have this quest deplete the environment accordingly. I also want to have stats for how much money the player is making, and the satisfaction of the adventurers. The two stats going up should be in stark contrast to the actual visuals of the environment.

Since I envision the game as mostly UI based (the player uses buttons to indicate which quests to issue, to buy more land, to import more animals, etc.), I think that Unity 2D will be the best choice. I will utilize many of the button UI features that Unity offers, such as event listeners. To represent the state of the environment, I will create a simple plant sprites using pixel art, and primarily use color to indicate the environment’s health. The plant sprites will start out a very deep green and transition to yellow and dull brown to represent decay.


I knew from the beginning that my artgame’s concept was extremely ambitious. Although I did not accomplish everything that I set out to do, I’m pretty satisfied with what I managed to accomplish with the time constraints.The biggest change that I made from the proposal to the final is using React.js instead of Unity. Because my game is essentially all UI, all of the physics and other features of Unity were overkill for my needs, and React allowed me to prototype much more quickly. There is, however, one big downside to React. It does not have a built-in loop, so the passage of time cannot be represented properly. Change only occurs when the player submits some input. As a result, I had to remove one of the main ideas listed in the project proposal, the accurate lifecycle simulation in which birthrates and aging are affected by the ratio of male and female animals, children and mature animals, and habitat limitation. This type of simulation is not only very complex, but also dependent on time.

Despite this big change, my game still adheres to the core idea that I wanted to explore, the interplay between the environment, consumption, and business. Although the gameplay mechanics weren’t completely clear or developed in the project proposal, I think that the systems I have now do a good job of reflecting my intent. On the surface, the gameplay is very direct. The player issues a quest to slay animals. This makes the adventurer happy, negatively impacts the environment, and makes money for the player.

The game becomes more complicated once the player wants to improve the environmental conditions. One quest allows the player to get the adventurer to tend to the ranch. This quest will improve the environment and add an additional animal if the player has at least two of a species. The downside is that the player must pay the adventurer the maintenance fee, and the adventurer gains no satisfaction. However, I also programmed it so that it the environment has an A rating, the adventurer actually will gain satisfaction. I included this to show that there is intrinsic value to having a beautiful environment, even if business’ see little monetary value in it.

Another system that affects the environment is how animals are replenished. There are two ways to add more animals to the ranch, the aforementioned quest to tend the ranch and the shop tab. Only tending the ranch actually improves the environment rating, however. If the player simply imports animals in from other places, it doesn’t actually make the environment better. I chose to make the game work in this manner to highlight that it is unsustainable to keep taking in resources from other places after we have already depleted our own. Instead, we need to take care of what we have and establish stability.

When considering where to take this game in the future, I would definitely start by remaking my current progress in an actual game engine. After the current prototype is ported, I will start working on the realistic simulation elements mentioned above. Another change to include comes from something I noticed during playtesting. Everyone tries to click on the animal sprites, but they are not clickable at present. This has caused a lot of confusion for players, and in the future, I will definitely make them clickable. Selecting an animal will bring up detailed information about it such as its age, species, species’ birthrate, and how many other animals of that type the player owns.

More changes to be made that will affect both the current state of the game and future iterations are numbers tweaks to adjust the overall flow of the game. This includes changing the amount of gold per quest, the pricing on each animal, and the effect of each quest on the environment. Determining how much to tweak these values will require extensive playtesting, but I’m excited to move forward in this game. Finally, I would like to make the adventurer’s satisfaction rating more expressive. Currently it is only a number, but I want to consider more ways to reflect the satisfaction visually. Ideally, the happy adventurer and the decaying environment will create a powerful contrast that will encourage players to get involved and active or at least start thinking about their consumption habits and how they can influence businesses.

Sourcing: None of the art was created by me. The background forest, deer, moose (I can’t find the moose again for some reason), and adventurer were all images that I downloaded from online.

As a framework, I used React.js, but no other outside libraries. All of the game code was written by me.   

Capstone Second User Test (Naimark)

For this user test, I had the players run a full version of the game, minus hardware. In particular, I wanted to make sure that the hints I created actually pointed intuitively to the solution. After uncovering around 3 or 4 hints, as well as investigating the square with the ghouls, the players were able to deduce which location was the correct one. Because of the small board size, the game only took around 10 minutes to play, which is much shorter than my original expectations. However, I think this is okay because the game simplifications make it easier to play test, and I believe that I can easily scale the length and complexity of the game in the future.

Users really liked that the computer moves the content around to different locations each time the game is played. This makes it interesting to play more than once. However, users did suggest that I add in a larger variety of hints. Even though the hints are in different places each game, they are still the same hints every time. Therefore, one of my next steps is to sit down and write a bunch more content. My goal is to have three times the number of hints I have right now.

Players also responded positively to the artwork of the board. The roads made it clear which locations were connected and could be moved between. The art also helped to group the location squares into areas, which is important to be aware of because of some of the hidden rules.

One aspect that users struggled with is going back to try and remember how many moves they had used in a round. This is promising because my use of technology is meant to solve this problem. Once the hardware is properly connected, the display will inform them of the number of moves they have left, without them having to retrace their steps


Assignment: Pushing Against Boundaries Unowned Collected (Krom)

In a previous class, Generative Language, I created a project that uses existing board games as source material to generate a new game. This was done programmatically by breaking up the rulesets into sections and analyzing them with natural language processing. The program then generates new rules based on the words analyzed.

This is the final, styled version of the game that I generated.

This is some of the raw output from the program. Formatting this game would look something more like

away! Striking

Objective: With their setting, Solve are a hot commodity. Collect resources to drinks and crossword treasures and monster, your slang, is the dice. 

Setup: They must be on the premises! Look on the gameboard for the start space and suspect name Make You. 

Gameplay: Move that hero, begins to move from the passages following these steps, starting with the most knights in a particular room.


I wanted to create this piece to express how games exist as art, specifically generative art. In Generative Language, we were given the definition that generative art is art in which the artist creates a system of rules which must be followed, and the product of following those rules is the subsequent art. When the professor explained this, I was stricken by the realization that games are a form of generative art. The game designer is the artist who creates the system, and the players follow those rules to create art, the experience of play.

My game is a more literal example of this underlying concept. It was produced with code as a piece of generative art. However, I wanted it to be relatively indistinguishable from a normal game. In many ways, the game I generated follows existing conventions of board games. The rule sets of board games tend follow a traditional structure. For instance, the first section is typically an introduction that lays out the games theming and the objective of the game.

Boss Monster

After that are instructions on how to set up the game board or pass out cards in the beginning. Then, there is typically a description of the actions that you can do on your turn. This third section usually goes into more detail about the gameplay and procedures. My mod recognizes that there are different goals and ideas underlying each of these sections and therefore processes and creates these sections separately. Furthermore, after generating text to serve as the rules, I also designed a layout with visuals from the games to serve as a rule booklet because this is how games are typically presented.



In this regard, I feel that my project rests comfortably inside the boundaries defined by the institute of games. I very much wanted this project to be perceived as a game. However, this is done in service of making a statement about the intersection of art and games. Moreover, the statement is not only relevant to the context of this piece, but also an assertion about all games.

The statement, that games are generative or performance art, is more directed towards the institution of art and heavily inspired by Sol Lewitt’s wall drawings. His art was as much about the rules he defined as it was about the interpretation of the person following it. The instructions for his wall drawings were often intentionally vague so that the person following them could interpret them in a unique way. Game rules are often the same way. In a strategy or card game, different players will perform different actions and strategies within the rules. I hope that by creating an art piece that embodies what makes games generative art, people will be able to extrapolate that most, if not all, games exhibit these same characteristics.

Final Project Design Research

For my competitor research I did a combination of searching for existing portfolios and looking around on to see what people have said about portfolios. On reddit, the most commonly given advice about portfolios is that you need to clearly communicate if a project was a team effort, and if so, explain exactly what your contribution was. People in the industry also commented that they want to see some of your process. They want evidence of how your project evolved over time, not just the final result. Another piece of advice was to have your portfolio show only the type of work you want to do, but I am still considering whether or not I want to only have games or include stuff I’ve made as well.

When looking at examples of portfolios, both game and non-game ones, they seem to always put the work first. I originally thought I should introduce myself, but I now think that it is more important to show my skills. Another aspect that seems to determine how successful a portfolio is how quickly it loads. Hiring managers are often in a rush, and waiting for a site to load is a waste of their time. I would still like to include a demo of my games, but if this comprises the loading time too much, I will scrap the idea.

User Stories:

  • As a user, when I land on the website, I can tell that this is a portfolio and know whose portfolio it is.
  • As a user, when I land on the website, I see a header bar with navigation buttons, a photo of the portfolio owner, a description of them and their work, and preview images of their best work.
  • As a user, when I hover over a preview image, the name and some information about the project is displayed
  • As a user, when I click on a preview image, I am brought to a detailed project page
  • As a user, when I view a project page, I can see detailed information about the project and additional photos or videos
  • As a user, when I click on the navigation buttons, I am brought to a grid view of preview images for all projects in that button’s category.
  • As a user, when I navigate to the project page of a game project, I will be able to play a short demo of the game in the browser without having to download any files.

Final Project Idea

Like many other seniors, I need a portfolio site to display to potential employers, so I will create one using React.js. To be more specific, I want to get a job in the game industry, and that goal will inform many of my design decisions. To better support this purpose, my portfolio UI needs to be able to show off the games that I’ve made.

I want each game’s project page to include a playable version of the game. Most existing portfolios include screenshots and/or gameplay videos, while a few also have a download link to the game. However, I don’t think many employers will bother to actually take the time to download and play a game. Embedding the game into the portfolio itself will make things easier for employers and increase the likelihood of them actually engaging with my work.

In addition to this, each page will also include typical information that employers want to know, such as if the project was created solo or as part of a team, what technology was used, etc. Previously, I considering integrated this information into the project description. However, when I was doing design research, I found a portfolio from someone in the game industry that communicates all of this info in a way I really admire. David Shaver organizes it in a neat, easily readable column to the left of the project description, and I will probably copy this aspect of the layout.

Capstone Midterm Progress Report (Naimark)

Changes From Proposal

Two big changes have been made regarding the technical specifications of my project. The first is that I have decided to use Python for the underlying game logic and control instead of Processing. I made this decision because I am more comfortable programming in Python, allowing me to prototype and develop more quickly. After doing some research, I was able to find Python libraries that support many of the same features of Processing that are important to my project, including serial communication and openCV.

The other main change I have made is moving away from using rfid to track player locations. After drafting out the board layout, I realized that I would need twelve rfid readers, one for every square. That did not seem feasible to execute. Instead, I will use a camera tracking solution. Leon suggested color tracking to me which sounds like an excellent solution, though I will still do some research into other possibilities.


Game Design

The structure of gameplay has been made totally concrete. This includes the unique abilities of each playable character, the type of actions players can perform on their turn, and how to win the game. After more user testing, I will make small numbers tweaks for balance such as the number of actions per turn or the probability of finding a certain item. However, the core rules and systems will remain the same. I have a few different drafts written of the “Official Rules” that show the progression of the gameplay as it has changed over time. I have also written a short backstory for each of the playable characters.

The premise of the game is that ghouls have been causing mysterious disappearances in Haven City. The players have talked to a priest and learned how to cleanse the city of the ghouls. They must find 3 holy items, and bring them to the heart of the ghoul’s nest in order to cleanse the evil once and for all.

The game takes place over 7 rounds, analogous to a week. At the beginning of each round, the narrator will state the day and then players will take their actions. The flow of gameplay is as follows. 1. Players confer with one another on where to move. 2. Movement occurs. 3. Players choose whether or not to use an investigate action on their current square. These steps are then repeated until players use up all of the movement actions for the round. Then the next day begins. If players don’t cleanse the ghouls within a week, they overrun the city, and the game is lost.

Each location on the board has exactly one thing in it. By investigating, players have a chance to discover what’s in the location. This can be either a holy item or a hint. The hints will help players deduce the location of the ghoul’s nest or a nearby holy item.

Technological Implementation

In Python, I have created a fully functional version of the game. This includes a digital representation of the board layout, a function that calculates the total number of moves it takes to move from one location to another, and verification of whether or not a player is actually able to reach that location. The information for the board layout is described in a JSON file that gives each location a name, a unique ID, a list of which locations it is directly connected to, and whether or not players need to climb in order to reach it. Python then interprets the data from the JSON to instantiate objects of the Location class. The movement calculation function is my implementation of Dijkstra’s algorithm. My Python code also applies the character’s unique abilities, and can now take into account when players are standing on the same square.

I have also decided to procedurally generate the content of each board location. Similarly to the act of shuffling a deck, this adds a bit of randomness to the game’s setup that improves the replayability, with the advantage of requiring less setup from the players. The location of the ghoul’s nest is different every time the game is played, as well as the different hints given when investigating. Some hidden rules are followed in generating the content, which ties into the gameplay. For example, a holy item will not appear in the same general location as the ghoul’s nest. Finally, I have begun to work on the serial communication between Python and Arduino. I have researched and installed the pySerial library, and I have successfully sent data over serial communication to the Arduino. I am currently fine tuning how Arduino interprets the data and how to send data back to Python.

Reactive User Interfaces Midterm Documentation: Commune Address Book WebApp


For my midterm, I created an address book app meant to be used as an internal communications tool for a company. Many large companies have several different departments, such as an HR department, Accounting department, etc. Companies with multiple products will also have separate interdisciplinary teams for each product. I designed my address book with the need to communicate with and across teams in mind.

Recontextualizing the assignment to fit my vision, I added the department that a contact works in to the information displayed on a contact card. I also changed address to be the location of the company’s branch offices. When sorting the list, in addition to first and last name, the user can also sort by department and branch location. The contact list can also be filtered by the department.

Additionally, my address book includes a list of teams to the right of the list of contacts. Using the list of teams allows the user to send a group message to everyone in the team. The user may also use the team list to find the contact card of a single member of the team.

Some use cases that I can imagine for my app include some of the following:

  • The leader of a team wants to message everyone about a meeting
  • A higher up needs to find the leader of a certain project
  • A team completes a prototype and wants to send it off to QA for testing
  • A programmer on one project heard that the programmer on another team implemented a similar function and wants to seek advice from them.

Component Overview

The app’s main component is the Contact component.  This component receives a first and last name, department, address, and image as props. Each Contact also features a message button. The callback function associated with this button causes the app to render the Messagebox component and takes the Contact’s name as an argument.

The Messagebox component consists of 3 input fields. The “To” and “Subject” areas are both normal text inputs, while the email body is a text area. The message recipient is fixed based on the contact that triggered OpenMessageBox function and cannot be changed. The Messagebox component has its own state with separate fields for the subject and the body. These values are set with an onChange function attached to the input fields. The Cancel and Send buttons both call the same onClick function, which resets the state of the subject and body back to an empty string. The onClick also calls the callback function that tells the parent App which button was clicked, and plays a CSS animation of a “message sent” notification if it was the Send button.

The Search component works similarly to previous input components that we have built in that it contains its own state as an intermediary to the value that gets rendered in the actual field. Upon updating, the Search component tells the app what’s inside of it, and sets the parent app’s Search state to that same value. The search is applied in the parent’s render function and searches first and last name. The search is not case sensitive. Originally, I also allowed for searching by department. However, this filtered out a lot fewer contacts when typing in the first few letters, making it more difficult to actually find the contact you want by searching. Additionally, that functionality overlapped with the Filter component, so I eventually decided that it was best to remove searching by department.

The final component is the Team component. This component is very similar to the Contact component and shares much of the same CSS. However, its props vary slightly. Rather than a first and last name, it only receives a single team name. The Team component also receives a list of the team members and their position titles. Like the Contact component, the Team component can also open a Messagebox, setting all of the team members as the recipients. Notably, each team member’s name can be clicked, which will isolate their contact card in the list of contacts on the left side.


  • CSS. CSS and general aesthetic design are two of my biggest weaknesses
  • Figuring out how to structure the messaging functionality. Although the Messagebox is its own component, in the beginning I was unsure what it should be a child of. Because the Contact component is the one that contains the button that triggers the Messagebox opening, I thought that it should belong to that component. However, there are several Contact components and I only wanted one Messagebox. After considering, “what’s a React way of doing things?”, I concluded that the main app should track whether the Messagebox should be open or closed in the state. When the Messagebox field in state determines that the Messagebox component should not render, it adds the “Off” class to the component. This class’ style is set to display: none. The callback function associated with the Message buttons, openMessageBox, removes this class.
  • Allowing for clicking a specific member of a team. Originally, I wanted the teamMembers prop to contain references to the actual Contact component of all of the members, but I had no idea how to do this with dynamic components. First, I tried to give every contact a unique id prop, pass the id as a props to the Team component in lieu of a name, and then somehow derive the correct information from the state’s contactList. This was insanely complicated, and I could not figure out how to make it work. I later realized that my goal was essentially just filtering, which my searching function already does, so I added another callback function that calls the same function that sets the search term in the parent app. In addition to showing only the clicked name in the list of Contacts, the name also appears in the Search bar. This has the added benefit of being able to return to the default state of the app by simply clearing the Search bar.


  • My friends Jamie and Kate for giving feedback on the color palette, side margins, and general layout.
  • Black Panther’s imdb page, which I downloaded all of the images from.

Capstone First User Test (Michael Naimark)

For my first user test, I had 3 players test the action/movement system of my game. I used a cardboard prototype of the board, and tasked the players with travelling to every square and attempting to activate it by flipping a coin. My two main goals were to determine how many rounds it takes to explore the board and to observe what strategies players would adapt with regards to each character’s special ability. First, I verbally explained the rules to the players, and then I observed them playing. The users all played the game with each other twice.

While explaining the rules, all of the players expressed some confusion. However, when they asked clarifying questions (example: “So on my turn, I can take x action?”), they typically had the right idea. One user suggested that it would be helpful to have cards that list everything that the player can do.

The most helpful thing that this playtest revealed is that the balance of character abilities is very off. During the first playthrough, the players decided to give almost all of the movement to one character, so I believe that their ability is too strong. The users also noted that to let the character whose ability is to climb inaccessible locations feel impactful, there needs to be more inaccessible locations on the board. During the second playthrough, I changed the rules from the first. The first time, two characters could not be on the same location on the board. The second time, players could be on the same location, and they could use each other’s special abilities when sharing the location. Although this rule was part of my original conception of the game, I got rid of it because of the difficulties involved in programming it. However, the players definitely had more fun with this rule in place, so my next step is to get that working in the code.

Both of my goals for the play test were met, so I would consider the session very successful. I learned that it takes 3-4 rounds for players to activate every square on the board. Players also communicated and worked together throughout the entire game, which is exactly what I wanted. However, all of my users knew each other beforehand and are friends, so I would like to see how the dynamics are different between people who may not know each other as well. Before my next user test, I want to incorporate all of the feedback that I got from this test. In addition to programming the rules to allow location/ability sharing, I will also work on the design of the board layout. I also want to conduct the next test with written rules instead of me dictating them.