Poizone

Notes

• Code Paolo Baerlocher
• Graphics[Marc Andreoli
• GitHub - PaoloBaerlocher/Archimedes: Sources of my Acorn Archimedes games
• POIZONE by Poizone

Description

1-2 Players have to remove certain blocks to reach the next grid-based level within a given time.

There are blocks that don’t count towards the winning condition, are decorative, and can be fixed or movable. Different blocks counting towards the winning condition have different rules on how they can be removed. Failing to adhere to a specific block’s removal rule leads to being stunned and loosing time. Decorative blocks can often aid in removing blocks. A special type of movable decorative block can be assembled to a 2x2 layout and gives extra score if done so. Other special types of decorative blocks can explode, stunning the player. NPCs occupy the levels and touching them also stuns the players. The NPCs can be stunned in return by activating the electric fence that frames each level. Only NPCs also touching the fence are affected.

Play Analysis

I attempted an analyses before reading Parler le jeu vidéo and concentrated more on my understanding of ludemes as rules or mechanics. Hansen proposes a model that see’s ludemes as semiotic units (see ). Poizonender Poizone.

First Level

• Ludemes: Avatar, Blocks, Monsters, Time, Goal Percentage, Teleportation Tile
• Sequences: Experimenting, Exploring, Pushing, Removing, Solving, Fighting

• The first sequence centers our avatar Pengo on the screen, leaving a bit of space free and than displays three different kinds of blocks. The free space enables the exploration of simply moving around.
• The blocks all have the same size, but differ visually.

• Moving up to a block stops Pengo from continuing to walk. Next to walking, there is only one more action we can do, which is to push.
• Pushing the block, destroys it. Meanwhile, the goal stat in the HUD increased. It seems to be desireable to remove some of the blocks to reach an objective.
• Pushing other blocks, the goal stat doesn’t increase. Thus, we start to differenciate between the blocks in terms of what kind of function that they have.

• We move up to the already known green block and push it, but this time we get knocked out as well. It seems that this blocks rule is to be pushed only when it can move afterwards.
• While being knocked out, we can’t move, while the time stat in the HUD is reducing.

• The same seems true for the brown block, which knocks us out when pushed against an obstacle.
• Meanwhile we also see a green blob appearing, which doesn’t look to friendly. But it’s moving around randomly and doesn’t pose a direct threat.

• Different to the green block, the brown one can be pushed against an obstacle, but only from the top (and bottom as we learn later).

• Pushing a block into the blob makes the blob disappear. Another thing learned.
• Walking into the blob on the other hand knocks us out again.

• Pushing the blue electric fence border does activate it, but no iminent change is observable.
• Waking onto a blue animated tile we find along the way transports us to another place in the level.

• Here we find our first situation which is a bit more complex, and needs some thinking in order to harmonize the different rules of the blocks we learned so far. We can’t reach the green block, and we can’t push the brown block from the side. The grey block doesn’t seem destroyable, when we push it. We could push the lower grey block away, but removing the green block against an obstacle would knock us out.
• That leaves us with removing the brown blocks from the top first, freeing the green block from being locked into the grey ones, then removing it.

• After having solved this situation, the goal stat reached 92% and became green.

• Shortly after, we removed the last block and got a 100% score, making us win this level.

Second Level

• After a brief animation, in which we escape a group of blobs, we arrive at the second level. It looks different and offers new blocks.
• Given their occurence, those with red framed in grey must be decorative/functional blocks. Removing one of them also doesn’t raise the goal stat.
• But removing the yellow nuclear one does. It can be pushed when leaning against an obstacle.
• Already on the first screen we see a complex situation of blocks, making us aware that the stakes are probably already higher.

• After a few seconds we learn that the red blocks need to be pushed when leaning against and obstacle, otherwise we will be knocked out. Kind of the inverse of the green blocks from the last level.
• Instead of blobs, there are now robots driving around and knocking us out.
• But, we meet one of the blocks from last level, the brown one.

• The robots seem to be a bit faster and erradic compared ot the blobs.
• There is also a red block completely free standing, which would mean that we get knocked out if we push it from any direction. This means we need to push another block so it slides next to red one before we can remove it.

• Meanwhile we figure out, that activating the fence while a monster touches it, knocks it out.

• That didn’t help tho, because time run out and we didn’t clean enough blocks out, making us loose this level.

Sequences

Mainsequence

A major sequence (level) always includes all bellow subsequences, except experimenting. The blocks rules can be learned in the tutorial. This sequence is in relation to the actions of the players, as well as the levels goal percentage and time.

Subsequences

• Experimenting
  • Learning the blocks’ rules by moving, pushing, removing
• Exploring
  • Exploring the level by moving around, avoiding monsters, teleportation
• Pushing
  • Pushing around blocks to remove them or solve a complex situation
  • Can, but doesn’t have to, remove a block
• Removing
  • Depends on pushing
  • Removing blocks in order to win a level by pushing them according to their rules
• Solving
  • Solving a complex situation of blocks that can’t be remove right away, because of their rules
  • Depends on pushing and removing
• Monsters
  • Trying to avoid encounters with monsters by not getting to close, walking around them, pushing blocks onto them, taking the blue power up

Pushing and Removing

flowchart LR

    A(Avatar) -->|pushes| B(Block)
    B --> C{Rules}
    C --> X{Success}
    X --> |Destroyed| B
    X --> |Moved elsewhere| B
    C --> Y{Fail}
    Y -->|Knocked out| A

Mechanics and Rules

a. Move

1. along x and y-axis by pressing move-input if field in walking-direction is free
2. teleport by walking on teleport field and reappearing at other position in level

b. Remove Blocks

1. push block according to its rules by pressing the push-input next to it while facing it
2. use other decorative or removable blocks if rules imply so
3. or if the blocks-layout doesn’t allow adhering to a block’s rules

c. Push blocks

1. push secondary blocks to create solvable situation
2. to hit a NPC
3. don’t hit another player

d. Avoid NPCs (Monsters)

1. they move
2. avoid them by moving around them
3. push blocks into them to remove them
4. stun them by activating fence

e. Win/Loose

1. win by removing all removable blocks within time
2. or remove a certain amount (90%) of blocks before countdown ends
3. otherwise loose

The rules regarding the blocks are partially explained on the new Itch game page, before the level in the original game, or as a help manual in the ported version.

Examples

Fig. 1: Start of the first level. Only a small portion of the whole level is shown. In this one, the green chemical block and the copper CFC block need to be removed.

b. Remove Blocks

1. push block according to its rules by pressing push-input next to it

• e.g. from the left and right, or from the top or bottom
• e.g. must or must not be next to another specific block

The green and copper blocks in Fig. 1 adhere to the following rules.

• Green blocks have to move at least one field before hitting another solid object to be removed. If they already lean against a solid object during pushing results in being stunned.
• Copper blocks have to already lean against another solid object and can only be removed by pushing them from the top or bottom. If they move after being pushed, they will not be removed. Pushing them from the wrong side results in being stunned.

2. use other decorative or removable blocks if rules imply so

Fig. 2: Player next to a pushable block. Green NPC-goos swarm around. Ice-blocks are decorative and movable. The blue flag is purely decorative.

Pushing the copper block from this side would result in being stunned. The block right under it is decorative and movable. If the player had moved that block, either accidentally or to hit a NPC, the copper block could not be removed right away. It would move until it hits a solid object, and then could be removed.

3. or if the blocks-layout doesn’t allow adhering to a block’s rules

Fig. 3: First example of a complex layout of blocks whose rules interact to make gameplay more difficult. Grey stones are decorative and movable.

To remove the green block, the grey blocks on the left and right side need to be pushed away. In order to so, first, the copper blocks need to be removed. There is the possibility to make mistakes, since the copper blocks are only correctly removable when pushed from the top or bottom. Several such complex layouts are installed during the game, sometimes necessitating that some other removable or decorative blocks are pushed into the correct position (c. Push blocks).

Annotated Code Analysis

• ARM Instruction set quick finder
• Notes about the porting process to PC - POIZONE by Poizone
• Archimedes/Poizone at main · PaoloBaerlocher/Archimedes · GitHub

ARM2 Assembly

• 8091 lines of code
• one single file
• no additional frameworks except for a module that allows decompressing lzw files
• labels, one of the most important organisational units, are often named eradic; it feels at times, that i practically see the conceptualization/development process unfold
• no whitespace for organisation
• comments are often also decorative, like having a frame
• comments often have to state what is what, since registers or addresses can hold different things
• comments also say where one is in the program or what is about to happen
• how are graphics stored? map data is like in special data files

Input Flow

• .Player1flag holds the player’s input along %xxxFUDLR (Function, Up, Down, Left, Right). The holder is set in various places, according to the input method (joystick, keyboard)
• Line 4411 loads Player1flag into register R1
  • LDRB R1,Player1flag
• The code proceeds to check the input and reacts accordingly
• Line 4413 for example compares the flag with with the pattern for the input for left and branches of to .noLeft if not.
  • TST R1,#%00010:CMPEQ R13,#0:BNE noleft ; LEFT ;
• On Line 4430, if .Player1flag is set for left, the code also checks if Space was pressed, the input for doing an action.
  • CMP R14,#0:TSTEQ R1,#%10000:BNE FinishReadKey ; SPACE ; ;
  • If that is the case, the code continues, or branches of to .FinishReadKey.
  • Several things can happen: block breaks, electric fence is activated, or the block is pushed.
• This routine is copied and slightly adjusted for the four directions Pengo can move.
• I didn’t figure out yet, how a block’s rule come into play at this point

Game Loop

• Initiated at the label .Loooop at line 74, which then branches of into .MainGameand .MainGame1

Python

• All the python files that make up the game have 3233 lines of code together.
• pygame does some of the heavy lifting and covers basic functionality, such as grabbing player input or drawing on screen
• proper oo programming, different files to handle the larger concepts
• whitespace to denote logic hierarchies, because python
• comments are rather short but well explenatory
• a lot of functionality in code is bound to the penguin class, which I didn’t expect. I guessed blocks are also a class with their own functions and attributes. monsters are, and the interaction of the penguin and monster class seems adequat.
• sprite sheets, map data is like in special data files

Input Flow

• Input control is provided by pygame via pygame.joystick.Joystick(0) which can be a joystick or d-pad (or simulated d-pad)
• Directions are checked from lines 809-835.
• Inputs, like directions or specific keys, are managed in an instance of the Key class from constants.py

Game Loop

• Initiated through while running on line 776, which checks then all the states the game is in and acts accordingly in one single loop

Ludemes

Ludeme	assembly	python
Avatar	254 coordinates vars 691 dessine un sprite sous controle du Controller 1350 Sprite Controller (interface pour l’utilisateur) (max. 20 sprites)	poizone.py 1175 draw pengo
moving	272 moving and pushing vars 652 control collision 4353 input flags 4411 reading input keys	poizone.py 799 reading direction input
Transporter	6060 transporter	globals.py 151 teleporters are initiated via land data
teleporting	6155 teleportation	penguin.py 390 check if on teleporter
Block(s)	885 DESSINE TOUT L’ECRAN DE JEU (BACKGROUND+BLOCKS) 6238 block rules	constants.py 115 class block types penguin.py 102 block rules poizone.py 623 draw background and blocks
pushing	272 moving and pushing vars 4430 reading push and check if pushable/destroyable or if fence > .NewCrash 4905 initiate destroying block > .ArbitreCrash	poizone.py 842 reading other inputs penguin.py 61 push block