Gary Gould Game Designer/
Programmer
Making games has been a lifelong passion of mine, driving me to tackle a wide variety of projects and technical challenges.
While I’ve worked primarily as a solo-dev, I’ve grown to prefer a team environment. I believe that my time as a solo-dev gives me a unique perspective that enables me to collaborate with team members from diverse disciplines in a valuable way.
I hope my demo reel highlights both the range of my technical skill set and my drive to create!
For the best viewing experience, it’s recommend to access this portfolio on a computer rather than a mobile device
About And Skills
Contact:
GaryDonGould@gmail.com
818-489-1884
“Hard” skills
-Well-versed in Unity and Unreal (8+ years total)
-C# (advanced), C++ (intermediate), JavaScript(Rusty)
-Multiplayer Networking (fishnet)
-Version Control (GitHub, P4V)
-Visual scripting (proficient in Playmaker, UnityVS, UE Blueprints)
-AI behavior and pathfinding
-Photoshop and Blender familiarity
-Shader, particle system, and animation system familiarity
-Mobile experience
-Optimization experience
Design skills
-Mechanics and “Gamefeel”
-Designing AI
-Puzzle Design
-Level Design
-Rapid prototyping
-Game systems and meta-design
-Player Psychology
-Balancing
-Creative Writing
Education
B.A. in Philosophy/Psychology(Joint Major), Minor in Computer Sciences
Hampshire College
In addition to Computer Science, I also have a background in philosophy and psychology. Reasoning out complex issues has been a constant driving force, and that translates well to game development. To subsidize my programming journey, I’ve worked as a bartender and bar manager, which required a high level of people skills and teamwork.
My path to becoming a developer might be somewhat non-traditional, but I’ve been able to apply my skills effectively in a professional team environment. I’d love the opportunity to demonstrate how I might contribute to your team as well.
Reclamation
Worked as both a designer and as one of two programmers 2023-Presnt (still contributing to patches and small updates)
Responsible for rebuilding—and expanding—enemy behavior from the ground up
Helped bugfix existing pathfinding systems
Created a pathfinding system for flying enemies
Designed and implemented enemy and player move sets
My Role:
(Large Collaborative Project)
Sample of Work:
This game presented a unique design challenge when creating enemies, since one of the main mechanics of this game was the ability to “possess” the clay bodies of many of the enemies that you face. Possessable enemies were called “Grimlings”, and had to be designed with a two major things in mind:
1.Each Grimling needed to feel both unique and fun to play
2.Each Grimling needed to have a near-identical set of moves when controlled by the player as it did when it was controlled by an enemy
The challenge was that there is a completely different set of values one should look for in how an enemy attacks vs how a player attacks. A player’s attacks need to feel “fun” and “responsive”, while an enemy’s attack needs to feel “fair” and “interesting”.
To demonstrate this balance, I’ll use the example of the Grimling called “Zappy”:
(Zappy when controlled by player)
Zappy’s one requirement was that it have a dash ability, so that it could to traverse through tight spaces as well as make long jumps. This led me to want to design a move that would compliment the ability to quickly dodge and reposition. I designed and implemented a floating orb that Zappy could manipulate, either by launching it away, or holding a button to pull it back as if it had a gravitational pull. Targets close enough to the orb would get shocked and take damage.
This weapon was suited for an enemy because it allowed to enemy to have a predictable intention: the enemy would either want to push the orb or pull the orb to try to hit the player. It was also suited for a player because it gave the player a lot of options and decisions to make involving positioning.
(Zappy when controlled by AI)
As for Zappy’s AI, once it found the player it would fire an orb, and then use one of 3 tactics based on its positioning:
Option 1: If the orb is behind the player, Zappy will draw in the orb while walking away from the player to make space
Option 2: If the orb is in the middle, Zappy will recall the orb, getting ready to launch another attack.
Option3: If Zappy is in the middle, Zappy will try to dash through the player, then drag in his orb behind him
You can see all three decisions at work in the attached video.
(the “EnemyPlayerOrb” state magnified, one layer down)
(the portion of the behavior tree that keeps track of the current position)
Here’s a few examples of enemy systems I developed for context:
A swarm of bees that use bread-crumb pathfinding:
An enemy that positions itself to throw a predictive projectile along an arced trajectory:
An enemy that knocks you out of your body, and then stands guard over it:
Our team consisted of a musician, an SFX designer, and myself (art, design, coding). We completed the jam in 5 days.
This theme inspired me to attempt two interconnected games set in the same physical space. The player’s actions in one game would affect their success in the other. My plan was that this dynamic would provide a clear and convincing motivation for progression.
I thought contrast would be interesting, so I went with two extremes: a hectic twin-stick shooter juxtaposed with a peaceful farming sim.
In one dimension you’d kill monsters to collect seeds, while in the other you’d plant crops that transformed into objects like turrets, defensive cover, or power-ups. This was my first time making a game in either genre, but it felt like an achievable goal.
Reap and Sow
Theme: “Life in 2 dimensions”
Dimension swapping
Tower Defense Strategy
Economy:
Early on I noticed that players tended to spend their seeds on power-ups like damage or speed, and would ignore the more interesting tower-defense plants.
My solution was to create a rare secondary currency called “fertilizer” which had a dual purpose: to make the player think more carefully when spending their resources, and to encourage the use of strategic plants that only required seeds.
To make progression clear to the player, fertilizer would only drop from a special enemy that would spawn after a displayed kill milestone had been reached.
Gameplay Loop:
At first, the player was allowed to switch between dimensions at will. However, in testing the game I saw that players would become engrossed in combat and forget to swap back to the peaceful farm dimension.
My solution was to allow the player to stay in the farm dimension as long as they wanted, but have their time in the action dimension be dictated by a timer. This had the added benefit of creating an extra layer of strategy: a player might take calculated risks based on how much time was left before the forced dimension shift.
While it may have been tempting to follow players’ natural instincts to keep fighting indefinitely, it was clear from testing that the forced shifts led to a more interesting and replayable experience.
For Example:
An enemy worth mentioning is the “Parsnip Phalanx”, who was created to solve a particular problem: as the game progressed, players were often tempted to try a “turtle” strategy, in which they would surround themselves with defensive plants. I didn’t want to eliminate that strategy—players enjoyed discovering it and it was a reward for experimentation—but once they found it, it took the challenge out of the game.
To counter, I introduced the Parsnip, which held a shield that would reflect projectiles. The only way to kill it was to maneuver behind its shield. As the game progressed, the frequency of Parsnips would increase, forcing the player to adapt to a more mobile strategy.
Staying alive until the timer swaps dimensions
Difficulty:
Players have less patience for jam-made games, so too steep or too shallow of a difficulty curve is enough to end a playthrough early and land you with a negative review.
It’s important to create a brief and entertaining tutorial, as well as have a ramping difficulty with obvious indicators of your progress. To this end I made sure to introduce new enemies as the game went on, as well as teasing some higher-cost plants.
While it has the very rough edges of a jam game, I’m happy with how this turned out.
If you’d like to see how the game was received, check out the comments on this page:
( https://itch.io/jam/gamedevtv-jam-2023/rate/2093023 ) )
hybrid tower-building/defense + puzzle/platformer
Solo Prototype
Almost all of the projects in my demo-reel were solo projects. I’d be happy to share more about them -- feel free to ask! Here’s a small excerpt from one such project:
I wanted to create a game where every element of gameplay blended seamlessly into the next. All the UI would be interactable objects in the game-space. Progression would center on collecting physical parts that you could attach to build a tower that was ever-increasing in height. I wrote a short essay here that might explain why I thought this was a goal worth pursuing.
To make the game feel seamless, the game’s building mechanics, traversal mechanics, and UI are all ostensibly one mechanic with one set of controls. Each player has a extendable robot arm that can grab objects, swing from them, drag UI elements, and manifest items: while the player can easily throw a light object, when trying to move a heavy object, the player will move themselves more. I selected some clips from a playtest where you can see these mechanics at work:
Example of Gameplay
Our players find they need to cross a gap, and decide to build a bridge. They use a few 3D printers to build themselves some parts.
The players need to power an exit to escape. They print out a powered switch and set up a winch in order to lift up a heavy power source.
Lastly, the players encounter an enemy blocking their progress. They use both building and traversal tools in order to defeat it.