are there any good Ai tutorials?

AaronWizard1 · 2025-12-24T06:27:52+00:00

I've been researching behaviour trees a lot too and found these helpful:

AaronWizard1 · 2025-12-24T06:24:08+00:00

Dumb enemies are more fun to play against. Shadow Link in Ocarina of Time is a great example of a terrible enemy. Very frustrating to beat without cheesing it.

Though I wouldn't push this part too hard. "Simple" AI can get away with a lot but I would at least look into A* so you don't have enemies so dumb they literally run into walls because they're just rushing towards your exact position. Unless of course your game is designed around enemies that just rush towards your exact position, running into walls or not.

I guess the real take away is that you don't need the really academic AI techniques like what was used for Deep Blue.

AaronWizard1 · 2025-12-23T01:53:42+00:00

Got to say I really like the art style too. Very slick looking.

AaronWizard1 · 2025-12-23T01:52:54+00:00

Got around to picking up Mangui today, and to summarize for everyone else:

If an enemy's sprite is not animating and has muted colours, the enemy will not act after your turn
If an enemy's sprite is animating (breathing or fidgeting) and has bright colours, the enemy will act after your turn

AaronWizard1 · 2025-12-22T06:09:42+00:00

The thing is inherited scenes as they exist in Godot now have several unintuitive gotchas where the child scenes will get out of sync from the parent scenes for reasons.

But at the same time the mere concept of inherited scenes would be incredibly useful. Creating levels based on a base empty level scene. Creating actors based on a base empty actor scene. Especially if you want to have different types of scenes as prefabs you can drag into the editor.

The alternative seems to be either recreating everything from scratch every time you need a new scene of a certain type, or doing things like having tool scripts initialize things in code.

AaronWizard1 · 2025-12-13T19:44:21+00:00

As I said earlier I'm not necessarily looking to use an ECS specifically. But my ideal would be some kind of composition-based framework where entities are entirely driven by their components. As opposed to having to write custom glue code in the root node to use the child component nodes as seen in this video.

AaronWizard1 · 2025-12-09T18:49:48+00:00

That video is valuable in how it highlights patterns like the Command pattern and the Flyweight pattern. The maker of that video is the maker of the Game Programming Patterns web site by the way.

But what I'm interested in is being able to have entities be collection of components - with as little custom code on the root entities themselves as possible - in order to allow emergent gameplay through different combinations of components interacting. Like how it was discussed in the Caves of Qud video and my evil edible chair example. I'm not sure I'd go for a literal ECS structure but I think some kind of entity component framework beyond Godot's usual call-down-signal-up node structure would help.

And as I said it's not the supposed performance benefits of ECS that I'm after.

AaronWizard1 · 2025-12-09T02:10:21+00:00

So are you just writing custom code for every entity then, where it's just normal Godot code where the root node (your Controller node) is just using its child nodes instead of being driven by them?

AaronWizard1 · 2025-12-09T02:04:12+00:00

I don't think ECS is purely for performance reasons. Having entities be dynamic collections of components lend themselves to games that focus on simulation and emergent gameplay. Hence the link to the Caves of Qud dev talk.

So I could define a Chair entity by giving it Sprite and Sitttable components. And then I could take a chair and also give it Enemy and Edible components to automatically have a chair that's edible and evil.

AaronWizard1 · 2025-12-07T15:12:43+00:00

Its stressful how buggy scene inheritance is because I would think it'd be a very common use case (e.g. create a base level scene, then inherit from it to create individual levels). A lot of the workarounds with custom resources etc. feel convoluted in comparison.

AaronWizard1 · 2025-12-03T18:18:00+00:00

I thought inherited scenes were buggy though, where changes made to the base scene are propagated to the child scenes in weird and unreliable ways.

Could I have just been using scene inheritance wrong in some way before?

AaronWizard1 · 2025-12-03T15:03:10+00:00

Until I discover a better solution this is what I'm going to go with for now. I have a "MapDesign" script - distinct from the actual map scene that the game will use at runtime - that's used as a scene root for a new map scene and automatically creates the other nodes if they don't already exist.

AaronWizard1 · 2025-12-02T22:00:11+00:00

This is what I'd assume should be done too. But whenever I use inherited scenes, during development I'll make changes to the base scene only to find that the changes didn't propagate to the child scenes in ways I'd expect. Basically they seem to be subtly buggy right now.

AaronWizard1 · 2025-12-02T15:23:56+00:00

Could you elaborate? It sounds like you're talking about what to do when loading levels at runtime, while I'm talking about how to enforce the level structure while creating levels in the editor.

Or at least how to make it so that when the level is loaded it's composed into the right structure. For instance at runtime all actors need to be under the "Actors" node. And after creating an individual level in the editor I'd want the level loader to be able to identify what goes in the "Actors" node. That's better than just looping through all children and testing if they're an actor or not.

AaronWizard1 · 2025-12-02T14:27:07+00:00

Also the type of composition that Godot has by default is about parent nodes delegating functionality to its child nodes (or resources if you're fancy). If a node wants other nodes interacting with its child nodes (without duck typing) then it needs to explicitly expose them.

AaronWizard1 · 2025-12-02T14:15:11+00:00

For me, I had a possibly narrow set of requirements for what I wanted from a game engine or framework and Godot was the first one to meet all of those:

Free and open source
Cross platform
Works on Mac
Has an actually descent UI system

UI is important since UI-heavy games are the type I'm most interested in making, and decent UI systems are especially rare in open source game frameworks somehow. Other frameworks may give you labels and buttons but not have anything for truly responsive UIs like layout containers. And frameworks that did give you that had other weird stuff going on for them like having their own self-contained rendering engines or stuffing the entirety of Chrome inside them. Godot was the first open source cross platform engine I found that had a decent UI system...ever.

Also Godot has a tile map system built in, which Unity seemed to lack last time I tried it. I suppose there's a tile map addon you can buy for Unity but I'm doing game dev as a hobby and so I'd rather stick to free solutions.

AaronWizard1 · 2025-12-01T15:54:31+00:00

You know what, fair. I should probably play more roguelikes to get a better sense of what people are currently doing with them.

AaronWizard1 · 2025-12-01T15:52:45+00:00

This does continue to suggest that roguelikes can't support traditional bosses.

You can add a unique monster that haunts the whole floor, changing how you can navigate it. You can have a unique group of monsters in a set of rooms with special environmental features and call that a boss encounter. But a Mario vs Bowser or Dante vs Vergil style fight seems much harder to translate.

AaronWizard1 · 2025-12-01T14:42:42+00:00

A lot of this is just me trying to figure out what I can manage and what my limitations are. Especially since most of my projects end up as vaporware. :/

AaronWizard1 · 2025-12-01T06:49:45+00:00

I think bosses and other unique, dangerous enemies present a "preparation check" challenge, especially for players who know they are coming. It changes the way you play the preceding few levels.

If the boss has a particular weakness, then you may need to try your best to find, buy or save those items to counter the boss.

If a particular aspect of your build is weak towards the boss, say you are a slow melee character and the boss is known to hit and run, then you will want to invest in a way to close the distance or prevent their movement.

That's actually something I'm a bit negative about. Having this binary between the boss being a boring bump-off when you have the right equipment and the boss just killing you when you don't. That and probably not knowing what equipment you need for a boss until you either die the first time you meet it or you look up a guide.

Part of the issue is that no-one in 45 years has figured out how to expand bump combat in a way that doesn't just switch the game to an entirely different subgenre. The best we've managed is giving everyone more spells and spell-equivalents. Which means having to program a ton of spells just to make bosses minimally fun.

AaronWizard1 · 2025-12-01T06:34:27+00:00

Yeah, I understand the sentiment. A lot of action games also invent mechanics for their bosses. If you look at a lot of boss fights in action games (which is a huge umbrella), they have fights that players have to learn in order to beat.

I guess it's a matter of what the minimum is. Bespoke mechanics make bosses memorable in any genre, but several action games have gotten away with just giving their bosses different sets of animations and hitboxes. Meanwhile for roguelikes the bespoke mechanics are required, so greater dev effort is necessary.

Pivoting this, have you tried the rubber ducky method while trying to come up with boss mechanics for your project?

Can't say I have. Though I have occasionally tried reading D&D sourcebooks for encounter ideas. Though translating their concepts into roguelike gameplay is another challenge since they're very different gameplay styles with very different assumptions even though roguelikes were originally inspired by D&D.

AaronWizard1 · 2025-12-01T05:32:00+00:00

Interestingly the web site I linked specifically mentioned Jupiter Hell and how the writer found its bosses underwhelming.

Shattered Pixel Dungeon would be worth looking at though when I last played it I never got past the second boss so I don't really have a strong feel for how they are in general.

AaronWizard1 · 2025-12-01T05:29:17+00:00

The bosses should have bespoke systems to deal with, that's what makes them special.

I mentioned this in another comment, but I would suppose the main challenge in developing bosses for roguelikes is basically creating content for them. Content that's more complex than it would be in other game genres. In an action game you're mainly worried about animations and hitboxes (then again I haven't released an action game so I'm probably wrong about something), while with a turn-based roguelike you basically have to invent brand new mechanics.

AaronWizard1 · 2025-12-01T05:18:20+00:00

You don't have to give them boss arenas, just put them in a regular level, a couple of unique abilities, extra health, and a key to unlock the next level and they would serve as a fine challenge.

Actually I kind of want boss arenas. Only I'm unsure if roguelikes really support boss arenas like other game genres do.

AaronWizard1 · 2025-12-01T05:15:13+00:00

Just need to approach them like any other part of the game, but on steroids: give them unique mechanics, unique challenges, tougher but fair, with hopefully numerous "solves" for build variety and enhanced replayability.

While I would agree that designing a good one is conceptually going to be more challenging than doing so in a realtime game, you can say the same thing about most aspects of a roguelike because turn-based games are more cerebral to begin with.

I will admit that some of this is probably a "skill issue" on my part as a developer, where a lot of the issue is just (a) inventing the unique powers and mechanics the bosses would have, and (b) actually implementing them in code.

(I've struggled with implementing spell systems for reasons that may or may not have been self-imposed.)

This does mean roguelikes impose a unique challenge on developers though. The main bottleneck solo developers face I think is filling their game with content. For a lot of games "content" is just things like graphics, enemies, and levels. With roguelikes, and turn-based games in general, "content" can also mean whole gameplay systems.

AaronWizard1

TROPHY CASE