The latest articles on DEV Community by Thomas Poli (@thomaspoli). https://dev.to/thomaspoli https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4186658%2F9df8f3ca-7656-4f10-8fcf-7fe00b99741d.png https://dev.to/thomaspoli en Thomas Poli Thu, 15 Oct 2026 11:22:06 +0000 https://dev.to/thomaspoli/how-game-engines-handle-physics-a-beginners-primer-2d7o https://dev.to/thomaspoli/how-game-engines-handle-physics-a-beginners-primer-2d7o <p>Ever watched a character ragdoll through a wall or a crate launch into orbit? Those are physics systems doing exactly what they were told. Here's how it works under the hood.</p> <h2> What "physics" means in a game engine </h2> <p>Mostly rigid body dynamics, handled by a <a href="https://en.wikipedia.org/wiki/Physics_engine" rel="noopener noreferrer">physics engine</a> — Unity uses PhysX-based solutions, Unreal uses Chaos, Godot ships its own solver.</p> <h2> Rigidbodies: the building blocks </h2> <p>A rigidbody bundles mass, velocity, drag and gravity response. Dynamic bodies are fully simulated; kinematic bodies move only when code moves them. See <a href="https://szgames.co.uk/" rel="noopener noreferrer">this UK gaming resource</a> for more beginner-friendly explainers.</p> <h2> Collision detection in two phases </h2> <p>Broad phase eliminates impossible pairs via bounding boxes or octrees; narrow phase runs precise tests on the rest. Games use simplified invisible collision proxies — most players never notice.</p> <h2> The physics tick </h2> <p>Physics runs on a fixed timestep (typically 50–60/second), decoupled from rendering, so simulation behaves identically at 30fps and 144fps.</p> <h2> Why physics bugs happen </h2> <p>Tunnelling, exploding crates and jittering stacks all come from the solver approximating reality each tick. The bugs are the seams showing.</p> beginners gamedev softwaredevelopment tutorial Thomas Poli Thu, 15 Oct 2026 11:21:56 +0000 https://dev.to/thomaspoli/running-llms-locally-on-a-budget-a-practical-2026-guide-4h2i https://dev.to/thomaspoli/running-llms-locally-on-a-budget-a-practical-2026-guide-4h2i <p>Cloud AI APIs are convenient, but they come with recurring costs, latency, and the small matter of sending your data to someone else's servers. Running a language model on your own machine solves all three — and in 2026 the tooling has matured enough to be genuinely practical on modest hardware.</p> <h2> Why run models locally? </h2> <p>Privacy: your prompts never leave your machine. Cost: after the hardware, inference is essentially free. Offline access: a local model works anywhere. The trade-off is capability on the hardest reasoning tasks, but for code completion, summarisation and drafting, the gap is smaller than many expect.</p> <h2> The tooling: Ollama and LM Studio </h2> <p><a href="https://ollama.com/" rel="noopener noreferrer">Ollama</a> is the simplest start: install it, run <code>ollama run llama3.2</code>, and you're chatting within minutes. LM Studio is the friendlier GUI alternative. If you'd like a fuller walkthrough, <a href="https://techsslash.co.uk/" rel="noopener noreferrer">this UK tech walkthrough</a> covers the whole setup step by step.</p> <h2> What hardware do you actually need? </h2> <p>The key number is memory: a quantised 7–8B model needs about 5–6 GB of free memory, a 13B model around 8–9 GB, and a 32B model roughly 20 GB. A laptop with 16 GB of unified memory comfortably runs 7–8B models.</p> <h2> Which models suit modest hardware? </h2> <p>The 7–8B class is the sweet spot: Llama 3.2 8B, Mistral 7B, Qwen 2.5 7B. For coding, smaller code-specialised models often outperform larger general ones.</p> <h2> A note on expectations </h2> <p>Local models hallucinate — treat them as drafting assistants, not oracles, and verify anything factual.</p> ai llm privacy tutorial