This is a demake of Adventure Creator, an old Atari 400/800 game. It's not my goal to perfectly imitate the game, just get enough of it in there to be fun and nostalgic to play.
The original game was by Spinnaker/Dale Disharoon on the Atari 400/800 released in 1984.
It is dedicated to the memory of Dale Disharoon who died in 2008. His game gave me and my sister Katy a lot of fond memories together. I hope this demake honors his memory and preserves his legacy in some form.
It's a bit of a strange and probably outdated game. It is best described as a roguelike with questionable mechanics. But it makes a fun toy, and probably interesting to small children and anyone who remembers the game.


I've got some code similar to this in my game for different types of entities.
knight.sm=cocreate( function () while(knight.alive) do w=knight.w h=knight.h s=knight.s if btn(0) then ... ... .. .. |
Basically inside the function I'm creating a coroutine from I just use the "knight" reference from global scope as a "this" reference, so to speak. But...now I want to create a different type of entity within a loop, using a similar approach to the above.
for m=1,10 do ::redo:: .... chest.sm=cocreate( function() while chest.alive==true do |
The problem I'm running into is that that "chest" variable inside the loop, only ever seems to refer to one chest (presumably the very first time the function() is processed by lua).
I want to create a coroutine for each chest entity, which has a reference to "that" chest for each one in the loop. I'm sure there's a way to do something like that but I'm fairly new to lua.

If I try to start pico8 with superuser it gives me this:
Failed to open audio: ALSA: Couldn't open audio device: Device or resource busy
but when I open it without sudo it does not give this error and sound works. I need to open pico8 in superuser because I want to access GPIO.
I've tried reflashing the PocketChip, but it didn't help.
Also available on itch.io, Indiexpo, and Kongregate.
Kelin's artwork:
https://www.pixiv.net/en/users/12757087/illustrations/Kelin
--
Hello, Everyone!!
This is my first game... in PICO-8.
The game is about Kelin who has a job to deliver a package to her client. However, rain comes and Kelin has to stay in an unused old house because the path to cave is blocked. She is also hungry. Help Kelin find food and something to rid the cave block in the old house with adventure gameplay mechanic!










Just a simple little 2D-rotation example.
The function takes a 2D position (X,Y) and rotates it by ANGLE. CX,CY represents the center/pivot point.
The lines of code in the middle are the rotation matrix:
local rotx=cosa*x-sina*y local roty=sina*x+cosa*y |
This rotates a point around the origin. Before and after doing so, we offset our position by our center coordinate - this lets us rotate around any arbitrary pivot point.
For bonus points: When you're rotating lots of objects by the same angle (like a camera rotating, or a complex prop rotating), you can re-use your SINA and COSA values.



You know that feeling when you only have 8x8 pixels to draw something, and it takes an hour to get it right?
Let's make that feeling worse by posting our sprite in this thread, without context, and then despair when none of the other users can figure out what it is.
I'll shamelessly start it off with this thing...
And no, it's not pikachu... :(




Hey, first of all, excuse my poor photoshopping (Using Krita on Linux, terrible tool. No idea why I'm not using Gimp).
But anyways... What if, while in the code editor, you could hold down a key (maybe ALT?) and it would turn all tokens into coloured blobs. So you could instantly see where and how most of them are used up.
Something like this:

Additionally, maybe instead of being randomly coloured, certain tokens (such as keywords, variable names, separators, etc...) could have a dedicated colour to them.
Now, disclaimer... I don't actually know how the tokens work exactly, I just coloured in the tokens as I felt.
The token blocks themselves, should also look more like this, but in pico8 colour palette:

but I think the image gets the point across even with my terrible photoshopping.



arrow:move
z:gather number from around.
This is 1st game I made.
I learned how difficult it is to make the game fun.
Hey!
I want to find a way to run my code from other editors such as vim or atom. I havent found a solution to this yet.
I know I can run a cartridge from terminal by typing "pico8 -run mycart.p8" for example. The problem with this is that it boots up the whole console before booting the game.
Do anyone know a way to just boot the game in an already running pico-session? That would be awesome.
EDIT: I just got the idea. If you run load("mycart.p8") in your code the cart gets reloaded and run with the new code. Is it possible to use the gpio to send a command that triggers load("mycart.p8") within the code? For a computer that does not have real a gpio-header I guessing you would have to simulate gpio?



So this started on this thread by weeble but I ended up rather... running away with the code idea and overhauling it drastically.
While I've resumed working w/ Weeble on this in his original thread, I'm keeping this thread updated as well as I make changes.
V2.0 details
[hidden]
Also with V2.1 I've moved the various data tables needed outside of the sprite sheet, copied up from page 3 which is the one tiles are rendered into in-game, so all of the first two sprite pages are available for graphics as is the first two rows and change of page #2.
With V2.2 I've added the initial code for clipping regions, to avoid redrawing the entire screen every frame. This is a MASSIVE speedup, pushing CPU usage outside of screen-transition periods down to 5% CPU at 60fps in most cases. I'm working on a '16x16 bitfield' based solution that will instead re-render the screen in regions as small as 8x8 pixels per frame, allowing for multiple moving objects that way.
I've also cut the CPU used for baking the tile graphics in half from ~2.5 frames at 60fps to ~1.3 frames at 60fps with this release, while the token count and overall codesize has actually gone down.
Finally, the game picks a random room in the entire 16x16 grid to start you in, so you get different areas of the maze each time you restart the cart. So hit Ctrl+R a few times to see all the various biomes.
As a caveat I have removed the 'biome viewer' in this version for now, as I'm redesigning the interface to be a general-purpose editor for the maze itself, including setting biomes on the maze and editing individual biomes directly.
As of V2.3 I've integrated newer 'cavern generation' code that weeble came up with, to avoid blocking paths and allowing for much denser 'crazyness' to occur, as well as my 'context sensitive dithering' code which makes the transition tiles look much more alive and distinct now.
I'm working on some additional cavern smoothing functions to retain the 'crowded' feel without having quite so many dead side-passages at times, and adding a caching layer for the more expensive parts of the room-generation, to allow much of it to be generated in the background as you walk around a room to get to the next exit.
V2.4 adds a fourth unique room design for some biomes, one with much deeper, winding passages and a crowded feel.
V2.5 adds a MASSIVE speedup to the bake_tiles function by calculating the 'masked' tiles a full 32-bit row of 8 pixels at a time. So one fourth as many calculations in exchange for a bit of bit-shifting to load/save the values, but overall it's a HUGE win, including on token-count! Only 2814 tokens current! :D As a note, the masking colors are now 2/3, 4, 5, and 6/7, with values 0, 1, and all those above 7 MUST be avoided in the masks now.
As an interim release, V2.5-caching includes a further sped up tile-rendering codebase which is also moving some data from peek/poke memory to lua memory, taking up roughly 128k of the 1MB available with pre-rendering graphics tiles organized for faster rendering. This transition is freeing up enough speed that I am preparing to remove the 'biome' approach and allow direct per-maze-room assignment of walls, floors, and borders (including palettes) to simplify world painting. The trade-off is worlds will take ~768 bytes of sprite/map memory to store instead of ~512 bytes as they are now.



This is my entry for my first gamejam ever, ludum dare 38:
https://ldjam.com/events/ludum-dare/38/momma-zilla
Mother nature has sent Momma ZILLA and her kiddos to punish humanity.
Collect baby ZILLAS for help!
When a building is destroyed, you can eat the humans for health
Z is to fire
X is blink
Dodge missiles!
Avoid fire!
Buildings hinder your path!
Crush vehicles!
2 minutes to cause as much destruction as possible. Get the high score!
increment_second = function(this) this.second = (this.second + 1) % 60 if this.second == 0 then this.minute = (this.minute + 1) % 60 if this.minute == 0 then this.hour = (this.hour + 1) % 24 if this.hour == 0 then this.day = this.day + 1 if this.day > days_in_a_month[this.month] or this.day > 29 and this.month == 2 and this.year % 4 == 0 then this.day = 1 this.month = (this.month % 12) + 1 if this.month == 1 then this.year += 1 end end end end end end |
I'm creating a tamagotchi kit, and since os.clock is no longer part of the API, I figured it'd be okay if the user would have to type his/her current time at every launch.
Currently at 1500 tokens, with a datetime input screen, an "are you sure this is correct?" screen, a class for stats/resources (ie. health, hunger, random_event_countdown, etc...), a class for date calculations, and plenty of overflow control for both classes.
Nearly done, but before I submit it, I'd like to inquire if there's a possible improvement to this eye sore of a function?




Hi all,
In case anyone is interested...
[box=c2c3c7]AdventureJam returns for its third year of game development pandemonium as anyone with a computer, an idea, and an internet connection is invited to create an adventure game over the course of 14 days!
Whether you love point & click adventure, text adventure or exploring 3D environments, we want you to jump in and create a game that embodies the spirit of adventure, whatever that means for you! Adventure games have been around nearly as long as computers, and what began with words on a black screen has evolved into an amazing spectrum of gaming experiences. Let's celebrate the awesome legacy this genre has created with 14 days of pixels, puzzles, parody and pathos!
AdventureJam will begin May 5th at 9:00 PM EST, and end precisely 14 days later on May 19th 9:00 PM EST. The voting process will follow immediately after the jam concludes, and will last until June 16th at 9:00 PM EST.
So [b]GET LAMP... GET SWORD... and GET READY... for AdventureJam!