Took me about two weeks (but I’ve been super motivated!) to put this game together.
I love this game on the C64 and decided it would make a great concept for my first game on the Pokitto to learn micro python and the like.
A: start game. Hold B to view instructions. Left: Music on, Right: Music off.
In-game, D-pad: move face pieces in the middle to top, right, bottom or left boxes. Button B uses a coin to buy a new center piece if the existing one doesn’t fit anywhere. However, as a penalty, a random box will get cleared.
Download the pokittobloidsWindows.zip file.
Extract it to your desktop or wherever you want,
Double click the PokittoEmu.exe to start the game.
PLEASE NOTE: There is no audio in the Windows emulator.
Tools I used:
Online Micropython IDE (code)
Let me know what you think and please don’t be too brutal
Here’s the zip file with everything in it, including the bin, readme and wav files for the music: pokittobloids.zip (1.0 MB)
Thanks guys for the feedback and also the help with the gif animation etc.
I’ve made some changes to the game which makes it even more fun and challenging.
Just need to implement some more graphics and code now, then I’ll upload the latest version (more complete) here to replace the one in my first post.
I’ve uploaded a new version of the game with instructions and the ability to clear a random block of faces using B button that uses coins.
Random generation isn’t that good, so you often get a piece that you can’t place. Sometimes it’s just dumb luck. I’ll need to look into maybe changing the code to compare the current and previous random pieces and if they’re in the same spot, to change it… (Good idea I think)
You should get a bonus coin for every 1000 points. However you only get that once now when hitting 1000 or more. I need to figure out how to implement it for every 1000, because the score can be 1000, or 1010, or 1200 from the previous 900 or 990 etc etc… This is gonna take some thought., unless someone knows how to do something like that?
Seriously though, I guarantee most of us have seen and even written worse code.
If you’re really that worried then you could PM it to me and I could have a quick look.
I’ll try to solve your problems without the code anyway…
Having actually had a chance to play the game and understand the rules I think I know how you could solve this.
(You might want to add a screenshot of the rules screen to the main post by the way.)
Each head has 4 parts: top left, top right, bottom left and bottom right.
If you count the number of each part placed then you know how many of each type you can still generate.
For example if partsPlacedTopLeft were 3 then you know you can generate 1 more top left pice,
but if it were 4 then you know you’re not allowed to generate a new one because the player can’t place it.
You could also do this the other way around, have partsFreeTopLeft start at 4 and then decrease it every time a part is placed.
Anyway, when you come to generate a part, what you can do is look at the part counters for each face part type, determine if you’re allowed to generate a part of that type and if you are you add that part type to a list.
When you’ve done that for each part you randomly select a part type from that list, which will mean you end up only selecting part types that you’re allowed to generate.
It might actually be cheaper to modify that list at the same time you modify the part counter, but I’m not completely sure.
An example of what the code might look like using the ‘decrement’ approach:
piece_shapes = 
if (available_top_left_pieces > 0):
if (available_top_right_pieces > 0):
if (available_bottom_left_pieces > 0):
if (available_bottom_right_pieces > 0):
# The same 'select_random' I demonstrated in the other thread:
piece_shape = select_random(piece_shapes)
# However you're doing that
piece_type = generate_piece_type()
return Piece(piece_shape, piece_type)
There might be arguably more ‘pythonic’ ways to do this, but this is the second cheapest and perhaps the simplest way I can think of doing this.
I’ll try to guess this one without seeing your code…
I’m guessing right now you’re using a boolean to decide if the bonus coin has been awarded?
Either that or you’re using a counter of some kind and your logic test is only firing for the first increase.
Either way there’s an easy solution. At the point at which you add to the player’s score (which hopefully is a function called add_points or add_score or something like that), you:
Store a copy of the old score
Add to the score
Compare the old score divided by 1000 to the new score divided by 1000
If the new score divided by 1000 is larger than the old score divided by 1000 then you add a coin
Thanks for the code ideas. The score / 1000 idea was very elegant, but doesn’t work as only INTs are supported and not Floats, so what I did was this:
if ((score > 1000 and oldScore == 0) or (score > 2000 and oldScore == 1000) or (score > 3000 and oldScore == 2000) or (score > 4000 and oldScore == 3000) or (score > 5000)):
coins += 3
oldScore += 1000
So my idea behind this is you get awarded coins up to a point. If you can reach 5000 points, you’re doing well enough to not need more
In any case, I like the twist my version of this game provides. The challenge of putting face pieces on the boards, but also making an extra challenge when you’re hit with a piece you can’t place, then having to pay for a new piece with a coin. You get award coins for completing faces anyway, so I think the system works well.
Many people praise Python for various reasons, but much like C++ it’s a language old enough to suffer from the occaisional misjudged historical decision.
Unrelated: the article says “an ado about nothing”, but the word ‘ado’ is uncountable, so the ‘an’ is ungrammatical.
Visual Basic is another language that has an integer division operator (\).
Interestingly they’re both from the early 90s.
However the ‘ABC’ language mentioned in that article which apparently has an integer division operation is from the 80s,
so I’m guessing that probably influenced VB as well as Python.
At any rate, I think most people have learnt their lesson about having a separate ‘integer division’ operator by now.
Operator overloading (and arguably basic type theory) renders it obsolete.
If you want any suggestions don’t be afraid to ask.