I’m making a merge game and am trying to get the active generator icon to overlay the item once it reaches at certain stage of merge.
I’ve been struggling with the simple task of overlaying sprites from Day 1.
Layer 1 is the cells to make the “gameboard”.
Layer 2 is the pieces overlayed into the cells.
Layer 3 is the “active selection” box.
I came up with a “process” that seemed to work until …
Layer 4 is the “active generator” lightning bolt. This is a little different since I need the bolt to stick with the game piece. Some game pieces get the bolt. Multiple game pieces can get the bolt. Some do not get the bolt. The bolt needs to move with the game piece.
So my previous method involved lining everything up with the cell from the gameboard’s view.
Here, I’m trying to keep the bolt as part of the game piece. The bolt does move with the piece this way and I can have multiple bolts on the board at once.
In Godot, the lightning bolt is lined up to the game piece perfectly.
In the game, it’s WAY off.
You are modifying the local position of the node in its scene with the local position of the grid which are two different coordinate systems. Try using the same coordinate system in both by using global_position.
I will admit to a confusion as to how the numerous coordinate systems in Godot are arranged and referenced.
As I understood it, the local coordinate system referred to the item in relation to its parent. Since the cells and pieces are children of the game_board, their local is relative to that. Whereas the active overlay is a child of the piece itself so its local would be relative to the piece.
I’ve been posting my .position, local(position), and global(position) in the debugger to track this down. The piece position is the same whether viewed from the piece’s perspective or from the game_board’s. The local and global transforms are very different. But placing $active.position = piece.position will sometimes throws it way out down and right, but sometimes it throws it way out up and left ? The position of the $active seems to depend on where on the board the piece is made even though the position of the $active is supposed to be the same as the piece.
I found and “read” that before. It never mentions or explains global or local. It just keeps talking about “CanvasItems” and “Transforms”. In the Inspector, the transform of an item is the position, rotation, scale, and skew.
It also has such self-referential sentences as …
Viewport Coordinates
This is the coordinate system of the [Viewport]
I have no idea what a viewport is.
This one is “in English”. Is there an explanation “in plain English” vs geek?
I just tested it again. I thought I had fixed it so I did it a 2nd time. Nope.
I made 3 generators. The 1st generator gets its $active positioned perfectly. The 2nd gets placed way out to the right. The 3rd got placed way down. Same code.
The $active.position changes depending on what quadrant of the game_board the generator is made in. It’s like a clock. As the location changes on the game_board, $active.position is displayed in a sweeping hand.
In the top-right quadrant, it’s off to the up & right.
In the bottom-right quadrant, it’s off down and right.
In the bottom-left quadrant, it’s off down and left.
In the top-left quadrant, it’s off to the up & left.
On the top row, it’s off more up. On the bottom row, it’s off more down.
In the middle rows and columns, it’s more straight.
Sorry, I tried to go through your project but you have such a mess of positions, scales and offsets and whatnot that I don’t even know where to start. It’d be better if you start from scratch once you understand how the coordinate system work.
Then, as I mentioned in my intro, ignore where I started to get to where I’m at and describe where YOU would start w a game like this. I agree the best thing would be to start over, but, if I don’t know any other way to do it, I’ll end up in the same spot. When I teach student drivers how to back up whether in a pickup truck or a semi, I explain that setup is 99% of the work in backing: poor setup = difficult backing. This entire program is a primer on Godot development using this merge game. I plan to incorporate a merge game into my main project so I will be starting it over on that project once I’ve learned a lot more.
While you don’t outright say it, are you saying that my scene are structured incorrectly?
What makes a correctly vs incorrectly structured scene?
When I first forayed into Godot, I started with that manual and fell crashing on my face. When I asked for help because the instruction for the 2D game was unclear, I was told, “It’s clear to me. Maybe you’re just too stupid to use Godot.”
So I started with GDQuest training. He has 2 tracks: 1) I’ve never programmed before. 2) I’m coming from another modern game development engine.
In my case, neither are true. I have 7 years of VB experience from 20 years ago. Yes, I have programmed before, and I’m not familiar with a modern game development engine. When I got started with game development in 1999, step one was to write your own engine in C++ which you then called from inside the VB program. (I still have the 900 page “Secret Black Book of Game Development” that I started with. It wasn’t until the arrival of Amazon that I was able to find that out-of-print book.) As has been mentioned by others, that’s long, hard, and frustrating. I worked on it for over a year and didn’t get this far with my card game back then as I am with this merge game today.
It’s kinda like going back to relearn modern web development when I was so well-versed in the old style of HTML4, etc. There were no <div> tags or anything back then. It’s come a long way.
I adjusted all the images I’m using in the game to be 64x64 natively so I don’t need to re-scale them. I can’t see any real difference in alignments or appearance.
I don’t know where I’m using an offset other than the nudges I note in the code.
I discovered that my game_board 0,0 was “centered” so that it wasn’t in the top, left but in the middle of the board. I went around and unchecked all the “centered” check boxes that I could find which were checked by default. Now all the positions are starting to match each other. to_local and to_global are the same coordinates.
