GDQuest's Godot 4 feature demos, one folder per feature

A menu you can play through

This project is a set of more than 20 demos showing the new features of Godot 4, and the repository description calls it free and open-source Godot 4 demo scenes to see the new features in action.

The structure of the experience is simple and it is the right one for a demo collection. If you run the demo project, the navigation menu gives you a short description of each demo. If you prefer to jump to the code, the README has the full list. And the README invites you to run the project and test them out.

That last point is the argument for the format. A Godot feature is often much easier to understand when you can press a key and see it happen than when you read a paragraph about it in the documentation. Each demo here is small enough to run in a few seconds and small enough to read in a few minutes.

The project is maintained by GDQuest, and it also exists outside the repository. There is an itch.io page for the demos, a YouTube video linked from the front matter, and the repository's tags give the coverage of the collection: demos, 2d, 3d, physics, clipping, 2d_lighting, 2d_particles, 2d_physics, audio, 3d_particles, 3d_physics, animation, audio_polyphony, fonts, heightmap, ui, voxelgi, navigation, networking, sdfgi, tilemap and tweens.

The release history shows how it tracks the engine. The tags are test, an initial release in February 2023, 4.0 for the Godot 4.0 demos in July 2023, and 4.6 for Godot 4.6 in March 2026, with the last push to the repository on 2026-05-16. The README also says the repository will be kept up to date with the latest Godot 4 releases, and links the source code for previous versions, starting with Godot 4.0.

The Godot 4.0 list, feature by feature

The Godot 4.0 section of the README lists twenty-three demos, and reading the list is a decent summary of what changed in the engine's first major version.

The 2D work includes 2D clipping, 2D dynamic lights, 2D lighting with a normal map, 2D particles and a 2D physics benchmark. The 3D group has 3D animation tree audio, a 3D balls pool, 3D particles and the 3D physics nodes. Animation retargeting and audio polyphony stand on their own, the first for transferring animation between skeletons and the second for playing many sounds at once.

Then the features that changed how a project is structured rather than how it looks. A cutout character demonstrates the new 2D skeleton and cutout animation system. The dialogue tree demo covers the rework of the dialogue system. The heightmap physics demo is about the new heightmap shape and its collision handling. The interface and theme variations demos cover the user interface rebuild, and the UI flexbox demo is the new flexbox container layout.

The navigation demo covers the reworked navigation system, the networking demo covers the new high level networking API, and the outdoor environment demo is about the rendering changes with the new environment system, including the SDFGI feature the tags mention. The interior diorama is a showcase of the same, in a room rather than a landscape.

Finally there is the tilemap demo for the reworked tilemap system and the tweens demo for the rewritten animation tweening.

So the collection is not a game. It is a feature tour, and the feature list it covers is essentially the list of things a Godot 3 user would have to relearn.

The 4.1 additions and the editor-only examples

Later releases added to the collection, and the README separates them from the 4.0 list.

Godot 4.1 brought three more. The exported node array demo covers the change to how exported arrays of nodes work. The particles turbulence demo covers the new turbulence noise in the particle system. And navigation obstacles are covered inside the existing navigation demo, in a scene named navigation_obstacles.tscn rather than in a directory of their own.

That last detail is a small sign of how the collection is organised: a feature that belongs to an existing system is added as a scene inside that system's demo rather than as a separate entry, which keeps the menu from filling up with near-duplicates.

There is then a second tier of examples, described as bonus demos and code snippets, which you cannot run from the menu. The additional/custom_resources directory demonstrates custom resource exports, grouped exports, auto-generation documentation and the new inspector panel and export features. The additional/POT_generation directory explains how to generate POT translation files. The additional/snippets directory holds examples of the new GDScript features and syntax.

And there are two extra scenes in the main directories: a rainy scene in the 2D particles demo, which is what the README's image of a rainy night scene shows, and in the networking directory no less than six different network architectures, which the authors tried to keep as simple as possible to demonstrate different setups.

Six network architectures in one directory is the most useful thing in the bonus tier for anybody working on multiplayer. Godot's networking has changed substantially between versions, and the alternative to six worked examples is reading the documentation and guessing which architecture suits your game.

The repository layout

The repository is organised the way you would expect a Godot project to be, and the directory names make the structure obvious.

Each demo has its own top level directory, named after the feature, and the full set includes 2d_clipping, 2d_dynamic_lights, 2d_lighting_normal_map, 2d_particles, 2d_physics_benchmark, 2d_skeleton, 3d_animation_tree_audio, 3d_balls_pool, 3d_particles, 3d_physics_nodes, animation_retargeting, audio_polyphony, cutout_character, dialogue_tree, exported_node_array, heightmap_physics, interface, interior-diorama, lod, navigation, networking, outdoor_environment, particles_turbulence, theme_variations, tilemap, tweens and ui_flexbox.

A few of those directory names, as they appear at the top level:

2d_clipping
2d_dynamic_lights
2d_lighting_normal_map
2d_particles
3d_balls_pool
3d_particles

The main/ directory holds the navigation menu, which is the entry point when you run the project. The shared/ directory holds the code common to more than one demo, which is the piece that keeps twenty separate projects from each carrying their own input handling. The static/ directory holds the images used in the README and in the menu, and addons/ holds any editor plugins the demos need.

The Godot project files are at the root: project.godot is the project file, export_presets.cfg holds the export configuration for the platform builds, and full_screen_handler.gd with its .uid companion is the small script that handles going full screen. There is a build.js, which is the node script that drives the build, and the icon files with their .import files, which is how Godot tracks imported resources.

The interesting thing about the layout is the absence of a shared framework. There is no library directory and no common base class, because these are meant to be read one at a time and copied into your own project, and a shared abstraction would obscure the individual examples rather than clarify them.

The people behind the demos and how to drive them

The README credits the work in a way that names the individuals rather than a team.

It says the demos were not built alone, and lists Fales, Paulloz, Tokage, iFire, Smix8, Calinou and Raulsntos as the people who helped. That list is a good description of the scene, since several of those names are known for engine internals, which matters for a collection whose subject is engine features.

The controls section is short, and the reason it is listed is that these are interactive demos rather than screenshots. Most demos use the WASD keys, the mouse, the left mouse button and the space bar. Where a demo needs something else, the README says so where it is relevant.

That is the practical entry point. A demo of a physics or lighting feature is meaningless if you cannot move something, so the WASD and mouse bindings are the base vocabulary of the whole collection, and a new demo does not need to explain them again.

The README also points at the images as documentation. There is a screenshot of the font handling demo, with a person and a speech bubble, one of the navigation menu, one of the physics benchmark showing a pool of balls, one of the dynamic 2D lights, one of the 2D particles in a rainy night scene, one of the light handling with voxels, and one of the physics with an area of bouncing balls. Each of those images is a feature in one frame, and they are what the collection looks like in the README before you run anything.

Where this demo collection is the wrong tool

There are clear cases where this repository is not what you need, and the reason is the same in each: these are demonstrations of features, not patterns for building with them.

A demo of the tilemap system shows you how the tilemap node behaves. It does not show you how to structure a tile-based game, where to put the tilemap in the scene tree, how to organise the art assets, or how to handle the save data that a game needs. The same is true for the networking demos: six architectures are shown, but the game-specific problems of prediction, reconciliation and cheating are not, because they are not engine features.

The second limit is that the collection follows the newest engine. The releases track the 4.x line and the newest is 4.6, and the README says the repository will be kept up to date with the latest Godot 4 releases. A project on Godot 4.1 therefore needs the older source, which the README links per version, and the tags are named after engine releases so the checkout is possible.

The third is that the repository is a demo collection rather than a course. There is no project that builds up, no exercise and no narrative. It is a menu of more than twenty independent demos.

The alternative approach is the engine's own documentation and class reference, which describe the API completely and are versioned with the engine. The difference in approach is that the documentation tells you what a property does, while these demos show you the effect of using it, in a running program, in under a minute. For learning a feature, the demo is faster. For knowing a feature completely, the documentation wins, and the best use of this repository is as the thing you run first and the documentation you read second.

Editorial conclusion

GDQuest's demo repository suits a Godot developer who has read about a new engine feature and wants to see it working before adopting it, and a teacher who wants runnable examples of specific features rather than a complete game. It does not suit somebody who needs production patterns, since each demo is deliberately minimal and shows the feature rather than how it is used in a finished project, and it does not suit an older Godot install without checking which branch matches. Check three things before you run it: which Godot version the main branch expects, since the releases track the 4.x line and the newest is 4.6, that the licence is one your project can use, since GitHub records it as a custom licence that the LICENSE file defines, and whether the feature you care about is one of the listed demos or one of the editor-only examples in the additional directory. The last push to the repository was on 2026-05-16 and the newest release is 4.6.

Frequently asked questions

Official sources

1. gdquest-demos/godot-4-new-features on GitHub
2. Issues
3. README
4. Releases