sebastian ploch cover photo

Welcome stranger to my Portfolio page.

About Me

Hello! My name is Sebastian Ploch and I'm a Games Programmer, currently getting a degree on Games Programming at Staffordshire University. I've been passionate towards technology and games since youngest days, but predominately programming is what gives me the most fun and feels the most rewarding but equally challenging. I see myself as an open-minded, quick-learning and humble being that dreams to work in an industry that combines both of my dream worlds!

PS: I'm glad to see you in here & hope to meet you soon!
meanwhile you can check my other social media (i promise they don't bite)


  • C++ and Object-Oriented Programming
  • C# (including .net library and threading)
  • Graphics Concepts (DirectX 11 / OpenGL)
  • Debugging
  • Unreal Engine 4
  • Unity Engine
  • Git Usage (including GitHub)
  • Problem Solving


As you are here already, why don't you have a look at my projects 😃

Mario Level Editor

SDL based Mario Level Editor

UKIE Green Game Jam 2019

UKIE Green Game Jam 2019

FreeGLUT + Core-Profile OpenGL Application

FreeGLUT + Core-Profile OpenGL Application

Super aMAZEing Game

Super aMAZEing Game


EmojiMan (Pacman + Clicker game hybrid)

Mario Level Editor

Level editor based off Retro Mario Bros game, that allows the player to create own levels, save and play through. Game comes with one pre-defined level to work as a guidance in what you can make yourself. Game has been built using own framework powered by SDL library to provide means to talk with hardware to draw sprites/play sounds/poll inputs etc...

OpenGL-Core Application Showcase
GitHub Repository

This project has taught me a lot, as was a first ever approach in making framework that will essentially mimic a game engine. That later would be used in making a game (Mario level editor in this case). I've earned a lot of experience in making reusable general classes as well as systems that will govern application built within and allow functionality and mechanics.

Throughout the project I’ve built multiple classes as part of the framework, being:
  • GameScreenManager
  • Texture2D
  • Text
  • Collisions
  • Tile
  • Entity
which all encompass some logic often tied with SDL functions, to provide means of doing particular task in most efficient and easiest way, essentially abstracting away from any confusion making using the framework a breeze to create app/game within.

For example, loading and saving a texture is as simple as:

    Texture2D* _texture = new Texture2D(renderer);

just by abstracting away SDL functionality into TextureClass that allows developer to quickly and efficiently do a task without having to worry about 10's of lines of code, and instead using just one function on a variable that will do everything for them.

Another case of providing easy means to do particular task would be Collisions class, as has been made to be a Singleton Class which means that you can use it's functionality to compare two objects whether they collide by using either AABB (box collision) or Circle collision check, without the need of instantiating the class.

    Collisions::Instance()->Box(object1, object2);

That being said, creation of this framework and later on a game within wasn't free of problems. Particularly encountered many in regard of memory leaking, as was first time that I’ve used extensively raw pointers which can become troublesome if not cleared correctly when not being used anymore. After some time of debugging and tracing creation of every troublesome pointer I did manage to get rid of those mistakes, giving me yet again even more experience in debugging and using pointers/memory addresses.

OpenGL-Core Application

OpenGL rendering application, that allows .obj models to be loaded in, accompanied with .bmp texture loading for the models. Allows user to freely move around the scene or move the tank, depending on which camera mode you are using (free camera, camera from behind the tank). Application has been written by using OpenGL's core-profile therefore allowing programmable pipeline approach opposed to fixed-pipeline, which gives much more flexibility as allows Shaders to be written for each segment of the graphics pipeline (vertex, pixel, tessellation etc...). Application utilises GLEW library to create bindings for OpenGL with drivers to provide most recent supported version, as well as GLM Library for maths related structures such as Matrices so that they're memory aligned, and lastly FreeGLUT library for means of easily creating and managing windows.

OpenGL-Core Application Showcase
GitHub Repository

Application being essentially first touch in writing Graphics Application using straight OpenGL code, was definitely not an easy journey but extremely rewarding in the end as I got to learn so many new things and concepts. Starting with understanding concepts of all graphics pipeline stages that happen during runtime, understanding and using various matrices such as world, view or projection. Learning plenty of new data structures like linked lists, binary trees and scene graphs. Ending on writing parsers to be able to load in .obj models and .bmp textures.

Application comes with custom
  • .OBJ Model Loader
  • .BMP Texture Loader
  • Phong Lighting Shader
  • Scene Graph
  • Linked List Data Structure
  • Camera Class

Most noticeable difficulty gave me writing parsers, and in particular .bmp parser. This would be because of it being really strict on reading correctly and assigning data from header of the .bmp image to local variables within my c++ code, where all of the variables needed to be correct to the very byte size expected from .bmp specification as otherwise read data wouldn't be fitted in according variables resulting in corrupted image. Another matter being that by default c++ compiler creates padding around variables for the safety, but that needed to be changed in case of reading .bmp file as memory would get mis-aligned.

#pragma pack(push, 1)

I've managed to achieve that by using pre-processor directive to remove the padding whilst reading the image file. All together it taken a lot of time to research and understand why things were not working the way they were supposed to regardless code being correct.

Emoji Man

Emoji man is a hybrid of a clicker game and pacman. Objective is simple, stay alive as long as you can and meanwhile buy upgrades/evolve your emoji within clicker compartment. Game was built using university's proprietary library called S2D that provided means to easily draw sprites, play sounds or poll inputs.

EmojiMan Showcase
GitHub Repository

This Project being my first game ever written purely in code using just small library was definitely a test of my not so long ago acquired c++ knowledge. This taught me a lot as didn't have any more colossal engine sitting on top that can do pretty much anything in matter of just few clicks or functions, but instead had to code it all in here by myself. Being left to myself and my creativity contributed in gaining a lot of valuable experience. Be it in general game design principles to thinking how will structure my code or logic behind mechanisms i will need. On top of that, I’ve also expanded my code base further, as had to use new libraries that never encountered before or even to use previously known ones to me in different ways. In general, this project also shaped the way I write and name variables, so they're consistent and are not confusing at any point, such as sticking to Camel-Case naming convention or pre-fixing local to class variables with underscore.

Biggest obstacle I've encountered throughout this project was order and logic in which I was deleting/freeing objects, often resulting in exception errors due to the fact of trying to delete something that was deleted already and essentially being null. With enough of time I’ve managed to squash those bugs out. Whole process taught me a valuable lesson and improved my debugging and coding skills. In the future should be able to avoid such mistakes altogether, and even if it happens again, I will be able to tackle and debug those much quicker.

UKIE Green Game Jam 2019

Apocatree is a "game" built for Ukie's Green Game Jam 2019, around the theme of Climate Change / Sustainability. The game idea was strongly inspired by Plague Inc, as the goal of the game was to convert the post-apocalyptic barren world. Into essentially a new home for humanity, firstly by planting miraculous "mother tree" that would over time grow new trees all around the map.

Green Game Jam 2019
GitHub Repository

The game, in the end, wasn't fully finished, because of our team "trying to bite, more than can chew". That is because we've spent good 12+ hours, trying to figure out the Tile System and AI in unity engine. Which happened to be the first time using the engine for the majority of us, or others had small experience using it.

Problems started to arise straight-up from using Unity's very own tilemap and tile system, that is because it doesn't allow any additional data to be passed onto tiles used in tilemap because of performance advantage and the way it was made. After a few hours of being unable to figure it out, the team decided to hard code values accordingly and just read them in. Which was a horrible solution that worked temporarily.

Green Game Jam 2019 - Hard Coded Values

Regardless of our temporary solution, we decided to move on to get something done. The team moved onto coding ai for "humans" that would control where they settle etc... That to say was a bit too ambitious as well, because we've tried to include Heuristic from tiles based on the availability of water, climate and such that would dictate where humans would put their houses down first. Which got to say worked half of the times, that being around 5 am in the morning where people that were assigned in making this AI went away to get well-deserved rest.

This left 3 of us (including me) with broken AI and hard-coded tile system that was bound to break at some point. With us not understanding what has been done to AI, and not willing to spend any longer on that. We decided to scrap what has been done in that regard and simplify our game idea.

With that in place, over the course of the next 6 or so hours. We got much more done than we did throughout the whole time earlier on. Which only shows how the badly overly complicated mechanism can mess up the whole schedule.

I was assigned to make re-make the whole tree spreading mechanism, which went surprisingly smooth. I did encounter the same problem that we had earlier with tiles though where I needed to get the position of each individual tile, which means that I would need to pass additional data to each tile. After a bit of thinking, I've come up with an ingenious idea to solve this problem!

Green Game Jam 2019 - Tile Struct

That idea being, making a struct that will contain generic tile that gets generated from tilemap and combining it with any data that I would need. In this scenario is a position which I calculate and assign when tilemap gets created. This itself if popped in my mind earlier, would save so much time and struggle from earlier. Better late than never, eh?

To summarise, the whole experience of the game jam was pleasant regardless of the many problems with the project. That is because, in the end, we had a lot of fun making it, as well as our group, bonded a lot from this activity! On another side, it taught all of us a lot in terms of scaling project accordingly especially during game jams where time is crucial, as well as not to dwell for hours on something that doesn't work and is stopping everyone else from working.

Super aMAZEing Game

Super aMAZEing Game, was a project created as an ice-breaker during the start of the University. The idea of the game is simple, you get randomly spawned in a maze and you need to make your way to the centre "red plate" to finish the level, throughout your journey you will encounter speed-up power-ups as well as obscure vision power-downs.

Super aMAZEing Game

This project was a very first time that I have touched Unity Engine, and as for first time. I think I didn't do too bad, as I've managed to achieve everything that I wanted. Be it obscuring vision through overlay texture over the camera, applying force to the sphere to move in a fashion that you can feel the weight. Or even simply creating spawn points for items and such.

The whole experience was pleasant and didn't feel too daunting, which I had fears about before starting it. I've learnt the basics of Unity Engine as well as bonded with my team-mate. For which this activity was created for in the first place :)