General and performance-related inquiries regarding game

Xrayleader

Hello, i'm fairly new around this forum, i'm currently making a game, so far i'm making good progress, but there's some questions that have risen along the way, most of them are in regards to performance, so my apologies if this isn't the correct place to put them:

1.- What are the proper coordinates to set resources inside a scene? (For example, i tried setting everything from X:0 Y:0, but it turns out it doesn't give a lot of room to scroll up or right, so i moved my assets way down to Y:1000) 2.- What is the recommended way to set up a "Level" Scene (For example, i have a test scene set like this:) main(Node2D) ---Player ------Camera2D ---ParalaxBackground ------ParalaxLayer -------Sprite ---Layer2(Node2D) -----Tilemap ---Layer1(Node2D) -----Tilemap ---Item(Kinematic2D) ---Enemy1 ---Enemy2 ---Enemy3 (Yet i've seen proyects with simpler setups) 3.- How many Audio Stream Players is the maximum recomendation/what is their impact peformance wise?(Is it better to have a single reusable Audio Stream Player and load the desired sound for the occasion or create one Audio Stream Player for each sound? 4.- One small bug i've noticed is that music slows down a bit when my character attacks, am i doing something wrong or is it an issue outside of Godot?

Those are the questions i have for now, thank you for taking the time to at least read this post :)

cybereality

Hi and welcome to the forum.

1) Coordinates can be arbitrary mostly. I mean, there are conventions to use. For 3D, 1 unit is 1 meter, and for 2D it is based on pixels. But where zero is shouldn't matter (unless you have a really large world and get floating point inaccuracy with huge numbers). Numbers less than zero become negative and shouldn't cause any problems.

2) Node hierarchy can also be mostly whatever works for your game. Definitely simpler is better, but I'm not sure there is a "right" or "wrong" way assuming it works and is not overly complex to waste your time.

I haven't worked with sound much, so I don't know about your other questions. Hope that helps.

justinbarrett

First every game is different requiring different methods. I can only attest what works well for me.

1) @cybereality is correct, from my experience

2) Node hierarchy is different for everyone, but what works best for me is to have a main node "world" that has the constant/persistent nodes e.g. player, camera etc.. for the world and or levels I just add and remove them as necessary. This keeps load times low and reduces ram usage...this also works well if you are streaming chunks in a large open world, or if you are just going through level by level keeping the previous level and next level in memory or loading them in the background.

3) AudioStreamPlayer is just a reference, like any other node AFAIK...what matters is how many streams are playing simultaneously...most computers can usually deal with it pretty well, that is, I have never run into issues with sound taking up too much of my resource pool. Like with anything else you can optimize sound with some clever techniques IF it gives you trouble..

4) this seems like either a bug, or something wrong in code... if you are using very large sound files I suppose it can do this when loading into memory, but I'm pretty sure they get preloaded... it's better to use many small sound files(like an orchestra) than a few very large ones. This can also be unrelated to the sound and something with the logic happening when the sound is playing. You can easily test this by assigning a key to trigger the sound while you are motionless...it's not the most accurate, but it could give you a hint that your logic is just too heavy...with many loops and lots of physics...or many deep statements(if else).

If you need more clarification feel free to ask more questions...the more specific you can be the better people here can help...good luck :)

Xrayleader

Thank you very much for your answers, i'm gonna give some input of my own: I tried, like i mentioned, using two Audio Stream Players created by code at runtime, one for sound and another for music, but when i attacked the music will slow down a bit and "crisp" while the attack lasted, using dedicated Audio Stream Players for each sound and music stopped the slowdown.....almost, i presume that the remaining slowdown is just issues with my hardware

Bimbam

As an aside, if your not already using the profiler in the debugger it has been a lifesaver for me for improving performance.

For example, it highlighted a drop in FPS I saw when introducing a LOD script, that ended up being due to running said script on each object instance. Instead, I rewrote to run at the parent level and iterate its children which seemed to improve things significantly (presumably there is an overhead associated with each script?).

Then I was still getting lag from excessive distance calcs from a specific function in my LOD script, as it was still trying to call the function ~800 times a frame. Threading & distributing the workload across frames reduced 800 function calls to ~24(across 4 threads though I'm not convinced my thread code is working quite right yet, and depending on what's within a given chunk) and my script induced lag disappeared with approximately the same functionality ^{^.}

Now I'm just fighting terrible GPU limits again -.-

Xrayleader

I don't think i've used it, might try setting it up later, thanks!

Also, i do have some visual bugs aside from musical ones, but i believe that an outdated GPU could be the issue

By the way, what are some of the do's and dont's of using "process"?, for example, i have some "ifs" for checking certain states, i'm aware that by putting them inside process means that it checks every frame, and so far it hasn't given me issues, but that doesn't mean it will not in the future (slowdown, etc).

cybereality

The docs say to use physics process, but I found this to introduce lag, especially on high refresh monitors. I think for stuff that is not latency critical, for example testing door triggers or item pickups and stuff like that, physics process is probably best. For core character movement, mouse looking, I would use process. It just feels the best. For stuff that happens infrequently, like jumping, opening the pause screen, switching weapons, that sort of stuff, can be in input.

Xrayleader

I actually used a combination of sorts that involves a "get_input" inside "physics_process", using "_process" to constantly check if some flags are "true" or "false", like i said, so far i haven't had any issues, but i would still like to hear some feedback to keep in mind.

Also, another question, what could be an effective way to freeze enemies an hazards?, as in, while on an "get item" animation or the like?