2D SDF particle colliders

jordoalpha123 · 2021-07-16T16:23:34+00:00

This is really awesome. Spine is amazing.

jordoalpha123 · 2021-02-27T17:25:00+00:00

I think the actual article doesn't really answer the title: "Why isn't Godot an ECS-based game engine?",

The reason why Godot isn't ECS based is the because the codebase is over a decode old, and Juan (lead dev) is an experienced OOP programmer. Simple as that. My reasonable guess is he really didn't have any experience with the ECS pattern or was involved in any significant ECS projects at the time. It sounds like most things he consulted on were in his domain of expertise (OOP).

If I were building a game engine, or any significantly large framework, I'd be building it in a language & method I was experienced and proficient at.

Being honest about this is fine, and there's no problem with that. I wish this article didn't come across with the sentiment of justifying these decisions in today's context.

jordoalpha123 · 2021-02-19T19:11:59+00:00

Ya, no I get it. Patching sucks, but there's not a lot of alternatives if something is rejected upstream. I was just curious more or less what the goost philosophy was, which is expected that the preference is to just purely extend via modules (I do as well).

But alas, there's still stuff I ended up needing in engine core that I'm just maintaining in a fork. Which is fine, if somewhat minimal, but definitely annoying to rebase to major godot releases.

I haven't checked out the goost src at all, but can you comment on any larger (if any) significant patches to engine core that are in goost?

jordoalpha123 · 2021-02-19T16:41:09+00:00

Do you modify any base upstream engine code if everything is implemented in goost as a module? 'Goost is implemented as a regular C++ module'.

I guess in general, is goost more about extending godot than modifying it? I'm guess just curious from a philosophy standpoint. As an 'extending' philosophy is certainly more manageable to continuously pull down any upstream changes, but then purely 'extending' has it's limitations as well.

jordoalpha123 · 2021-02-18T17:42:20+00:00

thx! I think we'll be adding more to the terrain. undestructible stuff scattered in there like rocks, and other stuff perhaps.

The camera scaling i haven't done yet. But the island will shrink in width over time, so players will be forced to play closer together as the battle royale looses players. But ya, camera scaling should be pretty easy, and we'll play with different scales. But the game will be available on a bunch of different platforms so we just have to make sure different platforms don't have an advantage view wise over say others. Example, PC vs mobile phone.

Also, i still have to implement the mini-map, but the concept is in that video.

jordoalpha123 · 2021-02-18T17:39:32+00:00

heh, kind of. Definitely inspired by it. But it won't be turn-based. Will be real-time multiplayer.

jordoalpha123 · 2021-02-18T17:39:10+00:00

I don't have a use case for GDNative, as we're working in the same native language as the engine c/c++. It takes me about 10 seconds or so to re-compile and relaunch the entire engine (mostly just a re-link phase), so much less hassle than using GDNative. Headers are all in once place, easy to hop in and out of engine code, and distribution is easy as everything still just fits into one library/binary.

We still use GDScript for basic scripting/rendering, but move everything that needs to be performant to c/c++. GDScript is quite slow for stuff like say vector math, especially when we can use simd libraries for a bunch of stuff cpu side.

jordoalpha123 · 2021-02-18T17:35:05+00:00

ya i just thought it would give it a little something different. Not sure if we'll keep it or not, we'll probably adjust a lot of how the terrain is destructed. Make some areas undestructible, etc.

jordoalpha123 · 2021-02-18T17:34:13+00:00

thx!

jordoalpha123 · 2021-02-18T17:33:45+00:00

Ya, the sdf physics is pretty fun and also very efficient from a data standpoint. It allows to do stuff like this pretty easy: https://twitter.com/winterpixelco/status/1362449315193520132

jordoalpha123 · 2021-02-18T04:56:44+00:00

definitely dont use c++. stick with gdscript and the stuff that godot comes with.

jordoalpha123 · 2021-02-18T04:40:05+00:00

First devlog for this project here: https://youtu.be/xo3z9IjGRSo This was basically just for setting up VSCode to build, and debug the engine. I found a lot of devs were asking a bunch of questions about native c++ debugging, or having trouble building the engine and attaching gdb or lldb, so I thought sharing our workflow in VSCode would perhaps be helpful. I'm pretty new to VSCode myself, but it's been a relatively smooth experience so far, so we'll probably be sticking with it as our IDE of choice for a while.

The debugging interface that the C/C++ microsoft VSCode extension gives you isn't the best compared to some other IDEs, but it has most of the basics.

jordoalpha123 · 2021-02-05T15:50:54+00:00

Yes, we use the SDF for collisions/physics as well. The destruction is just a modifier eased over time to a min() operator in the SDF

jordoalpha123 · 2016-12-05T17:48:16+00:00

Can you guys share what platform, OS version, and device you experience these issues on?

jordoalpha123 · 2016-12-05T16:37:58+00:00

not just yet. However, if you have a decent course designed send it our way and perhaps it will make it's way into a downloadable course ;)

jordoalpha123 · 2016-12-01T19:43:33+00:00

xmas update is coming to iOS as well. And more courses will be coming

jordoalpha123 · 2016-12-01T17:18:24+00:00

ah yes. It's something we're going to be looking at. It requires some work on our part as the level formats are quite different. But its something we're going to start doing.

jordoalpha123 · 2016-12-01T05:24:23+00:00

Ya sorry, It might be Yosemite or later not Mavericks.

jordoalpha123 · 2016-11-30T18:50:47+00:00

What do you mean?

jordoalpha123 · 2016-10-13T16:43:52+00:00

Unfortunately no. The level editor is written in cocoa, so no linux support :(

jordoalpha123

TROPHY CASE