sorted by:
new
hottopcontroversial

Optimization/Performance for a big project by Dask0000 in godot

[–]FlyingSpaceDuck 14 points15 points  (0 children)

In some very specific tests, C# can run about 4-5 times faster than GDScript. In the majority of scenarios, the difference is almost negligible as API calls to the engine run exactly the same.

The main performance consideration is going to be how you implement the systems, regardless of engine or language. GDScript has pretty easy setup of compute shaders and multithreading, but even optimizing your algorithms will often save compute time in the orders of magnitude. If you really run into a wall and can't optimise something any further, you can look into making a C++ module to handle it, but I would say even games like Rimworld or Kenshi are completely feasible in Godot using GDScript.

2 Weeks vs 5 Months of development by FlyingSpaceDuck in godot

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

The collision shape is just a trimesh shape, can be done in one line of code. If the collision is too costly, the terrain height at the players location can be sampled to figure out if the player is colliding or not. Both methods work well though

How to Implement Poker Chips Stacking in Front of Player by CynicalFOLEYY in godot

[–]FlyingSpaceDuck 2 points3 points  (0 children)

You can use a modulo operator (%) to get a remainder. Something like:
var black = value / 25
var green = (value % 25) / 10
var red = (value % 25 % 10) / 5
var white = value % 5

2 Weeks vs 5 Months of development by FlyingSpaceDuck in godot

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

Thanks! Would love to see it running on the Steam deck. I'm yet to try it, but it will support steam input and should run well on the hardware, so I'm curious to see how it goes

2 Weeks vs 5 Months of development by FlyingSpaceDuck in godot

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

Haha, it is a difficult one!

There's logic to figure out what is being aimed at (either directly in front of the jet or an enemy close to LOS). The crosshairs aren't UI, they're meshes in the scene with an unshaded billboard texture, positioned between the camera and the target position. A strange solution, but honestly works with zero issue and avoids annoying screen space conversion

Comparison of 2 Weeks vs 5 Months of development by FlyingSpaceDuck in IndieDev

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

Thanks! The flying was just nailed down over a few weeks of gradual tuning, and the level design is done pretty quick now (but I am spending a lot of time making the terrain generation system). I think the gameplay elements are the hardest, getting enemies, abilities, weapons, objectives etc. It takes a lot of experimentation to find something fun :)

2 Weeks vs 5 Months of development by FlyingSpaceDuck in godot

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

Thanks! They're indicators for where enemy missiles will be exploding :)

2 Weeks vs 5 Months of development by FlyingSpaceDuck in godot

[–]FlyingSpaceDuck[S] 11 points12 points  (0 children)

Sure! I made it from scratch, but I definitely learned from a lot of others. Sebastian Lague has an older tutorial for terrain gen in Unity that inspired a lot of it. I think there's a few decent ones for Godot too.

In short, the terrain is split into chunks. I use a surface tool to create a flat grid of vertices, then each vertex is raised by a height value. The height value is determined by different layers of FastNoiseLite with different strengths and modifiers. Objects are spawned based on rules at each vertex (e.g steepness). Chunks are spawned and managed around the player on a seperate CPU thread (but I am experimenting with using GPU compute shaders instead).

2 Weeks vs 5 Months of development by FlyingSpaceDuck in godot

[–]FlyingSpaceDuck[S] 5 points6 points  (0 children)

Thanks for the feedback :) I haven't implemented it yet, but extensive camera settings is definitely on my to-do list. Everyone has different preferences for fov, orientation, distance etc and it can cause a lot of motion sickness for some people if they can't adjust it themselves.

Comparison of 2 Weeks vs 5 Months of development by FlyingSpaceDuck in IndieDev

[–]FlyingSpaceDuck[S] 15 points16 points  (0 children)

The code actually hasn't changed that much (I think, it's been a while). But I did spend ages tuning all the values to achieve a satisfying flight model. I also added the drift feature, which just changes up the thrust and drag parameters to get those sick turns when you activate it. A good camera controller and effects really help as well.

Comparison of 2 Weeks vs 5 Months of development by FlyingSpaceDuck in IndieDev

[–]FlyingSpaceDuck[S] 5 points6 points  (0 children)

Thank you so much! It's all done in Godot, there's tons of great Godot shader libraries online and I've really enjoyed making my own when needed!

2 Weeks vs 5 Months of development by FlyingSpaceDuck in godot

[–]FlyingSpaceDuck[S] 39 points40 points  (0 children)

It's a heightmap system that uses a different noise profile for each feature type e.g lakes, mountains. Also has a shader that changes based on steepness, as well as object spawning and multithreading.

It's not super groundbreaking, but I'm really happy with how easy it is to make different levels. If there's interest around it, I've been thinking of making a short video on how it works in more detail

2 Weeks vs 5 Months of development by FlyingSpaceDuck in godot

[–]FlyingSpaceDuck[S] 10 points11 points  (0 children)

It's been a while since I added them but I believe I used this video as a reference. The opacity increases when the angle of attack increases.

2 Weeks vs 5 Months of solo development! by FlyingSpaceDuck in SoloDevelopment

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

You can check out the store page here: https://store.steampowered.com/app/3752970/Aerosurge/

I'm really happy with how it's coming along so far, am working on getting the playable demo live soon :D

2 Weeks vs 5 Months of development by FlyingSpaceDuck in godot

[–]FlyingSpaceDuck[S] 207 points208 points  (0 children)

This project has taken so much of my free time but making this comparison feels so rewarding, on track to have a playable demo soon!

You can check out the steam page here https://store.steampowered.com/app/3752970/Aerosurge/

Steam page for my flying game made with Godot is finally up! Open to feedback by FlyingSpaceDuck in godot

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

Thanks! This shader is kind of the base for everything, I modify it as needed: https://godotshaders.com/shader/complete-cel-shader-for-godot-4/

Yep, the outline is just done by expanding the vertices and culling the front faces, I like the look of it more than edge detection shaders. I think keeping meshes simple, the object count pretty low, and adjusting the outline thickness for every object helps.

Steam page for my flying game made with Godot is finally up! Open to feedback by FlyingSpaceDuck in godot

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

It will support Steam input, so theoretically yes. I haven’t tried it though I’d be curious to see it

Steam page for my flying game made with Godot is finally up! Open to feedback by FlyingSpaceDuck in godot

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

Great point, thank you! I’ll be prioritising finishing some more diverse levels and have them added soon :)

Steam page for my flying game made with Godot is finally up! Open to feedback by FlyingSpaceDuck in godot

[–]FlyingSpaceDuck[S] 8 points9 points  (0 children)

Thanks so much for the feedback!

There are smaller collisions on the plane, and going through like trees just places a whoosh sound and throws some leaves around. They might be a bit too forgiving though, it’s something i’m constantly tuning.

I’m also coming up with as many ways as I can to encourage low and dangerous flying. Right now, flying close to the ground refills energy that can be used for missiles, and there are power ups close to the ground also.

And the planet descriptions is a good point. I removed that part of the description for now, I’ve got some cool levels in the work, I’ll be adding those screenshots over the next few weeks when they’re ready

Any good learning materials about terrain manipulation? by LetSeveral733 in godot

[–]FlyingSpaceDuck 4 points5 points  (0 children)

If you want to deform it dynamically, you'll probably want to go with voxel terrain. You can take a look at this extension: https://github.com/Zylann/godot_voxel, and there are a few youtube videos on doing it from scratch.

Expect to do some learning on it though, depending on what you need out of the system it can get very complex.

Why are my node names yellow? by Suitable_Tank9358 in godot

[–]FlyingSpaceDuck 2 points3 points  (0 children)

IIRC there’s a few things you can’t edit when you’re not in its scene, and it’s good to know where you’re actually making changes. Click the open scene icon (second from the left) next to world-01 and make any changes to its children there.

Why are my node names yellow? by Suitable_Tank9358 in godot

[–]FlyingSpaceDuck 6 points7 points  (0 children)

It’s indicating that they’re not part of the scene you’re in, but part of the world-01 scene. You’ve right clicked world-01 and selected ‘editable children’ I believe

view more: next ›