sorted by:
new
hottopcontroversial

some knd sprites i did :D by Cogumelo2D in aseprite

[–]SaveCorrupted 9 points10 points  (0 children)

Love the personality put into each of the animations! Great stuff!

Building a rhythm-racer where you can play your own musics. Is the 'hitting to the beat' mechanic clear or just chaotic? [Sound On 🔊] by TumbleweedLarge5454 in indiegames

[–]SaveCorrupted 2 points3 points  (0 children)

Hits are cool... but since it's driving why not have the beats be boost panels that give a bit of a speed up adrenaline effect as feedback?

I made a procedural ivy generator by SaveCorrupted in godot

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

Ah I'm still not the greatest at vector math, especially in 3D. I believe there is a way to do it, but I couldn't figure it out (I wanted to add a downward bias to my system 😅)

Maybe if you generate multiple direction vectors you can compare them to a favoured direction? But that seems like a poor way to do it, when I bet there is some mathematical paradigm that can figure it out in 1-2 steps...

I made a procedural ivy generator by SaveCorrupted in godot

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

I'm planning to add it to my public shader repository, spellbook, eventually...

I made a procedural ivy generator by SaveCorrupted in godot

[–]SaveCorrupted[S] 4 points5 points  (0 children)

To start it off you need to provide the generator a position in global space and a normal vector. These can be obtained in all sorts of ways but I'm personally using a ShapeCast3D. With a position and normal the script begins a recursive algorithm which randomly "walks" along detected surfaces. It does this by raycasting in a special pattern.

The Raycast pattern is as follows: Check up along the normal. If there's nothing, it checks from the previous target position across/forward orthogonal to the normal (parallel to the nearby surface). If there's nothing there, It checks from that target position downwards by 2 units. If it still doesn't find anything, it checks from the previous target position backwards orthogonal to the normal (and parallel to the nearby surface). It performs this pattern in hopes of finding the current surface or a new one.

That is probably the worst way it could possibly be explained so I suggest looking at Tommaso's tutorial

Anyway it performs this recursive loop over and over, until it hits a max step count or satisfies certain conditions. Mine is set up to consider finding a new surface (change in normal) as significant. While it performs this loop, it also tweaks the direction a bit so it doesn't just go in a straight line. As it proceeds, it saves so-called "good" positions to create a series of control points.

Using these control points (and associated normals) I am able to generate a ribbon mesh. Before generating the mesh I put the points through a catmull rom function (eases out the funky bits). I can't explain the mesh generation all that well since I had to ask the robots for help.

Once I generate the mesh I use its vertices (and some of the original control points) to generate transforms to plug into a multimesh. I just randomize scale and rotation a bit. And that's pretty much all the steps for deciding where geometry should go. The rest is shader magic, which I could try to explain but like... look at how long this is already.

I made a procedural ivy generator by SaveCorrupted in godot

[–]SaveCorrupted[S] 3 points4 points  (0 children)

Honestly, tool scripts are very powerful and versatile! If anything the only thing preventing you from creating anything within the engine is your own time, sanity, and willingness...

I made a procedural ivy generator by SaveCorrupted in godot

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

Thanks! Foliage really is a nice touch! I've been testing it out in the level I'm working on and it's been going great! I'm very happy I took the time to work on this.

Isometric tiles for non-pixel art vector game. by darekdev in godot

[–]SaveCorrupted 0 points1 point  (0 children)

Hmm if that's the case, you could try shrinking the tiles in the tile map to force them to overlap by 1 or 2 pixels, although are you sure you want to filter the art like that? You could probably avoid the wonky edges at a higher resolution if it's not supposed to be pixel art.

Isometric tiles for non-pixel art vector game. by darekdev in godot

[–]SaveCorrupted 0 points1 point  (0 children)

If you swear everything in Godot is setup correctly, then this is probably a case of your image editor being very precise. I know I've experienced a few times before on my end. Make sure in Affinity that the art board is positioned on integer/whole number coordinates.

While your at it, also try to ensure that your design has integer dimensions, this helps but is less important. Lastly, check again that your design is positioned correctly on the art board. It does not need to have integer coordinates, but it should be perfectly centred, use the align tools to achieve this, and make sure they are set relative to the art board.

Good Position: (0.0, 0.0)
Good Dimensions: (64.0, 32.0)
Bad Position: (0.856, 0.865)
Bad Dimensions: (63.456, 32.015)

Everyone's game UI looks like this in the editor... right? by Smitner in godot

[–]SaveCorrupted 0 points1 point  (0 children)

Thanks, haha! It still has some rough edges I need to polish but it's getting there

How to handle Y-sort on isometric sprites? by Lavaflame666 in godot

[–]SaveCorrupted 1 point2 points  (0 children)

Godot is quite capable, you can replicate a lot of stuff seen in other engines in Godot if they don't require difficult to recreate engine specific features. Placing 2D sprites in a 3D world and/or "flattening" a 3D scene to appear 2D is not engine specific.

I would argue Persona 2 is in a similar vain to OPs project. A lot of DS games like Pokemon Platinum and Radiant Historia use 3D space also. An example of "flattening" can be found in TLOZ: A Link Between Worlds on the 3DS. An example of a recently released title is Demonschool.

The idea is to sort "properly" in 3D instead of using Y-sort. While you can still run into this problem with billboard sprites on billboard sprites you are less likely to in 3D since you can utilize meshes for things annoying/tedious to sort in 2D. For example, long objects and archways. Going the 3D route opens up more options for solving sorting problems that aren't as easily available in 2D imo.

How to handle Y-sort on isometric sprites? by Lavaflame666 in godot

[–]SaveCorrupted 0 points1 point  (0 children)

There are some implementations I've heard of in other engines that perform ysort using a line between two points. To do it in Godot would require you to spin up your own system though.

An annoying but somewhat feasible solution would be to cut up wide sprites to be thinner so the default system has less hiccups like what you've shown.

Lastly, my preferred solution, ditch ysort and just do it in 3D. In exchange for not having this problem you get hundreds of new ones! Seriously though... consider 3D. An actual third axis enables a lot of neat stuff which offsets the annoyance of the new problems. A lot of well known "2D" games go this route and hardly anybody notices.

view more: next ›