This repo contains my solutions to the Mars Lander puzzle series on CodingGame, a platform where programmers solve challenges by writing code that interacts with a simulated environment in real time.
The challenge: land a rocket on Mars. The terrain is jagged, fuel is limited, and you have to come down gently enough not to crash. Each solution was built on the previous one, with each level introducing new complications that pushed the code further.
Two languages are represented — C and C# — which came about naturally: I solved Level 2 twice, once in each language, as a way of exploring how the same logic feels in a more structured, object-oriented environment.
The Martian surface is represented as a series of connected terrain points. Somewhere in that terrain is one flat segment — the landing zone. The lander starts somewhere above, with some initial velocity, and you don't get to set a flight plan in advance.
Instead, every fraction of a second (each "game tick"), you receive a snapshot: where the lander is, how fast it's moving horizontally and vertically, how much fuel remains, and the current tilt and thrust. You respond with two numbers: the angle you want to tilt, and how hard to thrust. The physics engine does the rest and sends you the next snapshot.
To land successfully:
- Come down slowly enough (vertical speed under 40 m/s)
- Don't drift sideways (horizontal speed under 20 m/s)
- Be level at touchdown (tilt = 0°)
The tricky part is that you're reacting in real time with no lookahead — everything has to be calculated fresh each tick from the current state.
| File | Language | Level |
|---|---|---|
mars_lander_1.c |
C | Level 1 — one scenario, get something working |
mars_lander_2_c.c |
C | Level 2 — same code must handle 5 different terrains |
mars_lander_2.cs |
C# | Level 2 — same level, rewritten in C# |
mars_lander_3.c |
C | Level 3 — terrain may block the direct path to the landing zone |
The first level is a single, fixed scenario with the lander already close to the landing zone. The goal here was just to get something working: read the terrain, find the flat spot, point toward it, and control the descent.
The core ideas introduced here carry through every subsequent version: a landing_site data structure to hold what we know about the target, a control loop that checks the lander's state each tick and outputs a response, and debug telemetry sent to a separate output channel so it doesn't interfere with the game.
Level 2 uses the same code against five different terrain layouts, which means anything hardcoded for one scenario will fail on another. This pushed the solution toward something more adaptive.
The terrain map is now stored in memory during the flight, so the code can look up what's between the lander and the landing zone at any point. The descent rate adjusts dynamically based on how much clearance there is — flying high and open allows a faster descent; closing in on terrain forces a more conservative approach.
There's also a small fuel conservation trick: thrust is suppressed for the first few ticks, letting gravity build some initial downward momentum before the engine kicks in. On scenarios with a long horizontal transit to the landing zone, this makes a meaningful difference to the fuel budget.
The C# version covers the same level but reorganises the structure — flight control limits are pulled into a helper class, and the approach logic is split into cleaner branches. It's the same thinking, expressed differently.
Level 3 adds terrain that may sit directly between the lander and the landing zone, making a straight-line approach impossible. This required moving beyond reactive control into something closer to actual path planning.
Each tick, the code checks whether a straight line from the lander to the landing zone would intersect any terrain segment — a standard geometry problem solved with cross-product orientation tests. If the path is clear, it proceeds directly. If not, it computes a curved arc over the obstacle using a Bezier curve, samples ten waypoints along it, and navigates toward them in sequence.
The autopilot (nicknamed "Otto" in the code) manages which mode the lander is in — curved arc, straight approach, or final descent — and switches between them as conditions change.
Level 3 is the most ambitious of the three and reflects genuine wrestling with a harder problem. The path planning geometry works; the handoff from arc-following into final descent is where the limits of a purely rule-based approach start to show. A cleaner version would likely replace the manual control logic with a PID controller — a standard technique in real flight systems where the autopilot continuously corrects based on the gap between where you are and where you want to be.
What I find interesting about this series as a portfolio piece is less any individual technique and more the arc across the three levels: starting with something simple and concrete, then being forced to generalise it, then being forced to rethink the approach entirely when the problem outgrows the original design. That's a pretty common shape for real engineering work.
Specific things demonstrated along the way: data structures and memory management in C, the same problem in two languages, real-time state-based control logic, and applied geometry (line intersection, Bezier curve sampling) implemented from scratch under the constraints of a competitive programming environment.
The code can be run directly in the CodingGame sandbox — just paste it into the editor for the appropriate level and hit run.