image of sam springer

sam is a well rounded ux enthusiast who likes to stop and question the little things, like why stucco is so common on ceilings and whether capitalization is really necessary. while sam's list of hard skills spans a long and eclectic journey from rigging up electronics for art installations to building systems for viewing pointclouds in game engines, if you somehow find a skill they don't have they're more than willing to learn it. between 4 years of university at siat and 3 years of working for six12 creative, they had a bit of free time on their hands to work on some projects you can check out to get a sense of their style.

hi, my name is sam


ptp card image

pt & p

pt&p is an app designed to help physical therapy patients. Its role is two-fold: first, it allows patients to get helpful information on how to perform their exercises along with convenient reminders to nudge them into keeping a consistent exercise schedule. next it allows patients to communicate with their pt when they need to most. this means that patients experiencing any pains during or after their exercise can send quick note to their pt. a project site detailing the process and interactions can be found here.

grindstone card image


grindstone is a game about, at its core, my experiences living with adhd. it makes use of void-like atmosphere and deep ambient rumbles to separate the player from external stimuli, isolating the player from their environment beyond the frame of the screen. the player is then presented with 6 doors, one of which they have to walk through.

image of a door with the number 1 on it, text underneath says 'hey there, welcome! this is a pretty simple game, all you need to do is enter a door to add the number of points on the door to your score. you only have five tries, so aim for the highest score you can!' image of a door with the number 4 on it, text underneath says 'really? are you stuck or just lazy? seems to me like you're not trying hard enough, door 3 looks more your speed.

what they don't know is that the door they have to walk through is pre-selected at the beginning of each round, and the movement mechanics are altered from a list of manipulations that force the player to chose the preselected door. there's more detail in the about section of the game, but i used these movement mechanic manipulations to simulate how decision making can often feel for me by playing with the agency that a player expects to have over their character's movement. this lack of otherwise expected agency creates an uncomfortable feeling of being trapped in the player character's whims, as if the player character has decided which door to move towards. this feeling closely mirrors my own decision making process growing up, often knowing what i should do lacking the ability to execute it as my brain had already allocated the energy elsewhere.

you can find the game on my page here.

lux card image


lux is a game about the player building a bond with an object through action rather than words. the task was to create a game that had a branching or foldback narrative structure, and lux was our solution. we found it interesting to work with the limitation of not providing any text for narrative, but ran into some issues along the way.

the first was player engagement. during user testing, we discovered most users didn't want to interact with the orb we placed in front of them. regardless of if the orb had any sort of visual indication that it was interactable, players still had issues interacting with the orb. to get around this, we decided that an introduction section that outlined how to play was the quickest solution.

an image of the intro section of lux, text on screen says 'Use WASD or arrow keys to move. The orb is your friend. Trust your friend'

the narrative structure of lux was made to be foldback, with narrative choices diverging during the level but not changing the ultimate path the user wound up on until the very end. this meant that we had to have distinguished "right" and "wrong" choices for the player to make during the game. this came down to a simple junction the player would be forced to walk around in.

an image of the junction in a level in lux

this junction served as a way to force the player to make a choice, but also served as an opportunity for the player to grow closer to the orb. typically, when a player interacts with the orb, they're simply touching to move it forward. in the junction however, the roles are reversed. the orb will follow the player until one of two things happen.

an image of the player stuck on an obfuscated obstacle after the junction

the player reaches an obfuscated obstacle after the junction if the orb is following them. this obstacle isn't impossible to traverse without the orb's help though, meaning a player can brute force their way through using the jump key. however, if the player touches the orb it will fly in the opposite direction, to the other branch of the junction, and highlight the obstacle to help make it easy to go over.

an image of the obstacle and the junction deobfuscated by the orb

once past the obstacle the player faces the same leveling platform section, but if the player forced their way past the obstacle instead of going back to follow the orb they're greeted with the hollow shells of orbs strewn about the ground. we chose this to help convey that there was a reason the orb was weary about this path, reinforcing the idea that the player should trust the orb.

an image of the obstacle and the junction deobfuscated by the orb

lux was a game made in a group project for iat312, foundations of game design. the team members were Max Proske, Joshua Nicolas, and myself; with Max doing most of the work on the obfuscation and lighting, Joshua working on the sound design and animations, and myself working on the movement, orb tracking, and overall look/feel of the game. because it was a group project lux doesn't live on my, but you can find a demo build here

screens card image


screens is a game about relationships. more specifically, how exceptionally difficult it can be to escape abusive relationships. i wanted to make a game that made use of bullet-hell mechanics but the bullets themselves are the letters from messages you recieve from an abusive partner trying to pull you back in during your attempt to escape. there are multiple levels to the game, with the first being one where screens come in from the left and right over and over to try and attack the player, who dodges by moving around on their own screen, until destroyed. in this level, pickups spawn between rounds that allow the player to increase their firing speed, regain 20 points of health, or regain 10 units of health and increase their max health by 10 points (to a maximum of 20).

image of the main screen in the game screens

in level two, the player is faced upwards and their shooting abilities don't work, instead they're tasked with navigating through the messages on a rail to avoid touching the words.

image of the second screen in the game screens

the last level is a simple bullet hell boss screen with one stationary enemy at the top of the screen shooting patterns of bullets at the player who is free to move around the lower half of the screen. drop mechanics on the first level only help the user if they don't retaliate and instead focus on raising their max health, as attacking the messages right away to move on to level 2 leaves the player with only 100 health and the increased firing speed pickup isn't used beyond level 1. through these mechanics i attempted to guide the player in staying calm and focused during the discovery phase, not trying to retaliate right away and instead build themselves up for the eventual break.

you can find the game on my page here.

dot3d pointcloud viewer

a more technical project i was commissioned by dotproduct for recently was creating a tool designed to view pointclouds in 3d space with the ability to fly around the pointclouds and look at the detail captured by their system. to achieve this, i used meshlab to build a low-polygon mesh from the pointcloud data and imported it into unity. from there, i adapted a pointcloud import tool to pull the pointclouds in and generate mesh objects from them, lowering the amount of data required in the end assets as well as the amount of memory consumed while displaying the pointclouds. while not exactly a project i can show off due to the pointclouds being owned by dotproduct, i'd be happy to talk details about how the project works. you can see examples of the imported pointclouds below.

image of a staircase pointcloud loaded into unity image of an apartment pointcloud loaded into unity
dont stop card image

dont stop

dont stop was an assignment for school that i made as an attempt to create engaging gameplay using the simplest control scheme possible (drawing inspiration from super mario bros. and downwell). starting from here, i tried a game where you used two keys to turn a constantly moving object left or right, navigating it around screen. the user was then meant to hit targets to gain points. there were a couple flaws that i found in testing though. first, users were often confused by the object moving without their control so i scrapped the idea of always moving and assigned it to a key the user could press. but this messed with the pacing of the game and made it feel too easy, so the challenge was upped by making the targets threats as well.

image of the default screen in dont stop, with a white background and blue foreground

the user starts off in the default state with the blue triangle on the white background. from here, they move around screen trying to collect targets that match their color and avoiding the targets that do not. in order to collect the targets that do not match, the player can hold the space bar to invert their own color (as well as the background and any relevant information, not including the targets) so that it matches those of the targets they are trying to capture.

image of the reversed screen in dont stop, with a blue background and a white foreground

this helped solve the issue of pacing and difficulty, but now my key count was back up to 4 keys used. while i wouldn't consider the game a success in the terms of using the least amount of keys possible to create engaging gameplay, especially not even close to reaching the complexity of emergent actions that happen in the games that inspired this dev cycle, i learned a lot about how players value their agency through character control which helped me better understand how players interface with games.

since i wasn't a huge fan of how the game turned out i never uploaded it to itch, but you can find the finished concept here.

pablo card image

the life of pablo album cover generator

this was one of my first projects done with a friend, whipped up in a solid 2 hours at 3am the day after the album cover was released. while not as relevant now, it still serves as a good example of being able to adapt a design from physical to digital while keeping the theme consistent across media.

you can find the generator here.