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.

  • Moldy@programming.dev
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    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)