As you can see, I have highlighted 5 rows of 5 icons. Those are the 25 icons I needed to manage, conveniently stored in a PhaserJS sprite group so I can easily show/hide them with a single groupName.visible = true/false; and so on. Putting the icons into a single group is WAY easier to manage than declaring each icon as its own sprite, provided one can wrangle the logic involved. Let me tell ya, in this case, wranglin’ these bits was like wrestlin’ an angry bull in a well greased pan! In fact, I found it immensely helpful to break out the o’l pencil and lined paper to sort it all out!
The window is always on the screen, just hidden until the user clicks the button to “open” the window. This allows the initial sprites to be reused by positioning them one time and later simply flipping the “tile” they point to on the sprite sheet. So, when the user clicks the Next or Back buttons, the logic only needs to pull data from tables (arrays) and update some variables. In this case, here is the table of data for what icons are used per group of five icons,
You may notice that there are 45 groups of 4 numbers. That’s because the cost for these 45 different “Cubimals” always involves a certain amount of coins and then various values of 4 other items. That being the case, I don’t need to worry about changing the first icon in each row, so why bother wasting data by having an entry for it in the icon table.
Finally, to fit all 45 of the Cubimals on the screen, I needed to divide them into 9 “pages” that the user can flip through. What the user sees as “pages” are in reality a bunch of mental gymnastics that happen in the background, as you can see in the function below that fills in the data when the window is opened and the back/next buttons are pressed.
By a country mile, the hardest part of writing this function was the management of the //Cost Icons, which are the subject of this blog post. Having a look at how this part of the function works, it basically goes through each of the 25 icons and updates them, with the exception of the ones for the coins in positions 0, 5, 10, 15, and 20. It pulls the correct group icons per Cubimal based on the cubPos in RocketTux.cubCostIcons[cubPos][mod – 1] and individual icons based on mod – 1.
That’s all fine and dandy, but there are some “gotcha ya!”s in there, such as dealing with the fact that we need the 0 position in the RocketTux.cubCostIcons table as well as the rest of the positions. This meant that I couldn’t just do currentPage * cubPos, because the currentPage also starts at 0 – doing this would fill every Cubimal’s item icons on the first page with the ones from the first entry in the RocketTux.cubCostIcons table. That’s no good! Starting currentPage at 1 would complicate the matter of pulling data from the description and quantity tables, while also overshooting the RocketTux.cubCostIcons table length by 1, so I had to work with it as starting from 0.
To fix that problem, outside of the loop I had to put a condition “if the current page is 0, then cubPos should also be 0, otherwise cubPos should be currentPage * 5”, as you can see in the highlighted area below,
With that wrinkle ironed out, the for loop will pull and place the data correctly!
This is the kind of thing that probably seems very simple many programmers, but can trip up we hobbyists. It’s also the type of problem that is hard to find examples for, because it’s woefully difficult to describe and thus equally difficult to search for on the web. Hopefully this post will serve as at least one way a person can do this kind of thing!
Anyway, hope this was helpful!
Ps. Cubimals were part of a game called Glitch, created by Tiny Speck. When they shut down the game, Tiny Speck was kind enough to release all the artwork for the game into the public domain!