godot – Prose Poetry Code

Fork in the road

The past week or so has been an eventful one in the game development world. Unity is still backpedaling on their disastrous attempt at charging devs per-sale. The CCP-infested Unreal Engine has lowered its royalty fee. Ubisoft is teaching us all how best to set half a billion dollars on fire.

And then there’s Godot.

I’ve written about Godot Engine in the past. It first came out about 10 years ago, and it took the opensource world by storm. Here was a pro-level—okay, semi-pro back then—game engine that was free to use, without worrying that Unity would demand payment when you only ever opened the editor twice. (This actually happened to my brother.) Over the past decade, it grew, evolved, becoming the premier engine for budding developers on a budget.

All that changed a few days ago. "Get woke, go broke," the saying goes, and Godot’s management has chosen to go for broke. A far-left "community manager" proudly boasted on Twitter that this engine was perfectly fine being on an admittedly overzealous list of woke games. Fine. Sure. Find me a AAA studio that isn’t utterly broken to the mind virus, and I’ll gladly buy their games. Well, except I can’t actually buy their games; they won’t sell them to me. (California got one right this time, amazingly enough.)

Most people probably ignored the initial message, seeing it as just another fluorescent-haired professional victim parroting the latest narrative. And that’s probably how it was originally intended. But then came the doubling down. People who questioned the intent of the message started getting banned. Developers were kicked out. Backers were kicked out. The project head first claimed to be apolitical, then whined about being bullied off Twitter altogether, retreating to the safe space of leftist Mastodon. At every turn, those who objected to, disputed, or simply asked about Godot’s underlying political agenda were purged.

The great thing about open source is that this doesn’t mean the end. Because anyone can take the source, compile it, and release the resulting binaries, an open project can’t be shut down by progressive whim; this is most likely why so many are switching to "open core" models or demanding copyright assignments.

End result, though, is Redot Engine. Yes, the name’s derivative, but that’s to be expected. The whole thing is derivative, but in the positive sense that only free code under a permissive license allows. Redot hasn’t even released a build yet, and they’re already overwhelmed with support, so much so that Godot’s screeching gallery has started openly attacking it. They use the usual communist methods, so familiar from Antifa, BLM, and anything to do with Trump: projection, accusations of white supremacist beliefs, attempts to clog the system with garbage, and vague allusions of unseemly images stored on the "bad guys’" computers.

All this, because someone said, "No, I don’t want my game engine to have a political agenda."

Nor should it. Tools should be apolitical, because a tool, in and of itself, is amoral. It does not think or act on its own. It simply exists. The uses of a tool are in no way indicative of any inherent moral qualities of that tool. Nuclear bombs were once considered a viable means of digging canals, after all. And even if we accept the idea that a tool can espouse an ideology, why would we want one that’s communist? Why would we want to support the single most deadly ideology in all of human history? The one responsible for the Holodomor and the One Child Policy, the one that gave the world Stalin and Mao and Castro and Chavez?

Redot, as I see it, can be a chance to show that some people are still fighting against the encroachment of anti-human ideology in software. That gives me hope, because I’ve often felt I was fighting that battle alone, as I watched project after project adopt censorious codes of conduct or otherwise wall themselves off from rational discourse.

It’s not perfect yet, so my other hope is that the Redot team understands two things. One, something founded purely on a negative basis—that is, solely to be against another—cannot endure. This was the downfall of Voat and Threads, among many others

Second, if Redot wants to be inclusive in the true, non-bowdlerized meaning of the word, then it must be open. As yet, it is not. All discussion and development is currently hosted only in walled gardens: Discord, Github, Twitter, Youtube. There isn’t any way for a privacy-conscious developer/author to contribute, and I won’t compromise my own morals by supporting the very platforms which have spread the woke mind virus to software development in the first place.

So that’s where we stand right now. Godot has self-immolated, and I have no problem saying they deserve it. Redot is carrying the torch, but they need to prove that their words are not just wind. If they do, then we will have not only a great game engine for free, but a beacon of light in an otherwise dark time.

New adventures in Godot

As I’ve said many times before, I think Godot Engine is one of the best options out there for indie game devs, especially those working on a budget in their spare time. Since I don’t have all that much spare time (rather, I have more than I know what to do with), I thought I’d put my money where my mouth is and try to make a game.

I know it’s not easy. It’s not simple. That doesn’t mean I won’t give it a shot. And I’ll be sure to keep you updated as to my progress.

What I’ve got so far is an idea for a casual word-find game. Think a cross between Tetris and Boggle. You’ve got a playfield of letters, and the object is to select a series of them that spells out a word. You get points based on the length of the word and the letters you use (rarer letters like J or Z are worth more than the common E or R). Then, the letters you chose disappear, and others fill the space.

That’s where I’m at now: getting the field set up. Then, I’ll work on the rest of the basic game mechanics, from selection to scoring. UI comes after that, and games need sound effects, animations, etc. Eventually, I’d like to produce a mobile and desktop version for you to download here or elsewhere. (Still weighing my options on that.)

Don’t expect too much, but if I can get this done, I hope to move on to more ambitious projects. Although I do focus far more on writing these days, I still love coding, and game programming remains one of my favorite aspects. Godot makes that part easy, and it does it without all the cruft of Unity or Unreal. It really hits the sweet spot, at least as far as I’m concerned.

On Godot 3.0

For a couple of years now, I’ve been talking about the amazing Godot Engine. Recently, I’ve been writing so much that I haven’t had time to get back into coding, but the announcement of Godot Engine version 3.0 got my attention. Now, I’ve had some time to play with it, and here’s my verdict.

First off, Godot is free. It’s open source. It’s cross-platform, for both development and deployment. All three of those are important to me. I’m poor, so an engine that costs hundreds or thousands of dollars just to get started is, well, a non-starter. Second, my desktop runs Linux, so a Windows-only tool is probably going to be useless, and something proprietary really isn’t good when you have the very real possibility of having to delve into the bowels of the engine for customization purposes.

Yes, something like Unity is probably better for someone who’s just starting out. It’s got a bigger community, it’s more mature, and it does have a much more professional air. On the other hand, Godot’s new version really ups the bar, putting it on the same general level as other “indie-friendly” game engines.

New and improved

The biggest new feature in Godot 3.0 has to be the improved 3D renderer. 3D was always Godot’s weak point, especially on certain hardware. Namely, mine. Last year, I was running on integrated graphics (A10 Trinity, if you care), and I got maybe 5 FPS on Godot’s platformer demo. Fast-forward to January 1st, 2018, after I installed a new (to me) RX 460 running the fancy amdgpu drivers and everything. Curious, I fired up Godot 2.1 and the demo. Results? 5 FPS max. No difference.

With 3.0, though, that’s no longer a problem. From what I’ve read, that’s because the developers have completely overhauled the 3D portion of the engine. It’s faster on low-end (and medium-level) hardware, and some of the sample images are stunning. I’d have to do more tests to see just how well it works in practice, but it could hardly be worse than before.

In a way, that perfectly describes all the new features. The renderer’s been rewritten to be better. Physics now uses the Bullet engine instead of a homebrew system. Audio? Rewrite. Shaders? Rewrite. It’s not so much revolution as evolution, except that doesn’t work. No, think of it more as evolution by revolution. Now, that’s not to say there are no new features in this version. It’s just that those are overshadowed by the massive improvements in the existing parts.

I’ll gladly admit that I don’t care much about VR gaming. I’m not one of those who see it as a gimmick, but it’s not ready for primetime yet. But if you’re of a different persuasion, then you might be interested in the VR support that’s been added. I’ll leave that to you to discover, as I honestly have no idea how it all works.

More to my taste is the additional programming support. Godot uses a custom scripting language by default, a Python clone designed to interface with the engine. I’m not really a fan of that approach, as I’ve written before. Clearly, I’m not alone in that thinking, as version 3.0 now offers more options. First up is GDNative, way to extend the engine using external libraries (written in native code, hence the name) without going through the trouble of recompiling the whole thing every time you make a change. That one looks good on its face, as it opens up the possibility of integrating popular and well-tested libraries much more easily.

But that doesn’t really replace GDScript, although it does add the ability to make bindings for other scripting languages. The new Mono support, on the other hand, actually does change the way you write code. It’s not perfect (as of this writing, it’s not even complete!), but it definitely shows promise.

As you know, Unity uses C# as its language of choice; they’ve deprecated JavaScript, and they try to pretend Boo never existed. Well, now (or once it’s done) Godot will let you write your game in C#, too. Even better, it surpasses Unity by using a much newer version of Mono, so you get full C# 7.0 support, assuming you trust Microsoft enough to use it.

If that wasn’t enough, there’s also a “visual” scripting system, much like Unreal’s Blueprints. That one’s in its early stages, so it’s not much more than a flowchart where you don’t have to write the function names, but I can’t see it not getting improved in future versions.

So there you have it. I haven’t even scratched the surface here, but I hope it whets your appetite, because I still think Godot is one of the best indie game engines out there. If you don’t have the money to spend on Unity, you’d rather use a platform without a port of the Unreal editor, or you don’t want to risk getting sued by Crytek, then there’s almost no reason not to give Godot a shot. It’s only getting better, and this new version proves it.

Godot Engine 2.1

So a new version of one of my favorite game engines came out recently, and I’m just now taking a look at it. (Actually, I’m writing this on the 11th.) If you’ll recall from a couple of months ago, I tried making a game in Godot 2.0, but I couldn’t continue due to an illness. Now, with a new version out, I think I might try again soon. But first, let’s look at what’s in store, and let’s see if Godot is still worthy of the title of Best Free Game Engine.

Asset sharing

Unity’s absolute best feature is the Asset Store. There’s no question about that. It’s got everything you need, and it’s almost possible to make a game just by downloading graphics, sound effects, and pre-written code from there. And other engines (Unreal, etc.) are starting to jump on the same bandwagon.

With version 2.1, Godot can now say it’s joining the ranks. There’s a new Asset Library accessible within the editor, and it’ll eventually work the same as any other. Right now, it’s pretty bare, but I have no doubt it’ll grow as time goes on.

Better plugins

Godot’s editor has a lot of features, but it doesn’t do everything. Developers have always been able to add functionality with plugins (mainly through using the tool keyword in Godot scripts), but 2.1 brings a whole new EditorPlugin API, meaning that these tools can integrate better with the rest of the editor. They can also work with the Asset Library.

The API, like the Asset Library, is a work in progress, so it doesn’t have all the features yet. But give it time.

Editor improvements

If you don’t speak English, Godot 2.1 helps by supporting full internationalization of the interface. Along with that, the developers have added full support for actual fonts, instead of the whole “import TTF to textures” process we used to have to do. This also opens up the possibility of customizing the editor’s fonts, their colors and sizes. And it’s a small step from there to full-on theming, so that’s in, too.

Another nicety is custom keybindings, and that solves one of my bigger gripes. Not that I couldn’t change the bindings, mind you; I rarely do that in programming apps, if only because it makes tutorials harder to follow. No, now I can actually see what the default bindings are. Godot’s documentation was severely lacking in that area, but giving me the option to change now also brings the ability to discover, and that’s always a good thing.

They’ve also added some drag-and-drop stuff that I’ll probably never use, along with context menus, which I certainly will. And then there’s the usual improvements to the script editor, which are necessary when you’re using your own scripting language. (More on that later.)

Animation

Animation in Godot confused me. It must have confused a lot of other people, too, because one of the big new additions is a simpler way of using the AnimatedSprite node for, well, animation. You know, the thing it’s made for. No longer do you have to create an AnimationPlayer and all that, when all you really want to do is say, “Hey, play this one little animation, okay?”

The verdict

The official announcement (linked above) has a few other additions, like new features for live reloading. They’ve also got a link to the full changelog, if you like reading. But I’m content with what I’ve seen so far. Godot is still good, and it looks like it’s only getting better—maybe.

What does the future hold? Well, according to the developers, the next version is 2.2, due by the end of the year. (Yeah, right!) That one’s the first true “feature” release, and what features it’ll have. Do you hate Python? My brother does, so he’s happy to hear that Godot will soon give you not one, but two new options for scripting. One is a “visual” design system like Unreal’s Blueprints, a style that I’ll be writing about soon. The other is massive in its importance: C#. Yep, the same language Unity uses. If that takes off, then look out.

Beyond that, things get murky. They claim they’re already starting on Godot 3.0, and it’ll come out early next year. As it’s centerpiece, it’ll have an entirely new renderer, probably based on Vulkan. And that might be a problem. But I’ll wait and see. Godot is too good to abandon, but I hope it doesn’t abandon me on the road to better things.

Godot game, part 2: Abort, retry, fail?

I don’t believe in fate. Problem is, fate doesn’t seem to care.

The week started off just fine. I got a bit of work done on the game late Wednesday night and early Thursday morning. Then, disaster struck.

For most of the next few days, I was almost totally bedridden, shivering and sweating in turns, coughing my head off, getting dizzy every time I stood up, and generally feeling awful. I figured it was nothing more than the usual allergy flareup of late spring/early summer at first, but as the days wore on, I suspected something more was afoot.

It was my mother’s idea to take me to the ER yesterday evening. I’m a poor, white man living in the rural South, so that’s effectively my only option, and it’s one I only like using as a last resort. When I go, it’s more to find out exactly what’s wrong with me than out of any hope that they can fix it. The ease of mind is just as valuable as the diagnosis and treatment.

After a 20-mile drive down there (again, rural South) and about half an hour of waiting, the doctor gave the verdict: bronchitis. Nothing worse than that, thank goodness, but that’s already bad enough, if you ask me. In the grand spirit of American doctors, he gave me a round of antibiotics (for what is probably a viral infection, naturally) and some lovely opioid-based cough syrup that is about as appealing to me as the coughing itself. Honestly, I can’t complain too much; I know from experience that there’s only so much you can do for bronchitis, apart from letting it run its course. But my mind is at ease, and that’s a far better medicine.

What does this mean for my grand “Godot Game Month” project, you ask? Well, total failure. Nothing less. Even if I felt 100% better today, I doubt I could work hard enough to catch up on the days I’ve lost. And I don’t feel much better. (Just as I wrote that sentence, I had another mild fit of coughing. Fortunately, nothing bad came of it. Correction: more bloody mucus. Yay.)

I know my limits. I know how far I can push them. I hate to admit defeat, but I am well aware when something is beyond my capability. This is one of those cases.

So, to sum up, the game is on hold, indefinitely. Once I get at least somewhat healed, I’ll start working on it again, but as a long-term project, something I do in my spare time. I tempted fate with this idea, and she slapped me down for it. I’ve learned my lesson; it won’t happen again.

As for the other posts, I have a nice queue full of them, enough to take me through the middle of July. Those will proceed as scheduled. Hopefully, by the time I need*to write again, I’ll feel like doing it.

A Godot game, part 1

So I’ve really been neglecting the “code” aspect of Prose Poetry Code lately. I’ve been far more focused on writing than writing programs, and it shows. Let’s change that. Let’s make a game.

The month of June has five Wednesdays this year. The first one is today, June 1. That’s the starting line. By June 29, four weeks from the day this is posted, I hope to have…something. I don’t know what it’ll be, but I want it to be more than my previous aborted attempts at actually creating a game.

Here’s the idea. I think Godot is a great game engine for indie developers on a budget, as I’ve said more than once on here. Now, I’m going to put my (lack of) money where my mouth is. My game will be simple enough, a little word-building game that’s a bit like a cross between Tetris and Boggle. Blocks containing letters fall from the top of the screen, and the player has to arrange them to form English words. Each word formed counts for points (based on the length of the word and possibly other factors) and it is removed from the board after it is made. If the player runs out of space on the board, it’s Game Over.

That’s what I have so far. I’ll worry about combos, difficulty levels, and things like that along the way. Think of this more like a game jam entry than a design document. Hopefully, by starting small, I’ll manage to end the month with something playable.

For those interested, here are the technicalities:

Although I’m writing this post on May 4, and I’ve already created an empty Godot project, I won’t start coding until this post is up, on June 1.
The goal is to have a playable game by June 29. It won’t be a finished product by any means, but I want something that could reasonably be called an alpha by that time.
I’m using Godot for the engine, and the assets are coming from OpenGameArt. At the end of this, I may put all of it up for download, but I don’t know yet.
Each Wednesday, I’ll post a bit of a status report. Those will make up the Code posts for this month. (Software Internals will return the first week of July.)
Other posts (worldbuilding, conlang, etc.) are still on schedule. I write those beforehand, mostly when I’m bored, so I should have a month of them stored up.

You’re welcome to play along at home. This isn’t a competition, though. If I can’t do it, then I can’t. So don’t expect me to push myself like I do for NaNoWriMo. Besides, there aren’t really any metrics for development like a word count. Counting lines of code isn’t that helpful, because nobody can predict how many of them you’d need. And finally, this is meant to be fun and educational for me, but I hope you take the same time to explore for yourself.

With that, I’m out for this week. Wish me luck. I’ll need it.

Godot Engine 2.0 released

Finally!

I’ve been saying for a while now that I think Godot is one of the best game engines around for indie developers. It’s open source, it’s free, you never have to worry about royalties—all it really needed was a bit more polish. Well, version 2.0 is out, and that brings some of that much-needed polish. Downloads and changelogs are at the link above, but I’ll pick a few of the improvements that stand out to me.

Scenes

Godot is, for lack of a better term, a scene-based game engine. Scenes are the core construct, and the engine has always been built around making them easy yet powerful. With 2.0, that’s now even more true.

Thanks to the new additions to scene instancing, Godot scenes got even better. Now, every scene in a Godot game is, to put it in Unity terms, a prefab. If you’ve used Unity, you know how helpful prefabs can be; Godot gives them to you for free. Basically, every instance of a scene can be edited in any way. All of its child nodes, including sub-scenes, are there for the changing.

It gets better, because now scenes can be inherited, too. The obvious use for this is a “base” object that is slightly altered to quickly create others. Enemies with subtle AI or animation changes, for example, or palette-swapped pickups. But I’m sure you can find plenty of other ways inheritance can help you. I mean, it wouldn’t be used so much in programming if you couldn’t.

The editor

Without the editor, Godot would be nothing more than Yet Another Engine. But it does have the editor, and that’s one of its biggest draws. The new version gives the editor a major overhaul, adding tons of new features. It’ll take some time to work out how—and how much—they help, but it’s hard to imagine that they won’t.

The most important, from my view, are multiple scene editing and the new Script view. Working with Godot, one of the biggest pains was the constant need to switch between scenes. They’re the central component of your engine, but you can only have one of them open at a time? No more, and that change alone will probably double your productivity.

The dissociation of the script editor from the scene editor turns Godot into more of an IDE. That will make it seem more familiar to people coming from code-heavy engines, for one thing. But it also means that we can keep multiple scripts open across scene changes. Again, the time-consuming context switch when editing was one of my main gripes with Godot’s editor. Now it’s gone.

Live editing

This one deserves its own section. Live editing is, simply put, the ability to edit your game while it’s running. I’ll have to try it out to see how well it works, but if it does, this is pretty huge. Especially in the later stages of development, fine-tuning can take forever if you’re constantly going through the edit-compile-run cycle. If Godot can take even some of that pain away…wow.

Combine this with the improvements to the debugger, including a video RAM view and collision/navigation debugging, and it gets even better. Oh, and if you’re working on a newer Android game, you can even have live editing on the device.

The announcement at the Godot homepage has a video of live editing in action. I suggest watching it.

The rest

Godot version 2.0 is a massive update. Those features I mentioned are only the best parts, and there are a lot of minor additions and changes. Some of them are of…questionable benefit, in my opinion (I’m not sold on heatmaps in the list of open scripts, for instance, and why not use JSON for your scene’s text format, like everyone else?), but those are far outweighed by the undeniable improvements.

I’ve said it before, and I’ll say it again. If you’re an indie game dev, especially if you’re focusing on 2D games, you owe it to yourself to check out Godot. It really is one of the best around for that niche. And it’s not like it’ll cost you anything.

2D Grid Movement with Kinematic Bodies (Godot)

Movement on a grid is common in many games, especially 2D games. In one of my current projects (a “falling blocks” game), this particular problem came up: how do you get grid-based (or discrete) movement on the X-axis while retaining free, continuous movement on the Y-axis? Specifically, I’m using the Godot engine, but the same principle should carry over to any game engine or development environment.

Movement in 2D

Many 2D game engines offer physics systems, and they all tend to be pretty similar (probably because most of them use Box2D under the hood). While your game may be all about sprites, the physics code works with bodies and shapes. Roughly speaking, bodies represent the “mass” of your game objects, while a body’s shapes outline its area. When two bodies’ shapes overlap, there’s a collision, which is handled however your game is supposed to: kill an enemy, take damage from a bullet, etc.

Depending on the specific engine, you have a few different kinds of shapes available. Godot, for example, lets you assign rectangles, circles, lines, “capsules” (like a rectangle with rounded caps on each end), and general polygons. If these aren’t enough, you can combine multiple shapes on a single body. Of course, most 2D engines work this way, so you probably already knew all that.

For bodies, you again have options. Walls and other immobile obstacles are usually static bodies (i.e., they don’t move), and interactive elements are often rigid bodies fully under the influence of physics. The player character, in many engines, is a third type of body, the kinematic body, which causes collisions and stops when it hits a static body, but isn’t affected by forces or friction or, indeed, any physics at all. Once again, though, you already know all of this, because that’s how most 2D physics engines work.

The Setup

For this specific problem, I’m using a kinematic body to represent each falling block. Attached to that body is a sprite (the default Godot icon, for this post) and a collision shape, as you can see in this screenshot:

KinematicBody2D scene tree

(In Godot, there are separate classes for 2D and 3D physics objects, so we have to use KinematicBody2D and CollisionShape2D.)

The kinematic body is the basic object representing each block, the sprite is its appearance, and the collision shape defines its area. Simple enough. Now, what we want to happen is this: move the sprite in two different ways. On the Y-axis, the block should fall down continuously, moving through every point on its way to the bottom. On the X-axis, however, we want the block to “jump” from one position to another, because the blocks have to stack perfectly.

I’ve also set up a scene to use as a base. It’s nothing much, just walls on either side and a floor on the bottom of the screen:

Scene tree for walls and floors

When all this is done, we’ll have a sprite falling from the top of the screen until it hits the “wall” at the bottom. At any point after it appears, you can click and drag it to move it from side to side, and it will stay on a grid, something like this:

Grid movement

Making the Body

We can make the body/sprite/shape combination as follows:

The KinematicBody2D is the root node. The only property I changed was reducing the collision margin (Collision > Margin in the Inspector window) to 0.001, the lowest it can go. You don’t actually need to do this for the example, but it may help if you have a problem with collisions detected when bodies aren’t really touching. (There’s also a script attached to this node, but we’ll get to that.)
The Sprite is our image. Load the icon.png file that’s included with every Godot project, and you can leave pretty much everything else as is.
The CollisionShape2D node, as you might expect, is our collision shape. Due to the way Godot works, we need to define the shape of the shape, which you can do under CollisionShape2D > Shape in the Inspector. Create a new RectangleShape2D in the menu, and set its X and Y extents to something a little less than 32:

RectangleShape2D Properties

(The logo image is 64×64 pixels in size, and extents are measured from the center. If we set the extents to exactly 32, then some blocks might be considered colliding when they really aren’t. That’s because of the collision margin I mentioned above. You can even like 31.999 if you like, and that may work better than 31. Honestly, I’m not sure at the moment.)

The Code

Now that we have all that out of the way, we come to the real meat of the post, the code. Add a new script to your KinematicBody2D node. I named mine gridmove.gd, but you can call it whatever you want. Anyway, here’s the code:

extends KinematicBody2D

# Our accumulated motion on the X axis
var xaccum

# Track if we're dragging a sprite
var mouse_down

# These are the width and height of the sprite
var twidth
var theight

# A default fall speed (like gravity, but velocity instead of acceleration)
const STARTING_SPEED = 100.0

# A velocity vector that we'll use for calculations below
var velocity = Vector2()

func _ready():
    # This object will use input and fixed-timestep physics
    set_process_input(true)
    set_fixed_process(true)

    # Initialize our variables
    xaccum = 0
    twidth = get_node("Sprite").get_texture().get_width()
    theight = get_node("Sprite").get_texture().get_height()
    mouse_down = false
    velocity.y = STARTING_SPEED

func _fixed_process(delta):
    # The object will fall until it hits the bottom of the world or another object
    var motion = velocity * delta

    # Test if we've accumulated enough movement to "jump" one grid square,
    # If we have, then we'll add that much movement to our motion vector.
    if abs(xaccum) > twidth:
        motion.x = twidth * sign(xaccum)
        xaccum -= twidth * sign(xaccum)
    else:
        motion.x = 0

    # Move the object as much as possible
    motion = move(motion)

    # If we're colliding (with the wall or another object), 
    # then we need to modify our motion vector.
    # See the Godot wiki for how and why this works:
    # https://github.com/okamstudio/godot/wiki/tutorial_kinematic_char#problem
    if is_colliding():
        var n = get_collision_normal()
        motion = n.slide(motion)
        move(motion)

    # If the mouse button has been released,
    # we can stop worrying about motion on the X axis
    if not mouse_down:
        xaccum = 0

func _input(event):
    # Create a rectangle covering the entire sprite area
    var gp = get_global_pos()
    gp.x -= twidth/2
    gp.y -= theight/2
    var gr = Rect2(gp, Vector2(twidth, theight))

    # If the left mouse button is pressed while over the object,
    # all we do is set our state variable. If it's released anywhere,
    # we clear that same variable.
    if event.type == InputEvent.MOUSE_BUTTON and event.button_index == 1:
        if gr.has_point(event.pos):
            mouse_down = event.pressed
            get_tree().set_input_as_handled()
        elif mouse_down and not event.pressed:
            mouse_down = false

    # If the user drags while holding the left mouse button,
    # that's our signal to start accumulating motion.
    if event.type == InputEvent.MOUSE_MOTION and mouse_down:
            xaccum += event.relative_x
            get_tree().set_input_as_handled()

The comments tell you most of what’s going on in the code itself. Basically, what we’re doing is “saving up” the motion on the X-axis until it’s enough to move by one grid “square”, which is the width of the logo sprite. The xaccum variable holds how much motion we’ve saved, and we check it each frame (technically, each physics update period, which isn’t necessarily tied to the frame rate). If we’ve saved up enough, then we move the sprite, deducting that motion from our accumulated value.

The added wrinkle is due to gravity, as you can see at the top of the _fixed_process function. Blocks in this particular scene fall at 100 pixels per second, and then they might move on the X-axis. With a vector, we can represent both of these motions, as in line 44, but then we have a problem. Kinematic bodies, remember, can cause collisions when they move, and the move() method stops when the body collides with another, as explained in the wiki article linked on line 49, which also shows how to use the slide() method to change the motion vector.

Spawning the Blocks

The following script should be added to the root Node of the other scene (the one where we defined the walls and floor). All it does is spawn a new block (body, sprite, and shape) whenever you press Space.

extends Node

var block

func _ready():
    set_process_input(true)
    randomize()
    block = load("res://block.xscn")
    spawn(randi() % 10)

func _input(event):
    if event.type == InputEvent.KEY and event.is_pressed() and event.scancode == KEY_SPACE:
        spawn(randi() % 10)

func spawn(column):
    var node = block.instance()
    var tex = node.get_node("Sprite").get_texture()

    # Add 1 to the column value for the left wall,
    # add 0.5 because positions are relative to the center of an object
    var spawn_x = (column + 1.5) * tex.get_width()
    node.set_pos(Vector2(spawn_x, tex.get_height() / 2))
    add_child(node)

Most of this is basic Godot engine stuff like creating a node instance. We do add a hint of uncertainty by spawning each new block in a random grid column.

Conclusion

There’s a lot more that can be done with this code, and it’s probably not bug-free. There may even be a better way of going about this particular problem. If so, I’d love to hear about it! Also, even though I used Godot for this example, the same pattern will work anywhere you have 2D physics, from big names like Unity, to Phaser and other “simpler” engines. You might even be able to adapt it to work in 3D, but I haven’t really tried. Let me know what you come up with, and have fun!