[Game]Pokittobloids

micropython
puzzle
game
release

#21

Thanks @Pharap

I’m doing ok so far. I’ve managed to reduce the code massively. Some snippets of code were a little more complicated but managed to get them ‘for’ looped :slight_smile:

So, I’m now trying to take the audio out of the main file. I created a new .py file called audio.py and pasted all the audio data in there with an import upygame at the top of that file.

In the main.py file, at the top it now has:

import upygame as pygame
import urandom as random
import umachine             # For on-screen text
import file                 # Graphics
import audio                # Audio

Then a little further down I have my interface class which handles audio and screen stuff:

class Interface:
    def __init__(self):
        self.x = 0
        self.y = 0
    ...
        
    # Play sfx
    def playMove(self):
        g_sound.play_sfx(audio.moveSound, len(moveSound), False)

But now I get the error:

File "main.py", line 125, in playMove
NameError: name 'moveSound' isn't defined

As you can see, I’ve tried copying the way you can reference graphics be prepending it with the .py file name, and without, and it doesn’t work. Am I supposed to add something I’m unaware of in the new audio.py file to make the main.py code see it?


#22

Ok nevermind. My mistake. I didn’t change the 2nd part in the len() section… Working fine now…


#23

That’s a good improvement. Keeping the ‘data’ separate from the ‘code’.

That sort of thing happens a lot.

I recommend finding yourself a duck to explain your problems too first, and asking the forum if the duck doesn’t know.
(Other inanimate objects will also work.)


You should probably update the GitHub repo sometime soon.

Commits are more useful when they represent smaller, more meaningful changes.
For example moving the audio out to audio.py might be one commit,
and changing some of the code to use for loops to make it more compact might be another commit.

For one thing, if you accidentally introduce a bug, this makes it easier to pinpoint the bug because you can find the specific commit that caused the bug and it’s easier to spot the bug if that commit is fairly small.
For another, it ends up making your commit list more of an easily-readable list of changes and/or a documentation of the code’s history, rather than just a semi-random log of when you updated the repo.


Also you might want to rename file to something more meaningful, like images.


#24

Thanks for that info @Pharap

For “Rubber Ducking”, I have some IRC mates I discuss things with, albeit not all the time :slight_smile:

I have updated the first post with the latest bin. I feel the code could do with more improvements so I “might” carry on trying to tweak it, but at this point, I’ve cut the code size down and all is still working nicely.
I also adjusted the coin giving, as it made the game too easy. Now you get a coin for completing a face of the same type and a coin every 1k score. Thanks for your every 1k code btw :slight_smile: Works well.

As per one of my previous posts, I plan to just add those 5 things I listed and then will call the game done.

I am planning to do a pokitto version of another game after this, that I was originally going to make for the C64 but is currently on hiatus.
I like how easy devving for the pokitto is using the online IDE. However, are there alternative IDE’s for using micropython and pygame with the pokitto?

Also, does anybody know how many pokitto users/buyers there are out there?

And finally, I updated my changes to “version13” on the GitHub repo. I really should set up source tree and use GitHub properly, but I’m not sure how I’d set it all up and use the online IDE, hence why I’d prefer a proper app I can use on any desktop OS. Give me time to think about this as I’d like a more stable environment to code in. The online IDE often hangs/crashes the chrome tab or gives weird flash write errors and some other weird errors. Luckily I save the zip often and it seems to work well with local storage.


#25

Sorry about that. I think I know what’s causing the hangs, but I haven’t been able to get to it yet. Fixing it is going to be a lot of work and I’m focusing on FemtoIDE for the duration of the java compo.


#26

Is that dependent on the web browser? Does some browsers work better.?

I have faced that also (using Chrome), but rarely lost any code changes thanks to automatic saving :slight_smile:


#27

I noticed it was more stable on Firefox, but I don’t know if it was just a coincidence.


#28

Thanks FManga. FemtoIDE looks ideal for what I would like to use! Please consider adding Python to it as that would be amazing. And the fact that you will have git support too is just the icing on the cake.

Really looking forward to trying it out!


#29

I second this!


#30

There is an alternative. You can use the same Embitz dev env as you can use for C++. There is already “micropython” target that comes with Pokitto library. But note that there is not any emulator integrated.

You can also develop with CodeBlocks and test your code with Pokitto Simulator in Windows (at least?). The benefit is that also audio and the SD card is simulated. However, in the simulator the real limitations are not simulated (ram, cpu speed, etc). You might need to optimize the Python code when building it in Embitz & HW.

However, the Embitz & CodeBlocks enviroments are not so easy and convenient to use than the Online Pokitto
Editor.


#31

Don’t worry, I’ll definitely add Python support to FemtoIDE after the compo.


#32

Not tried it in any other browser as Chrome is my browser of choice throughout my computers. Anyway I agree it’s got some minor issues but is useable. Data doesn’t get corrupted or lost as far as I can see and I export often, so it’s a minor inconvenience. So with that in mind, I’m not sure it’s worth hassling with Embitz and Codeblocks.

FemtoIDE seems to fill exactly the gap we need for decent offline devving like the online version, so until that is ready to be used, I’ll stick with the online one :+1:

@FManga Thanks for adding that support in the future. Very much appreciated.

I have many more games I want to make for the pokitto, so things can only get better.


#33

So, I’ve completed implementing all I want for this game now.
I added code to play menu music and in-game music too. Tomorrow I will make the music myself and it should be a simple plug-and-play for me to test as I’ve already tested with some example songs and even converted an mp3 to the right format, exported it as required and it worked well.

Once I’ve done tomorrow, I’ll upload the final changes to the Github repo and the bin at the top of this thread and call it a day!

Then onto the next game! Hopefully the lessons learned in this game will improve my coding methods for the next one, hohoho.


#34

Part of the point of the excercise is that the duck isn’t supposed to talk back and isn’t actually able to answer your questions, because that means the solution has to come from you rather than someone else.

Though admittedly sometimes someone not understanding your explanation and asking to clarify a few things can help.

Like I say, there’s no problem with asking for help and advice,
but sometimes it’s more rewarding to come up with the solution on your own,
and sometimes it can help improve your problem solving ability.

Theoretically you can write Python in any editor but I don’t actually know one would go about compiling it externally.

Personally I use VSCode for Pokitto development,
but I only ever write in C++.

Personally I always just use the GitHub UI.
As long as you remember to commit little and often and/or plan ahead then it works fine
Creating and deleting branches on the GitHub UI is easy enough that there’s plenty of room for making mistakes.

I can never be bothered to install a git client,
and I find command line git frustratingly unintuitive.


I’ve never had any problems with it on Firefox (apart from a few copy-paste bugs),
but then I’ve never used it for more than 30-60 minutes.

I’m tempted to try to get that working on VSCode.
It should be possible somehow, it’s just a question of how.

But on the other hand I’d never use it, so unless there’s someone out there that actually wants it and would use it then it might be a waste of time.


Don’t forget to make an actual release version via the repo’s releases:


#35

The game is very well executed and the idea feels fresh :slight_smile:

I think the game needs a bit more in-game instructions. It is not obvious what the controls are moving and what are the rules for finding the correct pieces.


#36

Thanks for your feedback @Hanski

I’ve updated the instructions, images and bin in the first post with the latest code.
I’ve not had a chance to do the music yet as I’ve been quite busy IRL.
Hoping to get it done by this weekend which will then conclude this game.
In the meantime, it’s perfectly playable without the music.

On a side-note, I noticed that if you have the play_from_sd() method in the simulator and do a build, it kind of hangs. So I’ve added a variable at the top to change from False to True to play the music only on real hardware. (variable has to be manually changed, as I don’t know if there’s a way to detect if the code is running on real hardware or the simulator).


#37

You can detect that by reading a (PEX) pin value. That is different by default in the emulator and on HW. Look at Matti’s Nightmare soources.


#38
# Determine if we are running in emulator (or simulator)? 
# The pin Ext2 value is 0 in emulator but not in real HW.
isEmulator = False
joyhatY = umachine.Pin ( umachine.Pin.EXT2, umachine.Pin.ANALOG_IN )
joyhatYValue = joyhatY.value()
#print("joyhatY.value()=",test)
if(joyhatYValue == 0):
    isEmulator = True

if(isEmulator==False):
            g_sound.reset()
            g_sound.play()
            g_sound.play_from_sd("music.raw")

#39

Hmm… what is it in real hardware?


#40

Thanks so much for this useful info guys! I will be using this for all my projects going forward.