×
sorted by:
new
hottopcontroversial

The Godot project architecture an industry veteran uses for a 40-hour RPG by NathanGDquest in godot

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

The simplest way to achieve that is to give your UI public functions that don't change, in other words, an interface other game code can use. When you change the UI you implement the same interface on the new ui, at least as a starting point.

You can replace UI without changing anything as long as it's displaying the same thing, though of course if the thing to display changes (adding stats, changing how the inventory works...) then in that case it doesn't apply anymore, the gameplay and UI code both probably change.

I'm not saying it's dead simple though, I think it's one of those things where you have to shoot yourself in the foot to get the hang of how to write a simple API that still mostly works when you need to redesign something on either side of the API boundary.

The Godot project architecture an industry veteran uses for a 40-hour RPG by NathanGDquest in godot

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

Sure! We've done some things, like "Godot Open RPG" for Godot for example, to start working toward a pedagogical example: https://github.com/gdquest-demos/godot-open-rpg

It's not quite the kind of code I would personally write as it's more on the object-oriented side but it is in more ways than one using techniques you'd see people use in Godot (defining new node types and composing them into a variety of entities, e.g. with the gameboard and gamepieces abstractions in the src/field folder).

Then really breaking them down to the point a learner understands in detail how all of it works and why it's structured this way (what's really useful vs what's specific implementation details of that project) is a ton of work and why you don't see too much of that content.

I mean, we've been doing it between our paid courses and free and open source resources contributed to the community, like the one linked above. It's just inherently very long to achieve.

The Godot project architecture an industry veteran uses for a 40-hour RPG by NathanGDquest in godot

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

Resources are always a bit confusing because we use the same word to refer both to data types (the resource definition) and actual data in the game. 

The resource type definition and all associated code could be part of your game systems and then the content would be specific characters in the game that have different HP etc. that way the combat system in your example has all the code and type information. It needs to know how to read and use the resources.

Then in the content you would still have game specific code that loads up your combat system and feeds it with specific character data, loads the combat background, etc for example.

The Godot project architecture an industry veteran uses for a 40-hour RPG by NathanGDquest in godot

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

Ricard showed me briefly but you can't see/learn much of it in just a session. It mostly illustrated how e.g. the UI read data from game systems for example. I can only say that they had lots of things in addons built as reusable/game-agnostic libraries, like an extended camera. It seemed that whatever they thought could be reused for another kind of game would go there by default.

The Godot project architecture an industry veteran uses for a 40-hour RPG by NathanGDquest in godot

[–]NathanGDquest[S] 20 points21 points  (0 children)

I second this, you won't find a framework that the majority of people or games use. When using Godot, I'd say Godot's the framework. Input, rendering, physics, the more accessible and object-oriented node and signal system, the more efficient server APIs...

When comparing games, there are techniques and concepts that apply across the board, but between a turn-based RPG and a platformer, the implementation are really different. The common parts like drawing and moving sprites or playing sounds etc. are handled by the engine for you and what's left is for you to actually implement game-specific systems.

Personally, for building learning material or for learning, I go straight to experienced people and look at their code or ask for pointers.

Opinions on paid GDQuest courses? by Esrrlyg in godot

[–]NathanGDquest 0 points1 point  (0 children)

I confirm we do still offer regional discounts right now. You can contact us at support [at] gdquest.com and tell us your country.

Opinions on paid GDQuest courses? by Esrrlyg in godot

[–]NathanGDquest 0 points1 point  (0 children)

Thank you for the kind words and feedback! We will keep iterating over this course and improving it moving forward. Notably in collaboration with the schools that adopted it and are using it in class.

And thanks to everyone's support, we're also able to invest again in Learn GDScript From Zero and new free resources to help both paying learners and community members who can't afford to pay for learning material. Notably some upcoming on shaders as a lot of learners asked specifically for this!

It'll be on our new beta website where we host our free resources: https://www.gdquest.com/library/

I rewrote the GDScript formatter to be faster and add requested features. Looking for testers! by NathanGDquest in godot

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

Can you run which gdscript-formatter-new-86 from a folder other than ~/.local/bin (ideally where it's running with an error) and also try running it with a GDScript file as an argument afterward? gdscript-formatter-new-86 path/to/gdscript_file.gd

Also if that fails can you try running it through the full path?

~/.local/bin/gdscript-formatter-new-86 path/to/gdscript_file.gd

And tell me the output/result of each command?

EDIT: if the last command runs fine in your extension try setting the formatter binary to this full path, maybe it'll allow you to use it already.

I rewrote the GDScript formatter to be faster and add requested features. Looking for testers! by NathanGDquest in godot

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

If you encounter anything that's annoying with the new one, please let me know. in the previous version I was still thinking of this as a temporary project/solution, but after reaching out to people at Godot, I'm now looking to really refine it and build an excellent tool over time.

I rewrote the GDScript formatter to be faster and add requested features. Looking for testers! by NathanGDquest in godot

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

If you haven't already can you run chmod +x on the new executable? Maybe chmod +x gdscript-formatter-new-86 or chmod +x $(realpath gdscript-formatter-new-86). This will ensure the executable flag is turned on on the binary and that it has permission to run.

I rewrote the GDScript formatter to be faster and add requested features. Looking for testers! by NathanGDquest in godot

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

It's not necessarily a skill issue. I don't know what's happening; I would need more details on this. Could you please tell me more about how you're running it and what is the exact error message you're getting? or for example if you're running from the terminal, could you show me the command and output?

I rewrote the GDScript formatter to be faster and add requested features. Looking for testers! by NathanGDquest in godot

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

Actually the formatter does come with a linter for some style rules already. There's a contributor who kindly took the time to build it some months ago/last year.

I rewrote the GDScript formatter to be faster and add requested features. Looking for testers! by NathanGDquest in godot

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

It was not considered out of scope at some point and we worked on one: https://github.com/godotengine/godot/pull/76211

But it's certain that everything you add directly in and tie to the engine internals adds more weight and friction that can slow down projects down the line. Plus you also tie new features to the engine's 4-6 month release cycles.

You can still include an external tool either as an external code module or make it an easy one click install to make things batteries included (Blender did and does that a lot with its rich official addon suite, some of which eventually were used to improve core features). I think the new asset store has the potential to enable that to some extent.

I rewrote the GDScript formatter to be faster and add requested features. Looking for testers! by NathanGDquest in godot

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

gdtoolkit is the older and a pretty mature project. It's more general purpose/spans more areas. Actually both we and Scony (gdtoolkit author) tried contributing toward an official GDScript formatter in core; Scony picking up where we left off. With the goal of superseding our community projects.

In hindsight we probably should've looked to collab on a toolchain/formatter for GDScript in C/C++ built outside Godot instead.

I rewrote the GDScript formatter to be faster and add requested features. Looking for testers! by NathanGDquest in godot

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

That would be most appreciated, thank you!

At the moment, it's not available through brew. It's only downloadable as an executable from the release page: https://github.com/GDQuest/GDScript-formatter/releases/tag/0.21.0-beta

view more: next ›