Idhant.

Hellrunners

C++, FPS, Tech Lead

Description:

* A multiplayer FPS speedrunning game, built in C++ and OpenGL in 8 weeks.

* Built with an emphasis on movement, tight controls, responsive gameplay and smooth multiplayer upto 8 players.

* Data Driven level generation.

My Work:

  • Core Physics
  • Level Generation Systems
  • Core Gameflow System
  • Input Manager, Player Locomotion
  • Shaders, Post Processing
  • Debug Features

My Role:

Team Lead, Gameplay Programmer

More Details:

Physics, Collisions, Player Controller

* This project done for a university group project had me wearing a fair few hats in terms of roles. As a core physics programmer, I implemented collisions for capsules, OBBs and the core player movement.

* I decided our player was going to be a capsule, and that our platforms would be require to be rotated, so they would be OBBs. So deciding this earlier meant that I could add support for these early on, and make sure the collisions were working well. Since all our collisions were over the server, I did not need to many adjustments for player vs player collision. Ground detection was also written by me.

The capsule vs OBB interaction, we move the OBB into local space

and then call a Capsule AABB test on that

Tools, Level Generation

* To make level design easier, I wrote a data driven level generation system that allows us to load in levels easily from a tool. We decided that using unity as a visual tool to allow people to easily generate levels and have them show up on our project.

* As shown on the chart below, we take the level data from the unity scene where we place our cubes, traps, obstacles and such, and then move it to a massive struct that is then exported out to a JSON. Since the more flexibility you give your Designers the better, we essentially take every single detail of object and track it in the JSON. Then the relatively non required and non replicated things can be sorted out from C++ side.

Data flow from unity scene to our in-game scene for level generation

Shader Work

* On the graphics side of things, all most all of the shader work in this project was written by me. UI, fire, speed lines and the lava are some standouts. Alongside that, general bug fixes and adding debug mode, there is a lot of meat of work on this project.

Additional Tooling

* Half-way through the project, we were experiencing a lot of micro-stutters and low FPS. We did not know if this was a networking bottleneck, a memory one, or a graphics one.

* To help with that, I ended up implementing a Debug tool, with the following features; FPS count, Level Generation & Physics Update, Current CPU, GPU usage, Collision Counts, and Camera Debug info.

Debug Information being displayed on the screen

Debug Information being displayed on the screen

Gallery:

hover over the images!

4 players at the starting line before a race
Lobby system before a race starts
Medal depending on your time taken to finish
Grapple in action
Longer view of a stage
Waiting lobby menu, and level select
VER 3.0.1
* I am an Game Developer specializing in Gameplay Programming, Graphics, Feature programming and leading teams. With a knack for creating distict gameplay experiences, my work spans different platforms, seamlessly blending strategic thinking with cross-team solutions.
NEWCASTLE UPON TYNE 5.12.2025
IDHANT DABRAL
ALL RIGHTS RESERVED
  • Email

    starmandev@gmail.com

  • Location

    Newcastle Upon Tyne, UK

Building a game?

Lets Chat.