DEV Community: PDeveloper

Drag and Drop in Godot 4.x

PDeveloper — Tue, 28 Nov 2023 16:17:47 +0000

I was working on an inventory system, and as such one must enable players to play inventory Tetris in case they're bored. I have made drag and drop solutions before on different platforms, and know that there are potential edge-cases and problems waiting to suck time and life out of me. Looking for the go-to Godot solution for drag and drop, search engine results were all throwing older, manually implemented approaches mostly.

But I did finally stumble on the built-in solution which already exists in Godot, and if there's one thing I've tried to get away from, it's from DIY/NIH rabbitholes. Perfect!
Here's a quick run through so you don't have to:

Control node interface

Control nodes have 3 virtual private functions you can override and will enable drag and drop functionality:

# Control that can be dragged from
func _get_drag_data(at_position:Vector2)->Variant
# Control that can be dragged to
func _can_drop_data(at_position:Vector2, data:Variant)->bool
func _drop_data(at_position:Vector2, data:Variant)->void

Docs: _get_drag_data, _can_drop_data, _drop_data

The drag and drop mechanism also works in that order:

_get_drag_data - returns the data that can be dragged from the current Control. In my case, if a slot has an item, then I'll return the item, otherwise null.
_can_drop_data - will continuously be called on the Control under the mouse position, passing the relative mouse position and data, and returns whether or not this data can be accepted. This is where I check if the current item fits in the inventory grid at the mouse position, and if the current slot is even compatible with the item type (Weapon slot for weapons, Back slot for backpacks, etc.)
_drop_data - the final call, which is the same as _can_drop_data, except here we are accepting the drop, and should handle removing the item from the previous container, and add it to the current Control (or whatever else you plan on doing with the data)

To handle the display preview of the drag and drop operation, we use:
func set_drag_preview(control:Control)->void (docs)

As one can expect, this will use the Control node you pass as the display icon of the drag and drop, add it to the scene tree, and destroy it once the drag is complete.

There is also force_drag(data:Variant, preview:Control)->void (docs) which will initiate a drag and drop programmatically. If you are calling this from the _drop_data handler, use call_deferred to call it in the next frame, since the current drag operation is still finishing. I use this when dragging items to a slot that already has an item, so I initiate a drag on the previous item for a faster swapping UX.

Using it

It's a simple interface, the basic usage is straight forward - Create some data that will be dragged from a Control, check this data, and potentially accept this data in a Control that can be dragged to.

One last problem I had was detecting if the user ends the drag, but on a Control that will not accept it. Here we can return to Node basics and use the lifetime of the preview Control! The full lifecycle then looks as follows:

User clicks and drags, Godot calls: _get_drag_data
We call: set_drag_preview
User drags over a Control, Godot calls: _can_drop_data
User releases the drag, and _can_drop_data was true, Godot calls: _drop_data
preview_control.tree_exiting signal is emitted

To simplify this lifecycle, I'm using a separate object for managing the drag operation:

class_name ItemDrag

signal drag_completed(data:ItemDrag)

var source: Control = null
var destination: Control = null

var item: Item
var preview: Control

func _init(_source: Control, _item: Item, _preview: Control):
    self.source = _source
    self.item = _item
    self.preview = _preview
    self.preview.tree_exiting.connect(_on_tree_exiting)

func _on_tree_exiting()->void:
    drag_completed.emit(self)

Using this class, an example of the other functions could be:

func remove_item(item:Item)->void:
    inventory.remove_item(item)

func _get_drag_data(at_position:Vector2)->Variant:
    var item := inventory.item_at(at_position)
    if item == null: return null

    var drag_data = ItemDrag.new(self, item, _create_item_preview(item))
    set_drag_preview(drag_data.preview)

    return drag_data

func _can_drop_data(at_position:Vector2, data:Variant)->bool:
    if !data is ItemDrag: return false
    var drag_data := data as ItemDrag
    # Check if the item can fit in the inventory at this position
    return !inventory.intersects_at(drag_data.item, at_position)

func _drop_data(at_position:Vector2, data:Variant)->void:
    if !data is ItemDrag: return
    var drag_data := data as ItemDrag

    drag_data.destination = self
    if drag_data.source: drag_data.source.remove_item(drag_data.item)

    inventory.add_item_at(drag_data.item, at_position)

Some of the functionality could be enforced by the ItemDrag class, especially giving things like source and destination stronger types that are guaranteed to have an interface for handling/adding/removing items. But having this set of functions defined is a good start to handling the full drag and drop cycle of operations.

Global drag and drop

In addition to the above Control-based (GUI-based) approach, Godot provides some more event hooks into the lifecycle. Viewport and Control provide functions on querying the state of any drag and drop operations:

# Viewport
func gui_is_dragging()->bool
func gui_get_drag_data()->Variant
func gui_is_drag_successful()->bool
# Control
func is_drag_successful()->bool

The first 2 should be obvious - the first can be queried to see if a drag and drop is happening at any point, the second to get the same data we returned in the _get_drag_data callback in our Control (or whatever data is contained from force_drag or other ways a drag has been initiated).

The last 2 can be used with the func _notification(what:int)->void handler to receive global notifications when a drag and drop has started or ended, and if it ended successfully:

func _notification(what:int)->void:
    if what == Node.NOTIFICATION_DRAG_BEGIN:
        # Drag data is available (populated by our _get_drag_data() function for example)
        var data = get_viewport().gui_get_drag_data()
        # Use the drag data
    if what == Node.NOTIFICATION_DRAG_END:
        # Drag data is no longer available and has been disposed already
        print("Drag ended. Success: ", get_viewport().gui_is_drag_successful())

These may come in handy, but are further from the drag and drop context. Some use-cases could be used by relevant drop receivers to highlight themselves, based on the drag data.

With these tools, any drag and drop scenario can be handled, hopefully this saves you any attempts at writing a custom drag and drop implementation. I wish you the best of luck and success in using this information!

Planetarium2D - Noise-based Pseudo-3D planets

PDeveloper — Wed, 28 Jun 2023 07:50:29 +0000

A short overview of my planet generation tool. Updates to come. You can view the referenced tool and code here, or just pretty pictures:

Boredom to Laziness-driven Development

I was bored, and at work needed to do some drives to some places where I would be waiting in my car for anywhere from a few minutes to maybe even a couple of hours. I was never a fan of having games on my phone, but over time had some small indie RPGs or strategy games, or my golden standard, Sudoku. Back home, every few months I would dust off the digital version of Heroes of Might and Magic III, and accidentally time travel to 5AM before a full day of work. As one does, I imagined having Heroes III with me on my phone and being able to have a huge game going at all times (Very smart to lean into a dangerously time consuming activity...) I could continue whenever I had a few free minutes.

Obviously, instead of looking for an existing game, I have to make it myself...

So I started the project with Godot. To minimize the amount of art assets I had to create, I decided I was going to go for a Heroes III-like in space. White pixels are stars in the background, easy money. Unit portraits I was able to find a nice set from Kenney assets, and while browsing, he also had a set of planet layers that could be combined to create nice looking planets. But I'm a smart programmer. What if I want to have 100 different planet types? What if I want a lot of different planet sizes and variations on different properties like atmosphere and maybe special resources that are visible, and how cool would it be to have it rotate? I was approaching pre-mature optimization levels of genius.

I remembered back in the Flash days and the ConvolutionFilter people having pseudo-3d spheres in some games, and I liked the effect, I finally had a use-case to apply it. Combined with Godot's built-in FastNoiseLite which was a one-stop shop for several noise-generation algorithms, and enough parameters to be interesting, it seemed like I had my little planets project all set to take off. Why spend 2 hours making some prototype planet pictures for a personal game nobody else might ever see and continue making an actual game when you can spend 2 weeks making a planet generator and rabbithole into making an editor for them?

Spherical Distortion

Step one, create a fragment shader to take a 2D texture, and make it a sleek round ball of sphere. This step is actually fairly simple once you understand the input and output of the fragment shader, and what you want to happen. In shaders, the UV (the coordinate of the texture to draw) is mapped from 0.0 (start of the texture) to 1.0 (end of the texture), meaning that for any texture, a UV of (0.5, 0.5) will be the center of that texture, basically normalized 2D coordinates. For a spherical distortion, we want to draw the texture normally near the center of the "sphere", and as we move to the edge of the sphere, we can see more and more of the texture squished into the same screenspace, as it wraps around the imaginary sphere we're creating. In pixel terms - near the center, every 1 pixel we're drawing on the screen will be roughly equal to drawing 1 pixel of the texture. Near the edges, every 1 pixel we're drawing will be many pixels of the texture, and eventually infinity right at the edge (since we're looking at the texture from a perpendicular perspective, we can "see" "all" of it). What is a nice equation that gets us there? arcsin of course!

As x moves to 1, the tangent moves to being vertical, and the y moves to PI / 2! Since we'll be scaling the UV coordinates, we get a ratio by dividing the arcsin value by the original value, giving us the amount to scale by. We can also divide by PI / 2 to normalize this scaling factor within 0 <= x <= 1.

In Godot shader terms, this can look like:

vec2 spherical_distort(vec2 uv) {
    float radius = length(uv);
    float displacement_scale = (radius != 0.0 ? asin(radius) / radius : 0.0) / PI2; // PI2 is a PI / 2 constant
    vec2 displacement = uv * displacement_scale;
    return (displacement + texture_offset) * texture_scale;
}

With this function, given a UV coordinate which is centered around (0.0, 0.0), it will "push" it out as it approaches the edges of the circle. This is the basis for spherical distortion in the shader. You can also see 2 other parameters (in this case they are uniforms), texture_offset and texture_scale. The offset is what is controlling the scrolling, or "spinning" of the planet. The scale, as one could assume, is simply a zoom factor for the texture. Since it is a vector, you can stretch the texture horizontally or vertically as well.

I now had nice little spheres I could use. Job done, right?

I Don't Have Scope Creep Problems

As a genius programmer, it's not enough to have something working, add it to your game and get on with it. What about all sorts of changes, I want to play around with the planets? What about generating planets based on physical parameters like humidity or temperature? Obviously, I need to create a custom GUI to easily play around with the look and feel of these planets, shouldn't take too long, and it will speed things up in the long run.

The next few days were spent on a little editor, because I wanted to play around with how I could parametrize the planet creation based on a few properties I wanted in the game, things like water-level, humidity, temperature, and types of minerals on the planets. As I worked, I started to want more visual effects, and also easier to use UI controls. Piece by piece, I had a cluster-fridge of ambiguous goals and ideas.

An early version allowed me to modify the noise generation and color gradients. I'm controlling my scope creep, so these will be enough. I had already added specular lighting, which already felt like reaching too far, but didn't require too many changes, so ... "while I'm at it...".

Height and Specular Mapping

I was already happy with what this version was capable of, since my initial goal was to target a pixel-art style. It's simpler to work with in game development terms, at least for my purposes, and the lack of too much detail meant I could be more permissive in the colors and types of planets. It's sci-fi, after all. But after looking at the planets for a bit, it seemed janky to have a pixel-art ground texture, but a smooth high resolution outline. Do I just live with it because it's just a prototype, the important part is progress on the game? Ha.

I started delving into high resolution planets and basing my roadmap on making them look good. They already looked satisfactory, and by using several layers with the same noise parameters, I could differentiate the water and land (at this point specular was a property of the whole layer). But getting side-tracked must not be stopped. I remembered about height mapping from earlier days when I dabbled in 3D rendering, and also having the specular as a property of the texture, with its own gradient, would make creating cool planets easier. I first thought about the amount of work to now have 3 different textures (diffuse/color, normal, specular), generating a normal map from the height texture and how these would increasingly drive the base algorithm further from being close to Godot's built-in functionality (which was a goal). Here, Godot itself was the enabler of my journey to nowhere. Turns out there's a CanvasTexture. This is a compound texture of, surprise, a diffuse texture, normal texture, and specular texture. Nice. And to finalize my pragmatic decision making process, Godot's NoiseTexture can automagically generate a normal map, using the noise as a height map. Looks like I'm in for the long haul.

"Luckily", because Godot already had these tools built-in, setting things up wasn't too hard, but it required I revisit my gradient editing UI components. Initially these were made to just be usable, but since now I'll be working with 3 different gradients per layer, I can't have the interface being cluttered for the imaginary users of this tool.

I got a curve editor working, and (as one does) refactored UI code to be more compartmentalized. As it stands right now, the control points for all gradients are synchronized, so each control point of the color curve has a corresponding control point in the height and specular curves. This isn't inherently necessary, and will probably change in the future to enable better color palette generation (there was a prototype, but we're controlling our scope creep, so not for now) while keeping height and specular curves simple.

Maybe More Maybe Later

Nice. This should definitely be enough. And it has been, for now. There are future plans to continue development, one important low-hanging fruit would be to have export options for the textures separately (diffuse, normal, specular), at which point I can't help but feel this slowly turning into a generic material editor. RIGHT?