nomnomnami
patreon
dev diary: picross on ur phone!
🕑 Added 2023-08-07 19:34:22 +0000 UTClast friday i finally ported charm studies to android!! it only actually took a few hours of work to code the new stuff, but i had been too worn out/busy with other things to actually be able to do it until now... i didn't expect to get it done last week, so i'm really happy i could put it out!!
so what new code did it take to do this? i'm glad you asked!!!!!!!! (because i wanted to write about it today lol)
touch friendly controls
the main thing i needed to do, especially for the larger puzzles, was to have arrow navigation so that you could fill in the tile with a separate button instead of having to touch the ones on the grid. maybe if you're on a tablet with a larger screen it's not too bad, but the 15x15 ones weren't east to do on my tiny phone screen, so having an alternative was important!!
FIRST: there's no right click on touch screens, so i removed the "mark" tool and replaced it with "cross out" (which is what right click does on pc). being able to mark tiles in picross IS handy, but not super necessary for charm studies' level of difficulty... removing complexity is always a good move for mobile games (considering the design for many of them include very hand-holdy tutorials).
the puzzle screen for the pc version was built around checking which mouse button you're using to click, so i had to make a new screen (called a variant) for the button to behave differently on touch devices. this is a cool feature ren'py has, you can tell it to check what device the game is running on and it'll use the correct variant for it! (i did the same thing for the character select screen in BAD END THEATER)
NEXT: the grid navigation arrows! i needed to write code that told it to highlight the correct square when you pressed each arrow--this was the harder part, and the main thing i was too intimidated to figure out until last week.
those tricky arrows...
to briefly explain how the grid of tile buttons work: each tile has a number starting at 0 and counting up by 1 when we move to the right. so for a 5x5 grid we'd have 25 tiles (yay, math!) but the last tile is #24, because computers start counting at 0 (boo, confusing!). when you click a tile, it checks the number of the tile you clicked, and does [something] with it. so all the arrows needed to do was change that number, and the paint button would jump to the [do something] part.
so here was my FIRST VERSION of those buttons:
for moving left and right, i could make it go +/-1 until it got to 0 or 24 (for the 5x5 example), and i didn't limit it because it'd loop around to the next/previous row when it got to the edge. in my head i was like, "well it's still on the grid, so that works just fine!"
BUT, when i tested it, i realized that it SUCKED. people looking at a picross grid aren't thinking of it as one long string of numbers! all the picross games i've played has it loop around to the same row!! dangit!!!! that takes even more work to figure out, because now i need to do some math to make sure it loops around to the correct tile.
so here's the SECOND VERSION, that feels much better:
now all we have to check for is the "leftedge_tiles" and "rightedge_tiles"... but we have 3 different grid sizes, so how do we know what they are?! HEH... that's where my special functions come in.
when the puzzle is first generated, i have lines like "leftedge_tiles = get_leftedge_tiles()" so after we know how big the puzzle is (gridsize, aka the "5" in "5x5") it spits out the correct numbers for us:
(sorry i was leaving out the top/bottom stuff until now just for simplicity's sake. also because the buttons for them didn't fit in one screenshot lol.)
this is probably silly, but i had to think really hard to figure out how to write those functions... here are my scribbly ms paint notes that don't make any sense but did help me visualize the problem:
going from the bottom of the grid to the correct top tile was the most difficult one for me!! it turned out i had to set the tile number to "tileno-(gridsize**2-gridsize)"... who woulda thought.... anyway, when i tested everything and it magically worked at all sizes, i felt like a genius.
the game still has performance issues tho
big grids are super laggy!!! because there's over 200 buttons it's rendering every time you click a thing!!!!!!! i could not figure out a way around this. potentially the way i coded this game is just not scaleable, but the apk is available on itchio now so anyone can crack it open and look at the files... (casually begging someone to solve this for me lmao)
uhh there's also a funny little bug where if you change languages while you're doing a puzzle, when you close the menu the dialogue from the previous scene shows up over the puzzle ui. there's like a 1% chance any player would do this, so i decided to ignore it. but it's on my todo list for future updates anyway!
that's all for this week, i'm really glad i could finally put this game on android since a lot of people had been asking for it!!! sorry it's not perfect, but that's future nami's problem!!!!!! i'm going back to drawing comics for now.
thanks for reading~
Comments
Blackberry Mochi
Laaaate but as always, 'tis a joy looking through code I cannot actually comprehend but can vaguely recognize the makeup/functionality/process of and going "yeah!!! That makes sense!!! In a conceptual way!!!" Although, admittedly, the coding here does seem the most confounding of the bits you've shared, perhaps because of it being so explicitly technical, pff (what the frick does a double asterisk even mean in an equation???) Still fun though!!!!! But, regardless of the joys of code viewing, CONGRATULATIONS ON OVERCOMING SUCH AN OBSTACLE AND ALLOWING THE PHONE-ONLY MASSES TO ENJOY THESE CHARM STUDIES!!! Hopefully lag fixes can be made later, but, for now, it's just nice that it was done!!! (I do really really like the basic math in the bottom right of the '"scribbles for visualization" bit, tho. Sometimes we need to steadfastly remember: 25 - 24 = 1, 24 - 24 = 0, and 0 + 6 - 1....)
Harry Tsang
For the edges, you can think of the rows and columns as separate indices tileno = row * gridsize + col conversely row = tileno // gridsize # integer division that throws away the remainder col = tileno % gridsize # modulo that only get the remainder For looping back, you can use modulo (the % operator) too so you don't even need if-else imagebutton auto "leftarrow_%s": row = tileno // gridsize col = tileno % gridsize row = (row + gridsize - 1) % gridsize # need to add gridsize so that it doesn't go negative action SetVariable("tileno", row * gridsize + col) so edge detection is simply finding the row and col and comparing it to the row numbers def is_leftedge(tileno): row = tileno // gridsize return row == 0 def is_rightedge(tileno): row = tileno // gridsize return row == (gridsize - 1)
