project 18
2D Wizard Battle & Desktop Simulations
Two desktop game and simulation projects built from scratch on object-oriented principles, a custom game loop and a hand-written physics engine.
- Category
- Games & Tools
- Role
- Independent developer — game loop, physics and interface
- Year
- 2025 – 2026
technologies used
- Java
- Swing
- Graphics2D
- C#
- OOP
- NetBeans
problem
Problem
Object-oriented programming principles, collision and physics algorithms and dynamic pathfinding logic had to be simulated in a desktop interface environment without dropping frames.
solution
Solution
In Java and Swing I built a modular game engine structure centred on inheritance, polymorphism and encapsulation. I developed AABB collision detection, projectile mechanics, health bars and state management from scratch, along with pathfinding algorithms over a dynamic grid and minefield.
outcome
Outcome
The result was a set of desktop applications and simulations with no memory leaks and a smooth framerate, letting two players compete simultaneously via keyboard controls.
key features
- 01Modular game engine structure centred on inheritance, polymorphism and encapsulation.
- 02AABB collision detection, projectile mechanics and health/energy management written from scratch.
- 03Pathfinding algorithms over a dynamic grid and minefield.
- 04A game loop with smooth framerate letting two players compete simultaneously on the keyboard.
why these choices
Why no ready-made game engine?
The goal wasn't to ship a game but to learn how the game loop and physics calculations work by writing them directly. A ready-made engine hides that layer. Writing my own fixed-step loop on Graphics2D meant seeing thread management and timing logic first-hand.
Why fixed-step updates?
Framerate-dependent updates produce different physics behaviour on fast and slow machines. With a fixed-step loop the physics gives the same result everywhere; rendering speed and simulation speed advance independently.