RigidBody character demo for 3D using a capsule for the character. Cubes as RigidBodies spawn in the map from above to show interaction with the player (jump on them, gently push them), which would be impossible with a KinematicBody. How it works: This demo uses a RigidBody3D node for the player, and StaticBody3D node for the level. Each has colliders, the player moves itself via `apply_central_impulse()` in `_physics_process()`, and collides with the level. The ShapeCast3D node is used to detect whether the player is able to jump (i.e. touching the floor). Compared to a RayCast3D node which is infinitely thin, this allows for more reliable checking if the player is standing over an edge or corner. Language: GDScript Renderer: Forward+

This demo includes procedurally generated materials with 3 different techniques: - NoiseTexture2D: Built-in class that generates images on the CPU based on noise patterns (such as Simplex or Cellular). This is suited for static textures only. Texture generation is done asynchronously and is faster than using scripting, since the noise algorithms are implemented in C++ in the engine. - Scripting: Uses the Image class to procedurally generate an ImageTexture on the CPU. This is suited for static textures only. This approach is more flexible than NoiseTexture2D, but is slower to generate textures. Once the texture is generated, rendering performance is identical to NoiseTexture2D. - Shaders: Uses a 2D shader on a ColorRect node that matches a Viewport's size with the resulting ViewportTexture applied to a material. This is updated on the GPU in real-time, and is most suited for animated textures. This approach can also be used for static textures, with a lower performance overhead since the texture doesn't need to be updated every frame. Language: GDScript Renderer: Forward+

3D Platformer demo using a CharacterBody3D node. It uses similar code to the 2D platformer, but implemented in 3D. Language: GDScript Renderer: Forward+

This demo contains a series of tests for the 3D physics engine. They can be used for different purposes: - Functional tests to check for regressions and compare the behavior between physics engines - Performance tests to evaluate and compare performance between physics engines Language: GDScript Renderer: Forward+

This demo showcases a physical light and camera units setup: https://docs.godotengine.org/en/latest/tutorials/3d/physical_light_and_camera_units.html This allows you to use real world units for lights (lumen, lux, Kelvin) and cameras (shutter speed, aperture, ISO sensitivity). By default, Godot uses arbitrary units for many physical properties that apply to light like color, energy, camera field of view, and exposure. These properties use arbitrary units, because using accurate physical units comes with a few tradeoffs that aren't worth it for many games. As Godot favors ease of use out of the box, physical light units are disabled by default. If you aim for photorealism in your project, using real world units as a basis can help make things easier to adjust. References for real world materials, lights and scene brightness are wildly available on websites such as Physically Based: https://physicallybased.info/ Language: GDScript Renderer: Forward+

This project showcases various 3D particle features supported by Godot, for both GPU-based and CPU-based particles. This includes particle collision, attractors, trails and subemitters. Language: GDScript Renderer: Forward+

This demo showcases the use of occlusion culling and mesh level of detail in a 3D scene. The demo contains 1,024 identical rooms in a 64×64 grid. The room geometry is used as a basis for a baked OccluderInstance3D, which allows each room to be culled if it is hidden by another room's walls. Occlusion culling can provide a performance benefit in draw call-bound scenarios. However, since the Forward+ backend uses a depth prepass, the shading cost is already reduced by the depth prepass. As a result, occlusion culling will not always result in a tangible performance increase, especially in outdoor scenes that have fewer occlusion culling opportunities. Indoor scenes with no DirectionalLight3D casting shadows are a best-case scenario for occlusion culling. The blue spheres make use of automatically generated LODs, which reduce the number of triangles that need to be rendered each frame by the GPU. This provides a significant performance increase in scenes with complex geometry. In most scenes, this provides a greater performance benefit compared to occlusion culling. While running the demo, you can toggle the use of mesh LOD and occlusion culling to view the performance difference these features make in this project. Results will vary depending on your CPU and GPU model. WARNING: If you are using a engine build that is not fully optimized, you may notice that enabling occlusion culling decreases performance. This is because occlusion culling is a demanding process on the CPU, which needs all the build-time optimization it can get. Official builds are fully optimized, but self-compiled builds are not fully optimized by default (use the `optimize=speed use_lto=yes` SCons options). Language: GDScript Renderer: Forward+

Navigation demo for 3D scenes, with a character able to pathfind around a static 3D environment. The navigation path is drawn using a line. Code is provided for polyline following in 3D. Language: GDScript Renderer: Forward+

This project showcases the two main 3D text techniques supported by Godot: Label3D and TextMesh. Both Label3D and TextMesh exist in 3D space and can optionally be occluded by other objects, but they serve different use cases. Label3D: The Label3D node is a 3D node like any other. It draws text using one quad per character, which can optionally be set to work as a billboard. TextMesh: Unlike Label3D, TextMesh can optionally have actual depth since it generates geometry to represent the text. TextMesh is not a node, but a PrimitiveMesh resource you use within a MeshsInstance3D node. Therefore, you won't see TextMesh in the Create New Node dialog. Icons can also be displayed in Label3D and TextMesh using icon fonts, which can be generated from SVG files using serivces like Fontello: https://fontello.com/ Note that while Label3D supports colored rasterized fonts (such as emoji), only monochrome fonts can be generated from Fontello. TextMesh and Label3D with MSDF fonts are limited to monochrome fonts too. Both standard rasterized and MSDF fonts can be used in Label3D, while TextMesh will only support fonts that can be drawn as MSDF well. This excludes fonts that have self-intersecting outlines, which Godot currently doesn't handle well when converting them to MSDF. In most scenarios, Label3D is easier to use and can look better (thanks to outlines and MSDF rendering). TextMesh is more powerful and is intended for more specialized use cases. Language: GDScript Renderer: Forward+

Kinematic character demo for 3D using a cube for the character. This is similar to the 3D platformer demo. Language: GDScript Renderer: Forward+

A demo showing an example of a graphics settings menu. Included settings are: Video settings: - UI scale. - Resolution scale. - Display filter (bilinear or AMD FidelityFX Super Resolution 1.0). - Fullscreen. - V-Sync (traditional and adaptive). - Anti-aliasing (MSAA and FXAA). - Camera field of view. Effect settings: - Signed distance field global illumination (SDFGI). - Bloom (glow). - Screen-space ambient occlusion (SSAO). - Screen-Space reflections (SSR). - Screen-space indirect lighting (SSIL). - Volumetric fog. - Screen adjustments: brightness, contrast, saturation. Language: GDScript Renderer: Forward+

This demo showcases Godot's global illumination systems: LightmapGI, VoxelGI, SDFGI, ReflectionProbe and screen-space effects like SSAO and SSIL. Use the mouse to look around, W/A/S/D or arrow keys to move. Language: GDScript Renderer: Forward+

This project showcases the various 3D antialiasing techniques supported by Godot. - Multisample antialiasing (MSAA): High quality, high performance cost. Does not blur the image. - Fast approximate antialiasing (FXAA): Medium quality, low performance cost. Slightly blurs the image. - Temporal antialiasing (TAA): High-quality, low performance cost. Slightly blurs the image (but less so than FXAA). - Supersampling (SSAA): The highest-quality technique, but also the most expensive. Does not blur the image. - Alpha antialiasing: Applied on certain materials in the demo, available in two modes (Alpha Edge Blend and Alpha Edge Clip). This is most effective when MSAA is enabled, as Godot enables alpha-to-coverage rendering on the material in this case. When MSAA is disabled, a fixed dithering pattern is applied on the edge of transparent areas on the material. Godot allows using multiple antialiasing techniques at the same time. This can be useful to obtain the best possible quality, or to find a better performance tradeoff. A resolution scale slider is also provided. When set below 100%, AMD FidelityFX Super Resolution 1.0 upscaling can be enabled to improve visuals compared to traditional bilinear filtering. Language: GDScript Renderer: Forward+

This demo includes many examples of Decal nodes in action, for the purpose of showcasing Godot's rendering capabilities. The decal filter mode can be adjusted in the top-left corner: - For games with a pixel art appearance, the Nearest filter mode can be used instead of Linear. - Filter modes with Mipmaps prevent decals from looking grainy at a distance, at a small performance cost. When mipmaps are used without anisotropic filtering, decals will look blurry when viewed at oblique angles. - Filter modes with Anisotropic don't look grainy at a distance and also avoid looking blurry when viewed at oblique angles. However, filter modes with Anisotropic have a greater performance cost than enabling Mipmaps alone. Language: GDScript Renderer: Forward+

This project showcases the various constructive solid geometry features supported by Godot. CSG can be used to prototype level designs within the 3D editor: https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html Language: GDScript Renderer: Forward+

This example shows how to apply the State machine programming pattern in GDscript, including Hierarchical States, and a pushdown automaton. Why use a state machine: States are common in games. You can use the pattern to: 1. Separate each behavior and transitions between behaviors, thus make scripts shorter and easier to manage. 2. Respect the Single Responsibility Principle. Each State object represents one action. 3. Improve your code's structure. Look at the scene tree and FileSystem tab: without looking at the code, you'll know what the Player can or cannot do. You can read more about States in the excellent Game Programming Patterns ebook: https://gameprogrammingpatterns.com/state.html Language: GDScript Renderer: Compatibility

Example of how to make a fake wall using TileMap's `_tile_data_runtime_update()` method. It shows how to disable collisions per layer. Language: GDScript Renderer: Compatibility

This is a simple game where your character must move and avoid the enemies for as long as possible. This is a finished version of the game featured in the "Your first 2D game" tutorial in the documentation. For more details, consider following the tutorial in the documentation: https://docs.godotengine.org/en/latest/getting_started/first_2d_game/index.html Language: GDScript Renderer: Compatibility

This demonstrates how to manage large amounts of objects efficiently using low-level Servers. See Optimization using Servers in the documentation for more information: https://docs.godotengine.org/en/latest/tutorials/performance/using_servers.html Language: GDScript Renderer: Compatibility

"This is a test project that I made just to get a grasp of this game engine. Many elements are missing, such as sounds, menus, etc. Some elements are also kind of messed up. Expect this project to never be updated (maybe) because I might forget that I made it. I don't know why I decided to submit this here. Any feedback and suggestions are appreciated. Thanks."

Adds organizational classes like the GameRoot node, the LevelRoot node, or the GameMode resource, in order to facilitate making the base structure for a game. It is lightly inspired by Unreal, hence the name. This plugin adds the GameRoot, which is the main node of the game, and can load levels with transitions; The LevelRoot, which contains a GameMode; The GameMode, which is extensible, and has references to optional scenes for the player character, camera and controller, as well as a hud for the ui. These can be changed at runtime, as well as the entire GameMode itself, which updates the instances of these scenes as well. PlayerSpawn2D and PlayerSpawn3D nodes allow easy selection of spawn points.

Inspects subresources. ⚡ Must be ENABLED to be used! `Project` -> `Project Settings` -> `Plugins` - Inspect contents of Nodes and Resources - See if any resources inside are built-in and not in separate files - See resource types at a glance - Open full inspector by clicking an item - Pin root node/resource to prevent view from changing - Add Resource Files to Favourites to open them without searching File System/Quick Open

A fun game that showcases the basics of 2D game development in Godot.

The 3 Axies starter 3D: Buba, Pomodoro and Puffy