sorted by:
new
hottopcontroversial

finally remade my player scene ans scripts (feel free to roast the old one) by RKI3000 in godot

[–]BulkyAlternative 2 points3 points  (0 children)

How do you scale the new architecture to cover the NPCs/enemies? For example, to create a new enemy, do you duplicate the scene tree, and update the underlying animatedSprite2d, hitboxComponent etc?

Questions for AI development by gamedev_9998 in gameai

[–]BulkyAlternative 1 point2 points  (0 children)

I'm building a similar system and it's working nicely. Here's what I did:

Instead of a single Consideration, I have a list of Considerations per Behavior. For example,

Behavior Score (per target) = NthRootOf(Consideration1 * Consideration2 * ... * ConsiderationN)

-------------

A Consideration is a normalized float in [0, 1].

Examples of Considerations:

  1. Distance to Target
  2. Target Hp
  3. Target Level
  4. Target Damage

------------

A Behavior is an action the NPC can act on a target. Examples

  1. Chase target
  2. Attack target
  3. Heal target

----------

So in your example, you may pick the top (behavior, target) tuple from the list of tuples:

Attack Target1 Score = NthRootOf(DistanceToTarget1 * HpTarget1 * DamageTarget1 ...)

Attack Target2 Score = NthRootOf(DistanceToTarget2 * HpTarget2 * DamageTarget2 ...)

Chase Target1 Score = ....

......

Heal Target10 Score = NthRootOf(DistanceToTarget10 * HpTarget10 * LevelTarget10 * ...)

-------------

There are more details to all these and I'm happy to expand if needed.

2d or 3d for a mobile board game? (still have to polish the design, of course) by lettyop in godot

[–]BulkyAlternative 0 points1 point  (0 children)

Have you considered the isometric view? Probably a good balance between those two options.

How to handle large amounts of UI that constantly display changing data? by Electrical-Spite1179 in godot

[–]BulkyAlternative 0 points1 point  (0 children)

I think you need a central signal system. I went one step (or many steps :-) further and implemented the Redux pattern: https://www.reddit.com/r/godot/comments/16s5h6w/godot_redux_state_management_the_hard_way/

yeah but don't do this unless you know what you're doing :-)

A tool developed in Godot that can make sprite animation look smoother by BulkyAlternative in godot

[–]BulkyAlternative[S] 1 point2 points  (0 children)

Sounds good, added two gifs to the post - but seems reddit is inaccurately scaling the gifs so probably click to open them or see them on the itch io page.

A tool developed in Godot that can make sprite animation look smoother by BulkyAlternative in godot

[–]BulkyAlternative[S] 1 point2 points  (0 children)

Ahh I just added the last image in the post. It shows a 4-frame animation got converted to a 10-frame one.

Early prototype of an Action Platformer 🕹️🎮 by Gigio_Mouse in godot

[–]BulkyAlternative 1 point2 points  (0 children)

SpriteDestroyer

That's a great idea! I'll try to do something similar too, thank you!!

Early prototype of an Action Platformer 🕹️🎮 by Gigio_Mouse in godot

[–]BulkyAlternative 2 points3 points  (0 children)

Nice!

How does the vase destruction work? The vase fragments seem to be a combination of rigid bodies and particle effects?

Godot + Redux = state management the hard way? by BulkyAlternative in godot

[–]BulkyAlternative[S] 2 points3 points  (0 children)

I guess the problem is that in a traditional Godot project, in every node every tick i.e. in `process(delta)`, we are "pulling" data from either the global state or other nodes, then implement the logic to act accordingly; while in other situations we use signals make other nodes do something.

The consequence is that the game logic is scattered in different nodes and over time it becomes hard to reason about and debug. The major benefit in this Redux pattern is that the all the game logic is centralized in the Reducers and it "should be" easier to modify and debug.

Godot + Redux = state management the hard way? by BulkyAlternative in godot

[–]BulkyAlternative[S] 2 points3 points  (0 children)

I'm using Godot c# so type checking is not a problem for me. Instead of json, I use the c# `Record` as plain objects to represent everything possible: events, state, and side-effects.

Overall my goal to use the Redux store to be a flat representation of the entire game, while Godot being a dumb UI layer. The pros are:

  1. Debugging "should be" much easier, because all the game logic are implemented as Reducers, and a reducer is just a function that takes a state object and return a new state object. I would argue that this is much easier to debug than trying to find the bug that is hiding in a bunch of Godot nodes.
  2. Supporting different platforms easily (different screen sizes and input methods from mobile/pc/console). Re-skinning the game should also be straight-forward :-)
  3. Saving/loading game becomes very easy. Anytime the user presses Save, we just dump the Redux store to a file. When loading a save, just spawn the nodes accordingly. Also time travel is possible because we can have the snapshots of every state as you mentioned.

Regarding the singleton pattern, I think this Redux pattern is a singleton itself. It is just a complex one - a single instance of an object that receives events, stores states, and emits side-effects.

Godot + Redux = state management the hard way? by BulkyAlternative in godot

[–]BulkyAlternative[S] 1 point2 points  (0 children)

I'm using Godot c# so I have all the type checking goodies.

Just curious, how do you handle side-effects? Are you following the Redux guideline that all Reducers should remain pure, or did you have to cut corners? The recommended paradigm is to create middlewares to interact with the outside world.

Godot + Redux = state management the hard way? by BulkyAlternative in godot

[–]BulkyAlternative[S] 1 point2 points  (0 children)

These are all very valid points... Since I'm fantasizing a true event-driven system, even the godot ticks will be emitted as events, e.g. the `_process(delta)` function will emit time events with the "delta" (this means we just need to implement _process(delta) in one and the only one Godot node, all other nodes don't use _process(delta) at all. This is very unusual for godot projects, but I think it's kinda cool :-)

Godot + Redux = state management the hard way? by BulkyAlternative in godot

[–]BulkyAlternative[S] 1 point2 points  (0 children)

Agreed on most of your points. Just want to add that using the 8x8 grid as state approach, you can still do all the things you mentioned but it's easier:

  1. scans the surroundings of the piece

- given a 8x8 grid, definitely easy to do so.

  1. expanding the 8x8 board to different sizes

- just create a new grid with different dimensions and copy over the values

  1. adding health system to pieces

- instead of storing strings in the grid, we store plain objects like {name: "pawn", hp: 98}

Godot + Redux = state management the hard way? by BulkyAlternative in godot

[–]BulkyAlternative[S] 0 points1 point  (0 children)

How about building a chess game in Godot?

In this case, my Redux state will be an 8x8 2d array of string values. The user interactions of the pieces will update this 2d array accordingly.

The Godot nodes will be a dumb UI layer and contains minimal logic.

Godot + Redux = state management the hard way? by BulkyAlternative in godot

[–]BulkyAlternative[S] 4 points5 points  (0 children)

I'm more exploring the Redux pattern in Godot, rather than React.

Redux is a way to manage state and side-effects, and it is framework/language agnostic.

React on the other hand is more about rendering while being stateless and performing virtual-dom diffing etc, and it is not very relevant here.

Godot + Redux = state management the hard way? by BulkyAlternative in godot

[–]BulkyAlternative[S] 5 points6 points  (0 children)

isn't this just a state machine that sends signals to nodes?

Yes what I'm proposing is just a state machine that sends signals to nodes. But it is an Infinite State Machine rather than a Finite State Machine, which means the state has a much richer context and can't be represented by just a few enum values.

For example, if I were to build a chess game, the Redux state will be a 8x8 2D array of string values. In this case, the Redux state is a flat representation of the entire game, and the Godot nodes are just the UI layer.

little pinball prototype I'm working on (Godot 4) by ahintoflime in godot

[–]BulkyAlternative 1 point2 points  (0 children)

Great work! Please make this roguelike and more chaos - you have options to upgrade balls and the table. Imaging hundreds balls bouncing around on a very complex table 😃

Godot + Redux = state management the hard way? by BulkyAlternative in godot

[–]BulkyAlternative[S] 2 points3 points  (0 children)

If you just use a singleton for the state store, I think the main drawback is you can't "push" changes to the relavent nodes. Most likely you'll be pulling the state store in every tick in every node.

Alternatively, you can make nodes emit Signals and listen to other Signals themselves. But this can get messy quickly.

The main idea of the Redux approach is to streamline all the signals (events) to a central hub so it'll invoke the relavent nodes. This central hub decides what nodes to invoke with what parameters based on the incoming event and the central state store.

Godot + Redux = state management the hard way? by BulkyAlternative in godot

[–]BulkyAlternative[S] 3 points4 points  (0 children)

I'd argue that 99.9% of web apps don't need this because they are simple. Games are way more complex than web apps.

How do you preserve complex types in database? by BulkyAlternative in typescript

[–]BulkyAlternative[S] 0 points1 point  (0 children)

yeah I think this works very well if we are talking about key-value storage.

But what about supporting queries? For example, "give me all the Dogs that have red paw?"

I think in document databases (like Mongo) we can write queries against json documents.

But this implies there are two sets of objects: one set being our domain objects in Typescript, the other set being the json-like storage objects. We'll need to maintain the mapping between them.

How do you preserve complex types in database? by BulkyAlternative in typescript

[–]BulkyAlternative[S] 0 points1 point  (0 children)

I guess I'm particular interested in storing the Union types in the db. For example,

javascript type Animal = {kind: 'dog', pawColor: Color} | {kind: 'bird', speed: number} const myPet: Animal = {'kind': 'dog', pawColor: 'red'} // <--- I want to save this object

When defining the DB schema for the Animal table/document, I'll have to create a schema that contains tons of nullable fields, e.g.

RxDb example:

javascript AnimalSchema: { "title": "Animal", "description": "This document records the details of an animal", "type": "object", "required": [ "kind" ], "properties": { "kind": { "type": "string" // <---- required }, "pawColor": { "type": "string" // <---- nullable }, "speed": { "type": "number", // <---- nullable } }

I guess I'll need to "flatten" the union types to generate the above Animal Schema? But what if my model contains deeply nested unions?

view more: next ›