My sense is that Foundation and Tableu would have been more understanable and that they did not need to be typed many times.
if (t_stack_last.suit == 0 or t_stack_last.suit == 1):
if (stack_first.suit == 2 or stack_first.suit == 3):
self.stack.card_return = t
if t_stack_last.suit in (0, 1) and stack_first.suit in (2, 3):
self.stack.card_return = t
@JonB thanks. I defined everything and added the music code and it’s stopping and starting on cue. Thank you for your help. I wasn’t sure how to use the stop resume and pause. I sometimes still have trouble figuring out little things.
Also the only bit I didn’t really understand was when you set up the button class you used init, but then you did spritenode.init what is this for?
when you subclass an object that has __init__ paramiters you must either call the Parent class __init__ as i did here or you can use super(). if you do not call the parent's __init__ then the new object will not inherit the dirived.
I’ve learnt so much reading your code, love the way you’ve done so many things, spent ages going through it all. Could you give me any insight into the order you went about writing it?
I usually start with utility classes. in my Example game this would be stuff like Screen() and EventManager(), then visual testing. at this point i woud start my ButtonNode() and Animations().. now i create my Player(), GUI() and o on. the order on the script itself doesnt matter with Object Orientated Programing (OOP) just remember the Interpreter exec the scripts top down. so in order to Dirive from from Class A it must exist before Class B.
@Tonnoaw I would also try to import game_menu.py and build a menu with title and option selection buttons. So, rather than setting “cheat” mode in the script, define a mode button for a non-programmer to change mode of operation.
this community has always got me in the right direction. hopefully this rpg will be play-test ready in roughly 6-8 months (im doing everything alone art, story, coding... so bare with me lol) and as it moves along ill try to post updates and functional "builds" that way you all can throw some input in. when it is fully completed i plan to host it on app store but i will be providing copies for group of you that have been aiding me along the way with python. i never thought i would be able to do this level of coding on a mobile device. lol thank you again and again @omz amazing work on Pythonista!
Do not use magic constants in your code (like position_options) in multiple places, it's a nightmare when you want to change them. Move them outside of create_tile, touch_began and reuse them there. Like MARGIN_OF_ERROR.
Keep your functions / methods short. It's good when they can fit one screen (well, depends how the screen is big :), but you know what I mean. Not a hard rule, but it's about readability and crunching all these bugs quickly. It's easier when it's short. touch_moved is very long and overly complicated.
You shouldn't hardcode positions based on your device in case you want to run it on iPhone SE for example.
Split your task into several smaller ones. Replace one huge function with many small ones doing just one thing. Again, readability & easier way how to spot a bug.
I didn't dive into your touch_moved method, sorry. But I did quickly hack an example of generic board & moving tiles. You can find it here.