Log In  
[ :: Read More :: ]

Understanding ENVIRONMENTS

Inherited from native LUA, _𝘦𝘯𝘷 (NOTE: type it in PUNY FONT, won't work otherwise! For External editors, write it in CAPS _ENV so it transfers as PUNY FONT inside PICO-8) can be a tricky feature to understand and use (abuse?). There's been some talking around this subject and as I am actually using it heavily in my coding style (very OOP I'm afraid...) I thought I could share some knowledge around it.

If we take the information directly from LUA's manual what we are told is the following:

As will be discussed in §3.2 and §3.3.3, any reference to a free name (that is, a name not bound to any declaration) var is syntactically translated to _ENV.var. Moreover, every chunk is compiled in the scope of an external local variable named _ENV (see §3.3.2), so _ENV itself is never a free name in a chunk.

Despite the existence of this external _ENV variable and the translation of free names, _ENV is a completely regular name. In particular, you can define new variables and parameters with that name. Each reference to a free name uses the _ENV that is visible at that point in the program, following the usual visibility rules of Lua (see §3.5).

Any table used as the value of _ENV is called an environment.

Cryptic right? Let's try to distil the information...

Let's start with understanding what's a free name. Any declared identifier that does not correspond to a given scope, f.e. GLOBAL variable definitions, API defined symbols (identifiers, functions, etc) and so on, is considered a free name OK... so this starts to get us somewhere! Any time we are using a global scope variable name or an API function call, internally LUA's interpreter is actually converting that to _𝘦𝘯𝘷.identifier. These tables used as values for _𝘦𝘯𝘷 are usually called ENVIRONMENTS.

Let's move into the next part: _𝘦𝘯𝘷 itself is just a local identifier in your current scope, and like any other identifier you can assign anything to it. In particular, you can overwrite the automatically created _𝘦𝘯𝘷 in your current scope, which will always be the GLOBAL ENVIRONMENT, and point it to any table, and from that point on, any free name will be looked for inside that table and not in the _𝘦𝘯𝘷 scope originally received .

Everytime a scope is defined in the LUA execution context, the GLOBAL ENVIRONMENT (on isolated scopes, like function scopes) or the currently active environment (inside language scope constructs) is injected as a local external variable _𝘦𝘯𝘷. That means every function scope, any language scope construct (do ... end, if ... end, etc)

Great! So that's all there is to know about _𝘦𝘯𝘷... but how can we use this to our benefit? Let's find out!


The core and simplest use-case for ENVIRONMENTS is mimicking WITH language constructs. It's quite typical that you have a table in your game holding all the information of the player... it's position, health level, sprite index, and many others probably. There's almost for sure some place in your code that handles the initialization of the player and that probably looks something similar to this:

-- many more here potentially...

Depending on how many times you need to access the player table you can actually consume a big number of tokens (1 per each access to player). When you have more than 3 (the general cost of redeclaring _𝘦𝘯𝘷) or 4 (the cost if you require a scope definition for it) you can benefit from not needing to repeat PLAYER for every access like this:


  local _𝘦𝘯𝘷=player

The use of the DO ... END block in there prevents that we override _𝘦𝘯𝘷 for all our code, and that this applies only to the lines we want it to apply.

This technique is particularly useful if you use an OOP approach where you pass around SELF as a self-reference to table methods and will reduce drastically the need to repeatedly use SELF everywhere:

   local _𝘦𝘯𝘷=self
   if not dead then
     if (lives==0) dead=true
     sp=2 -- dead sprite


You can even reduce the need for the override this way (thank you @thisismypassword for the contribution):

   if not dead then
     if (lives==0) dead=true
     sp=2 -- dead sprite

In a sense, this is very similar to WITH language constructs in other programming languages like Object Oriented BASIC or PASCAL. The benefit: reduce token count and char count. But don't just jump blindly into using this, get to the end of this post and understand the associated drawbacks!

Drawbacks of using ENVIRONMENTS in PICO-8

The main drawback for using an overriden ENVIRONMENT is loosing access to the GLOBAL ENVIRONMENT once we replace _𝘦𝘯𝘷 in a particular scope. When that happens, we stop seeing global variables and all API and base PICO-8 definitions, so we won't be able to call any function, use glyph symbols or access global vars. Luckily, METATABLES can help us here taking advantage of __INDEX metamethod.

METATABLES can be defined as a PROTOTYPE for other tables, and apart from defining elements to inherit in ohter tables, they can also define the BEHAVIOUR of these tables using METAMETHODS. Those are a quite advanced feature in LUA and I won't cover them in this post but for __INDEX that is going to be our solution for keeping our access to the global scope even if we have overriden our ENVIRONMENT (at a small performance cost...)

__INDEX METAMETHOD defines the behaviour of a table when we try to access an element that is not defined in it. Try this code to have a clear example of what it does:



  stop("accessing non existent key "..key.."\nin table "..tostr(tbl,true)) 


__INDEX can be defined as a function or as a TABLE that will be where the missing identifier will be searched for... and there's our solution, just redefine __INDEX as _𝘦𝘯𝘷 and our problem is solved:





If we apply this approach to our previous example we can do things like this:

   if btnp(⬅️) then 
     if (x>0) x-=1
   elseif btnp(➑️) then
     if (x<128-8*w) x+=1
   if not dead then
     if (lives==0) dead=true
     sp=2 -- dead sprite

That's a very basic OOP-like approach to have entities inside your games, that expose entity:update() and entity:draw() methods you can call in your game loop (like having a list of entities in a table and iterate it calling update() and draw() for each entity inside your _update() and _draw() functions).

__INDEX will also come to the rescue when working inside functions to prevent losing global access... as functions themselves don't have metamethods you can "trick" things if you set _𝘦𝘯𝘷 to a table that has __INDEX set and leverage the lookup to it:


function doit(_𝘦𝘯𝘷)

 ?"global b=>"..b



There is another effect that loosing access to the GLOBAL ENVIRONMENT generates, and this one is not fixed by __INDEX. Any new free name we create will be created inside the active ENVIRONMENT, so we won't be able to create any new GLOBAL variable from within the scopes affected by the override. If you need to be able to access the global space, one easy option is have a global variable pointing to the GLOBAL ENVIRONMENT in your code. Natively, LUA has _G environment available everywhere, but this one is not present in PICO-8, so you will need to create your own.

-- used by __index access

 newvar=25 -- this is created in mytable
 _g["initialized"]=true -- this is created in GLOBAL ENVIRONMENT


function _draw()
  -- outside table scopes (no __index access)
  local _g,_𝘦𝘯𝘷=_𝘦𝘯𝘷,mytable
  if _g.initialized and _g.btnp()>0 then

?tostr(initialized)..":"..mytable.newvar..", "..mytable.a..", "..mytable.b..", "..mytable.c

Other uses

There's many more uses you can find for using ENVIRONMENTS... shadowing and extending the GLOBAL ENVIRONMENT, some Strategy Pattern approach (f.e. having several tables with alternate strategies extending the global scope and switching between them...). Don't be afraid to experiment! The basics are all here, the limits are yours to find!

P#116282 2022-08-25 20:12 ( Edited 2023-06-05 05:42)

[ :: Read More :: ]

I leave here in the forums a copy of my entry to lowrezjam 2022, Aztec. Code ended up being really messy and there's a lot of things to fix/improve post-jam, but I thought it would be a nice addition to the BBS. It's multicart (has a loader companion) as I needed a bit of extra space in the main cartridge to fit everything.

Cart #aztec-1 | 2022-08-18 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Tonatiuh, the Sun God is angry! The High Priest Tonauac has decided to invoke the Tanatiuh Cualo, the ritual that will eat the Sun God and placate his wrath, but to achieve it he needs the Jewel skulls to be placed in their right places in Tenochtitlan's Templo Mayor.

While he prepares for the ritual, he sends you, the Aztec prince Guatemoc, into the temple to search for the sacred skulls and place them in their pedestals. Beware the traps and misteries that protect the sacred grounds of the Temple!

Code, SFX & Art by SlainteES
Music & SFx by: VavMusicMagic

Find this game on itch: https://slaintees.itch.io/aztec

Issues and bugs to fix:

  • Jumping whlie climbing continuously reattach you to the ladder if pressing a directional button
  • Some issues with "top of a ladder" state detection can cause you to drop from the top of a ladder
  • Some performance issues randomly due to suboptimal collision detection
  • If dying mid-air ocassionally the game does not make you land before actually dying (rare to happen)
  • Minor sync issues detecting activable objects (particularly Obsidian mirrors, that can be activated a bit earlier than they should)
  • Some more (yes... those again...) ladder issues can end up pushing you inside walls... 1 bugreport so far, but a nasty one... (Really... who decided ladders are cool?)

Fixed Issues:

  • Reset DX velocity to 0 before respawn, you could "move" while respawning because it was not set to 0
P#115799 2022-08-15 17:14 ( Edited 2022-08-18 09:05)

[ :: Read More :: ]

Cart #xor-13 | 2022-04-18 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

XOR Must Be Revealed

His many faces are scattered through 15 levels. Acquiring all the faces on any level will enhance your knowledge of Xor.

Beware Xor controls his world and doesn't give up his personality easily

Rediscover this classic from 1987, originally released by Astral Software under Logotron. This is still a very early WIP (first playable alpha actually), a few levels can be played but still missing levels, sound and probably some graphical polishing. The game will provide the original 15 levels and several extra ones once complete and ideally (if sticking to plan...) a level editor so you can create your own levels and puzzles.

Take control of Magus and Questor and beat all the levels in Xor's world by picking all his many faces and exiting through the door. Switch between Magus and Questor with X and see a level map with Z. You can quit a level if you get stuck from the map screen.

Experiment and unravel the strange rules that govern Xor's Domain!


This is an early Alpha Any feedback appreciated!

  • 15 levels implemented
  • Forcefields, Fish, Chicken, H-Bombs, V-Bombs, Fat Dolls, Switches and BMUS implemented, though levels with BMUS have not been tested that much... expect failures
  • ingame press πŸ…ΎοΈ to see the map
  • Switch shields with ❎
  • Quit level (f.e. when unsolvable...) holding ❎ in the map view
  • Some basic SFX


  • Teleporting does not center correctly on shield after the move : FIXED (for real this time I hope...)
  • Teleports not correctly reset between levels : FIXED
  • Explossives missbehaviour, they should not exploed when used to detonate others : FIXED
  • Moving explossives missbehaviour, failed to explode afer las update : FIXED


  • Big rewrite to save compressed space... hard limit there... got it down to 95%
  • Full SFX and Music
  • Level access logic (10->11, 12->13, 14->15)
  • End level letters for the Decoder
  • Password unblock for free level access
  • Extra levels (extra levels pack and Prospector in the mines of Xor extra levels) probably requires multicart
  • Level Editor
  • CARTDATA handling with best scores per level and controlling level access
  • Probably splitting into 2 carts if including editor...
  • A way to share new levels (probably stored in spr/map area on the second cart with serial)
P#109635 2022-04-03 20:04 ( Edited 2022-04-18 12:13)

[ :: Read More :: ]

I've been doing some experiments with LZW compress/decompress lately to retake some work on my Isometric engine so I could manage bigger tilesets (compress on string or memory, spr bank switching, etc). Reasonably happy on how this is working... it's a straight forward LZW with 256 dictionary size and 16 root symbols (a.k.a. 16 colour indexes). Works quite well for moderately big images but fares quite badly the moment it runs out of dictionary entries as dictionary is not optimized but generated dynamically both in compression and decompression and it potentially wastes entries with low re-usability or even foldable into later entries (f.e. long single colour runs that would do better on RLE)

Unsure if this will help anyone as there's already other compression solutions through the bbs, but here it goes in case you feel like it can be useful.

See the code for info on how to use it, the compression generates a small header (2 bytes for width/height) and the compressed string. The decompression can use pset/sset/mset or an internal pxset function that can write screen-format blocks at arbitrary memory addresses (lower performance than native funcs if you are writing to spr,map or screen though).

The cart shows 3 32x32 sprites (512b) displayed with SPR and compressed->decompressed with LZW equivs along compression ratios info.

Cart #lzw_experiment-0 | 2021-08-27 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#96541 2021-08-27 20:59 ( Edited 2021-08-27 21:02)

[ :: Read More :: ]

This is my entry for LOWREZJAM 2021, still incomplete and it will be mostly a POC of a complete game.

Cart #golden_star_jam-2 | 2021-08-20 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

The game is a tribute to the Natsume's SNES classic "Wild Guns" and is inspired by the gameplay in that game.

In "Golden Star Sheriff" as the new sheriff in Dodge City your duty is to chase and get rid of a big band of thieves that have taken over the city and it's sorrounding areas.

Current state of the game (JAM Version) is going to be a tweaked version of the full game as there's been not enough time to have multiple levels in place, so it will take place only in the first level, Dodge City streets, chasing for "Perro Loco", the lowest ranking bandit chief in the band. The game is tweaked so you can play several times the phase with increased odds rather than actually advancing phases...


Move with cursor keys, shoot with X and roll with Z or C while moving left or right. A gamepad is highly recommended for this game.

While pressing the fire button you will enter "free aim" mode and will hold your position while sending out a barriage of bullets!

When you find yourself in a tight spot, roll out of danger... bullets won't be able to catch you while rolling! But... be very cautions as rolling is a reflex action and you cannot control where you will be landing!

Note: The code just grew dirtier and messier the closer to the submission date... plenty of junk both in code and the cart (sprites, sound and such)... also it is my usual convoluted extreme OOP approach, you have been warned ;)


Moved Health icon from a red cross to a heart, complying to Red Cross mandates
Adjusted targetting speed, player bullet speed and power-ups bonuses to balance things up a bit
Implemented rolling coyote time to facilitate rolling/dodge activation

Fixed a bug that was not updating Z for the bandits and they ended up incorrectly sorted at drawing time, also changed the health power-up icon to comply to Red Cross restrictions prohibiting red crosses depiction for this kind of stuff, not it is a nice heart

P#95998 2021-08-14 15:36 ( Edited 2021-08-22 09:23)

[ :: Read More :: ]

So I decided to go for a platformer... my first in PICO8. Building it on top of my OOP game model (which maybe was not that good an idea...) so it is a code nightmare. Already at version 4 with a few discarded prototypes in the middle and for sure require some cleanup and refactoring... but kind of works and it would be great to start getting feedback.
Torches are an application of an old experiment, it's been a while I wanted to include them in some project (and for sure require fine tunning, as they are map cannot scroll as they are poke'd in place with additive blitting)

Still a very early WIP, no screen boundary control so if you fall off an edge you will fall forever :)

I am parking this for a while but I will come back to it very soon, I relly like where this is going

Cart #crazy_scribes_adventure-5 | 2021-07-31 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

move with ⬅️/➑️ ⬆️/⬇️
hold ⬇️ to crawl
jump with ❎
drop from a platform with ❎ when crawling
activate action menu (currently Psalm selection) with πŸ…ΎοΈ (just the visuals, non-functional)

Last changes:

  • Added Coyote time (maybe it's a bit too gracious...)
  • reduced the scribe's speed to make it more reasonable (now it is like he lives at 30FPS on 60FPS world)
  • var-heigt jumps
  • vertical speed adjusted when hitting the ceiling
  • debug cannot be toggled in anymore (still there, but key was repurposed)
  • added bats (not yet fully operational, they don't "attack"
P#95329 2021-07-27 07:09 ( Edited 2021-07-31 08:40)

[ :: Read More :: ]

Cart #fantasytactics-10 | 2020-08-20 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

So LOWREZJAM 2020 comes to an end... I finally submitted a playable project but with a lot of unfinished features. For a start there is no AI, In the remaining time I would not have been able to add a proper "smart" AI so I prefered to leave the game as 2p game only (or for those wanting to challenge themselves balttle yourself!). Sound is totally missing... I will be welcoming sfx and track contributions... that area is not my best. You can check it also in it's itch.io page

Future plans

At this resolution (mode 3, 64x64) and with the constraints in time for the JAM I "abandoned" that cart and started focusing on rewriting things on a 128x128 more organized cart (keeping all the good things in this one) so expect to keep hearing from Fantasy Tactics HD ;)

Game mechanics:

This is a simplified "tactics" game (Final Fantasy Tactics, Tactics Ogre and so many more...). There's two opposing sides, The Kingdom and The Undead and the objective is wipe out all the opposing forces. Every turn a unit can MOVE and perform an ACTION.


Activate a unit with ❎ and it's move area will be displayed in RED. That area is calculated based on the MOVE trait of the unit but considering units cannot go trhough other units, rocks or trees, that you cannot end your move in water (but you can jump across 1 tile of water) and that you cannot jump up more than a height difference of 2. Press ❎ again to select where you want to move or πŸ…ΎοΈ to cancel the action and release the unit.
Press ❎ on an empty tile to get the TURN MENU that helps you find units that have not yet moved and allows also to end the turn inmediately


After moving, the ACTION MENU will show up with the available actions. After selecting ATTACK or to cast a SPELL a TARGETTING AREA will be displayed in GREEN. Any potential target in the area is tracked and you can iterate through them with the cursor keys to pick the target you want. If the unit is carrying POTIONS and it has lost some HIT POINTS it can drink one of them to restore up to 3HP. SUPPORT spells automatically succeed and apply to the targetted unit. You can cancel your orders with πŸ…ΎοΈ.


ATTACK and OFFENSIVE spells initiate a combat roll. Combat is DICE based. The attacking and the defending units roll a number of dice and depending on the results the combat is resolved.

  • BASIC ATTACK: The roll is ATTACK vs DEFENSE traits. HIT symbol is SWORD, DEF symbol is SHIELD
  • SPELL ATTACK: The roll is "SPELL LEVEL" vs DEFENSE trait. HIT symbol depends on the spell, DEF symbol is SHIELD

The combat result is the defending unit looses as many HIT POINTS as the count of HIT minus DEF symbols

The Units

The Kingdom

  • [0x0]
    Archers: Fast moving, attack at a distance, carry a potion
  • [0x0]
    Halberdiers: Sturdy and with a long reach, carry a potion
  • [0x0]
    Axemen: Strong attack, carry a potion
  • [0x0]
    Priests: Weak attack, SUPPORT spell HEAL (+4HP)
  • [0x0]
    Wizards: Weak attack and defense, OFFENSIVE spell FIREBALL (LV 4, HIT symbol FIREBALL)

The Undead

  • [0x0]
    Lancers: Avg attack, low defense, long reach
  • [0x0]
    Swordmen: Avg attack and defense
  • [0x0]
    Reapers: Strong attack, low defense
  • [0x0]
    Necromancer: Low attack and defense, SUPPORT spell MEND (+4HP)
  • [0x0]
    Lych: Sturdy wraith with strong attack and defense, OFFENSIVE spell MIASMA (LV 4, HIT symbol SKULL)
P#80838 2020-08-16 11:17 ( Edited 2020-08-20 19:01)

[ :: Read More :: ]

I am working on a project for URL LOWREZJAM 2020 and I think it is time to present it here to get some comments maybe.

The cart is quite far from being playable but as there's been some expectation around it I've dediced to keep the wip cart here so ppl can comment and try it. Don't expect too much out of it, still very early

Updated with a bugfix... using potions broke unit release

Cart #fantasytactics-8 | 2020-08-17 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

It's going to be a "tactics" like game (tactics ogre, final fantasy tactics...). Still plenty of work to do and not sure if I will be able to put everything up for the Jam but for sure I am gonna keep working on this to a point it becomes a playable game. For now working on 2 carts... the game itself and the editor and probably I will release the editor/isometric renderer on it's own cart in case someone wants to experiment with it once it's kind of "complete"

Project is in MODE 3 as the jam is 64x64 and I am using some odd sizes around (my general sprite/object box is 10x16) even though I am adding full support to custom sprite sizes for the renderer itself.

At the current version it moves 20x20 tiles at 85-90% cpu at 60FPS but I think I can bring that down a bit... There's a few optimizations like truncate tile rendering when outside the clipping boundaries (some hidden blitting is already in place but need to push that a bit further)

Some images on how it has evolved to the current state:

Hope you like the idea, comments appreciated.

P#80443 2020-08-07 07:29 ( Edited 2020-08-17 16:29)

[ :: Read More :: ]

I've tried to upload several times a new version for a cart but seems something breaks that cart in particular... everything runs fine locally (windows machine) but the uploade version gives a syntax error in an odd place (inside one px9 generated string)

I saved the cart a few times but results are the same... any idea on the reason and a potential fix?

cart is

Cart #deflektor-17 | 2020-07-29 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

(and a few of the previous ones... 14+) In terms of changes against version 13 there's a few extra lines and some extra bin data in the map area. Not htting any of the limits (compressed at 98%,7253 tokens, 48153 chars)

P#80075 2020-07-29 07:26

[ :: Read More :: ]

Probably everyone has one of these... sharing in case you don't and need a quick wrapper around the mouse support.
The library implements an OOP like MOUSE object that supports 2 buttons and provides the following methods:

  • enable() : Enables mouse suport
  • disable() : Disables mouse support
  • pressed(<num>) : true/false if button number <num> is pressed in current frame
  • clicked(<num>) : true/false if button number <num> is pressed in current frame but was not in the previous
  • released(<num>) : true/false if button number <num> is not pressed but was in the previous frame
  • inside(minx,miny,maxx,maxy) : true/false if mouse is inside the defined rect boundaries

Would be quite easy to extend, mouse cursor can be set to any spritesheet index and would be easy to handle animated cursors, bigger cursors and such...

The demo cart shows how it behaves... pressing buttons changes background color, clicking and releasing draw some points on the screen (in green hues for btn 1, blue hues for btn 2.. brighter for click, darker for release)

Cart #mousedemo-0 | 2020-07-19 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#79605 2020-07-19 14:16

[ :: Read More :: ]

Took me a while to debug and identify why this was happening...

I was taking advantage of RESET to clear clipping and palette and as a side-effect RND() started to misbehave returning always the exact same number. I guess that RESET also sets a fixed srand seed and that's why the pseudo-randoms go stale... Probably worth documenting that RESET also does that or if this was unintentional fix it...

P#79357 2020-07-15 18:58

[ :: Read More :: ]

Will post here my experiments with particle effects...

Experiment 1: Fireworks... basic explosions

version 1: very basic approach

Cart #fireworkstest-0 | 2019-09-11 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

version 2: added gravity pull and callback update/draw for particles to operate multiple particle types (f.e. rocket and spark in the test)

Cart #fireworkstest-3 | 2019-09-13 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

Experiment 2: Additive blit particle fire

version 1:

Cart #particlefiretest-0 | 2019-09-14 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

version 2: Supporting sprite-based blendop palettes (for now only partial additive palette included), next goal blit optimization

Cart #particlefiretest-1 | 2019-09-14 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

version 3: PEEK/POKE BLIT without great results... per-pixel blendops still kill it, updated color and added some toying controls

Cart #particlefiretest-2 | 2019-09-15 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

P#67630 2019-09-13 19:17 ( Edited 2019-09-15 20:08)

[ :: Read More :: ]

While starting work on my little deflektor project I decided to have classic 7 segment led style numbers, my first iteration (the one currently in the game...) is based on sprites but I wanted something a bit more versatile. This is a basic line drawing small library to handle 7 segment led like any digit length display. It should be fairly easy to define a text set and draw 7 segment text desplays (just need a table with the segment mapping for every letter and put up a wrapping function that receives a text and not a number)

It supports background displaying of segments ("off" segments), color configuration and segment width configuration. The cart includes the library and a very basic demo on what it can do

I might be working on reducing token size a bit (library itself is around 300 tokens) and I think there's some salvageable space there, but don't count on it for now

Hope it helps someone out needing a 7 segment style display

Cart #led7segment-0 | 2019-08-14 | Code ▽ | Embed ▽ | No License

P#66679 2019-08-14 18:49

[ :: Read More :: ]

I've invested some time working on a demake for one of my favourite games from the 8-bit era, Deflektor (by Costa Panayi). Your goal is to guide a laser to the receiver on each of the levels, access to it is blocked until you destroy all pods on the level. Laser overloads when it hits mines or if the emitter gets feedback.

Cart #deflektor-18 | 2020-08-27 | Code ▽ | Embed ▽ | License: CC4-BY-NC-SA

HOW TO PLAY (you can go through this tutorial in the game itself)


  • 1 MORE LEVEL (now totalling 8)


  • 1 MORE LEVELS (now totalling 7)


  • 2 MORE LEVELS (now totalling 6)
  • ADDED safety pre-check so levels don't start on full-reflection or overload status


  • FIXED tutorial can be run multiple times


  • FIXED bug duplicating player cursor entity...
  • FIXEX tutorial scrambled if you play before running it


  • Massive rewrite (almost 80% of it is new...)
  • ADDED a few more levels
  • REMOVED editor mode... it is now it's own cart... was too big
  • ADDED Tutorial, Intro screen, proper game over and End Game sequence
  • FIXED a few nasty reflection bugs for the laser beam


  • FIXED bug with negative angle reflections not causing overload
  • ADDED some more basic FX
  • EDITOR MODE early version (reqs. mouse)
  • ADDED laser loading phase at start level/new live
  • ADDED end level scoring
  • WIP bgmusic (in the cart but not playing, unsure if it will stay)


  • FIXED bug in map loading that made optical fiber to crash (main reason to re-release)
  • ADDED some basic SFX
  • FIXED optical fiber pair coloring
  • some minor token salvaging and code clean-up


  • FIXED extra greediness in beam capture at mirror centers causing odd reflexions
  • FIXED color error on initial rise for the overload meter
  • MASSIVE spr sorting to allow for a reasonable leveldata format
  • Level is loaded from data (level info will live in 0x1000 to 0x1FFF unused shared map/spr space)
  • Crude leveldata persister as a prototype for leveleditor mode (unsure if editor will be a separate cart)


  • Optical fiber interaction
  • Laser grid scatter interaction
  • Level can be completed
  • Interaction with the receiver (connected status to end level)
  • Removed displaying laser point debugging
  • FIXED metal wall reflexion failing for some situations


  • Basic intro page
  • Beam generation and reflection
  • Player movement
  • Mirror interaction and auto-rotation
  • Beam interaction with mirrors, walls, mines and pods
  • Full HUD control
  • Crude live / energy / overload management
  • Scoring
  • Hardcoded level mapping


  • MUSIC: title music from the original and maybe a bg loop while playing
  • SOUNDS: laser connection sound
    • live lost sequence
    • level transition
    • extra detail in end game sequence
    • gremlins from the original game... unsure if I will be adding those
    • a few more levels... the plan is get around 20-30 levels in place
  • CODING: even if I refactored a lot, there's still quite some junk... could be I do some more
P#66564 2019-08-11 19:31 ( Edited 2020-08-27 16:45)

Follow Lexaloffle:          
Generated 2024-04-17 16:00:52 | 0.104s | Q:68