DNA [DO NOT APPROACH]
Gameplay Programmer and Technical Designer
(August 2024 - April 2024)
Download link: [coming soon]
Programming responsibilities: Engine development, gameplay programmer, technical design, enemy behavior implementation, animation programmer
Team Size: 6 team members
Misc. responsibilities: Creative direction, pixel art and animation
Collaborated with team members in the framework and development of the entity-component system for game objects
Designed, programmed, and implemented 6+ creative and expandable enemy behaviors
Used Godot’s @tool system to create a fake 2D “z-axis” and modifiable ground shadows
Conceptualized and integrated the main “player corruption” mechanic with effective usage of Godot’s signal system
Spearheaded animations for game objects and UI, including sprite stacking for complex player animations and shaders for the title screen logo
DNA [DO NOT APPROACH] is a sci-fi, 2D top-down dungeon crawler with a procedurally generated map and a goal to recover and repair the broken pieces of your crashed spaceship. As you explore the surface of an unexplored planet and salvage what you can, you’ll have to survive against the hostile environment. It wants you to become a part of them — while it could grant you abilities necessary to progress, bad things will happen if you succumb to its corruptive properties…
Development history and retrospective
For DNA, my main role was to fill the game world with monsters the player character would confront; more specifically, I was a gameplay programmer and technical designer focusing on enemy behaviors and our main “player corruption ability” mechanic. To do this, I spearheaded designing a component-based system with my team, implementing different properties we could attach to game objects to change their mechanics and add behaviors; Godot’s node tree structure complimented this framework naturally.
For example, the “health” component — one of the main components I was responsible for — handled an object’s current health points, invulnerability frames, and its living/death state. I made heavy usage of Godot’s signals to allow other objects to “listen” to changes in HP or its living state; these were used to update the player’s HUD, create VFX when taking damage or healing, handle certain enemy interactions, and check when the player dies, to name a few examples.
Another unique component I created was something subtle in gameplay, but important mechanically; I created a “shadow” component. Because DNA is a two-dimensional game, but required the illusion of depth and distance from the ground for some behaviors, I made a component that would offset the object’s sprite vertically and draw an elliptical shadow underneath it that changed based on distance from the ground. Its size, transparency, color, and offset can be changed and updated in-editor since I employed Godot’s incredibly handy “@tool” to see changes in real time. The player character and enemies now visibly “jump” and “fly” with clear signifiers.
DNA was originally conceptualized the summer before my senior year of college, taking inspiration from my positive experiences working on my previous PCG project. The concept of a game mixing the fun enemy ability acquisition mechanics of the Kirby series with the dire circumstances and aesthetics of Changed and packaging it all into a Binding of Isaac-inspired roguelike seemed incredibly appealing. It also seemed like an excellent opportunity to use Godot, as I had yet to work on a larger-scoped project using the engine. When the semester started, I presented my concept to a group of my peers, found a team who’d be able to bring their own goals and expertise to the project, and started development in late August of 2024.
Although I was the one who developed the core concept of the game, I worked together with my teammates in order to develop the final gameplay loop and determine personal and team goals. We wanted to set reasonable expectations for the project, structure our time and contributions as to not overwork ourselves, and get the project in a complete state by a specific date to have it presentable for networking and showcases. With a small and cohesive team, we actively supported each other, chipping in to help bugfix issues, participating in pair programming, and helping one another understand the parts of the systems we worked on.