[Game]Matti's Nightmare



Not yet :sweat_smile: I’ll have to try again after work.


Cool! Would be nice to not have to reset the device when we want to try again after a Gameover. Is the game completable?

Oh and I found the secret room (Tors H B), in fact I also found a secret way to get to The worstmare! As well.


The room is named after me? Haha shoot I didn’t find it yet


That is because of your bee phobia :wink:


Currently the objective is just collect all the treasures (6), but there is not any ending sequence.

We have a winner :slight_smile:
I did not know any other secret path.


From the first room you can go thru the right wall at the top.


It’s not a bug, it’s a feature. :P


It is time for a boss fight! Any suggestions for the boss character in this surrealistic theme?


A giant foot.


(Cue “The Liberty Bell”!)


I am almost sure I saw the exact same thing in Manic Miner or Jet set Willy.


I did a quick search and I think I know what you’re thinking of:

I honestly had no idea about that, I’ve never played either game,
it just seemed like an appropriate thing to have.
I was half thinking “surreal -> Monty Python -> foot”,
and half thinking of the Master Hand from Super Smash Brothers Melee.
(Also I was imagining a much larger foot without a shoe.)

Manic Miner was released after Monty Python’s Flying Circus,
(the same year as Monty Python’s The Meaning of Life),
so that was very likely a tribute to Monty Python.


A giant foot is err… great!
There are also giant noses in Wario Ware:


The boss fight in progress:



I finally was hit by the out-of-memory error in the game. My list which contains room configurations (the room name, the tiles used, the enemy positions, etc.) takes almost 10 kb, which is about the half of the all available memory for a python game(!).

What can I do about it? Here is one room configuration item:

   [   # *** room5: Nightmare begins ***
        "Nightmare begins",

        [ # Tiles
            [0x0, data.backgroundSurf0, 0],
            [0x1, data.wallSurf1, glob.TILE_FLAG_BLOCKING],
            [0x7, data.backgroundSurf1, 0],
            [0xC, data.floorSurf0, glob.TILE_FLAG_BLOCKING | glob.TILE_FLAG_PLATFORM]
        [ # Sprites
            [   # scissors
                [data.scissorsSurf0, data.scissorsSurf1, data.scissorsSurf2, data.scissorsSurf1 ], # frames
                [[-2,0],[2,0],[0,0],[0,0]], # frame offsets
                # wx, wy, vx, vy, adur, dir, del,  bx1,   by1,   bx2,   by2,  bType,   hflip, vflip,  coin
                [ 60, 10,  0, 1,     1,   3,   2, -999,     0,   999,  14*8,      0,   False, False, False ]
            [   # clock
                [data.clockSurf0, data.clockSurf1, data.clockSurf2, data.clockSurf1 ], # frames
                [[0,0],[0,0],[0,0],[0,0]], # frame offsets
                # wx, wy, vx, vy, adur, dir, del,  bx1,   by1,   bx2,   by2,  bType,  hflip, vflip,  coin
                [ 20,  17,  1, 0,    1,   2,   3,   20,  -999,    90,   999,      0,   False, False, False ]
            [   # juice
                [data.juiceSurf0, data.juiceSurf1 ], # frames
                [[0,0],[0,0]], # frame offsets  
                # wx, wy, vx, vy, adur, dir, del,  bx1,   by1,   bx2,   by2,  bType,   hflip, vflip,  coin
                [  9,  44,  0, 0,    1,   2,   1, -999,  -999,   999,   999,      0,   False, False, True ] 


  1. Each number in the list takes 32-bits ( 4 bytes) in MP. I could combine all separate flags to one “flags” field, and make consts for getting the flags values by ‘&’-operation, like SPRITE_FLAG_VFLIP = const(0x2). Consts do not consume any ram in MP.

  2. Maybe I try to reduce the tree depth in the list to see if that saves memory

  3. There are also some values quaranteed to be always under 256 (like frame offsets). I could pack 4 of those into one 32-bit value

  4. Ultimately, I could pack all values to the bytes literal (e.g. b'\xff\x1a\x01\xcc') as that is the only way I know how I can put data to rom (to be exact, string literals go to rom also). No ram used at all :slight_smile: Very, very cryptic, but very efficient also. Thought, I doubt I can pack object pointers, like data.juiceSurf0, to a bytes literal anyway.


You could:

  • Implement SD functionality in micropython so you can load rooms from the SD card
  • Try using tuples instead of lists in some cases
  • Find ways to use byte strings instead of numbered lists
  • Switch to C++


Probably later, when there are tens or hundreds :wink: of rooms, that have to be done. For now, I want to keep this game playable also without SD.

Right, as tuples are immutable one would think it goes to rom. I could check it but as I have not seen that in any MP documentation I suspect it is still in ram…

Could you elaborate this?

Maybe, when @Fmanga gets the IDE to the same level regarding of integrated tools :wink:


You could also split the game into two separate bins if you have already a lot of rooms. A PokittoCookie can be used to make sure that the second bin can only be played once all levels in the first part have been completed.



I was under the impression that most people have a micro SD for their Pokitto.

I was just thinking that they are probably cheaper/more lightweight than lists, but I don’t know for definite.

A quick glance at the micropython source code would imply that tuples are probably sizeof(size_t) bytes smaller than lists.
That’s not much, but it would soon add up.

If references can be generated at compile time then it’s possible that they could be stored in ROM, but if not then they’d have to be stored in RAM.

I would assume that:


Uses less memory than:

[60, 10, 0, 1, 1, 3, 2, -999, 0, 999,  14*8, 0, False, False, False]

Because ‘bytestrings’ should be using bytes.

But that also depends whether or not -999 and 999 are important.
I’m assuming from their values that they’re just supposed to represent a maximum and minimum, hence I translated them to \x80 (-128) and \x7F (127).

At the very least you might be able to pack the Falses into a bit vector if python has a ‘byte’ datatype.

What tools do you need other than ‘compile’ and ‘upload’?

I’m presuming from the fact you mentioned FManga you use the custom version of Code::Blocks rather than EmBitz or PlatformIO and an editor?

To me that seems like more hassle than requiring extra files on the SD card.

For one thing, to keep the .bins available for use on the go you’d need an SD card anyway,
at which point you may as well just make the game refer to files on the SD card in the first place since it would be less hassle for the end user (i.e. no need to flash .bins to change rooms).


Not necessarily, The SD game card is +5 euros if you buy a Pokitto. Thought, SD cards are so cheap that it is not a hard requirement to have that for a game.

Yes, that is what I already talked about in my previous post.

I was referencing to FemtoIDE discussed about in the Discord channel. An integrated pixel editor and sound importing would make life a lot easier. :slight_smile:


Check the video. Still need to do sound support, though.