Academia

---

Last fall, I was grouped up with three fellow students in Quinnipiac University's SER225 Agile Development class to build something wild: a Java-based platformer game where you play as a computer science professor trapped in the underworld. The mission? Fight your way back to life so you can finish grading papers. It was fun, hilarious, and an awesome learning experience.

Using a custom engine originally created by our professor, we developed:

• A playable protagonist with a supernatural twist
• Multiple levels filled with enemies, collectibles, and hazards
• A custom map editor for designing new realms
• No external libraries — just pure Java
• Agile-friendly architecture for team-based development and future expansion

You can check out the project here on GitHub. Just clone, run, and dive into the madness.

This project was more than just a grade — it was a deep dive into collaborative development, game logic, and creative storytelling. I got hands-on with:

• Object-oriented design and game architecture
• Agile workflows and sprint planning
• UI/UX decisions for both gameplay and map editing
• Debugging platformer physics (gravity is a drama queen)
• Balancing technical constraints with creative freedom

It reminded me how much fun learning can be when you’re building something weird, personal, and just a little chaotic.

Since the core game is functional, I’m planning to take it to the next dimension, literally. My goals:

• Import the game assets into Blender
• Recreate the sprites as 3D models
• Rename each 3D object to match its original sprite name for seamless integration without needing to rewrite the code
• Explore stylized rendering to preserve the game’s quirky charm

This next phase blends my interests in code, visual design, and creative experimentation. It’s a chance to evolve the project from a class assignment into something truly personal.

I love finding old code—it’s like uncovering a time capsule of past learning. Recently, while digging through an old folder, I came across a Java Swing project I’d completely forgotten about. An object-oriented design-related program called Moving Color Ellipse that uses control elements to move shapes across a window.

What It Does
The program creates an interactive canvas where you can:

• Click on colored ellipses to select them
• Move them around using directional buttons (up, down, left, right)
• Exit the program with a simple quit button

Why It's Still Interesting
Even though it’s a small project, it demonstrates core programming concepts beautifully:

• Object-Oriented Design: Each shape is an instance of a ColorShape class hierarchy
• Event Handling: Mouse clicks and button presses trigger smooth interactions
• Proxy Pattern: A middleman object (MovingEllipseProxy) manages selection and movement
• GUI Principles: Clear separation between logic and display

But beyond the technical details, this old code taught me three big lessons about why revisiting past projects matters:

1. Old Code Shows Growth

Looking back at this program, I can see:

• Where I over-engineered (like the proxy layer for such a simple app)
• Where I got it right (the clean shape hierarchy)
• How my coding style has evolved since then

It’s like a snapshot of my thought process at the time—flaws and all.

2. Simple Projects Teach the Best Lessons

Big, complex apps can obscure fundamentals. Tiny projects like this? They highlight them. Here, OOP isn’t just theory—it’s visible in every moving ellipse.

3. Old Code Is a Base for New Ideas

Looking at it now, I’m itching to:

• Add keyboard controls (why didn’t I do that originally?)
• Implement shape resizing/rotation
• Introduce more color options

The best part? Since the core structure is solid, these upgrades would be easy. That’s the power of good design.

Looking at it now, I can imagine adding:

• Keyboard binds
• Shape resizing/rotation
• More color options

Old projects like this are great reminders of how much we've learned—and how even small programs can teach big concepts about software design.

If you want to review it, the code is available below on GitHub

While cleaning up some old files recently, I stumbled upon a Java program I'd written years ago—a simple but fun Monster Battle Simulator that pits a Giant against an Ogre in a turn-based fight. It was fascinating to revisit this little project and see how it holds up!

What It Does

The program simulates a battle between two mythical creatures:

• Giant: High health (100) but moderate strength (15)
• Ogre: Lower health (60) but hits harder (25 strength)

Each takes turns attacking, dealing randomized damage until one (or both) are defeated.Why It’s Still Interesting:Even though it’s a basic program, it demonstrates some core programming concepts nicely:

• Object-Oriented Design: Each monster is an instance of a Monster class.
• Encapsulation: Private variables with controlled access via methods.
• Randomization: Attacks use Math.random() for variability.
• Looping & Conditions: The battle continues until one monster falls.

The Code’s Structure1. The Monster ClassDefines the creatures with:

• Health & strength attributes
• Attack logic: Deals damage based on strength + randomness
• Damage handling: Reduces health when attacked
• Life check: Determines if the monster is still standing

2. The Battle ClassRuns the simulation:

• Creates a Giant and an Ogre
• Loops through attack rounds, printing health updates
• Declares a winner (or a draw if both fall)

Sample OutputThe battle plays out in rounds with clear health tracking:Example: 

Round          Giant Health          Ogre Health  

1              100.0                60.0  

2              87.3                 52.1  

...            ...                  ...  

Finding this was a fun surprise because: ✔ It’s a time capsule – I wrote this while learning Java for the first time ✔ Simple but effective – Not unnecessarily complex. ✔ Easy to expand – Looking at it now, I have ideas on how to improve it. Add more creatures, give different types of attacks, and a stamina component, making each attack a little weaker after the first