_Update() Jam is a little launchpad cart that you can use to come up with new game ideas... the cart displays the "rules" for the jam, and also contains all the source code and sprites for you to start making your own jam entry.
If you're an advanced designer or pico-head it can be fun to follow some of the strict rendering rules, but sometimes its enough to have a bunch of funny little sprites to look at to guide your thought process.
Along with some friends we all created original games over the holiday break based on this jam, we'll be uploading those separately, as well as the launcher (also made with this cart's restrictions!) so that everything works in Splore mode.
NOTE: Had multiple questions about if using the full map space counts as messing with the sprite table, and in MY opinion, it does not, as long as you're doing it through either data compressors or the map tab <3
_Update() Jam games!
Stairway to Kevin - https://www.lexaloffle.com/bbs/?tid=154769
A Jackpot of Skulls - https://www.lexaloffle.com/bbs/?pid=jackpot
Bird Watcher - https://www.lexaloffle.com/bbs/?tid=154589
Frogwell - https://www.lexaloffle.com/bbs/?pid=182701#p
1 question, are we allowed to use the bottom half (pages 2 and 3) of the spritesheet for map-data still? or is it entirely banned outright?
ahahaha i forgot to specify that - yea i personally do not count the tilemap space intruding on pages 2 and 3 as "manipulating the sprite area" and i think its fair game to do so (and in fact all 3 games in Vol. 1 do exactly this)
great question! i'll also update the top post with that note
Oh that is ALSO a great question
IMO yes, but, be advised that the map and tile rendering is restrictive enough that it might limit the normal utility of those
Let's jailbreak :
Simplest is to use print "\^1" witch does the same thing as flip() without calling flip() directly. Let's say it's forbidden and let's study _draw() for vulnerabilities :
function _draw()
cls(0)
map()
for i=1,min(16,#gfx) do
spr(gfx[i][1],gfx[i][2],gfx[i][3])
end
print(txt,txt_x,txt_y)
end |
System is meant to reduce our drawing ability. We win by either finding a way to arbitrarily draw to the screen while following the rules, or gain ArbitraryCodeExecution ACE from _draw() while following the rules.
function _draw() Can't replace the function (against the rules)
cls(0) is there to delete what we may have drawn to the screen in _update().
palt(0,true), camera(...) and clip(..) don't affect cls(), but we can trick the system to clear elsewhere :
in _update, draw to the screen, then set the screen to high memory with poke, and set txt with \^@ to set the screen address back to normal. The result is _draw becomes a NOP. (WIN)
map()
We can trick the map call to display a screen in high memory :
as top left 16x16 tiles of the map, set the tile number in order in order (0 to 255 row by row)
in update, set the screen as high memory and draw to it, then set it back to normal and set the sprite source to high memory. We haven't touched the sprites in low memory nor called pset(), so it's a win, if a bit of a stretch.
for i=1,min(16,#gfx) do
This line does proper control of the gfx external input and limits the max number of sprites to 16.
The rules don't explicitly say we can't replace the min function to a custom one with ACE inside, but it's a big stretch. We could use the top left pixel of sprites to draw, but with 16 sprites, we can get control of a 4x4 corner of the screen, not really a win...
spr(gfx[i][1],gfx[i][2],gfx[i][3])
Short of replacing spr, we can't really do anything with the call, but the parameters gfx[i][1] are pure gold : gfx[i] is safe (i is between 1 and #gfx), but gfx[i][1] is not : it can be an empty array with an error handler calling the ACE code. This is the ultimate WIN.
print(txt,txt_x,txt_y)
txt can be set to poke the screen.
Another possibility is to use cursor and color changes to draw arbitrarily, one cursor change and one letter per screen pixel.
I guess Adam's proposition is to give us a set of Lego bricks for us to make a world. Of course you could melt them to go beyond those strict limitations, but isn't that missing the point? Making any Doom clone here is rather an uninteresting cheat imo. I was myself about to ask him if poking sprites memory was OK, but didn't as I suppose the obvious answer is: no, stick to those given sprites. On the other hand I was wondering about palette changes and as it's used on example carts, that looks like "sure, go ahead". Anyway, really nice and inspiring jam idea there, wish it was more like a real jam à la itch.io but that won't stop me from trying to figure somethg to make.
BTW Adam on your itch cart, the "about _update() jam" goes to "loading" then nowhere, unless you press an arrow which then launches a random game.
fwiw i don't mind the mental exercise of "what kinds of things could you do by the LETTER instead of the spirt" !! esp if it leads to new design ideas... leveraging a print message to trigger a flip is dope and sneaky (if the end result is it doesn't push you to consider new design ideas then its also moot otherwise ofc !!)
also ElGregos you are correct, there's something up with that itch upload, probably some last minute patch thing. i'll update after work, thanks for the heads up !!
UPDATE: itch upload is fixed, thanks again!
aaaah this is such a cool idea!
i wanna make something for this!
@ElGregos, I really like your Lego bricks analogy. Too much freedom is often an obstacle to creativity, and being given a small fixed set of bricks to create from is often liberating, as the limited set of options helps avoid choice paralysis.
This is already the pico-8 philosophy, and Adam's jam cart is an extra step in the same direction.
I still think fighting against the (arbitrary or physical) limitations is a potential vector for creativity, and one that is historically very successful on most systems. Even on pico-8, fighting the limitations lead to unbelievable technical carts like nebulus or poom. Following the limitations is a perfectly valid alternate path that lead to great cozy gems that fit format like baloon, frog king or celeste. Small grid tile puzzle games that comfortably fit in the pico-8 box (sokoban and the like) but are great for their puzzle content and use pico-8 as a dev tool big enough for the genre is also perfectly valid. (Adam Atomic made plenty of those, and they are the pico-8 games I play the most)
I tried the "fight the limitations" approach to see what could come out it, and shared the results because I found them technically interesting and surprising. What I learned is that sandboxing and sanitizing external input is extra tricky in LUA, when even an array access can silently turn into a function call. Not what I was after, so I agree it's a miss, but I missed the objective of finding game ideas, the chosen path had potential even if that lead nowhere.
Controlling a 4x4 pixel screen was too little, and full control was too much, but failure is part of the process and often teaches more than success, so I felt I failed successfully and that was worth sharing.
okay i made one :)
i posted on the main page already but love how that turned out!!
started a list of update jam games up top!
@Adam Atomic
I've started working on one.
Here's a sneak peek
It's a puzzle game where you swap adjacent tiles but not colors, and have to make everything look the correct color while never having more than two colors per tile type. (I'm working on the levels and polish ATM)
My question is about the tiles : if I make black opaque, the border to the right and the bottom of the top swapping tile hides a part of the tile under it. If I make black transparent, the black parts of the tile over become holes and you can see through them.
For better visuals, I'd need to change the sprites to make a distinction between black opaque and black transparent (programmatically or manually). It's definitely against the letter of the rules, but would that be against the spirit ?
[Please log in to post a comment]
