Takeaways:

• Goals & Intent
  This was a really interesting project, and a good excuse to get hands-on with low-level networking. The goal was to add hosting, connecting, and game replication to an existing engine that already handled gameplay and rendering. While it wasn’t my first time working inside someone else’s codebase, it was my first experience adding networking to an engine that didn’t already support it, which made for a fun and meaningful challenge.

• What Went Well
  The lockstep model turned out to be a simple but effective way to keep both peers fully synchronized, with collision resolution remaining deterministic. I initially struggled with how network calls should fit into the main engine loop, but switching the sockets to non-blocking IO made everything click. Instead of the game stalling while waiting on send/receive calls, it can now continue running and simply check for network activity each frame. That change was small in the context of this project, but in a real-time game it would have a huge impact on responsiveness!

• What I Learned / What I’d Improve
  This project deepened my understanding of low-level networking by giving me hands-on experience with game replication, custom UDP packets, and peer-to-peer connection logic. If I were to revisit it, I’d like to experiment with a different replication model, such as a server-authoritative client/server setup. It would be a fun opportunity to make it so players can move freely around instead of waiting on the other's input, and shift responsibilities like collision resolution to the server.

Takeaways:

• Goals & Intent
  This project was my first experience working with procedural generation, and it served as a way to dip one toe into a massively deep and complex approach to level design. My goal was to start with a simple generation algorithm and adapt it to produce levels that felt cohesive and intentional. I also wanted the final project to have an engaging difficulty curve that felt hand-crafted, while still being procedurally generated.

• What Went Well
  The part of this project that I'm most proud of are the different zones in generation I implemented. Through iteration, adding more generation parameters, and repeated playtesting, I was able to introduce more structure and turn that chaos into a level that felt cohesive. I was also happy with the playtesting process itself, which helped me balance the variety of enemies in the game and give each one a distinct gameplay gimmick. 

• What I Learned / What I’d Improve
  While I'm proud of the progress I made balancing the enemy difficulty and player power-up drops, most of my decisions were based purely on observational playtesting. If revisited this project it'd be nice to implement a telemetry system or automated testing to collect concrete data, like each enemy's damage per second or average time they spend in combat with the player. Also, A*!! It'd be really interesting to implement pathfinding to analyze ideal routes through the level and test how different generation parameters affect the distance the player has to travel.

Takeaways:

• Goals & Intent

I really like the Playdate! It's a very fun and quirky handheld, and the barrier to entry for making games is very low. The SDK is publicly available, and the documentation is easy to understand -- especially if, like me, you already have experience with Lua. This was a fun, low-stakes project that I still come back to every now and then to mess around with when I have the free time.

• What Went Well

I'm proud of how my enemy AI turned out for this project. When I started I knew I wanted a decently smart enemy paddle that was challenging, but not unbeatable. I did some research, and implemented a few prototypes, but a big challenge was making it so that the AI would run on the device -- since the desktop simulator runs with more power, optimization was needed to port it onto the handheld. In the end, I decided to use a series of raycasts to predict where the ball would make contact with the other side of the screen. What I like about this implementation is that it's easily adjustable: I can choose to add minor offsets on the angle of the casts, and lengthen the time between casts, to mimic the actual imperfections of a human player. 

• What I Learned / What I’d Improve

Learning how to implement draw calls for the Playdate was the most challenging part of this project. Even though the graphics in this game are pretty simple rectangles and circles, it was still tricky to wrap my head around pushing and popping context to the handheld screen. Looking back, this project actually helped me as I learned how to implement custom OpenGL rendering, since the two use similar graphics architecture.

Process Breakdown:

1. Preparing references & scale - Using reference photos from the attraction, I planned the model's real world scale and relative proportions.

2. Blocking - Created simple shapes to define the body, arms, and head. The character is made of simple, blocky shapes with lots of little details, which were fun to try and replicate.

3. Modifier workflow - Added non-distructive modifiers like Boolean Union, Array, and Shrinkwrap to flexibly implement second pass details.

4. Final model polish - Finished development of model's shape and materials.

5. Rigging Setup - Created a set of linked bones, movement constraints, and vertex groups for every moving part - luckily with my iterative development and the robot's base design, it was easy to select and modify distinct areas.

6. Animation - Implemented animation sequences focusing on clear motion and timing, using keyframes and constraints to achieve behavior in line with the original animatronic, but with much more movement and personality.

7. Rendering & post-production - Rendered final outputs with basic lighting and post-processing to present the model's form and animation capabilities.

Process Breakdown:

1. Preparing references & scale - I stuck closely to the orthographic blueprint reference to determine the final model's scale.

2. Extrusion - Constructed most of the head & handle of the Warhammer through repeatedly extruding basic cube and cylinder shapes.

3. Final Polish - Exported the material through Paint.NET, and applied final touch up of the model's shape.

4. Optimization - The extrusion technique didn't make too much extra geometry, but I simplified any topology I could find to reduce the triangle count down to around 1,000.

5. UV unwrapping and texturing - Unwrapped the model by hand, manually splitting along seams on the diffuse material. The smile on the back was a minor pain to position correctly.

Process Breakdown:

1. Preparing references & scale - References were taken directly from the in-game model and were placed orthographically behind the model, making it easy to create a matching sculpt.

2. Blocking & hard surface modeling - The goose's beak and feet were modeled first, and the body was blocked out with a combination of spheres and cylinders stitched together topologically. 

3. Sculpting - Utilized push/pull, exaggerate, and smoothing tools to create the natural curves of the goose's body in line with the reference photos.

4. Optimization - Realigned the model's topology and reduced the poly count by hand down to around 2,000, while still keeping enough natural detail.

5. UV unwrapping and texturing - Unwrapped the model by hand. Luckily the goose has extremely simple colors; the hardest part was lining up the eyes so they remained circular.