Hey @zep,
Do I remember right? I think when I asked for state-changing funcs like color() or clip() to return the previous state, I'm pretty sure poke() (and its 2/4 friends) was one of them. Seems like it always returns 0 now.
(Also, if it's meant to return the previous state, remember to return a tuple of old values if you're given a tuple of new values.)
Thanks to some great and kind advices, I could fix the problem.
And then I added many things prepared. I'm going to work more, so this is for-now form.
← and → ... Move left or right
↑........... Enter the door (Move to next stage)
↓........... Activate switch
〇........... Jump(on the ground), Air dash(in the air)
×........... Nothing for now.
*The title "Kagiventure" comes from "鍵(Kagi, key in Japanese)" and "adventure".
as of 0.2.2, all menuitems now have their functions called when left/right are pushed while the menuitem is selected?? It took me an embarrassingly long time to realize this... (probably due largely to a bug where the menu doesn't actually close but the items are still triggered, even if the function does not return true which helped to obscure this behavior)
@zep it seems like this change to menuitem's functionality was intended to be extra functionality and only improve the capabilities of menuitems, but the problem is that the new functionality is always activated, even it's not needed or wanted, so if the user accidentally presses left or right (which is very easy to do with a joystick or with the mobile D-pad UI, and this is how I noticed it!) the menuitem's function gets triggered, and the only way to prevent that (i.e. in order to maintain the old behavior where left/right do not trigger the function) is to use up more tokens in the menuitem's function to check which button was pressed!
Today I did something I haven't done in 20 years: I finished making a game.
Huge huge credit to SpaceCat, whose course I followed.
It's a Flappy Bird clone where you play as a bubble trying to avoid cacti.
I am still very very much a novice and I'm sure the code has some issues but WOW was this a fun experience.
[edit: fixed a collision issue]
I'm having trouble with a for loop. The code runs but it doesn't work as desired. Here's the code:
function pikmin_create(n) g = 1 for group in all(pikmin.sprite) do for i = 1,n do if g == 1 then add(pikmin.sprite[group],6) elseif g == 2 then add(pikmin.sprite[group],8) elseif g == 3 then add(pikmin.sprite[group],10) end end g+=1 end end |
pikmin.sprite is initalized in function _init() as follows:
pikmin = { sprite = {{},{},{}} } |
This should assign every group/subtable in pikmin.sprite a different sprite. However the assignment doesn't work (as the default 0 sprite gets printed).
What am I doing wrong?
This is the first game that I've made.
It's a simple puzzle game where you explore your surroundings and use context clues to decode the language.
Controls:
Arrow keys to move.
Hold Z to look at an object.
Hold X to open your inventory.
A piece of paper and a pencil would help.
You 'win' when you can figure out the context of the end of the game.
Big thanks to:
Dylan Bennett and his Pico-8 Adventure game tutorial: https://www.youtube.com/watch?v=J1wvvbVQ5zo
Gruber for the music tutorials: https://www.youtube.com/playlist?list=PLur95ujyAigsqZR1aNTrVGAvXD7EqywdS
Gustavo Vituri for some sprites: https://gvituri.itch.io/tiny-ranch
If you find any problems, please let me know. As I said: this is my first project.
[64x8] | |
A complete implementation of the CHIP-8 Architecture on PICO-8.
The CHIP-8 architecture was designed to allow making simple video games portably, in the mid-1970s, and has since seen implementations on just about every platform known to man.
Options available from the pause menu:
- Buttons fully rebindable to match standard PICO-8 controls, but can also be changed to Devkit mode to operate it with standard keyboard controls (& mouse).
tiles
Arrowkeys to move.
about
If this code looks like it was written by a first time programmer, that's because it is.
This simple, probably very inefficiently written game, wil hopefully continue to evolve a bit as i learn the basics.
So far tutorials by BitesNbits and Lazy Devs have been very helpfull.
stuff added since last time
- the code has been cleaned up a bit
- a better looking end and start screen
- The tile grid is randomized
- It loops and can keep going forever
might get added in the future
- better visual/sound design
- and a generally more fun and balanced experience (it might be too difficult now)
- a better not as lazy title
and yes I am also making a shmup
using 0.2.5 e
Game running fine - found through splore, runs fine in editor
Game page: https://www.lexaloffle.com/bbs/?tid=34952
-Produces <EOF> error when running on web
" error line 23 (tab 2)
camera(scr.x, scr.y)
<'eof'> expected near 'end' "
I have read similar post where web exports won't run
games made in previous version of the editor, however
I have attempted to export again from latest version
and experience the same problem running on the BBS
(preview), so feel the bug must be rudimentary/code based.
Essentially the error stems from calling a function within a function
(not within an if or else statement), however when I remove
the above function call, the same error is produced by the previous line
(within the scope of an if, else statement) [[function camera_pos()]]
Could this be as simple as 'cascading' unclosed function error?
Any help much appreciated as I would very much like to continue this
project (and obviously avoid similar bugs moving forward)
Thanks
mildly interesting: when drawing a perfectly vertical line (line(1,1,1,h)
) or perfectly horizontal line (line(1,1,w,1)
), it used to be cheaper (in cpu cycles) to use rect
or rectfill
instead. but not anymore! I'm testing this on 0.2.5g; I'm not sure when this changed.
tl;dr: line and rectfill cost the same for orthogonal lines (rect is more expensive for vertical lines only)
simple test:
full test:
[hidden]
function one(fn,opts) local fmt=function(n) -- leftpad a number to 2 columns return n<9.9 and " "..n or n end local dat=prof_one(fn,opts) printh(fmt(dat.lua) .."+" ..fmt(dat.sys) .."=" ..fmt(dat.total) .." (lua+sys)") end function hline(x) line(0,0,x,0,2) end function hrect(x) rect(0,0,x,0,2) end function hrfil(x) rectfill(0,0,x,0,2) end function vline(x) line(0,0,0,x,2) end function vrect(x) rect(0,0,0,x,2) end function vrfil(x) rectfill(0,0,0,x,2) end printh"--" for i=0,127 do printh(i..": ") one(hline,{locals={i}}) one(hrect,{locals={i}}) one(hrfil,{locals={i}}) one(vline,{locals={i}}) one(vrect,{locals={i}}) one(vrfil,{locals={i}}) end --[[ ... 14: 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 15: 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 16: 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 4=13 (lua+sys) 9+ 2=11 (lua+sys) 17: 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 2=11 (lua+sys) 9+ 4=13 (lua+sys) 9+ 2=11 (lua+sys) ... ]] |
summary:
rect: when h is 1, sys cost is: max(1,w\16)*2 (agrees with CPU wiki page) when w is 1, sys cost is: max(1,(h-1)\8)*2 (disagrees? unsure) line and rectfill a,b = max(w,h),min(w,h) when b is 1, sys cost is: max(1,a\16)*2 (agrees with CPU page for rectfill, but not line(?)) |
Player 1: Arrow keys
Player 2: ESDF
C: Speed up
X: Slow down
Update 10
- Added bounce counter
- Fixed balls rarely getting stuck on the edge of the screen
Update 8
- Added nicer color palettes
- The ball can no longer go nearly vertically
- Added shadows to the text
- Players can no longer leave the screen
- The background color will now always change
- Text is now always centered
This is my first PICO-8 game, a port of the Nine Men's Morris board game.
https://en.wikipedia.org/wiki/Nine_men%27s_morris
The instructions are found in-game but are also just a quick Google search away. 🙂
I first played this game in the 90s as it was included in Sierra On-Line's Conquests of the Longbow: The Legend of Robin Hood. I thought this would be a fun little project to learn PICO-8.
Thank you @farawaythyer for your excellent post on How To Make Great Small Games, it is an encouraging read for anyone who wants to create something. https://farawaytimes.blogspot.com/2023/02/how-to-make-good-small-games.html
Also thank you to the fine folks at Sierra who worked on that section of the Robin Hood game and Ralph Gasser for your "Solving Nine Men's Morris" whitepaper. Certainly my version is very basic, but his technical paper is a recommended read for those interested in game analysis/theory/solving.