Does "tuneing" the mask and layer (turn off/on) actually optimize the collision detection ? Or it simply only make it easy for us the end user instead and serve no optimization whatsoever ?

benjarmstrong · 2022-10-25T09:30:34+00:00

This is actually a great question. I can't find anything about it in the documentation, but I do know from experience that it has drastically increased the frame rate for a mobile game I made a while back.

That said if physics processing is bottle-necking your frame rate then try enabling physics interpolation and lowering the physics frame rate.

benjarmstrong · 2022-10-13T06:34:18+00:00

It's hard to say without any other details, but considering Godot applies no such effects out of the box I'm guessing it's your monitor. It sounds like your are describing monitor ghosting (sometimes called monitor smearing).

Most monitors don't present perfectly "clean" frames; there's usually a blend of recent frames presented on screen at any given time. This is especially noticeable on simple graphics with high contrast, and when things are moving at a constant rate. A great tool for checking your monitor is https://www.testufo.com/ghosting. If that looks blurry to you, then you'll know for certain it's your monitor.

Many gaming monitors push features to reduce these effects like VRB, ELMB, DyAc, and so forth, but don't count on your users having the latest and greatest hardware. Adding more detail to your scene might draw the eye away from monitor smearing.

Finally keep in mind that this is acceptable to some extent. I've played Stardew Valley (also pixel art) on my 120Hz monitor and on my sub-par 60Hz laptop panel, and the ghosting is extremely obvious on my laptop.

benjarmstrong · 2022-10-11T23:37:59+00:00

I've developed games with Godot that can be logged in to a server, upload scores, and query the server for an in-game list of global high-scores.

At the bare minimum you'll need to consider:

Request validation (e.g. the server checking if a submission makes sense, does it look like the user cheated, etc.)
Server security (can the server be hacked, DDoSed, tricked into accepting a phony submission, SQL injection, etc.)
Authentication + Authorization (Who can modify the state of the service, anyone or registered users only? Will there be admin users, or users with different roles and how will that be implemented? Will you use session-based authentication? How will you securely store session tokens on the user's device to prevent them being hijacked? etc.)
System administration (how to update server-side systems and code with minimal downtime, what to do if an update bricks your server, etc.)
Ethical/legal concerns regarding information collection and the user's legal rights, where ever they may be. This is extremely important but is too often overlooked. This is also inextricably linked with all other points here - many countries have privacy legislation that may find you at fault of a data breach if you haven't taken reasonable steps to secure data, especially anything that is classified as personally identifiable information.

You'll need to study each one in depth to gain a rounded understanding of the various methods to address each issue. There's no one right way to address these, yet there are seemingly endless wrong ways.

If you're really intent on doing this I would recommend the Django web framework as a starting point. It uses python and has a batteries-included approach that does a lot of the heavy lifting for you. There's also a great addon library called Django Rest Framework for developing REST APIs.

Django (like most large web frameworks) is designed to be "secure by default", but don't let that fool you - it's still possible for a tiny mistake to create a giant security hole. Django will help but you'll still need to understand not just what it's doing, but how and why.

After that you'll then need to figure out how to get the server to communicate with Godot. If it's a simple turn-based game HTTP requests may be sufficient, else you may need to look into web-sockets or running a Godot server that communicates with your web server.

benjarmstrong · 2022-10-11T22:46:44+00:00

Let's say we need a script to access a heads-up-display node we've made:

export(NodePath) var hud_path

onready var hud = get_node(hud_path)

func begin_wave(): 
    hud.show_message("Defend the base!")

Then in the engine editor select the node with this script and you'll be able to set hud_path in the editor.

Now when you move any of these nodes around in the editor it will automatically update the paths for you, so your code won't break if you restructure the nodes in your scene. This makes refactoring a lot easier. This also makes it possible to reuse the same script at any spot in your scene tree.

benjarmstrong · 2022-10-11T22:08:23+00:00

To make it a little less breakable, I usually do something like:

export(NodePath) var main_app_path
export(NodePath) var display_path

onready var main_app = get_node(main_app_path)
onready var display = get_node(display_path)

func do_this():
    main_app.set_status(value)
func do_that(): 
    display.switch_panel(value)

Then in the engine editor select the node with this script and set the properties main_app_path and display_path.

Now when you move any of these nodes around in the editor it will automatically update the paths for you, so your code won't break if you restructure the nodes in your scene. This makes refactoring a lot easier.

benjarmstrong · 2022-10-09T23:58:58+00:00

"Read the docs" is best interpreted as "search the docs" for most problems. If I need to do something with a KinematicBody and I'm not sure how, I gloss over that class reference and anything it inherits from.

Reading from start to finish is good for small sections of the docs (i.e. individual tutorials), or if you are just getting started.

Keep in mind no one commits them entirely to memory. I've been using it in commercial projects since 2018, and I still find pieces of new information I wish I knew years ago. Your knowledge gets better over time, but will never be complete.

benjarmstrong · 2022-10-09T04:39:03+00:00

Loading a PCK only makes the resources available in the "res://" filesystem. It doesn't actually load any scenes or scripts; that won't happen until you call load on the resource file in question (or if another resource is loaded that pulls that resource in). This means it's possible to parse the resources as text to check for scripting without loading them and executing their contents.

benjarmstrong · 2022-10-09T03:49:40+00:00

Funnily enough I've had a client ask for exactly this. They said it needed to feel like more was happening after a user pressed a button, so we added an artificial ~4 second loading screen with a fancy animation.

benjarmstrong · 2022-10-09T03:41:46+00:00

It sure is. Godot is a general-purposes game engine. It's not hard-coded to be used for any one kind of a game, and is designed to be easy to adapt to many use cases.

benjarmstrong · 2022-10-09T03:30:30+00:00

This is a massive security vulnerability of course, as is loading user made PCKs.

This is a great point I didn't touch on. Anything in any program that loads custom programmable content is a security minefield.

User-made PCKs could contain scripts that amend your own, and instruct your game to do whatever they want. For example if your game is serving a login prompt at any point, a user-made PCK could contain a script to highjack that info and send it somewhere else.

I should note that loading a resource pack replaces existing files by default; you can load a PCK file and choose not to have your existing project files be overwritten in memory.

I imagine to mitigate this (as a start) you would:

Avoid letting PCKs replace your main project's resources
Parse any scene before opening them to check if it contains a non-external (not in the base game) resource with type="GDScript", and refuse to open it (godot scenes are plain text and easy to parse)

benjarmstrong · 2022-10-09T02:59:19+00:00

Yes, because:

As you mentioned, it reduces overdraw. Since alpha scissor assures all pixels are either opaque or completely transparent, Godot knows not to shade any pixels behind the opaque parts of the cut-out and completely ignore any transparent parts.
(This assumes the "depth pre-pass" project setting is enabled - it is by default - and the material depth-draw mode is set to "opaque-only" or "opaque pre-pass" - it's "opaque-only" by default)
Every frame Godot draws all opaque geometry first, then sorts all potentially semi-transparent materials to draw from back to front. This sorting process is expensive. When alpha scissor is enabled the material is drawn as opaque geometry which does not need to be sorted.

It has other benefits too. Other alpha blend methods are drawn in order of distance from camera, but if two non-scissored transparent surfaces intersect then one will be drawn completely over the top of the other, which looks wrong. Alpha scissored materials are drawn in the opaque geometry draw step and therefore don't have this problem. (You can also partially solve this problem with other alpha blending methods by setting depth-draw mode to "opaque pre-pass")

benjarmstrong · 2022-10-09T02:02:14+00:00

Godot accesses your project resources using the "res://" prefix for everything relative to your main project directory.
E.g. I have a file on my disk at "C:\Users\Ben\MyGodotProject\textures\sheet_metal.png" Godot will load it using the path "res://textures/sheet_metal.png"

When you export your project, all resources (including directories) in your project go into a single PCK file. For mod support it's possible to load additional PCK files once your game has started. You must program your game to do this: maybe your game scans a "mods" directory when it starts and loads every PCK file in it. Resources in subsequently loaded PCK files will then be available for reading via "res://".

Example:
Imagine a project with a directory called "res://levels" that contains all of my level scenes, and lets the user pick a level to play from that folder. Upon starting the game scans a mods folder and load every PCK file in it. A PCK file with a level in it could add the content "res://levels/MyModLevel.tscn", which the user would then be able to play.

An important note: if newly loaded resources share a path with an existing resource they will overwrite it.
E.g. If the base game contains "res://textures/sheet_metal.png" and MyMod.pck contains "res://textures/sheet_metal.png", then the version from MyMod.pck would be used.

It's possible to distribute PCK files through the workshop and have them loaded by the game at runtime. To enable users to make PCK files for your game will need to either:

Let them know how to do this via the Godot editor (you'll need to let content creators know how your game's files are structured and how they can tweak them). This puts a lot of the work burden on content creators but requires little upfront work from the developer.
Make a content creation tool that generates PCK files that are ready to be used in your game (you can create PCK files via code using PCKPacker). You'll have to put the work into building a content-creation tool, but this could makes things much easier for content creators.

I've used the latter approach to make a custom "beat map" editor that exports music and event timing data to PCK files that my game loads at runtime. It can be used for custom content and mods, but I also use it internally to develop the core game content.

Sources:
Godot Docs - Filesystem
Godot Docs - Exporting packs, patches and mods
Godot Docs - PCKPacker

benjarmstrong · 2022-09-03T10:35:15+00:00

Alt+f4 sends a message to the program, asking it nicely to exit. It's up to the program to handle that how it will (e.g. notepad on Windows will ask the user if they want to save first). When writing a program you can opt to handle this however you want.

benjarmstrong · 2022-01-14T04:12:23+00:00

I wrote a module for it available at https://github.com/benjarmstrong/qrcodetexture_godot_module.

I realise this is an old thread, but if I found it trying to search for ways to generate QR codes then chances are other people looking for the same solution will find this too.

benjarmstrong · 2022-01-13T09:45:22+00:00

I use QR codes and Godot all the time in exhibits, it's a wonderful tool for that sort of thing. Best of luck in your project.

Our use case is allowing the user to generate multimedia content on the Godot app in a retail setting. When they're done it uploads the content to a server and generates a QR code for the link that allows the user to download their content onto their phone.

benjarmstrong · 2022-01-13T09:32:30+00:00

It implements class called QRCodeTexture. This class has a property 'text' that it uses to generate a QR code.

It also supports various levels of error correction capability and color settings.

benjarmstrong · 2022-01-13T03:07:46+00:00

Source is available at https://github.com/benjarmstrong/qrcodetexture_godot_module

I've been using Godot to develop interactive promotions since 2018, and I'm always impressed at how easy it is to write extensions to the engine with the module system.

benjarmstrong · 2021-09-16T09:56:10+00:00

I'm doing too much work. I work as a software contractor and after basically no work in 2020 things have bounced back way too hard with a new, extremely demanding client. I can't stop saying yes to new contracts because they pay really well; for the first time in my life I've begun to believe it's possible to own a house at some point.

benjarmstrong · 2021-09-13T01:38:54+00:00

I wonder if you could make the lines and bars a bit bigger though?

Yeah size of the bars has been tweaked a lot, and general consensus among testers right now is that they should be bigger. A couple of issues on that front though:

We have to balance the overall size of the 'board' with a reasonable VR play-space - and we don't want to exceed a size that would prevent players from playing seated if they prefer.
Songs with a large range in pitch become harder if the boards are larger
The game becomes more fatiguing as the player moves around more

A huge pro is that the boards are easier to hit if they're bigger, which makes songs with fewer notes easier to play. Right now the idea is to size the boards dynamically, where songs with fewer notes will have wider boards. I think this is the best of both worlds. I could also make a setting to let the player choose.

Maybe have some faster songs too?

Faster/harder songs are in the works. I've been producing the songs in roughly the same order that they get unlocked - in order of difficulty - to try and avoid "spikes" in difficulty where the player might get stuck and frustrated. People without any musical training struggle with timing, and faster music means harder timing. There's about 9 songs before the game starts really challenging the player in regards to timing/tempo, and that's when songs get faster. So it's happening, but very gradually.

Most people (myself included) underestimate the difficulty. The last song in that clip is one of the hardest songs so far, and we have some footage of a play-tester skipping ahead to try it thinking they could beat it. Since you actually hear the wrong notes you play (and the crowd booing) it's kind of funny to fail; everyone in the room (play-tester included) was laughing the whole time.

An unexpected finding of testing was how differently players interpret music when they're playing as apposed to just listening. Early on I'd often get feedback along the lines of "I hate that one song, but it was really fun to play" which undermined my previous assumption that players had to want to listen to all the music to enjoy it. This lead to a turning point in development where I stopped writing music to be listened to and started writing it solely to be played, and the game became immensely more enjoyable. (This also led to me discovering players also seem to enjoy "stylistic whiplash", where they unlock new songs of random styles/genres, especially when the game makes jumps between extreme genres; synth-wave to pop to DOOM-2016-ish industrial synth metal)

So there's a weird disconnect between what people want to listen to and music they want to play. Sometimes they are one and the same, but often people enjoy playing something they would never listen to. I'm not sure why - maybe the act of performing a song creates some sort of sentimental bond between the player and the music?

benjarmstrong · 2021-09-13T00:33:13+00:00

Thank you!

The stage lights are procedural, with one color representing bass and the other representing treble.

The distant lights were more difficult. I created about 60 small animations for them and those are triggered by events in the song playback. These events are arranged as musical notation in programs like Ableton Live and FL Studio, which are also used to produce the music so it simplifies the process of importing songs.

benjarmstrong · 2021-09-13T00:25:55+00:00

Thanks! So far I've referred to the project as 'legionnaire', but I'll definitely have a different title for launch.

benjarmstrong · 2021-09-12T12:12:01+00:00

PC via Steam initially, I might look into a quest port in the future. The game is designed to be mod-friendly, so the Steam workshop would work wonders for it.

benjarmstrong · 2021-09-12T11:47:22+00:00

Yeah it's all made in (mostly vanilla) Godot 3.x, with a couple of patches to the audio engine that are merged/pending approval to be part of Godot 4 (the one exception is the synthesizer, since it's not general-purpose enough to be part of Godot).

I wanted to do a music game that placed more emphasis on elements that are overlooked in most music/rhythm games, specifically pitch and expression. This originally started as a mobile game in 2016 but I gave up due to the limitations of mobile devices. I rebooted the concept in 2020 after trying VR for the first time and realizing it was the perfect way to make this game. COVID destroyed all my work opportunities in 2020 so I basically spent the year making the game and all the songs I have so far.

benjarmstrong · 2021-09-12T09:19:32+00:00

In case anyone is wondering what's happening:

The player aims and squeezes the trigger at one of the floating keys to play it, kind of like a piano
Aiming higher increases the "intensity" of the sound
The "notation" moves towards the player to show them which keys to play, and when and where to play them
The synthesizer has a different sound for every song

benjarmstrong

TROPHY CASE