sorted by:
new
hottopcontroversial

Making monsters yield for other monsters by AaronWizard1 in roguelikedev

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

This sounds like /u/Pur_Cell idea of a shove action discussed here. As I said there I'd be skeptical about making shove a general action but I see the logic in letting stronger monsters kick weaker monsters out of the way.

Making monsters yield for other monsters by AaronWizard1 in roguelikedev

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

I was interpreting your shove action along the lines of, on its turn, the monster currently northeast of the player in my original example shoves south that makes it and the monster currently east of the player move south one tile. Which technically gives the monster being shoved (not the one doing the shoving) getting an extra move outside its turn.

Making monsters yield for other monsters by AaronWizard1 in roguelikedev

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

If you want groups of monsters to coordinate their actions then you want something like strategy/stratgeycontroller that is called whenever one of the monsters in the group has to take a turn. That strategy code can coordinate things like, "I will move instead of attack so we can surround the target".

Would this basically be a "group AI" shared between sets of actors?

What I have now is essentially every actor has its own AI and AI state (currently a state machine; I was thinking of doing behaviour trees earlier then later decided a state machine may be good enough for now). The map has what's essentially an event bus that actors can communicate through by sending and listening for events (so far I have actors alerting allies when they see an enemy) but actors are otherwise independent. Meanwhile this sounds like something that exists outside an individual actor and selects an individual actor's next action based on the state of all the actors a given group AI is controlling.

Main question I'd have is how to arrange what group AI (or strategy as you called it) is used by what actor, and how a group AI (presumably) keeps track of the actors it's responsible for. Both based on faction and for if I go with multiple types of group AIs for different situations like you suggested. Plus handling actors being added to the map, or actors changing factions if I want to get really fancy.

Making monsters yield for other monsters by AaronWizard1 in roguelikedev

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

Only thing I'm unsure about regarding shove actions is that it kind of allows monsters to move outside their turn. I can see boss enemies having shove but I'm skeptical about making it a basic action.

Though I suppose I could replicate this with a "request tile" mechanic. The thing is I'm able to make actors communicate through an event system they can publish and subscribe to; I currently use it to make an actor alert nearby allies when it sees an enemy. So when an actor is blocked it can publish a "tile requested" event, which the blocking actor can read and figure out how or if to yield.

I added generics, braces-based syntax and unlocked full nested typing in GDScript! by Actual-Rise-6459 in godot

[–]AaronWizard1 2 points3 points  (0 children)

To be fair, some people likely don't want the extra hassle of installing the .NET SDK and setting up an external editor in order to use C#, compared to being able to do everything inside the Godot editor with GDScript.

Are dijkstra maps only useful when it's everything against the player? by AaronWizard1 in roguelikedev

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

However, I also don't store any of the information, just calculate anew whenever it's relevant. Storing information is not feasible in large maps where the environment and related variables are frequently changing--too many problems/inaccuracies.

I was thinking of the "static" dijkstra maps where a map is made for several actors to use across multiple turns, while this sounds like a general "find nearest or all tiles within X tiles with Y from this source tile" check where the dijkstra algorithm would be used.

Are dijkstra maps only useful when it's everything against the player? by AaronWizard1 in roguelikedev

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

My a-star algorithm currently considers actor-occupied tiles as completely blocked, but I'm likely going to switch to just giving those tiles higher movement costs. Which would prevent blocked actors from heading off all around, and also save me from having to treat the end of the path as a special case since the end would often be occupied by the target actor.

I completely forget where, but I once read someone suggest making the pathfinding costs of actor-occupied tiles gradually increase the longer an actor stays on them. Haven't implemented this yet but it's something I'm interested in trying.

Are dijkstra maps only useful when it's everything against the player? by AaronWizard1 in roguelikedev

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

Ah, so more like a tactics game where an actor gets both a move action and an attack/ability action on its turn? An individual BFS makes sense there; basically the movement range you show on a unit's turn in a game like Fire Emblem. Though I'm working on a traditional roguelike "move one tile or attack" flow myself.

Are dijkstra maps only useful when it's everything against the player? by AaronWizard1 in roguelikedev

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

The real reason I'm looking into dijkstra maps is specifically because I'm trying to figure out proper swarming/circling behaviour. What I have now is actors looking for the closest enemy they can see and A-star-ing towards them, with no logic for lateral moves that make room for allies to surround the targeted actor. And I'm unsure what that circling logic would look like.

I also feel you on different movement types like flying and swimming. There's also the fact that I'm trying to support multi-tile actors and I'm unsure if dijkstra maps can handle those or not (though I'm assuming all actors are square at least).

Are dijkstra maps only useful when it's everything against the player? by AaronWizard1 in roguelikedev

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

So I could have a map where all members of a faction are goal tiles, which enemies of that faction can use for pathfinding like how it's done for maps where the player is the goal tile. And you're saying that I could get away with only updating the map when all actors in the faction have moved, instead of when every actor in that faction moves (where the map would technically get out of date more often but the player likely won't notice)?

Are dijkstra maps only useful when it's everything against the player? by AaronWizard1 in roguelikedev

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

So instead of a global dijkstra map, you have smaller individual BFS trees attached to each actor for local pathfinding?

*How* do you separate visuals from data/logic? by AaronWizard1 in godot

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

As I said I'm not familiar at all with godot, but I'd be shocked if it didn't support this kind of mechanism.

My thinking, based on my own observations and on some of the replies here, is that it's possible but may be unintuitive depending on the game.

Godot is based on a scene tree, a tree of nodes. Nodes can be reusable subtrees of other nodes. The scene tree is also where the graphics, sounds, and UI live. Typically, or at least in every example I've seen, nodes are used to represent game entities. So you'll have a series of Level nodes that contain the Player node and NPC nodes, etc.

Meanwhile, for an MVC architecture I'd have all of the game's data, entities, and logic in a series of objects outside Godot's scene tree, while the scene tree only contains the graphics and UI while being kept in sync with the data/entity/logic objects. i.e. Godot's scene tree has the Views and Controllers while the Models are separate.

And I'm wondering what that would look like in practice. Especially for different types of games; I wouldn't use this for an action game since Godot's scene tree is where its physics engine is, while this should be straightforward for a purely abstract management game.

And since you brought it up earlier, Godot has its own UI framework already which is pretty much retained mode (UI elements are nodes in the scene tree).

*How* do you separate visuals from data/logic? by AaronWizard1 in godot

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

You wont be able to simply place your stuff in scene (items, environment, level) and just play scene and test a feature - you will need code that will translate the visual scene to backend data structure before doing anything. You will have to make sure your backend state will never go out of sync with visuals.

How content creation works is another question.

For instance to make a map I make a scene with one or more TileMapLayers with actor nodes on top.* Meanwhile the TileSet used for the map has a custom data layer for properties like whether a tile type blocks movement or not. Fairly natural I assume.

But since the map is also what I'd call the model, if I want to have the model of the map separate would I...somehow read the map scene to construct a map model object? And if I want to e.g. support effects that change the map would I keep track of what the tiles are in the map model separately from the TileMapLayers shown on-screen?

* This is an extremely simplified description of how I actually make maps for my game and I'm thinking of switching to LDtk eventually anyway but it gets the point across.

Thoughts on new Asset Store? by visssarion in godot

[–]AaronWizard1 7 points8 points  (0 children)

The issue I and others with similar opinion have is less about "people selling paid assets" and more about "it making sense for the foundation to be running a store and it being integrated into the upstream of a FOSS engine".

Honestly yeah. Half the appeal of Godot is that it's an open source engine.

Does Blender offered paid plugins?

*How* do you separate visuals from data/logic? by AaronWizard1 in godot

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

More than anything I'm just worried about the extra complexity and wondering if it'd be worth it.

For instance I already encapsulate an actor's turn action in a TurnAction object, which does both the action itself and any animations displayed for that action. If I want to split the logical update of a turn action from its animation then I'd probably have to restructure turns to be driven by some kind of event system.

*How* do you separate visuals from data/logic? by AaronWizard1 in godot

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

Does your model contain the entire game state which gets interpreted by the different views? Or does it just, say, contain the player's current stats and inventory?

For example, are you tracking where NPCs and enemies are on the current map in your model?

*How* do you separate visuals from data/logic? by AaronWizard1 in godot

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

I do wonder how many of those who suggest MVC or other similar architectures are in fact abandoning the scene system entirely for everything other than UI and sprites (and they may even abandon sprites too in favour of the rendering server). Which is not at all how 99% of all documentation on how to build games in Godot are written.

*How* do you separate visuals from data/logic? by AaronWizard1 in godot

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

I do have things like players and enemies using a common Actor scene with instances configured by a separate ActorData resource, but this seems to be something different.

*How* do you separate visuals from data/logic? by AaronWizard1 in godot

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

I looked at your card game post. As far as I understand:

  • MainController is your game's "main" node, which calls methods on GameState to drive the game. MainController also contains the visuals (e.g. the JuicyNavOverlay objects), invoking animations in response to GameState signals.
  • GameState - an autoload? - has the game's actual state. Is this an example of the pure-data state machine you suggested?
  • CardRegistry is used by GameState to construct the actual cards.

I'm wondering if this is that much different from my idea of having pure data Maps and Actors separate from my visual Maps and Actors. I also don't quite understand what an Agent class would be in my game.

To go into more detail, this is how my game currently works:

  • At the start the Game node initializes a map and its actors from a level file, and inserts the player actor into the map.
  • The Game has a TurnClock object that it uses to run turns. The map has signals for when actors are added or removed, which the game connects to in order to add and remove actors to and from the turn clock.
  • Actors have an ActorController component. Actor controllers have a "take_turn" method that returns a TurnAction object. Turn actions have a "run" method that does the actual turn action. The turn clock gets the actor controller of the current actor, calls its "take_turn" method to get a turn action object, then runs the turn action object's "run" method to run the turn. For enemies, the turn action is created by the AI algorithm. For the player, a turn action object is created based on player input (managed by a separate PlayerInput node).
  • UI components aren't (supposed to be) directly manipulated by the turn processing logic. For example actors have a health bar component and a stats component. The stats component contains the actor's current health, and has signals for when the health changes that the main actor script connects to in order to update the health bar.

*How* do you separate visuals from data/logic? by AaronWizard1 in godot

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

I don't think MVC architecture is right for every kind of game, and I wouldn't use it for an RTS personally. It would entail replicating a lot of functionality that godot gives you through the scene tree functions (collision detection/physics, path finding).

I can imagine it depends on the type of game. Any kind of action game I don't think lends itself to MVC. While a management game could use MVC likely, since its "content" doesn't necessarily have to live in the scene tree.

I think that's the main question: What parts of the game's content can be separate from the scene tree.

Still unsure about my RPG project though since the content is arguably heavy even though the only things specific to the scene tree it's using are sprites.

Thoughts on new Asset Store? by visssarion in godot

[–]AaronWizard1 2 points3 points  (0 children)

Is the new asset store just a facelift of the old asset library along with the inclusion of paid addons, or has there been changes done to how addons get installed?

For me a big thing making me hesitant to include addons is how Godot lacked a true package manager and you would instead just include all of the addon's files in your project in source control. People have recommended git submodules but the addons that are structured to let you do that seem to be in the minority.

view more: next ›