Journal Entry 7

Date: 9. 4. 2025

Activity:

• Watched the video Juice it or Lose it
• Tried adding "Juice" to an existing project using DOTween
• Finished work on Project B

Notes: 

I arrived a bit late to the lab lecture, so I missed the Q&A about Project B. Fortunately, I didn’t have any questions myself, so I was able to jump straight into the lab session.

During the lab, I started working on the Juiciness with Breakout lab project. I used DOTween to add animations and effects—it was straightforward and intuitive. However, I got completely lost when trying to work with Unity’s particle system. There are just so many parameters and options that it quickly became overwhelming. Since I had less time due to arriving late, I wasn’t able to implement a complete, presentable version. Nothing was uploaded, and we weren’t required to finish the lab at home, so I shifted my focus back to Project B.

Project B

The majority of my work on Project B happened over these past two days. The process took a lot more time than expected. I started by dragging the one-page level design into the scene as a sprite, which sped up the initial level blocking. However, implementing all the intended features turned out to be more frustrating than I thought. I had to jump between multiple sample scenes to figure out how specific prefabs worked.

Since my level design was meant to showcase a wide range of features from the 2D Game Kit, I ended up needing to integrate a lot of different elements. Some of them were—let’s say—mysterious in how they work. By the time I had all the prefabs placed (breakable columns, health kits, keys, dialogue triggers, teleporters, buttons, and checkpoints), I thought I was nearly done.

But fine-tuning the level layout and polish took much longer than expected. I also ran into some issues with the build process. Lastly, I tried to implement a start screen and a win screen. Unfortunately, there’s a weird bug where the win screen doesn’t correctly link back to the start screen when reloading from the Start scene, and I haven’t figured out why. That’s part of the “mystery” I mentioned earlier.

All in all, the process was a mixed experience. Debugging and figuring out someone else’s setup was quite nerve-wracking, but tweaking the level and working on aesthetic polish was surprisingly fun and satisfying.

EDIT 11.04.25

There was some ambiguity regarding how strictly we were expected to follow the One Page Design from Project A. From my perspective, a One Page Design is meant to convey the structure of the level—the flow, the obstacles, and gameplay-relevant elements. What I do not consider part of a One Page Design are elements such as level decoration, as well as Start, Game Over, and Win screens. These do not affect the playthrough itself and, in my view, fall completely outside the intended scope of the OPD.

This interpretation is what guided my approach. The additions I made—mainly visual polish and extra scenes—were deliberate choices, based on the assumption that the OPD is a level design tool, not a substitute for a full game design document. It’s visual, not prescriptive. If there was an expectation to treat it as more than that, it should have been stated clearly from the beginning.

The only direct change I made to the OPD layout itself was moving two blocks slightly downward (the ones next to first enemy the player encounters). Aside from that, my level adheres to the intended design.

Invested hours:

• Lab – Juiciness with Breakout lab project:  90 minutes

• Level blocking and feature integration: 4 hours
• Level polish and fine-tuning: 1 hours
• Build problems: 45 minutes
• UI setup (start/win screen) + bug testing: 1 hour
  
• Aesthetic pass and Audio pass: 3 hours

Total Estimated Time: ~10 hours

Outcome:

• Gained experience with DOTween
• Completed and submitted Project B
  

Key takeaways (summary by ChatGPT):

• Time estimates often don’t reflect the complexity of implementation—especially when using pre-built toolkits or assets.
• Animation and juiciness can add a lot of polish to a project, but learning new tools like Unity’s particle system requires focused time.
• Despite challenges, polishing and creatively enhancing a level is a fun and rewarding part of the development process.
• UI scene linking issues can be subtle and difficult to debug—something to research more deeply going forward.
• Building a level with many prefab interactions is challenging when documentation or expected behavior isn’t always clear.