I’m a seasoned programmer and I’m trying to gather courage to start my first game. And a nice way to procrastinate is to try and get very familiar with the engine of choice by reading its documentation.
So one thing that puzzles me is how input works in Godot. I understand the basic concept - there are two ways to get inputs. Either poll them through the Input singleton (preferably in _physics_process()) or override one of the input callbacks (_input(), _unhandled_input(), etc). Fair enough. Thus I’m weighing the pros and cons, but I feel like I lack some information.
What’s the performance penalty of polling? Is it more efficient to handle _input() events and then set variables in my script, which I then check in the _physics_process()? It’s still kind of polling, except instead of the built-in Input class I use my own variables. But it’s simple boolean variables rather than string lookups in input map. Or is the performance difference negligible?
When are the _input() events called? I don’t think GDScript calls them in another thread, or does some sort of signal-like trickery where it suspends your script to call _input(). So I’m guessing they happen sometime between _physics_process() and _process()? Is this documented anywhere?
I’m worried about missing inputs or not registering inputs at the proper time, especially when the player’s machine is slow. Is it possible that either method misses an input entirely when the framerate drops? Alternatively, if all inputs are guaranteed to be registered (is this documented somehwere?), are there also any guarantees about the timing? Like, if the machine is slow enough that _physics_process() needs to play catch-up (that is, multiple _physics_process() calls between each visual frame), is either method guaranteed to deliver the inputs “at the right time”, relative to _physics_process() time? I don’t see any timestamps in the InputEvent class…
Godot is pretty much exclusively single threaded, concurrency is done through scheduling. You can create multiple thread for game logic but the engine doesn’t make any on it’s own.
It is better to use _input or _unhandled_input over polling every frame, I’m unsure by how much. It probably doesn’t matter much as you don’t often have hundreds nodes that require input handling.
I believe before each frame starts, again no threads for game logic so inputs are queued to be processed in between frames.
Inputs do not miss, if your player is lagging that badly then there is no way to recieve and process inputs faster than the computer can run.
I usually make use of both. The Input singleton for named actions (movement) and _unhandled_input for mouse. I think with the mouse it’s the only option.
It appears you are trying to future-proof your code.
Since you come from a development background, I recommend playing around with it before asking these questions. I did what you did when I started, and three years later, all the architectural diagrams I have on my wall are out-of-date because my understanding of how to do things the Godot way has grown, and Godot itself has changed a LOT. There are whole libraries (plugins/addons in Godot parlance) I wrote that have become obsolete because Godot handles them in the engine now better than I did.
If you haven’t yet, I recommend you take a look at these two documentation tutorials:
The things you are worrying about are theoretical. In reality you are most likely either:
Never going to encounter those issues.
Trying to make a 3D AAA game that Godot cannot handle. (Yet.)
If you have a particular worry about a game concept in your mind, you would be much better served telling us what it is and your specific worries. There is advice we can give you, if we know how to help.
Well, yes, this is my development background/perfectionism showing through. Whenever I write code, above all I strive to make it correct, whatever that might mean in the particular context. That involves thinking about all the edge cases and trying to figure out “how could this code break”? By making sure each separate piece is rock-solid, I gain confidence to build on top of it. After all, as they say, “If you don’t have the time to make it right the first time, when will you have the time to do it over?”
Conicidentally, I’ve never gotten into the habit of writing unit tests. There’s just never any time for them.
The game I’m thinking about isn’t some 3D AAA monstrosity, god forbid. It falls more in the category of a “2D platformer” - a genre close to my own heart. I don’t know what performance issues I might run into, but I don’t expect it will do anything terribly taxing on the hardware - unless I mess something up.
But the desire to define and achieve “correct” is always there.
Seriously though, if you’re interested in exactly what is happening in the iteration step, you can peek into engine source. I actually haven’t looked into specifics until now and I’m not the engine contributor.
In main.cpp there’s Main::iterate() which I assume is what is called over and over. Here we can see exactly in what order are things happening.
The call that dispatches events presumably is Input::get_singleton()->flush_buffered_events(). It appears twice; first inside a loop that does phyiscs steps, so for each physics tick, and then again right before MainLoop::process() is called.
I’ve been developing professionally for a few decades now myself. When learning a new language there’s always refactoring. With Godot you’re going to find that holds true. Because, if nothing else - the engine is changing.
I mean, true. In this case, the answer is…when you make the next game. I actually am a big planner too. I have created a whole framework I use for developing games in Godot. GitHub - dragonforge-dev/dragonforge-game-template: Game template for game jams. Because I got tired of developing the same sh*t over and over again for game jams.
See, I was with you until this point. There are two good unit testing frameworks for Godot: GDUnit4 and GUT. Now I don’t actually use them anymore, but I’m surprised with all your planning that you don’t unit test.
It won’t - even if you do mess something up. The only taxing thing I’ve managed to do so far is load layers of images on top of one another in the background. (I’m still trying to figure out how to collapse them to one image in Godot without me having to break out Gimp or Krita.)
You are the project manager.
I recommend you join some game jams and do a few tutorials on making a platformer. Game jams will help you get over the planning part, and tutorials will teach you how to get something out the other end, (and all the places you can do it better.)
I get the impression that you’ve never really had to be your own manager and direct yourself. Please correct me if I’m wrong.
I think this perfectionist mindset comes from having to work for a boss. Meaning, you’d get penalized and/or judged when something goes wrong.
Being your own boss has it’s pros and cons like any lifestyle. You don’t get paid by the hour, or get a set schedule, or have a consistent paycheck coming in.
In return, you get to have total control over how much work is enough, don’t have a boss breathing down your neck, choose your co-workers or lack thereof, and can be even more successful if you work hard.
It’s less an obligation and more another mode of existence. One which I prefer over working a standard job.
I also never want to work for a game studio. As the jobification will drain the life from me. Game development tasks are cannot be quantified with a time clock, because sometimes a task takes only a little bit of time or you could be stuck for a week on a single issue.
Also, game design and programming are NOT the same and require completely different skillsets. They’re two sides of the same coin with gameplay implementation.
And a nice way to procrastinate is to try and get very familiar with the engine of choice by reading its documentation. 
Whenever I write code, above all I strive to make it correct, whatever that might mean in the particular context. That involves thinking about all the edge cases and trying to figure out “how could this code break”? By making sure each separate piece is rock-solid, I gain confidence to build on top of it. After all, as they say, “If you don’t have the time to make it right the first time, when will you have the time to do it over?”
There are two good unit testing frameworks for Godot: GDUnit4 and GUT. Now I don’t actually use them anymore, but I’m surprised with all your planning that you don’t unit test.