• [] Description
  • [] Main Title
  • [] Small intro section on index above posts.
  • [] Remove Version Page
  • [] Fill About

Think of it like a research paper in a way - you need an Abstract at the top that summarises the entire thing (goal of the project, one-two second overview, feature list/skills used/developed, any future plans) then you can go deep dive

I think its a little ambiguous how you’re intending to present this project, is it a product, a portfolio piece, a blog post, or a retrospective? It feels like you’re aiming for this to be a portfolio piece given the technical breakdown of the features provided, so I’ll go ahead assuming that You want to make it easy for me to find out at the high level what the goal of this project is, and what to expect from it. You currently start by breaking down the project structure, which feels like more of a “you want to use my project? here’s what you need to know” like you’d see on a GitHub wiki. I’d recommend starting with something like - “The Vulkan Engine is a vertical slice Game Engine and Editor written in C++. Created as a way to prove out and learn a number of key engine features it now exists as a small scale engine usable for simple 3D projects”

Still in the “make it easy for me to get the gist” I’d then give a rough bullet point of the sections below (almost like a contents page) so if Im looking to just tick off boxes on my “does this candidate have this skillset” list I can

I’d go into more deep fives into the technical aspects of the system, shows you know what you’re doing and have a good grasp of the material There’s some bits of the page that are confusing to me - “The editor project is mostly untouched other than the addition of the renderer to one of the windows.” makes it sound like this is built ontop of something else? What does untouched mean here, is the Editor side someone else’s project that you haven’t added much to? I’d seek to clarify how much of this is yours if that is the case in the opening statements.

Avoid self deprecating language, informality and inspirations is good - but if you say it’s bad I’m just gonna believe you and move on lol - its not untouched it’s “small scale” or “vertical slice” or “proof of concept” :^)

I’d maybe suggest breaking some parts into blog posts you could then link to, showing the earlier iterations of your collision system just make the product seem weaker by showing where its “not working” (even though you since refined it), whereas framing it as a blog post you then link to for like a “see here for a breakdown in how I achieved the current collision resolution system” after you go over what you got to a final solution

Similarly a blog post giving more of a retrospective on the terrain feature, why it was scrapped, what challenges you faced and how you’d potentially approach it again if need be would be better than going “I started a feature then scrapped it, moving on” kinda thing