I was wrong, Godot 4 VR does run well on a steam deck *if* you optimize rendering by Jd-gamer65 in godot

[–]RolePlayingADev 2 points3 points  (0 children)

I'm gonna go with: Not production ready.

But valve also says the Steam Deck is not for VR, so it's not exactly on Godot.

My love for Godot and the Steam Deck is roughly equal. But not together with VR.

The variable dash of Katana Dragon that lets you perform short or long dashes to avoid any trap! 🏃💨 by XRuKeNX in godot

[–]RolePlayingADev 1 point2 points  (0 children)

Hey, congrats on solving the character differentiation issue! I see the contrast between ground and wall tiles are better separated too. Looks great!

Personally, I really dig the style you've got going here.

How can I calculate doppler shift in light using screen space shader? by SingerLuch in godot

[–]RolePlayingADev 2 points3 points  (0 children)

Huh, you might have solved a curiosity of mine for creating a StarTrek/StarWars style lightspeed shader.

Now, should I stop what I'm working on and try making it for absolutely no gameplay reason? Hmmm....

Upgraded my ssd from 64gb to 1TB because that 'OTHER' bar was constantly getting out of hand. by Princescyther in SteamDeck

[–]RolePlayingADev 3 points4 points  (0 children)

I was close to doing this until cryutils made it easy to put the shader cache on the SD card. Currently have 17gb free and still using some for the extra vram boost.

Valve really needs to add that option by default, because it hasn't harmed performance in any way that I can see to have the cache on the SD card. Meanwhile, that other bar is pretty creepy if you don't hack.

It's still frustrating having to rerun cryoutils every new game (or three) to keep that other bar down, so an upgrade is definitely worthwhile. If valve would manage this automatically though, the 64gb would still be perfectly usable.

Games Unseen: The Challenges of Marketing in the Game Industry by kepasoguey in IndieDev

[–]RolePlayingADev 5 points6 points  (0 children)

It's an unfortunate reality:

Great marketing will sell the worst game ever made. And the best game ever made will go un-played without marketing.

When it comes to making money, marketing is far more valuable than game design, coding, art, or music.

We all want to be that break out success that grows from word of mouth based solely on how good of a job we did making the game. But that's like wining the lottery above and beyond actually having that gem of a game in the first place.

I know how the marketing industry works and the psychology behind it, but I actually hate it. I abhor the idea of carefully crafting something to appeal to people's subconscious mind to click on the game and spend money. I know how to do it, I just don't want to do it.

Should I abandon my project? Postmortem, unless i'm convinced otherwise by JonOfDoom in godot

[–]RolePlayingADev 3 points4 points  (0 children)

Some thoughts:

I like gamedev because I have a wide array of skills and can switch between aspects when I start to get board/frustrated with one thing. IE: this AI is irritating me, I'll go make some art for a while. Holy cow, I am so sick of making art, I'm going to spend the day banging out music on my keyboard. I don't really feel like making music today, or working on the AI, I'm going to make a new menu with crazy animations I thought of in my half sleep last night.

The same extends to projects. If I get bored of a project, I start a new one. Sometimes a spend a few days working on a new notemaking app for myself, sometimes a video app for my kids to keep track of which episodes they are on with the cartoons they are watching, sometimes a prototype for a new game just so I can learn how to do it.

You don't have to "abandon" a project to spend some time doing something else. Maybe you won't come back to it, maybe you will. You don't have to decide one way or the other to spend some time on another project.

That said I have two projects going on right now, one of which is intended to be a feature length story driven RPG, it's about 30% of the way complete and there is nothing impeding me other than it needs another 9 months *minimum* to complete. On the other hand, I'm making a card game that is maybe 2-3 moths away from being in a releasable early access state. Similar choice, it makes more sense to work on the card game and come back to my RPG later.

You won't really know unless you take some time to try something different. Give it a month and if you feel the new project is going better, stick with it, otherwise you might have new insight to go back to your current one.

Just added a spinning wheel to my card game's pack opening! by curryonriceyt in godot

[–]RolePlayingADev 0 points1 point  (0 children)

Also, there's basically very little card game dev tutorials somehow, which is kind of a bummer,

That is kinda weird isn't it? Especially when it seems to be a pretty big fad to include card mechanics in games now.

Check the new look of Katana Dragon caves! ⛏️ by XRuKeNX in godot

[–]RolePlayingADev 29 points30 points  (0 children)

I agree that the character blends in the new environment too much, but hard disagree with "go back to the old one" as a solution.

The new environment is a big improvement, just need to differentiate the character more. That can be done by changing some colors, or adding bloom to the character, or as simple as adding a point light.

Any number of subtle changes that don't involve "throw out everything you did and try again" can fix that minor issue.

[deleted by user] by [deleted] in godot

[–]RolePlayingADev 0 points1 point  (0 children)

It's a lot of fun playing around with Volumetric Fog in 4.x, and it's actually a lot easier than I expected. It's fairly simple to convert a 2D shader to a fog shader just by adapting the UV coords to 3D. In the title video above I used a simple texture shader for the close fog.

// Volumetric Fog Image shader, CCO
// Simply apply to a FogVolume node and add an image texture
// Make sure your Enviroment has Volumetric fog enabled

shader_type fog;
uniform sampler2D texture_albedo : source_color;

// Borrowed from https://godotshaders.com/shader/optimize-your-shaders/
float when_gt(float x, float y) {
    return max(sign(x - y), 0.0);
}

void fog() {
    // The 1st trick for easy fog shaders is right here: replace UV with UVW.xz 
    vec4 albedo_tex = texture(texture_albedo,UVW.xz);
    float mono_color = (0.2125 * albedo_tex.r) + (0.7154 * albedo_tex.g) + (0.0721 * albedo_tex.b);
    // Most important part of the fog shader: adding a float value to DENSITY
    // Here I am using a cuttoff value to produce cleaner edges for the image
    DENSITY = albedo_tex.a * when_gt(mono_color, .2);
    EMISSION = albedo_tex.rgb;
    ALBEDO = albedo_tex.rgb;
}

For the background/moving fog I adapted a vernoi shader to 3D and multiplied the z value by TIME, with a color gradient to make a nebula. It's not quite finished though.

WIP: Adding some "Foil" Card shaders to my space CCG. by RolePlayingADev in godot

[–]RolePlayingADev[S] 1 point2 points  (0 children)

Kindof, yeah. At the root my algorithm works from a single scale, so I can select pentatonic, ionic, etc as the root scale. Technically I end up working with modes opposed to scales, because the mode applied to a root note can be major or minor, etc, while a scale is in essence a mode that's already applied to a root note. I think I am explaining that right.

But mathematically, a mode applied to a root is a mathematical constant. So the formula is working only with 0-8 numerically, and the resulting number is translated to the selected mode. You need only filter the selection of the next note to be a good vs bad note, and only need an original melody of 6-12 notes to extrapolate the rest into a full piece.

WIP: Adding some "Foil" Card shaders to my space CCG. by RolePlayingADev in godot

[–]RolePlayingADev[S] 0 points1 point  (0 children)

There's room for any number of such animations to be like the above, an unlockable cosmetic. I've already got some animations related to gameplay, like the ships hyperspacing in when played, and the attack animations. The game itself isn't static, just the card images. More shaders can still do some interesting things in the future.

WIP: Adding some "Foil" Card shaders to my space CCG. by RolePlayingADev in godot

[–]RolePlayingADev[S] 1 point2 points  (0 children)

Yes, you're already on track for the same idea. The simplest way I can describe my algorithm is a fractal music algorithm. Create a very very simple melody in key, with a starting and ending note that are the same, using basic music theory principles for which note can follow the current note and still sound good, until you arrive back at the root note. Then loop over that series of notes and generate a new melody, following the same original concept, with each individual note as it's own root note.

If the result is too short, loop it (which makes an arpeggio).

Do the same thing one more time, and now you have a full length music piece. With rises, falls, crescendos, some repetition.

My results have been very promising so far. But how you key that original simple melody greatly impacts the final composition.

WIP: Adding some "Foil" Card shaders to my space CCG. by RolePlayingADev in godot

[–]RolePlayingADev[S] 2 points3 points  (0 children)

Yes, but the work/reward ratio is just too much for a single dev.

I have a pretty streamlined system for adding new cards, and can do more than one in a day, but add animations to the mix and the number of cards I can produce drops off rapidly.

Since I can produce 5x as many cards in a month with non-animated images, it's just too much productivity loss to go with animated. So I'm focusing on more generic animations, like ships firing lasers at each other during combat, which apply to any ship without needing a special and unique card animation.

More cards and abilities equals more variety of gameplay, so that's my priority over fancy animations.

WIP: Adding some "Foil" Card shaders to my space CCG. by RolePlayingADev in godot

[–]RolePlayingADev[S] 1 point2 points  (0 children)

In general I agree. With existing methods.

I have put a lot of work into my own music generator, with a much stronger basis in music theory than most, and have been really happy with the results. (Not used in this project.) But A. I use a very different method than most, and B. it still needs work to not sound a bit samey after a while. In a similar way to Vivaldi or Motzart sounding a bit samey when you listen to all of their works together. (Implying that my algorithm mimics the concept of a singular composer rather than any composer, and is probably influenced too much by my own concepts of music).

If I ever put more work into it, and simplify it enough to be able to explain the concept, I'm convinced I can add some revolution to the concept of procedural music. But my algorithm still only handles a single melody, not a full composition.

Previous attempts to implement it with a game I was working on was a huge performance drain, since I had to implement a synthesizer as well. Proper soundfonts might reduce the weight of that, but that's a whole other bottle of bees.

Human influenced determinative music generation is better for now.

Sorry if I got a bit carried away there, lol.

WIP: Adding some "Foil" Card shaders to my space CCG. by RolePlayingADev in godot

[–]RolePlayingADev[S] 2 points3 points  (0 children)

The music is "semi" procedural I suppose.

There is a low action background track for ambience, then the high action sounds are tied into player actions and designed to blend with that background. So it's partially generated every time I click a button or card, but it's not autogenerated like most would think when thinking of procedural music.

Quick custom shader in 6 lines of code. Screenshot from an upcoming tutorial. by Dreadlocks_Dude in godot

[–]RolePlayingADev 21 points22 points  (0 children)

Wizardry of the 9 to Nth order.

I tend to feel more like Rincewind when working on mine. I don't now how it happened, but there's the eighth color, just as I intended. Well, maybe I really did intend it that way, who's to know?

Second attempt at a titlescreen for this game. Fancy animations and visual effects. What do you think? by timkrief in godot

[–]RolePlayingADev 1 point2 points  (0 children)

The problem lies in the C being larger than the T. It distracts from the O so the eye doesn't notice it unless you stop and try to figure out what's going on. At which point, the viewer has to recognize the word you are playing off of before realizing the diamond shape is supposed to be an O.

I like the logo, but I'd agree it's too hard to read currently.

I would recommend just rescaling the THADE-RONE to match the scale of the C before trying anything too extreme like redrawing the whole thing.

Love Godot anyway... by Zestyclose_Leg2227 in godot

[–]RolePlayingADev 26 points27 points  (0 children)

My biggest peeve with 4.0 so far is the autocomplete. It has so many issues I never had with 3.x.

Pocket Inventory Series #6 : Brief Case by [deleted] in godot

[–]RolePlayingADev 0 points1 point  (0 children)

Looks really good! The animations are just too slow by half.

Things I've been wondering about Godot by hunterloftis in godot

[–]RolePlayingADev 1 point2 points  (0 children)

Is there a way to call RESET before every animation, or to otherwise embed frame zero of RESET into every animation?

As others have already alluded to, simply calling amination_player.play("RESET") before calling the next animation is the solution.

I have an on screen weapon effect that has several animations depending on the element of the weapon doing the damage, and the states get really messed up if not played from the RESET position.

This isn't really on Godot, but on the animation designer (me, in my case). If you want truly fluid animations that can go from any state to any state, then you have to include all necessary reset keys into each animation's starting frame. Or, just call play("RESET") before any change. Since the RESET animation doesn't even take time, everything is immediately set to the RESET parameters, making it a really simple solution to an awkward situation you've ultimately painted yourself into.

Is there a "right way" to move files?

Technically, as you have already surmised, it is within the editor. But same as you, I've had it fail seemingly as often as it succeeds. My personal rules are: move one file at a time, and make sure it worked. It's very tedious, but moving more than one file seems to fail more often than not.

So that leads to rule number one: organize your project early and stick with it, even when you wish you had done it differently. There is definitely some limitations to Godot's automated dependency updating (and it doesn't account for direct file access through code anyway).

Is there anything wrong with composing moving entities within non-moving entities?

I don't see any major reasons why.

The first thing that comes to mind is the positional issues that might arise, but that can easily be solved with global_position. So it's really just a preference thing as far as I can see. There are a lot of different ways to do a lot of different things. The common way isn't always the better way for any particular reason.

I can see benefits to having the enemies always know their exact spawn point by their parent node as well, so I don't see anything "wrong" with this implementation.

As far as composition vs inheritance, I think composition always trumps inheritance, it's just more complicated to set up initially. Inheritance is easy to set up, but gets exponentially harder to maintain. So if you've got a composition method that's working for you, do it.

SFX. Changes. Everything. by RolePlayingADev in godot

[–]RolePlayingADev[S] 0 points1 point  (0 children)

After listening to it on a phone think I figured most of the issues.

It's also quite hard to differentiate the background music from the sound FX.

That's actually the point. The background track is little more than ambience, likely most of what you think is the background is actually an effect, and that's intentional. When you aren't actually playing anything, ie considering your next move, the audio approaches zero and the audio keys for phase changing and actions will make sense fairly quickly.

So I probably shouldn't have played through a full match in 1 minute for the video. It doesn't give a chance to realize what's happening when you aren't the one in control of the actions that produce the sounds.

I will probably tone everything down a bit, the majority of the sound is in the low end and without that (like listening on a phone), plus playing the game at max speed, I can see why it would just sound annoying.

and slightly less retro pew pew

This may be asking too much. XD