01
Start with the player loop
Before the implementation expands, I look for the player intent, the state that carries it, and the feedback that makes the result legible.
About / Mukund Pareek
Build the part players remember
Hyderabad, India
I'm an Unreal Engine gameplay programmer drawn to the invisible work behind a responsive game: state, authority, movement, feedback, and the tools that help a team keep improving them.
A point of view
I enjoy the moment when a game stops being a collection of features and begins to feel coherent. A movement transition lands at the right time. A combat action has a readable cost. An AI decision creates a useful problem for the player.
That is why my work tends to live at the boundary between player-facing feel and the engineering underneath it: gameplay architecture, multiplayer correctness, editor tools, and technical experiments that make a system easier to inspect.
How I work
Systems with a reason to exist
02
Make ownership obvious
Good systems have a clear authority boundary, predictable lifecycles, and debugging paths that do not depend on the person who wrote them being in the room.
03
Leave room to iterate
I like C++ foundations that are deliberate, with the right Blueprint and tooling surface for designers to tune the game without fighting the architecture.
See the evidence
Open to a good conversation