Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Starver]

All sprites seem to be aligned to a grid of twice the density of your debug-grid, or indeed the grid you'd get by packing your sprites shoulder to shoulder. (Your 8² vs 16² confusion clearly comes into play there.)

And all sprites whose centres align with grid-crosses are ignored (for blocking purposes, plus a sprite whose centre aligns with a half-horizontal on-grid position (and, if you had one, I presume a half-vertical one). The only one that blocks is the only one that has a centre on a mid-mid 'box' position.

From this (purely from visual inspection) I would presume that the bottom-right corner of the sprite is being tested against grid-crossings and excluded as a match/clash between the two. Normally I would have expected a sprite origin to be top- or bottom- left, according to graphics convention (though maybe if you paste an icon as a mirror image of its original it would go from [x,y] to [x-w,y+h], and do this). With other systems having centre-origin (spreading ±<w/2> and ±(h/2) from that). I think you've told us/given us the info to remind me which one Godot is, but I've not gone back up the thread to check.

So I think you have either two issues or 'merely' one-and-a-half. Both trivial, so long as you understand the error.

Firstly, get your (hangover-induced?) grid-size agreeing with the 'sprite-gridsize' of placement.

Secondly, check for off-by-one errors. Or an off-by-half. In the first instance, the top-left origin of sprite is being compared with and blocking against the bottom-right located intersection, so the code might be confusing things by exactly one (and only by the half-and-half-aligned sprite is it even finding that blocking node, which is lucky for the diagnostics. In the second instance, it's blocking (as would be logical, to surround by a grid that should enclose a sprite) against the centre-coordinates of the sprite, but this is half-grid-resolution off from what it should be.

And if you double the grid-resolution to match the sprite placement one (but leave the sprite size), your 'collision of nodes' should not just match the centre spot but the new nodes formed of your denser grid that are just on the sides/corners of your sprite, too...

Code: [Select]

*=•=*=•=*=•=*=•=*=•=*=•=*=•=*=•=*
”       " ' " ' " ' " ' " ' " ' "
• O#O#O •-•-•-•-•-•-•-•-•-•-•-•-•
” ##### "       " ' " ' " ' " ' "
* O#X#O * O#O#O *=•=*=•=*=•=*=•=*
” ##### " #####       ' " ' " ' "
• O#O#O • O#X#O#O#O •-•-•-•-•-•-•
”       " ######### " ' " ' " ' "
*=•=*=•=* O#O#O#X#O *=•=*=•=*=•=*
” ' " ' "     ##### " ' " ' " ' "
•-•-•-•-•-•-• O#O#O •-•-•-•-•-•-•
” ' " ' " ' "       " ' " ' " ' "
*=•=*=•=*=•=*=•=*=•=*=•=*=• O#O#O
” ' " ' " ' " ' " ' " ' " ' #####
•-•-•-•-•-•-•-•-•-•-•-•-•-• O#X#O
” ' " ' " ' " ' " ' " ' " ' #####
*=•=*=•=*=•=*=•=*=•=*=•=*=• O#O#O
..your "double grid" of "s and =s with nodes of * augmented by the tween-grid of 's and -s with new nodes of •. And variously aligned sprites of centre X and extends by #s to the O corners/mid-edges (sharable, due to the vaguaries of how I decided to do this particular ASCII art) that leaves pathable corridors between the not-too-close neighbour through which you could move any other sprite, whether highly constrained (single track, upper left) or with wide choice (larger gap, bottom right).

Does that make sense?

Or... Just make placement-grid the same (and in the same parity) as the pathing grid like I think you always intended. But with the above diversion I should also help you with any future multitile path-blocking supersprites (assuming you don't just have a DF approach to it, c.f. wagons), of arbitrary size/extent per object.

[delphonso]

It for certain is testing the top-left corner. I expect there's something off about where it's testing (or perhaps it considers 0,0 of a sprite to NOT collide, for some reason) The sprite is squarely in the top left corner of that collision vertex, which could explain it. I'll find some way to test it today. I'm certain it will be a non-issue after a cup of coffee and last night's good sleep.


EDIT:
I turned the offset off and now it's obvious where it was actually colliding.




EDIT Part Deux!

E 0:00:02.919   set_point_disabled: Can't set if point is disabled. Point with id: 86536 doesn't exist.
  <C++ Error>   Condition "!p_exists" is true.
  <C++ Source>  core/math/a_star.cpp:517 @ set_point_disabled()
  <Stack Trace> astar_tilemap.gd:125 @ set_obstacles_points_disabled()
                astar_tilemap.gd:100 @ get_astar_path_avoiding_obstacles()
                level.gd:15 @ _input()

For some reason, it doesn't catch...basically any of the points. It is counting everything on a 16x16 grid, though when it displays that, it doesn't really look that way.




Third edit:

I'm a fucking moron.






everything is fixed.

[delphonso]

I should just have a note on my desk that says "If it's not working, it's because it needs to be offset." I swear I run into this issue literally every game.

Since the sprite was centered, the collision was checking right in the center of the sprite, rather than the top-left corner, which is what we want for a clean grid. Easy fix and then suddenly everything worked correctly.

Okay, now that everything is fixed, let's remake the map and throw a dude on there.



I had to remake the map because the trees were 16x32 - I was sure it wouldn't work, but just wanted to check. Now it's all rocks, snowmen, and buff guys.

Right now, the code assumes there's only one player. I add a few lines of code to allow you to click on a unit, then direct them where to go.





With that all working, the debug section gets removed, and along with it a few commands to allow me to toggle the grid. The line is the actual pathing script, so that is going to stay around.

I decide to do a bit more polish and clean up at this point. I trim down Heartbeast's code to about 100 lines, some of which I'm still not using, but might when it comes to enemy AI.

I also update the function for the main menu, which had bloated considerably.

Here's how old me would do that:



And now: the new and improved delphonso:



Rather than explicitly tell the code to hide each element of the scene, I just iterate over all the nodes in the scene, which would include labels, buttons, etc.

Now let's make this combat scene look more like a real combat scene.

We name the units Tom and Joe and add a button to send the unit to the square you have selected.



So the way this works now is you click a unit, then a label tells you who you have selected (I'll add another ui element to this at some point).



Then you click a square and the path is revealed.



And then you click "Commit Move" and the unit moves...directly behind the button.



God damn it, Tom.

[King Zultan]

Dang this thing is taking shape quite quickly, have you become some kind of code wizard?

[delphonso]

It's a mix of coding skills improving (slightly), debugging skills improving (much more) and just gaining familiarity with the engine.

The whole "self.get_children()" is something I've known about for a while, but only now feel comfortable enough to use it, as it is pretty abstract.

[eerr]

I personally have been stuck on implementing a fancy pathfinding myself.

seems like something I should either dumb down, or copy off someone that know's what they're doing.

My idea was, a pack of wolves hunting.
making them behave naturally while also on a grid is not something I know how to do.
I had no idea where to start, so I sort of drifted off on that problem, and moved to easier to make stuff/stuff i already knew the basics of.

[delphonso]

Yeah. I'd love to be at the point where I could do this stuff myself, but I just don't think I'm at that level yet. Certainly using this code and reading through it has helped a lot. I roughly understand how the code itself works, but there's a lot of technical knowledge (the methods inside the AStar object, for example) that I'm missing.

I'm going to build a state-machine for dealing with player inputs and then I'll need to stop working on that part and actually work on saves/stats which was, you know, the whole point of this project.

[King Zultan]

I know nothing about code so I must ask what a state machine is?

[delphonso]

I know nothing about code so I must ask what a state machine is?

That's what I used to control the fish that swam around the pond and also for the gamejam game.

Basically, instead of having a big list of "if ____, then ____" commands, you simplify it into a limited number of "states"

For the fish it was "swimming", "turning", and "idle" and just cycled between the states, making the fish do certain behaviors in each one. I'll do something similar with the mouse in this. "free", "unit selected", "attacking", "moving" or something along those lines.

[Starver]

Basically, instead of having a big list of "if ____, then ____" commands, you simplify it into a limited number of "states"

For the fish it was "swimming", "turning", and "idle" and just cycled between the states, making the fish do certain behaviors in each one. I'll do something similar with the mouse in this. "free", "unit selected", "attacking", "moving" or something along those lines.

...that's probably a decent cue to reply to the following:

My idea was, a pack of wolves hunting.
making them behave naturally while also on a grid is not something I know how to do.
I had no idea where to start, so I sort of drifted off on that problem, and moved to easier to make stuff/stuff i already knew the basics of.

Briefly edit: <= That word turns out to be a blatant lie... Sorry!, I have done something like this (not wolves, but it can be generalised to all kind of things, that you want to 'zerg' in anything more than a dumb rush at a target and exhibit other behaviours.

It'd be a dynamically (and cross-referencing) weighted sum of urges that I'll call Pack, Prey and Personal.

Pack is perhaps the most complicated, but based around Swarming behaviour where the desire is to be not too distant (but not necessarily too close) to other pack-members. it might have sub-states (for wolves: travelling mode, hunting mode, running-down mode, going in for the kill) which might designate a desired position to be at a given the flank of the pack 'mass' (or even gone around what is in front, info from the Prey urge's targetting, to lie in weight as a backstop to the more obvious zerg-like rush, which necessitates a special "pack position attractor/repulsor" combination to guide its individual swarming bevaviour), if not the Alpha position who merely feels the need to follow The Plan, so long as they have the flanks near them that they think they should have. - There's simpler versions of this, but you can have fun tuning the more exotic tactics into it to. The urge to Pack might be strongest (given more weight) in both offensive and defensive situations, but if (say) sufficient pack-members (or the Alpha, in particular) are lost/unseen during an encounter with an antiPrey (see below), it could be suddenly revalued as the weakest weighting of urge.

The urge of Prey is a (usually attractive) tendency to head for a target. If not actual prey (the current thing being hunted, or a scavangable item of interest), it can be something off-screen (the pack's den, where there is a desire to rest and recuperate?). It can also be a negative urge (encountering a dangerous foe, "antiPrey", the urge is to go away from that spot, being liable to become prey oneself) and there's the "healthy distance" version which encourages a Pack/Flock-like distance from the target (close in, to surround a big bovine wielder of sharp horns and worry at it but keeping out of range of its head-weapons; further away, such as cautiously moving beyond the herd (undetected) to spring a divisive pincer attack...). Plus there can be (and often will be) multiple such Prey (and/or antiPrey) point presences to sum up the effects from. Strengthened and weakened in the global mish-mash of primary Urges according to various factors.

The element of Personal is the random-wander, the strength of desire to be closer to the (potential) food than the others, the expectation that one is always at the right flank of the Alpha (the pack pecking-order generator having assigned this position, or another, to this particular individual) or near/further from another pack-friend/-rival. Usually the most subtle effect that just makes the rest of the behaviour not look like it's being coordinated by a computer (though it is!), but could be dominant if (say) you encounter the wolfpack when idling, and you're stealthed to the max and just creeping through the area.


Just take the three major Urges (themselves a summation of sub-Urges under their own rules and sub-states and all those pesky little calculations that generally boil down to vectors of various kinds) and, depending upon the State (could be merely Hungry, Fearful, Idle or a bit more complicated) mix them together for each wolf, translate that to a movement, enact those movements, deal with reactions (others in the pack, other NPC entities involved, the player's response in their own 'tick') and perhaps change state (packwide or personal) if circumstances changed across a threshold of any kind

And you can isolate and test each Urge (and sub-Urge) in its own right, before then testing States that define the mix. Can't promise you no unexpected emergent behavious (e.g. a tendency for the pack to spiral clockwise around some strange and otherwise unremarkable point - easily done!), but you can make sure that your vector-maths doesn't make them a direct result of some basic wrong-sign-error in an initial subcomponent.


The trickiest thing is the grid aspect. With directions (instantaneous, per tick, at least) being restricted to cardinal/diagonal and 'speeds' being probably one tile (or ✓2 tile-edge distances, but diagonally) at a time, subtleties might be lost. Collisions (movement to same tile) need thinking about (DF solution? Or does one entity (randomly?) get there first and block the other entity(/ies) that wished to move there?), as does the finer-angles of destination perhaps need some stateful 'memory'[1] All problems avoided in a vectorised movement system with a positional resolution much finer than the 'station-keeping' distances that you'd not normally expect your entities to approach within (except for deliberate collision/attack).


But it also needn't be this complicated. It could just he Pack or Prey or Personal (i.e. "Idle) for general station-kept movement across the map, surrounding (or fleeing directly away from) the biggest attractor (or repulsor) or the generally lolling about with occasional shuffling around at random. Depending upon the wolves' single current (shared) State. You don't need to combine them proprtionally, necessarily, and might even have some other mutually-exclusive states (P-initialed or otherwise...) that you think they should do. Like circling an apparently uninteresting point. (Perhaps indicating wary interest in something that the player can't immediately see? But if you disturb/displace/kill the pack and get go examine the focus tile properly you end up finding that some Mystical Orb Of Power was half buried there, and it's a very useful loot-item with geat in-game potential!)


Then again, I do like Emergent Behaviours from a tuned (or improperly tuned!) mix of simulated wants, needs, fears and whims. If only I could progress to making some of my thought experiments reach consumer-grade levels of quality, rather than moving onto my next (mostly unrelated) whim.


[1] If, for several turns, you're highly consistently attracted to go 8 tiles north and 7 tiles northwest of your initial position, better to aim to alternate N, NW, N, ... (terrain/obstacles allowing) than clump Ns until the dominant direction is now NW and then potentially clump them. Additionally, if it's an 'off-map' attractor, N should not win out every time just because at each step the vector is 8xN and 7xNW as it wants to head at roughly the same angle to a point off 'at infinity'. Some stack of recent compromises in movement that skews in a NW because "we've already oversubscribed on the Norths, at this time!" could be a useful trick, even to bias a recalculated Urge-vector, to indicate some sort of Urge-inertia, in that tracking slightly NNW wins out for a tick or two, even when N now is twice as necessary as NW, say.

[eerr]

I'm stuck on basic pathfinding, not uh, a fully simulated pack of wolves.
I'm a newbie...

I'm also not really feeling a grid based game anymore.
I look at a grid and I'm like, damn, i wish this thing wasn't confined to a grid.
None of the games I've chosen to make, recently, are better for having a grid.
https://youtu.be/zmwk_OiUtxQ?t=38

[Starver]

...I regret the length and detail of that post. I was too much in a hurry to make it short. I even started to rewrite it much briefer, later on, but got called away from the keyboard again after an hour or so. So this is me apologising again for being an unmitigated stream of consciousness. Who says things like "unmitigated stream of consciousness". But maybe it'll help/not overly hinder someone out there.   

[bloop_bleep]

When delphonso becomes a prominent indie game dev I will be able to say I was here when it began. Kinda like those people who played Dwarf Fortress back in 2006.

[bloop_bleep]

I personally have been stuck on implementing a fancy pathfinding myself.

seems like something I should either dumb down, or copy off someone that know's what they're doing.

My idea was, a pack of wolves hunting.
making them behave naturally while also on a grid is not something I know how to do.
I had no idea where to start, so I sort of drifted off on that problem, and moved to easier to make stuff/stuff i already knew the basics of.

Do you want them to exhibit pack behavior or just mingle randomly like the others aren't there?

If you want to implement A* pathfinding, you can just look at the wikipedia article on it, complete with pseudocode: https://en.wikipedia.org/wiki/A*_search_algorithm#Pseudocode

The heuristic h describes the shortest possible distance between two points. It is not necessary, you can just set it to be 0 always and the algorithm will work (in fact exactly like Dijkstra's algorithm), but the better heuristic you have the faster on average the pathfinding will be. If moving on a grid, you can use the Manhattan distance between points (x0, y0) and (x1, y1): |x0 - x1| + |y0 - y1|. If moving not on a grid, you can use the straight-line distance: sqrt((x0 - x1)^2 + (y0 - y1)^2).

[delphonso]

I'm also not really feeling a grid based game anymore.
I look at a grid and I'm like, damn, i wish this thing wasn't confined to a grid.
None of the games I've chosen to make, recently, are better for having a grid.

This is actually a very important point to think about. Like, if you're doing a control scheme, you really should think about /why/ that one is the right one for your game. Think of something like Pokemon. Why is it grid-based? Genuinely, there seems to be no reason. Zelda manages to do grid-based puzzles with pixel movement, which is the only thing from Pokemon that seems like it would require the grid.

Something like XCOM benefits from the grid because it makes it clear whether you're in cover or not. Fire Emblem has terrain types, so likewise benefits, though I think that game is easier to remove grids and do something like Phantom Brave's movement.

...I regret the length and detail of that post. I was too much in a hurry to make it short. I even started to rewrite it much briefer, later on, but got called away from the keyboard again after an hour or so. So this is me apologising again for being an unmitigated stream of consciousness. Who says things like "unmitigated stream of consciousness". But maybe it'll help/not overly hinder someone out there.   

This thread is always a home for Starver's streams of consciousness on code optimization, game design, and tales from the middle years of computer science. It was an interesting read and actually something a friend and I have been hashing out (in pseudocode, really) to make some sort of ant simulation. It just plays into our interests of automatizing units and seeing what they can get up to. I think any fan of DF can get that.

When delphonso becomes a prominent indie game dev I will be able to say I was here when it began. Kinda like those people who played Dwarf Fortress back in 2006.

Hell yeah. There's still a large gap between where I am now and a shitty commercial release, but I think I'll get there. Maybe this year, if I can keep up the practice.

I personally have been stuck on implementing a fancy pathfinding myself.

seems like something I should either dumb down, or copy off someone that know's what they're doing.

Do you want them to exhibit pack behavior or just mingle randomly like the others aren't there?

If you want to implement A* pathfinding, you can just look at the wikipedia article on it, complete with pseudocode: https://en.wikipedia.org/wiki/A*_search_algorithm#Pseudocode

Fake it til you make it, baby. I really think there's value in completing a game/project. If that means copying someone else's code and not fully understanding it, that's fine, honestly. I think that sort of intermediary step is necessary to actually understand it fully later.

Weekend is over and the kiddo is heading to school tomorrow. We'll see how much I get done. I'm boiling over with ideas right now, so I'm eager to get started.