SHOVEL KNIGHT:
GUNS OF CORRUPTION
The textures and main concept belong to the creators of original Shovel Knight:
Yacht Club Games.
This project was made for DAE:GD 1st year, 2nd semester course "Programming 2"
For this course students were allowed to remake an existing game and I have choosen Shovel knight, because this game was highly acclaimed as an old-school 2D platformer (which I love myself) and initially I wanted to mix it with side-scroller shooters like Contra and Metal slug. Unfortunatelly, we were not given time to add extras, so I finished the required features and core mechanics of the original game. The game works with support of SDL and my code maintains all the game objects on the screen: player, enemies, items, current level/scene, etc.
GALAGA REMAKE
The textures and main concept belong to the creators of original Galaga: Namco.
This project was made for DAE:GD 2nd year, 2nd semester course "Programming 4"
Galaga is the second arcade game I made in C++. This project was a good training for programming patterns, especially the State pattern for the enemies in the game.
Besides that I figured out different ways of implementing observers and spotted quite some optimization moments, that allowed preventing unnecessary calculations.
For example: to make enemies fly in and attack following curvy trajectories, Bezier curves math was used. It allows making checkpoints-trajectory for enemies to follow. Enemies don't calculate flying direction each frame unless previous distance between an enemy and checkpoint is bigger. This happens if an enemy has overflown the checkpoint or the checkpoint is reached.
As it was with the Q*bert, my version of Galaga features 3 game modes: singleplayer, co-op and versus. Establishing rules for those game modes was tricky but in the end I managed to get some interesting results and players, who tested the game, quickly figured out implicit game mechanics that made the gameplay fresh and fun.
Q*BERT REMAKE
The textures and main concept belong to the creators of original Q*bert: Konami/Sega.
This project was made for DAE:GD 2nd year, 2nd semester course "Programming 4"
Q*bert was quite a challanging one for understanding. The use of isometric space in 2D requirred some time to be digested and then the enemies (Ugg and WrongWay) should have been able to jump on the sides of cube as if gravity works for them in another way. But after some allignments to character movement, the game was already playable. We were also told to make co-op and versus modes for this game. Originally Q*bert didn't have those but with some imagination and definition of some rules, the fun was doubled with amount of possible players going from 1 to 2. The game also has gamepad support.
This game project was a good testground for implementing the programming patterns we have been told about during the course, such as: Components pattern, Command pattern (+ InputManager), Observer pattern, Singleton pattern (for managers).
The game is working inside one scene, to which different game objects with different components are loaded, like in old-school consoles and arcade machines (where Q*bert belongs).
The engine is flexible enough to allow users to make other 2D-arcade-games like Pacman, Frogger, Tetris, Asteroids, etc.
RAYTRACER
This project was made for DAE:GD 2nd year, 1st semester course
"Graphics Programming 1"
Raytracer was the project that combined math, physics and programming into one final product. Figuring out visibilty problems, behavior of light and managememnt of resources brought me to a good understanding of how graphics work today and what graphics hardware and software companies are trying to achieve.
Raytracer included writing code to do both basic and complex stuff from scratch:
from writing formulas for detecting simple geometrical shapes in scene to adjusting reflectivity of metals with BRDF (bidirectional reflectance distribution function). All the functionality of this raytracer is based on physics. So it was crucial to firstly learn and understand physics, then figure out math behind it and then implement it in the code.
RASTERIZER+DIRECTX
This project was made for DAE:GD 2nd year, 1st semester course
"Graphics Programming 1"
This was the second part of Graphics Programming 1 course. It included introduction to HLSL (high level shader language) and making code base for DirectX. This time most of the functionality was either already implemented in Raytracer and copied over or provided by DirectX.
Rasterizer was not as intuitive as Raytracer in implementation. It actually was an inside out Raytracer with shortcuts for calculating color of each pixel. That is why Rasterizer was way more performant than Raytracer (from 5 FPS to 55-60 FPS), but DirectX changed the game completely and boosted performance even more (up to 2000 FPS).
If Raytracer was introduction for physics based rendering from scratch, Rasterizer was introduction for methods and tools of high-performance rendering. Worth mentioning is that Rasterizer actualy fakes some lighting and material calculations, while Raytracer was keeping track of all physcial aspects in a dynamic way. Sometimes this level of attention to details is not worth performance loss. Unless we are talking about not games but beauty scenes, which are usually not even real-time rendered.
AI-SURIVOR FOR ZOMBIE GAME
This project was made for DAE:GD 2nd year, 1st semester course
"Gameplay Programming"
This project was my first dive into AI in games. The point of this course was to teach studnets efficient ways of implementing decision making game agents. The most popular patterns are Behavior Tree, which I succesfully utilized in this project, and Finite State Machine.
During course we did touch both patterns and more (blackboard, spatial partitioning, behavior weights, etc). The end result was making a survivor-agent that was smart enough to survive zombie apocalypse or at least survive as long as possible.