All my files are on Git @ Godot-Project-Backup/Merge_Prim at main · TesFalcon/Godot-Project-Backup · GitHub
===================================================================
You had a bit of confusion above when I used the term “dynamically”. Let me explain…
Dynamic is the opposite of static. The 1st definition of Dynamic = “(of a process or system) characterized by constant change, activity, or progress”. By contrast, the 1st definition of Static = “lacking in movement, action, or change, especially in a way viewed as undesirable or uninteresting”
Prior to game time, there is 1 cell with a static texture, and there is 1 game_piece with a pre-set texture. At game time, I use the variable height and width to determine the size of the game_board and thus the maximum number of cells that will be instatiated. In the beginning, I used a small board of 2x2 to make reading the debugging comments easier to follow. The present board is 7x9. Later iterations of the game will change the size and shape of the game board. As seen in the images above, my dynamically generated game_board with static imaged cells are fine.
Once the game_board is made, the game_pieces are also made = the maximum number for cells. Unlike the game_cells, the pieces have their textures applied and changed at run-time (dynamically). In the present iteration of the game, there are 15 families of textures with 4 - 11 images in a given family for a total of 251 possible textures that could be applied to the piece at run-time. This will GROW in later iterations of the game.
The reference to these families of images are stored in separate arrays which are all combined into a dictionary of arrays named by the family. (My code example above demonstrated that.) Thus I only need to check 2 basic pieces of information to know which image to load at run-time: family (string) and texture_index (integer). Since the index is an integer, I can walk through the textures in the family by simply incrementing that index up to the maximum for that family image array.
As you stated above in your initial response, when the project gets packaged for distribution, the images are renamed and moved. Thus my static reference to res://pokemerge/game01_64.png becomes broken. Apparently, EVERY packaging and distribution of the game breaks this static reference in some way since it also breaks in distribution to HTML. The only reason it didn’t “break” as noticeably on Windows is because I was able to add the Pokemerge image folder to the .zip along with the .exe, but without that folder being added, the same issue happens.
=====================================================================
FYI, It’s a merge game. Two pieces that look alike are able to “merge” together. One piece has its texture incremented to the next texture in the family. The other piece is released from memory and disappears.
As you merge pieces together, certain pieces in certain families become “generators” and, when clicked, produce NEW pieces depending on the family that the generator exists in and a bit of randomness between common and uncommon family generation.
The entire object of the game is to generate ALL of the images in all of the families with various incentives to encourage the player to keep clicking and merging. My 13 yr old played / tested it for over an hour, and at the end said, “That was FUN! Get that on my phone!”
