UI/UX and Gameplay Programmer
Docystephen@gmail.com (503) 896-6332 www.linkedin.com/in/stephen-a-docy/
Throughout my time at DigiPen I've had the chance to work on many interesting and complex projects. Through these projects I've learned many different skills and lessons related to game development. From practical skills such as experience with the tools and features Unreal Engine has that made developing UIs much easier, to softer skills such as task management as both a team member and a team lead.
Below you can find examples of some of these projects along with the many lessons I've learned along the way. If you have any questions about any of my projects or are looking for a UI/UX or Gameplay programmer, feel free to reach out to me! I'm happy to chat anytime!
Narwhal Knight
Narwhal Knight is a 2D aquatic platformer where you play as a Narwhal who launches through levels and skewers deep sea enemies. The goal is to complete the levels as fast as possible and with the fewest moves, while also collecting coins along the way. Me and a team of two others created this game for the Pixel Game Jam 2024 in nine days.
On our small team, I primarily focused on the UI/UX programming and design using Unity's new UI builder tool. This was my first-time using Unity's new UI toolkit as I had only done smaller prototypes in Unity before. Through Narwhal Knight I was able to quickly pick up the basics of how to use the UI builder and learn more complex features and settings. This led to me having a strong understanding of the UI toolkit by the end of the project. While there are things I would have done differently if I could start the project again, the final product worked and fit with the style of the game quite well.
Outside of the UI itself, I did work on various other UX and art related tasks to help polish the game. One of these tasks included the bubble particles, which was a nice introduction to Unity's particle system. I also aided in the implementation of the tile assets which taught me about Unity's tile map system and how to ensure our pixel art assets looked sharp.
Pinata Panic!
Pinata Panic is a 3D destruction game with physics based movement. The player controls a Pinata who's goal is to cause as much destruction as fast as possible. The game has tons of different interactions, some of which do basic damage and others apply status effects that do damage over time and unlock more complex interactions. The game is very humor focused as the movement is chaotic and the interactions are over the top and crazy.
On this project I was the main UI/UX programmer and the Tech Lead for our team. As Tech Lead I managed the progress of the programming side of the game, and made sure the programming requirements for the project were met. I made sure bugs were handled quickly and that all programmers knew what tasks needed to be completed. On the UI/UX programming side of things I worked closely with our UI/UX artist and designer to implement the designs and assets they made into the game. I created custom logic beyond what Unreal Engine provides by default as needed based on the designer's ideas and designs.
Point Tracker
One problem I had to figure out with Pinata Panic was how to communicate the player's score. I chose to do this through three elements, a point ticker, a progress bar, and a rank. We originally started with just a point counter and a progress bar, however, it wasn't very eye catching and the player often wouldn't care about getting a higher score. To remedy this I came up with two solutions to help draw the player's attention to their point total. The first was a point ticker that was animated when your point count went up, much like an analog display. The second was to show the player's rank above the
progress bar, since we already had a rank system at the end of the level. Both of these changes helped emphasize one of the core parts of the game, causing chaos to get as many points as you can!
Another feature I worked on was controller support. Specifically, handling how the player navigated the UI using a controller and making sure that all UI features worked across both control schemes. This meant not only making sure that all parts of the UI were still accessible but also making sure all animations and sound effects still worked correctly. While Unreal does have a system for making sure navigation works correctly the hover states for buttons did not work at first and took some time to get working similarly to mouse controls. Making sure all of this came together required a lot of testing to catch any issues that might have come up when the UI was changed over time.
Controller Support
Inner Spark
Inner Spark is a top-down turn-based tactics game set in the bronze age. The player has to escape a city that has fallen into darkness, fighting the monsters they encounter along the way using whatever weapons they can find. The player must use strategy and a special resource they collect along the way called sparks to overcome the enemies they find and escape the city. The game is mostly UI based as the player uses the UI to control what actions their characters take in each turn, as well as to see the state of their characters and the enemies they are fighting.
On this project I was in charge of UI/UX design and programming, which made me the main person in charge of the overall UI from design to implementation. This was quite a lot of work, as unlike with Pinata Panic I didn't have anyone else to rely on for art or design. This led to a heavy amount of iteration in engine as I would usually start with implementing a basic working version of a UI element then hammer it out into a well-designed version over multiple updates.
Player UI
The first major challenge I worked on was how to display information for each player character. Inner Spark’s characters have health, action points, sparks, and weapons that all had to be displayed visually. The overall layout of the information was decided fairly early on, however, the final placement took some time. At first, I placed the UI above the player character, like a health bar. This worked well at first since it made it easy to understand your characters’ current state. Unfortunately, this approach proved problematic as it would block the visibility of the enemy and their status. This led me to consider
solutions such as occluding the UIs, but that would have been complicated to get right. In the end, I decided to just make the UIs part of the HUD and used a highlight to showcase the UI for your selected character. This was a much simpler solution to implement, and it quickly solved the occlusion problem.
While creating various parts of the UI, I created various materials to provide more refined and more powerful animations than could be created using widget animations. The first I created was highlight circles that appeared beneath players and enemies. This helped solve problems early on with the players not realizing they were supposed to click characters to select them and enemies to attack. It also gave us more options to highlight characters if needed for other parts of the game like the tutorial. Later on in the project I created a material to display action points as circles and
Unreal Materials
sparks as lanterns. I then used material parameters to allow these icons to be partially hidden to represent empty slots and also be able to flash to show the player is about to spend them. This helped our team move away from using text for both of these, overall making it much more obvious how many sparks and action points each character had, and how much was spent for each action.
Card Game Simulation
I made this card game simulation for a technical design class as a way to learn how to create an action list system, where actions like move, fade, rotate, etc. are added to a list and then executed. This makes it much easier to handle the basic parts of a UI heavy game and makes it much easier to automate the game which is shown in the video above. It also made it quite easy to add the ability to save all the actions that were put into the list into a file, which could be replayed exactly as it happened before. These features make it so much easier to find bugs and reproduce them. So much so I've found myself using this system after this class in other Unity projects I've worked on, since the action list makes it much easier to start prototyping as it handles the basics for you. In addition to giving you a robust framework you can build on to provide automation and replay testing based on the specifics of the game.
Ironvale Grove
Ironvale Grove is a 2D lane based battler, where the player has to gather mana orbs that fall from the sky. Using that mana, players spawn units down the various lanes to fight the enemy units on the opposite end. For the lanes we used a node based spawning and pathfinding system where units would spawn at a node which would point that unit to the next node to go to. This allowed us to more easily make many different kinds of maps and have dynamic paths that can switch which node a unit goes to with a button.
This project was made with a custom engine created by our team mostly during the first semester of our game project class. During this time I worked on the physics and animation systems primarily, as well as helping out other teammates with various other systems such as our data serializer and deserializer. Once the basics of the engine were created we began working on the game itself, expanding the mechanics of the game as the engine became more fleshed out. During this time I worked primarily on the enemy behaviors as well as the node based system we used for the paths both the player's and enemy's units walked down.
Unit Behaviors
I worked on almost everything related to units from how they moved to their base behavior script to how player and enemy units spawn. This took up most of my time on the project as not only did I have to work on the units and their behaviors but I also had to build out the engine functionality needed for them to function. This included working with a teammate to build a messaging system which allowed game objects to announce certain events like death which other game objects could subscribe to. I also worked on the hierarchy for how units are setup, creating a base behavior class that handled the
basics like movement. Then I could create children of that class to create the different unit variants. In the end we had a very robust system that could easily handle more units being added to the game in the future if we had more time to keep working on it.
One of the mechanics we decided early on was to have different path layouts for our different levels. This was due to us looking at other lane based games and finding that either they made levels different through different path layouts or through adding new units. We decided on the layouts as we knew new units would take a lot more time compared to different path layouts. After we decided on this I took charge of implementing how the paths would actually work. I ended up using an approach similar to a linked list, with each node pointing the friendly and enemy units to the correct nodes. This made
Node Based Paths
it easy to just have the unit always walk towards a node and upon reaching it look at that node to find the next node to go to. Then to implement the path switching we just had each node have a queue of nodes it sends friendly and enemy units to. Then the player could use the button to switch which node units are going to on the fly and any units who haven't reached the node yet will go to the newly selected node instead of the old one. This also allows the enemy AI to either randomly switch the direction or switch based on where the player's units are.