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

Godot

5873 readers
16 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

!roguelikedev@programming.dev

Credits

founded 1 year ago
MODERATORS
 

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.

top 4 comments
sorted by: hot top controversial new old
[–] Moldy@programming.dev 2 points 1 year ago* (last edited 1 year ago)

Since replying to my comment from kbin doesn't seem to work, I've signed up here to post a little update.

If your project has Use Physical Light Units enabled, lighting through GDScript and the RenderingServer isn't possible to do cleanly on stable builds. The enum used to set light intensity isn't bound, so you have use its integer value.

RenderingServer.light_set_param(light_RID, RenderingServer.LIGHT_PARAM_INTENSITY, 1500)

Becomes

RenderingServer.light_set_param(light_RID, 20, 1500)

[–] Moldy@kbin.social 1 points 1 year ago

It's not something that's immediately obvious, but Godot's scene system is pretty much entirely optional. You can bypass it and interact with the various servers that handle rendering, navigation, physics, and other core functionality directly. They actually recommend it for performance optimisation. You could also implement your simulation using that same server architecture if you wanted to: https://docs.godotengine.org/en/stable/contributing/development/core_and_modules/custom_godot_servers.html

[–] Biggles@sh.itjust.works 1 points 1 year ago

Pretty much every engine out there is built on strong opinions about “how game code should be structured” so while you almost always can bring your own opinions like this, you are likely to make life difficult for yourself…

It very much depends on what kind of game you’re making but I actually don’t think Godot is actually all that unsuitable for the sort of separation of concerns you’re going for, though you’re unlikely to find many tutorials geared towards that style of coding.

I say this as someone with similar instincts about how to structure my code, who spend 2-3 years working against the grain in UE4 to maintain a clear model/view separation in a 2D simultaneous-turn-based strategy game & am currently going down a similar route with Godot.

You can use plain Node & Resource derived classes for a lot of your model-side stuff & only use “things that automatically draw themselves” nodes as a layer on top of that if needs be… but yeah, it very much depends on what kind of game you’re making. For most traditional real-time games (as opposed to turn-based ones etc), especially anything 3D or where you want to use in-built physics stuff, I’d lean towards trying to work with the engine as much as possible, rather than being too fanatical about following a particular design pattern that isn’t fully encouraged by the engine… at least for your first game or two!

[–] Suppoze@beehaw.org 1 points 1 year ago

I think it is entirely possible in Godot. You don't have to extend any Godot specific class when you create new objects and scripts, just define a new class, and put your game logic there. Then, you can use an instance of that class in your rendering specific logic.

If you want, you can take a look at my pet project, a match three "game", I made it to learn Godot. I had the same concerns as you, so I tried to separate game logic and animation. What I did was to create separate queue for the animations based on game logic steps.

https://github.com/zsoki/godot-4-match-three/blob/master/Events/Game/game_event.gd

The code is not terribly optimized or readable, so sorry. But might give you some ideas.

load more comments
view more: next ›