Easy ways to turn your passion for gaming into a career: from real-time physics engines to coastal CFD and digital twins

Computational fluid dynamics is the discipline of solving the equations of fluid motion numerically, on a mesh, for a geometry too awkward for pen and paper. A tidal lagoon is one such geometry. So is a bulb turbine draft tube, a port approach channel and a seawall under a breaking wave. The games industry solves a simplified version of the same equations sixty times a second for fun. The gap between the two is narrower than either side admits.

Why the skills overlap

A real-time physics engine and a coastal CFD solver share more vocabulary than you would guess. Both discretise space, both step forward in time, both worry about stability when the time step is too large for the grid, and both are written by people who have spent nights hunting a NaN. The differences are about what you are allowed to get wrong. A game can fudge mass conservation if the splash looks right. A tidal model cannot, because a 2 percent error in the volume passing through a sluice becomes a 4 percent error in energy and a planning inquiry. The move from one to the other is a move from plausibility to accountability, and most of the technical foundation carries across.

• Shader and GPU programmers already think in parallel, which is how modern solvers run. Lattice Boltzmann and smoothed-particle hydrodynamics codes are, in structure, compute shaders with a journal reference.
• Physics-engine modders have usually met the semi-implicit Euler scheme, collision meshes and constraint solvers. Replace rigid bodies with control volumes and you are halfway to a finite-volume code.
• Level designers and technical artists understand meshes, level of detail and the pain of a bad topology. That is mesh generation, which is where most CFD projects actually go wrong.
• Tool builders who have written editor plug-ins and pipelines already know the only skill the profession is chronically short of: making a workflow repeatable.

Four routes in

There is no single door. These are the four we have watched people walk through, roughly in order of how long they take.

1. The open-source contributor route. OpenFOAM, Delft3D, TELEMAC and SWAN are open coastal and CFD codes with public issue trackers. Fix documentation, then a bug, then a small feature. Six months of visible commits to a solver that practices actually use is worth more to a hiring engineer than most certificates.
2. The visualisation route. Engineering practices are poor at showing what their models mean. A person who can take a 2-D tidal model's output and render it as a convincing animated flythrough of the estuary, with correct colour mapping and no artistic liberties with the data, is employable tomorrow. Start with ParaView, learn its Python API, then learn to drive a game engine from the same data.
3. The conversion master's route. A one-year master's in coastal engineering, computational engineering or marine renewable energy accepts physics, maths and computer science graduates and a growing number of self-taught programmers with a portfolio. It is the slowest route but it comes with the professional registration pathway attached, which matters if you want to sign drawings one day.
4. The digital-twin route. Ports, water companies and offshore operators are building live models of their assets fed by sensors. The job is half simulation and half software engineering: ingest data, run a reduced-order model, serve a dashboard. Game developers who have built multiplayer back-ends find this familiar.

Learning OpenFOAM the game-dev way

OpenFOAM is the free finite-volume toolbox that most coastal CFD in the UK is prototyped in. It has a reputation for being hard to learn, which is only true if you learn it from the front. Learn it the way you learned a game engine: start with a working example and break it.

Install it, run the dam-break tutorial, and watch a column of water collapse in a tank. Then change the tank. Then put a block in the tank and watch the vortex shedding. Then make the block a crude bulb turbine nacelle and look at the pressure minimum on the shoulder. In four weekends you will have reproduced the first figure of a cavitation feasibility report, and you will understand why our practice spends so long on draft tube geometry. Our main sheet explains where that pressure minimum matters and why a Thoma number below the runner's threshold is the moment a quiet loss of efficiency becomes an audible one.

Two habits to bring over. First, version control everything, including the mesh settings, because a CFD case that cannot be rerun is a rumour. Second, build your own tiny test cases with known analytic answers, exactly as you would unit-test a physics engine against a dropped ball. Solvers lie convincingly, and the only defence is a case where you already know the truth.

Digital twins and CAD visualisation

A digital twin is a model that stays attached to the real thing. For a tidal lagoon it means a hydrodynamic model that takes live tide gauge, turbine and sluice telemetry, runs ahead a few cycles, and tells the operator what to do next. The engineering is in the reduced-order model that makes it fast enough. The software is in the plumbing. The presentation is in the visualisation, and this is where game skills are least appreciated and most needed.

Engineers produce CAD. CAD is precise, heavy and unreadable to a planning committee. The person who can take a caisson design from a CAD package, decimate it sensibly, texture it honestly, drop it into a real-time scene with the correct tide running past it and let a councillor walk around it has done more for the project than another 200 pages of appendix. The constraint is honesty. Nothing in the scene can be prettier than the data. If the model says the scour hole is 1.2 kilometres long, the hole in the scene is 1.2 kilometres long. The discipline of not making it look better is the whole professional difference.

What we look for in a portfolio

When someone writes to us from the games side, these are the things that make the principal read the second paragraph.

• One fluid simulation, any method, with a comparison against a known result and an honest paragraph on where it was wrong.
• One mesh you made of a real object from a scan or a drawing, with a note on where the topology fought you.
• One repeatable pipeline, from input file to output figure, that someone else could run.
• One visualisation of someone else's public dataset, with its units and its datum labelled. We like Chart Datum. We notice when it is missing.
• Evidence that you can write a paragraph a non-specialist would understand.

The passion for games is not the obstacle people assume. It is the reason you already know how water should look. The career is learning to be sure that it also behaves. If you want to see where that leads, the feasibility desk on our home sheet is the end product, and it is built from exactly the skills above.