this post was submitted on 17 Jun 2023
27 points (100.0% liked)

Godot

5915 readers
14 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

[email protected]

Credits

founded 1 year ago
MODERATORS
Ategon
snowe
Feyter
27
Godot looks great, but I want to separate game logic and display. (self.godot)
submitted 1 year ago* (last edited 1 year ago) by Buttons to c/godot
12 comments fedilink hide all child comments
 

I like most things I see about Godot, and I'm going to try making some games with it.

Whenever I imagine programming a game though, I imagine the game logic and simulation being separate from the display. For instance, if I was to make a game like FTL, I would plan to simulate all the ship interactions and the movement of the characters purely in code, and then write a separate module to render that simulation. The simulation could be rendered with graphics, or with text, or whatever (of course, a text render wouldn't be human friendly, but could act as a dedicated server for some games, or I could use it for machine learning, etc).

I'm not an expert at Godot, but it seems this mindset is not going to fit well into Godot. Is this correct? It seems like the same object that is responsible for tracking the players health is going to also be responsible for drawing that player on the screen and tracking their location on the screen, etc. Will my player class have to end up being a subclass of some complicated Godot class? (Also, I'm a fan of functional programming and don't always use a lot of classes if given the choice.)

What are your thoughts about this. Would you recommend another engine? No other engine seem to be in the same sweet spot that Godot is currently in.

you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 2 points 1 year ago (1 children)

It sounds like the thing you want is Functional Reactive Programming (FRP), where you have a state value that represents the current state, an update function which integrates an input and the current state, and a display function which just presents the state for the user. This is not Godot, but you may be able to search for an FRP game engine and find something more than a half-built weekend project from 8 years ago ๐Ÿ˜…

Godot is not a function-oriented environment at all, though the version of gdscript in Godot 4 does have first-class functions finally. Their entire model is very object-oriented, though. So your player will 100% be a subclass of a Godot class.

That having been said, more than many OOP projects Godot encourages object composition over multiclassing and mega objects. The "right" way to build a character in Godot is to have a health component that just holds health, takes damage, and heals. Then another which does damage to thing, etc. Then the player is a subclass of the physics body, and does have some glue code, but all of the concerns just get added to it and it becomes the sum of its parts. That allows the health component to be added to enemies and trees as well without rewriting it, etc.

[โ€“] Buttons 2 points 1 year ago

FRP is interesting. I could connect a FRP system to Godot's rendering server, as suggested in another comment.

Also, I think there is push-based and pull-based FRP. Pull-based would probably work better, the FRP updates would only calculate as new values are pulled out of the system by the surrounding Godot code.

Overall though, FRP seems like overkill (I'll still consider it), but its moving into building-an-engine territory rather than building-a-game.