Hi, I'm Collin Eye, a game designer and programmer based in Dallas, Texas. You can contact me at collin@etalgames.com
This portfolio has details on significant projects that have either been released or reached a natural end. I think of myself primarily as a game designer interested in expressive systems. However, because I build my games in an in-house C++ engine my work involves a lot of systems programming.
DEVELOPMENT INFO
Team size: 6
Role: Project lead, gameplay programmer, composer
Time: 2 years
Tech: Custom C++ game engine, Dx3D 12, Vulkan, Steam Deck
Links:
Steam Page
Trailer
SUMMARY
The Art of Flight is an action game about flying multiple ships at the same time. Shift your focus from ship to ship as you play out an epic space battle full of moments of sacrifice, comradery, and daring.
The Art of Flight is an arcade-style top-down shooter developed part-time over two years in our C++ game engine etcetera. I was the project lead, composer, and gameplay programmer, but I did a fair amount of engine development as well. There was one other programmer for 9 months of development, and 4 contract artists. The bulk of my time was spent on gameplay code and design. The core design-pillar is that you control a squadron of multiple ships at the same time. My goal was to explore all the thematic and gameplay moments that fall out of that system.
My process designing the game was to find what the game was telling me as I played -- when was I engaged, when was I bored? This led to the most interesting design elements of the game. Each enemy was designed in a way to subvert some rut the player might fall into. Spending too much time at the bottom of the screen? The Interceptor will bob below you and shoot up. Trying to cluster your ships together to avoid spreading your attention too far? The Manta Ray will tear through your formation with its laser. I found the most engaging part of the game was any time you had to spread your attention. This happened the most when you were playing “out of position”, like when your squadron is split into multiple clusters, or when a ship you just rescued is hanging on its own until it can regroup. I found a few mechanics to make that happen more often.
“Rivers” are obstacles that will draw in one of your ships and send it floating along a track until it emerges at the end. “Portals” give you a multiplier for each ship you send through, but because they pull nearby ships in you don’t want to group too tightly, otherwise you risk letting too many ships escape. “Solo” is your special ability that you use to freeze time for everything but one ship which you can control until your meter expires. This was my answer to one of the main design questions: “how do you control your formation?” The solo ability gives the player very high expressive power in how and when they arrange their squadron. They might activate solo to dodge a projectile only to find themselves flying that ship around asteroids as its distant companions scrap with bogeys.
I took the game to a number of conventions to get plenty of hands-on testing and feedback. After taking it to DreamHack 2023 I thought it'd be a good idea to have a local co-op mode for conventions. This mode turned out to be a lot of fun, and was one of the main draws as we took it to PAX East and West, and Play NYC in 2024, along with another two showings at DreamHack in 2024 and 2025. The co-op mode was expanded for four players, and I also developed a versus mode the players compete against each other to see who can hold onto a glowing orb the longest as they fight together against waves of enemies.
I led a team of 4 artists to model and texture all the objects in the game. The design needed a strong contrast before background and foreground objects, and one of our concerns was how to do that without restricting the color-palette of either. The easiest option would have been to keep the background black, or at least sparse. But our initial vision was water-color inspired nebulas. We achieved this by writing a data-processor that took in textures painted by our background artist, Kalish, and generated bundles of “splats” which would be rendered like particles. There was a bit of work done to reduce over-draw, especially important since there was a lot of alpha-blending of particles. For the fore-ground objects (ships, projectiles, obstacles), we drew an outline around each ship, which helped to distinguish them from the background which, unlike space, had no black. That created contrast, but there was too much. The ships were just flat, cel-shaded colors. The concept art we had from Jose Esquivel had a lovely texture we wanted to come through. But just painting that onto the texture itself made them look splotchy. So we decided hand-paint normal maps so that the ships would look painted (albeit in a rougher style than the backgrounds). That way the ships would respond in interesting ways to the lights. Did I mention that each projectile carried a point light?
I expanded the musical ideas from previous work on Changes and Plura Tune-A to create dynamic music. I was very inspired by minimalist composers like Steve Reich, and Terry Riley, as well as the work Suzanne Ciani did on pinball machines. The idea was to treat each in-game event like a “voice” in a musical piece, so each event is a sequencer defined by a simple script file. Each voice has its own rate, so for example if you have a voice that fires every 0.2 seconds, when you signal it, it won’t actually play the sound til the next tick. This is how all the events are in-time. But because each voice has its own rate you’re able to create poly-rhythms, and as long as the voices sync each measure it stays on-beat. Learning how to play this instrument took a lot of experimentation and sometimes involved writing new features. One of those was the “tag” system where any voice can add a tag, and then any section of a voice could query for a tag. That way it was easy to get disparate voices to play in the same key, without requiring that all of them line-up by having the same duration. For example the voice for the Seeker enemy might have 4 sections that play around the “root” chord, but 2 other sections that could play around either the “ii” or the “V” chord. Another thing I had to experiment with was mixing and arrangement. There are a lot of voices in the game, and selecting a suite of instruments that all sound good together, without stepping on each other's toes, was an interesting but often flailing process. In the end I found something that sounds very unique and helps to convey the somber grace I wanted to express.
We wanted the game to launch on Steam Deck so I worked to optimize the rendering and physics loops to sustain sub-16ms frame times on Steam Deck. The rendering improvements just involved rendering into lower-resolution targets and upscaling in the final pass. But the peak entity count that could reasonably be encountered in game is around 7000 entities (this happens when the player activates the spread-shot ability where each player ship fires 5 shots at once). If you were controlling a squadron of 30 ships (unlikely to occur but not impossible), that winds up being a lot of projectiles! To do this I leveraged my knowledge about the data. Our physics system is relatively general and naturally updates the transform hierarchies each tick. But the projectiles don’t ever rotate after their initial spawn, so we did not need to spend time computing the quaternion based on the yaw and roll.
Another optimization was to multi-thread the particle system.
DEVELOPMENT INFO
Team size: 3
Role: Project lead, gameplay programmer, writer
Time: 2.5 months
Tech: Custom C++ game engine, Dx3D 12
Links:
itch.io
SUMMARY
A card-game about translating a poem from Spanish into English.
Found in Translation was an official selection of the Experimental Game Showcase at the Game Developers Conference 2025.
It is a game about translating a poem from Spanish to English. I wanted to capture some aspects of translation, such as interpretation, diction, and problem-solving as you balance the tension between poetic expression and accuracy of translation.
There are three types of cards: “words” which you write down on the page, “ideas” which are played to the field, or “narration” which have key-words that can trigger those “idea” cards. With the cards you explore the translator’s mind, exploring possible renderings of a phrase, and triggering associations between the words of the poem and the character’s own thoughts.
The key to the design is that you write down a word at a time which means the player has a lot of expressive possibilities within the poem. But when coupled with the associated words that pass through the character’s mind it means you have a much larger word-bank than you initially realize, which expands the range of things you can write about beyond the poem itself.
I created a transaction system to handle card actions and animations. Cards are defined in a custom data-format in a plain txt file. Each card has a list of commands which are executed when played.
The first version of the game was done over two weeks for a game-jam by myself, Kalish (art), and rosko (music). The core of the game was designed in that period, but I took another 2 months to polish the design and user experience, which involved polishing the tutorial, making it easier to place and remove words, and giving the player multiple pages which they could use as a scratch pad as they work on their translation.
DEVELOPMENT INFO
Team size: 1
Role: Gameplay programmer and composer
Time: 1 month
Tech: Custom C++ game engine
Links:
itch.io
SUMMARY
An audio-only music game about weaving patterns.
This was done during development on The Art of Flight as a vacation project to explore some some musical ideas. I wanted to take a fresh approach to instrumentation to see if I could learn more about mixing and arrangement, which I did.
The game has no visual element other than the control prompt on screen. There are one or more sequencers that are always playing, and then the face-buttons on the controller will trigger a corresponding "silent" voice to play. The goal was to capture part of the experience of composition where you are pulling melodies out of the air and playing with the music that has already been written.
DEVELOPMENT INFO
Team size: 3
Role: Project lead, gameplay programmer, writer
Time: 6 months
Tech: Custom C++ game engine, Dx3D 12
SUMMARY
A short first-person narrative game about two people talking. Unreleased prototype.
Typically narrative games present very discrete choices to the player, usually in the form of dialogue trees. I wanted to explore the types of choices that could be made when the player has no control over what their character says, only how they say it. How much are they able to express thru movement and interaction with props?
I implemented a skeletal animation system along with an animation exporter for Blender. The animation system supported layer blending, which we made much use of in the design, having a separate layer for the head, torso, arms, and legs.
I worked with the animator, G, to choreograph the scene. The game was more like an interactive cut scene where the player acted opposite the NPC, which needed to have reactive animations so that it was clear to the player they were responding to their input. I had never directed any blocking or animation work like this, and it was a lot of fun to act out the scene ourselves and improvise ideas before committing the resources to keyframing the animations in Blender.
The technical achievement I'm the most proud of is the IK system. The game in its present form does not feature stairs or inclines of any kind, but it does involve a lot prop interactions and even interactions between the characters.
Initially I tried an iterative approach to solving the IK chain using Cyclic Coordinate Descent. This yielded fine results, but it felt a little robotic, and the code was pretty unrefined. Before improving the implementation I wanted to take a fresh crack at it from first principles.
What I found was that the solution I needed was almost always about getting the arm to a point. There are some interesting things we can leverage there. First, we can create a plane between our destination point and our shoulder. Then on that plane we know that the start of our forearm must lie somewhere on a circle around the point, where the radius of that circle is the length of our forearm. If we also take a circle centered at our shoulder, with radius equal to bicep length, then we have 2 possible points where our forearm can be, and it's as simple as picking the one that rotates our forearm the least.
This system was used to animate the player grabbing a glass, reaching for a door knob, and for your partner placing her hands on the player's shoulders.
It was a very fruitful experiment that taught me a lot about animation and narrative design, but continuing development was beyond my scope as it would involve much more art and animation resources than I was able to invest.
DEVELOPMENT INFO
Team size: 3
Role: Project lead, level-designer, gameplay programmer, writer, composer
Time: 2.5 years
Tech: Custom C++ game engine, OpenGL
Links:
Steam Page
SUMMARY
A block-pushing puzzle game set inside a cellular automata where each level tells a story about the transformations caused by life and death.
The majority of the programming on Changes was done by me, with some help from Heather Zeis at the beginning and middle of the project. She implemented the animation system and did early experiments with rendering styles.
The movement was implemented using a transaction system to verify that a move could successfully be completed. Each move transaction was stored as a diff so that the player has full undo history.
Rendering is done by taking a tessellated quad and offsetting the verts. The cell data (such as height and position) is passed to the shader with a buffer object. We use the vert index to lookup which cells affect that vertex and offset it accordingly. This plane is rendered 8 more times at a positional offset to create the mirrored effect. The noise is sampled based on the world position to make sure that there is not a discontinuity between the “reflections” at the seams.
The pads underneath the water are rendered using subsurface scattering. I used the technique detailed in the wonderful talk on the topic by Marc Bouchard and Colin Barré-Brisebois. I created a tool in engine to fiddle with the values and see results in real-time.
To minimize loading times all assets are loaded into different memory arenas based on their lifetimes. This makes it trivial to unload assets. We avoid frame hitches when loading by making sure to load the assets in the background in a separate arena so we can simply swap between the active data. GPU resources are also allocated up front and updated as next textures come in.
One feature I'm very proud of is the dynamic audio system where music is created entirely from in-game events. Each turn of the game we play sounds for all the events that happen in the game (cell birth, death, player movement, etc). We use a "liszp" file to specify which sounds play for each event on a given turn. We can choose to play a random note from a pool, or play things in a sequence to create an interesting wind-chime effect where the sounds of your last move echo as you consider your next action.
DEVELOPMENT INFO
Team size: 2
Role: Project lead, gameplay programmer
Time: 1 week
Tech: Custom C++ game engine, OpenGL
Links:
Play the game here.
SUMMARY
An interactive montage of music box games.
This was done for the Lunar Game Jam hosted by the Dallas Society of Play over one week in 2020. Inspired by Brian Moriarty's Perlenspiel engine, I wanted to try making something very simple, partially as a demonstration to students, and to experience for myself what they would go through working in such an engine. The engine, called Mosaic, was written in C++ and offers an API for interacting with a grid of tiles. A modified version of this engine is used in the game design classes I teach.
I went in wanting to use a montage of short game-vignettes in a relaxed and exploratory way to let the player experience and think about the moon in different contexts. The game turned out to be something of a playful music-box that shifts from the cosmic to the intimate. My brother, Riley Eye, contributed music and design ideas.