With the recent addition of abstract classes, I wondered if Godot was heading for another OOP feature I love from C#: the interface. I've seen a few people mention it in the past, but still no indication of it being added or even considered. Having spent the last month or so learning C++, I thought I'd try my hand to implementing the feature myself, and here's how it turned out.

There are a few bugs that need to be ironed out yet, but GDScript recognises "@interface" and "implements" and demands that all the functions in the interfaces you implement must be defined in that class. It also recognises classes implementing interfaces as those interfaces. In the above example, this means the code recognises bouncy_ball as an IBall object.

I'm still working on this, but once I've solved all the problems I know about I'll be submitting a PR to try and get this feature into future versions of Godot. Meanwhile, if you want to play around with this, here is where you can find my fork. Have fun!

Edit: I've been made aware of Traits, which appear to pretty much solve this problem but with a slightly better approach.

what Shader to make next ?
pick low-mid difficulty Shader or VFX and I will try my best

Shader Link : https://godotshaders.com/shader/colored-fresnel-shader/

Working on the sewer area for my PSX-style RPG.
This has involved building a bunch of modular pieces I can use to quickly build out new scenes in Blender, as well as learning Geometry Nodes which I make use of to create procedural cobwebs.

Since my game makes extensive use of pre-rendered backgrounds (inspired by old PSX games), I render out the background sequence as a series of JPEG stills, and then further I export an appropriate subset of the static geometry as a GLTF file which can be imported into Godot & used to mask dynamic geometry (such as the player) in order to layer correctly with the background.

The result is, in my opinion, pretty damn cool looking. Very happy with how this visual style is progressing & how the workflow is shaping up!

This is the first commercial project I'm proposing to do, I've always been in the "games for myself" environment and "I just want to implement this mechanic I saw in a game".So in July I decided to challenge myself and officially develop a commercial game.

I will soon complete 2 months of development and overall, we have the structure of the game, both mechanically and in the art style, but I won't lie, this project will still last for at least 4 months and a lot of things will change and possibly undergo adaptations.

I don't have any experience about marketing my game, in general, we can't invest much in it, our strategy is a demo and a STEAM page with the best capsule that our artist can make, but I simply saw some cases where this early publication drove away the public and the late one... well, it was too late.

When should I start these steps? Only when the game is 90% complete? Could someone with more experience marketing their games offer some advice?

👉 Check out the tutorial on Youtube: https://youtu.be/fahDYsPjUvc

So - wanna improve your custom 3D skybox in Godot, to get rid of the annoying issue of "pole stretching"? Discover how to use equirectangular panorama images and cubemaps in a few minutes :)

(Demo assets at the beginning from Kenney)

"FireLight" is an omniLight btw

Hey everyone! The Greenening is my first bigger project using Godot (after about 8 years of using Unity) and things are going quite well! I just released the demo and I'm super excited to share it with you!

🎮 You can play it here: https://store.steampowered.com/app/3634980/The_Greenening_Demo/

In The Greenening, you control a fluffy cloud, raining down on a forgotten planet. Discover the secrets hidden beneath the ashes and bring the world back to life. 🌱

It also features tons of upgrades, a cute character by the name of Sparkle and a cozy idle space garden.

I’d love to hear what you think - especially about the audio-visual style, pacing, and overall game feel.

Your feedback means a lot, thank you so much! 💚

i have being working on this blender-godot addons for syncing entire blender scenes in to Godot and be able to edit them on the fly i'll probably be making a YouTube video about it over at my yt channel YT/@Devbud check it out

Features of the Editor

• Layer Selection
• Tool Selection:
  • Pencil
  • Rectangle
  • Line
  • Select (supports copy,paste,move)
  • Fill
  • Erase
• Tool Shapes:
  • Filled Circle
  • Hollow Circle
  • Filled Rectangle
  • Hollow Rectangle
  • Scatter
  • Filled Diamond
  • Hollow Diamond
  • Cross
  • X-Cross
  • Chess
• Tool Modifiers:
  • Brush Size
  • Line Thickness
  • Collision Ignore
• Undo/Redo Function
• Automatically generated Filter-Section (scans custom data)
• Automatically generated Tile Inventory (scans tilesets and custom data, creates automatic tile previews)
• Visual Feedback and Previews
• Realtime 2D World Minimap
• Hotbar (9 slots) support

please give me feedback for the UI Design and general features! :)

Premise

Hello everyone! In a post a few months ago I was struggling to find a good workflow for level design in my PSX style game using Vertex Lighting. I have now found a really solid, modular workflow that I wanted to share for anyone in a similar predicament!

The goal here was something modular that I can combine and experiment with easily in Godot, while being able to use Vertex Lighting and achieve a PS1 aesthetic. This flow seems to be working for me well in that regard!

Trenchbroom didn't work for me because I needed smaller vertices to make vertex lighting work- Trenchbroom makes massive surfaces for things like walls and overall it didn't feel like it was facilitating what I wanted to do very well. Instead I ended up with a very beginner friendly and simple Blender + Godot workflow

Base Asset Creation + Import

1. Create some tileable square textures however you prefer (wall and floor for now).
   • Tune these to map to about a 1 meter space in Blender / Godot
   • Lots of tutorials out there on making tileable textures; I'd recommend looking into this step further if you don't know how!
2. Configure Blender to a 1m grid with snap and just create some 1m tiles, maybe some 0.5m tiles too.
   • I was able to achieve a lot with just a base wall, floor, and half-variant of each.
   • I cut my quads in half, or sometimes "pinned" them (cut in half twice) to make them work nicely with vertex lighting. PS1 games did this for vertex lighting as well.
3. Import the .blend file to Godot. In the import/re-import settings, go to the meshes tab and click "save to file" for each mesh. Put these in a kitbash or level_tiles folder.

Creating Tile Scenes (Components to make larger scenes with)

1. For each tile, make a new scene with the parent node as a "StaticBody3D". Make child nodes for MeshInstance3D and CollisionShape3D.
2. Assign the appropriate tile mesh to MeshInstance3D and create a BoxShape3D as the collision shape in your CollisionShape3D.
3. Align the parent "StaticBody3D" so that its bottom left corner aligns to 0,0,0 (rather than being centered) and align the children so that they follow the same practice (e.g. if your blender file was centered, transform it so that it matches the bottom left corner to 0,0,0 along with the parent).
4. Shape your collision shape to match the tile, with its surface aligning with the surface of your mesh.
   • It should be like a shallow box that goes under the floor or behind the wall with the same width / height.

Create Kit Pieces

1. This part takes some experimentation based on the needs of your project, but I've found that the most useful kit pieces are just sections of floor and wall in a 2x3, 3x3, or 5x5 layout. I name them things like floor_1_2x2 or wall_1_5x5.
   • You can make other things like pieces where a floor meets 3 wall tiles and a ceiling, but I found this clunky for more freeform design where I didn't know how tall I wanted the walls yet etc.
   • You can circle back to this step later to make kit pieces as they become more obviously needed in your development loop.

Creating Actual Levels

1. Create a new Node3D root scene. This is where you will combine tiles / kit pieces to make a level or level chunk.
   • Feel free to mix "Tile" pieces and "Kit" pieces here. You don't need to make a kit piece for everything, only what you find yourself reusing or doing by hand repeatedly!
2. Place a bunch of your new floor_1.tscn tiles together (or floor_1_3x3.tscn's together etc), making sure to enable "snap to grid". You should be able to build out floors, walls, etc.
3. If you make "level chunks" this way, you can again make a larger scene to combine your level chunk scenes into for a nice modular workflow!

No registration needed. The package includes a shader that lets you animate the UI and also applies a specular effect. This package is CC0, so use it for your personal and commercial projects https://jettelly.com/game-assets/ui-animation-and-specular Let me know if you have comments!

I've been working on my game for just over a year now, and I was kind of surprised that my codebase was this huge. Is this the norm for you guys?

I have made the dog states in such a way that he will decide whether to play or not based on a "playful" factor which can be changed by the user.

In my project, I wanted the player to be able to pull small objects towards them (like ammo, health, whatever). Unfortunately, since the first collision layer is the only thing the shapecast can detect, it's possible to pull things to you from the other side of things, pulling them through the wall/floor from the other side, even if the player can't see them.

Is there any way to make the shape cast ignore the walls without making the shape cast ignore anything that isn't assigned in a dedicated group? I plan to add occlusion culling later on that won't render anything the player can't see, which may fix my issue, but in the meantime, are there any other options?

(Also I apologize if this is a stupid question, this is my first Godot project)

Hey everyone!

A few months ago I posted about my analytics tool for Godot. Since then, I've been working on some features that were requested and wanted to share the progress.

New Feature: Pick Rate Analysis

This one came from feedback about tracking player choices. Instead of just counting events, you can now see actual selection rates:

• Card games: "Lightning Bolt picked 87% of the time when offered"
• Shop systems: "Health potions bought in 34% of encounters"
• Dialogue trees: "Players chose aggressive option 62% of the time"

The charts show percentages instead of raw numbers, which makes balancing decisions way clearer. I've been testing it with a few card game devs and the insights have been pretty useful.

Multi-Engine Plugins (All Open Source)

Also expanded beyond Godot based on requests (useful if you use more than one engine):

• Unity: https://github.com/TokebiAcademy/tokebi-metrics-unity-plugin
• Unreal: https://github.com/TokebiAcademy/tokebi-metrics-unreal-plugin
• GameMaker: https://github.com/TokebiAcademy/tokebi-metrics-gamemaker-plugin
• RPG Maker MV: https://github.com/TokebiAcademy/tokebi-rpgmaker-mv-sdk
• RPG Maker MZ: https://github.com/TokebiAcademy/tokebi-rpgmaker-mz-sdk
• Godot: https://godotengine.org/asset-library/asset/4225 | https://github.com/TokebiAcademy/tokebi-metrics-godot-plugin

All the plugins are open source so you can modify them or contribute fixes. The idea is you can track multiple projects in one dashboard regardless of which engine you're using.

What's Different

The pick rate stuff is specifically built for game mechanics, most analytics tools just count events, but this calculates meaningful percentages for player choice data. Plus having all your projects (Unity, Godot, whatever) in one place is pretty convenient.

The plugins are all available on GitHub if you want to see how they work or add features.

Link: https://tokebimetrics.com

If anyone tries the pick rate analysis, curious to hear what you discover about your player behavior.

What kind of player choice data would be most useful to track in your current projects?

What is ResourceUID intended for exactly? I've been using it to create unique identifiers for some nodes, but according to the documentation it sounds like ResourceUID might be used specifically for naming resources, potentially ones created dynamically mid-process?

Is it alright to use it for my own purposes as well, or may this mess up some hierarchy/organization stuff later down the line.

This is Frontier Combat: Beginnings, a JRPG where you build combo chains turn-based, but defend opponent combos in real time!

5 years of spare time solo-development, 1 hour single player gameplay and LAN multiplayer!

If you liked the game I will appreciate your wishlist! :) https://store.steampowered.com/app/3847960/Frontier_Combat_Beginnings/?curator_clanid=4777282

If you loved to play puzzle game "Mathora" on your phone then you can play this game for free. https://play.google.com/store/apps/details?id=com.himal13.MathIQGame

Features: Basic puzzles with word based and more Other 4 modes to play to improve your math Ingame rewards and more

Support me to reach 1k download

You have exactly one advice to give to your past self before starting your journey with Godot, what is it?

Edit: Make Local is an option when you right click a GLTF imported node in the scene tree. I'm not talking about Make Local on a resource, which makes more sense to me.

Let me start by saying I have used Godot 4 just about every day since launch, so I am pretty experienced in the engine. This is a long rant, so I'll put a TLDR here:

TLDR: After years of using Godot, I don't understand the point of "Make Local". Nobody makes a 3D model once and then it is perfect. It precludes the option of iterating on it, or at best, makes iterating extremely painful. So what's the point of this feature?

When it comes to importing models, textures, etc., .gltf + .bin file importing makes a lot of sense. The Godot docs also suggest this as the best way to do it. I don't like .blend importing, the external blender call is slow, and sometimes it breaks things. So .gltf + .bin is the way to go.

Now, once the file is actually in the engine, you have two options:

- Drag the .gltf file into a scene to make its own node containing all of the contents of the .gltf file

- Set mesh save paths, save animations, etc., to extract the contents of the .gltf file

Most game developers will immediately recognize the problem with the first option: namely, that you will need to modify the structure of what gets imported. You might need physics bodies, scripts, or ShaderMaterials applied to the objects contained within it. You might need to add signals or dynamic behaviour, or groups. At this point you have two options:

1. Hit Make Local - effectively destroying the link to the original blender file, but allowing you to modify the node however you want
2. Hit Make Editable - gives you some ability to add nodes and change things, but not completely

To my knowledge, developers don't like either of these options. I know in Brackey's video on importing things into Godot, he strongly suggests the option of "set mesh save paths", to create a more modular workflow where you still maintain the link to the .gltf file.

So that's all fine and well - and I use this workflow myself sometimes - but doesn't that defeat the purpose of .gltf in the first place? We have an entire scene hierarchy that we aren't using.

To my knowledge the solution to this is either:

Use convoluted pipelining steps (like the Blender-Godot addon, which I develop), or use GLTFDocumentExtension (a better way) to get more integrated pipelining.

I know there is some effort to get GLTFExtensions integrated in the engine, but won't this ultimately have some limitations as well? The extensions can't cover all usecases. Even something simple like trying to make a dynamic door opening object - there's no specific extension that would cover this type of dynamic functionality. In an ideal world, this type of thing could be pipelined, like how the Trenchbroom editor allows dynamic functions to be baked into the level design.

Should every developer make their own GLTFDocumentExtension pipeline to design their or asset conditioning pipeline? In principal I like the idea, but the overhead is intense, and even though I know how to do it, I often don't opt for it because it's slow or may end up not actually fitting my usecase.