gdquest-demos / godot-make-pro-2d-games

A-RPG demo made with Godot, MIT-licensed, from our Godot course
MIT License
995 stars 108 forks source link

How can we improve the code and project structure? #65

Open NathanLovato opened 6 years ago

NathanLovato commented 6 years ago

The demo and the course try to show some good practices with Godot, and a range of game programming techniques: _stateful objects (e.g. the porcupine or the sword), Finite State Machine, using initialize/setup methods after the _ready callback, etc._

I did a lot of research over the past year, asked fellow developers for insights... but it's by no means perfect. I'd love to get your detailed feedback on a range of aspects:

  1. How to simplify parts of code while keeping it scalable
  2. How to code more reusable scripts and nodes, e.g. for the States on the boss and the player
  3. Improving the folder and file structure (see LikeLaker's example for inspiration)

And more! This is an open discussion. The goal is to produce more efficient and scalable code in the future, to record more precise tutorials, and to build lovely open source demos. But for that I need constructive feedback.

For now on Godot 3.0, as Godot 3.1 is still in alpha. I'm aware that some 3.1 features would help simplify the project a lot, but that'll have to wait for future demos.

Ranoller commented 5 years ago

Godot 3.1 breaks part of your code. First, you can´t access directly to a enum constant without name the parent. So you need to do : STATES.IDLE in the place of IDLE (an example). Other thing: You can not declare a bunch of preloads inside a const. You need to use a diccionary and "load". There are many other things, Godot 3.1 will be very disruptive with code written in 3.0, but code dynamically written in 3.1 should work in 3.0..... I´m trying to fix some of the issues, but is very difficult to me to follow your project, because, since "godot good way of things" is separate scripts, scenes, etc... in different folders, in real world i can´t follow a project structured in this way. Scenes folder, script folders, etc... say what Juan say´s about project organization, for a single developer, is the way to follow.

Ranoller commented 5 years ago

Example: You have this code in ShopSubMenu.gd:

func initialize(shop, buyer, items): var purse = buyer.get_purse() info_panel.initialize(purse)

Parser says: ParserError: Function signature doesn´t match the parent. Parent signature is: Variant initialize(Variant=default)...

But I´cant find a "initialize" call in this script, so this is called by other script. And is difficult to follow the code in this way.

NathanLovato commented 5 years ago

The project is only for Godot 3.0 for now, that's normal. I'm not looking to port it to 3.1 for now.

Regarding initialize, as the name implies, this method is here so another node can initialize this one. That's not about Godot, that's object oriented code in general. In a very basic game you can work with simpler code, but as your projects grow this won't be enough.

Agreed there's room for improvement with the folder structure. It's a hard one as there's no one good structure that'll fit all projects. I would move all assets to a collective /assets/ folder and reorganize the other folders by broad systems... not sure what'd work best though at this point.

Ranoller commented 5 years ago

i feel that scenes, resources, etc... can be in different folders, but for not reason, i can't work in a project with splitted scripts folders... i need all the code in a single place, and my project is not tiny, and i know others like me so i feel better :) :)

NathanLovato commented 5 years ago

You can organize your projects in different ways. We group files per system, trying to follow object oriented design. The goal is for the folder structure to represent the software's architecture. This one would need some work but that's the idea. On the RPG it's working well so far: https://github.com/GDquest/godot-turn-based-rpg/ It's probably better structured than this one though