OpenRPG rewrite: Godot 4.X about godot-open-rpg HOT 14 CLOSED

No problem about long posts! Long discussions require details.

Before answering, I'll first posit some assumptions (@NathanLovato correct me if you disagree). These aren't direct answers to your suggestions; they're more general guidelines that I'll use to discuss the project.

In general, I very much like your proposal. I have a few comments/ things to discuss.

Main serves as the point of entry to the program [...]

That's completely fine. Keep in mind though that you want to maximize the possibility of running single independent scenes with F6, for easier testing or demonstration. There are three major architectures that lead to that:

1. Making sure the scenes never, or rarely, depend on Main, and run as quasi-complete even if it isn't there
2. Making Main an autoload
3. Explicitly and verbosily require dependencies in each scene (scene loads Main, or composes it from smaller nodes)

My personal preference is towards 3, but the community, or docs, seem to favour 2, so that is what I would recommend.

I'm imagining that - down the road - Main will be a finite state machine

I'm not sure of what you mean by state machine here. If you mean a set of distinct and easily identifiable states that cannot overlap, yes, completely.
But if you mean a specific generic "State Machine" implementation, then I'd probably warn against adding indirection and complexity to something that can remain very simple in my mind. But we can cross that bridge when we get to it.

Session [would] store party info, inventory, the player scene during combat/area map transitions, etc.

Sure, that seems good. Maybe consider using a resource instead.

The Field gamestate [...]

All good

I had originally been thinking that there would be a Player node dedicated to tracking the player. [...] Please see below for an alternative.

This is a valid idea, and the composition based setup is also valid.
I suggest to start with your initial proposition, as it is simpler, and switch to composition if we notice the simple implementation is blocking.

Sorry for not answering before, I've had a busy day.

Regarding signals: we connect them in code. In general, we want everything to be as explicit as possible.

Feel free to comment back on anything you disagree with or find unclear.

Good work!

from godot-open-rpg.

It all sounds good. Regarding the state machine part, it's good too, just seeing the screenshots, I would recommend avoiding one node per state in this project for things like the Main node/script.

Having taught people to make state machines like that I know that it looks simpler, but for simple code like what Main will likely become, you tend to end up with more boilerplate than code actually doing something useful, and you fragment code, which are big tradeoffs for just seeing the node names in the scene dock.

I don't know if you intended to make state machines with one node and one script per state, but just in case I prefer to mention I think it'd add unnecessary complexity to the Main scene at least.

@Xananax while people tend to use autoload, I prefer to stick to Main being a plain old scene and nothing depending on it. It's not complicated in my experience and it makes the project easier to explore than using an autoload as this scene will automatically open when importing the project.

from godot-open-rpg.

Thanks for the feedback, this is great. Exactly what I'm looking for.

I've been plodding along slowly, trying to unlearn some "solo dev" habits and reworking initial attempts to require less dependencies. I'm impressed at how difficult it is to write simple code, I hope this will not be too far off the mark.

It's hard to setup a small MVP as there are so many moving parts. There are many elements from the TRPG course here and I've changed the architecture some (as expected, including removing the state machines and other boilerplate code). The biggest notable change (and this is something that will require feedback) is that I have tried to pull apart the program data into several resources. For example, in the TRPG course the gameboard has methods dealing with many different pieces of data (paths, terrain, characters, etc.). In the FTL-like in 2D secrets, Rooms seem to place the occupants and handle interactions there. In the old OpenRPG project each pawn would request movement from the gameboard which would then call methods on the pawns. Etc.

I'm not sure that I have reduced cross dependencies, but I've tried to isolate them more. I have a pathfinder class that deals with terrain and which cells are walkable/empty/occupied. A gamepiece "directory" performs all lookups you could ever want on the pawns/gamepieces (by cell, uid for use in events or finding the player, etc.). The grid class handles conversions between units and placing things on the grid. These are RefCounted objects created on the fly (the exception is the grid which is a resource) so that there is only a single copy of the databases. They're still passed around quite a bit but hopefully all of the connections are explicit and prevent coupling different systems. For example, the cursor can do it's thing completely independent of the gameboard.

Please note that Kenney's stuff is placeholder (it's so good!).

I have to work in character movement, at which point I will then clean up what I have, do a write up of the current architecture and then put through the initial PR. I'm hoping to have something to show off at the end of the week, but life is busy so we'll see.

Thanks again.

from godot-open-rpg.

Thank you for this!

I think your proposal of an initial project is good. Let's start on that basis, and let's be willing to iterate on it until we feel it's a satisfying architecture, after which we can move on to the next system (combat, inventory, ...).

I don't think an architectural diagram is necessary, unless you want it. For me, directly intervening on code without abstractions is generally preferrable
(Of course, this implies sometimes tearing the code down and rebuilding to a large degree. I'm personally fine with that).

However, an architectural diagram can serve as a thinking tool for some people. If that is how you proceed and you'd rather have feedback on that first, that is completely fine by me.

At the moment, I do not have specific opinions about all the points you've made; they all seem good to me! Some reserves about "not componentizing", but it really depends on the implementation.

So then, I suggest the next step is to open a WIP PR and work there. If you want to discuss things before implementation, feel free to follow up in this issue, open new issues, or comment in the PR.

from godot-open-rpg.

I apologize for this long post. If there is a better way to run design by the folks at GDQuest, please let me know. For the first prototype I wanted to verify design with the team to make sure that I'm not completely out to lunch.

I agree that iterating over code/structure will be more productive than trying to "structure" everything from the beginning. I DO find laying things out helps at first and I may be able to head off some issues (or raise red flags when you question what in the world I was thinking) by blocking them out within Godot and then iterating on top of that.

This is the rough structure I've laid out for the "first steps" prototype. Please note that I've added the player controller in two scenes to get feedback on which method would be preferable. I'm open to changing anything and I like the idea of componentizing as much as possible.

This may be more complex than it needs to be at first, so I'll try to explain what I was thinking with each scene:

Main serves as the point of entry to the program. Main would have a few utility objects (Session - explained below, audio elements that should only have one track running at a time such as music and ambience, a screen overlay - which I forgot to picture here - for fading the screen, etc). Each game state would have an initialize method where it could be fed references to these systems so, for example, the combat state can quickly transition to combat music.

I'm imagining that - down the road - Main will be a finite state machine (probably pushdown so that we can just pop the combat state, re-activate everything in the field/explore state, run a post-combat event and let the player keep going) so I've set it up as such. If that's more complicated than necessary we could rejig it to just route events to the active game state.

Within Main, Session probably needs explanation. My thinking is that we'll want a place to cache a) player data and b) world data. Regarding player data, we would want a place to store party info, inventory (if it were ever implemented), the player scene during combat/area map transitions, etc.

The Field gamestate is where the player runs around a grid/map purchasing gear, talking to NPCs, etc. The terrain layer is background terrain and what is currently labelled "TileMap" would have grid-based obstacles (trees, houses, maybe cliffs, etc.). The obstacle grid would by y-sorted as well as all of its children. It seemed more clear to add the gamepieces to a node dedicated to parenting them, but they could be children of the obstacle tile map just as easily.

I had originally been thinking that there would be a Player node dedicated to tracking the player. I had been thinking of calling a "set_focus" method that could follow any given gamepiece and the player node would handle setting up a controller, disabling ai, following with the camera, etc. My reason for doing so was that I did not think you would want to control two different characters at a time, as that seems confusing. Please see below for an alternative.

Edit: Down the road the map itself would be dynamically loaded from one of several. The player would be injected to the map when it is loaded.

A Gamepiece scene is a base scene for any given object that will occupy a space on the gameboard. I had been planning a limit of one gamepiece per gameboard cell. I had been thinking that characters, interactive elements such as treasure chests and signs, events, and such would all be gamepieces. The Path2D and PathFollow2D can be used to easily path along the grid. Hopefully the graphics nodes are pretty self explanatory, but I was thinking that Sprite and its children would handle any height-based movement (such as jumping). Finally, I've roughed in that controller components could be attached to any gamepiece to control them. Please note that the Controller node + children would not exist in the gamepiece base scene but would probably be added dynamically.

Edit: Forgot to mention that the gamepiece GFX/Animation would be a swappable component. It's laid out here to show the full structure.

Anyways, I would love to hear any feedback you may have and, hopefully, I'll have this up and running by the weekend.

Thanks for taking the time to read.

Edit: I couldn't seem to find this in the GDScript style guide. Is there a preference for connections being made in editor or in _ready via code?

from godot-open-rpg.

Just a quick question as I wrap up the initial PR in the next few days, what would you like included for assets? Do you want something from a previous version of the demo (might be tricky, I was hoping to have an animated character to demonstrate changing directions)? Does all GDQuest art need to be unique, or are appropriate CC0 assets good enough for the first iteration?

Thanks.

from godot-open-rpg.

Feel free to work in any way that you feel is sensible and allows you to move without being blocked.

CC0 assets are fine! We can figure out what to change later.

from godot-open-rpg.

Sorry for the confusion with that pull request. Do you want the full commit history including 3.0 versions of the project? Or should the 4.0 rewrite restart the commit history? I can't imagine wanting to bounce between the two.

Once I've got that setup properly I'll put a pull request through for review and we can maybe chat about the demo.

Thanks.

from godot-open-rpg.

It's fine to have a clean history for this work.
We'll either keep the previous one in its own branch, or move your PR to its own repository. It's something to be decided later, for the moment it's fine to keep working in your repo and ping us through PRs/Issues.

We're travelling for the next two days, so there'll be no time for review, but I'll give you feedback around the beginning of next week.

Thank you!

from godot-open-rpg.

Ok, sounds good. I'll keep communicating through this issue for the moment.

I'm not sure if it's because I don't know what I'm doing, but Github isn't interested in setting up a PR for either branch on the OpenJRPG repository since I've restarted from commit 0 - as they are "are entirely different commit histories".

I had a write-up done on the initial PR that may explain the general architecture of the project. It appeared to have pinged several old contributors so it seemed best to restart the commit history since the two are so incompatible.

For now, the demo can be grabbed from the following repository. I'll hold off until I've heard back from someone on the team to verify that I'm headed in the right direction with the project. Movement works great except the characters' animation components don't seem to be set correctly on mobile exports.

Thanks and safe travels!

from godot-open-rpg.

Ok, I fixed the disappearing-characters-on-mobile-export issue. I'm not entirely sure what was going on as the animation component is set as an exported packed scene and the setter wasn't even being called. Works nicely on Android now, even on my slow Kindle Fire.

@Xananax, I was thinking about how involved this first milestone is and how it might be more to review than is possible given everyone's time constraints. I wondered if you would like me to break it apart component-by-component and slowly tack it together so that we could look at things piece-by-piece? If you would like I can strip it back to a simpler starting point.

from godot-open-rpg.

No, thank you, but it's okay. I prefer to go over a coherent whole; the only thing is that I might have to ask you to wait, depending on when you're available.

Is it ready for review now? Can I review it in the next few days?

from godot-open-rpg.

No, thank you, but it's okay. I prefer to go over a coherent whole; the only thing is that I might have to ask you to wait, depending on when you're available.

I'm happy to wait; I'm not in a rush at all and will work at your schedule. I just wanted to make sure that I couldn't make your life (well, the review anyways) easier.

I think it's a good idea to do the review now, as it will give me an idea on the state of the code and if I need to make any big architectural/code style shifts before getting too far into the project. Please see the (closed) PR for a brief description of the architecture. Until we have a 4.0 branch/repository it probably makes sense to just pull the code from the following repository.

I've tried to stick as close as possible to more recent GDQuest tutorials. I've also attempted to make the architecture more clear (who does what, things only have one main purpose, names make sense). Also, exports should work though I haven't tested IOS or web.

Please let me know if you have any questions or want more clarification on something. Thanks again for your time.

from godot-open-rpg.

For posterity's sake, I setup a review-ready PR to be merged to the feature/code-rewrite branch (they don't share code, obviously). It also includes a few minor updates (consolidating debug tools, facing target characters after following a path, some decoupling/robustifizing the cursor).

from godot-open-rpg.