After dealing with a weird RAM issue on my computer, I finally picked up PICO-8 along with "Game Development with PICO-8 - Issue 1" (see Resources page, thanks packbat for reminding me about this zine!). In just a short amount of time, I was able to complete the first tutorial, making the Cave Diver game. It was an enjoyable process and I even had to do my own troubleshooting, such as figuring out where I made typos in the coding. :O
I have already created my own modified sprite and changed the colors. Later on, I will try doing some additional things like adding music.
One thing I'm wondering about for anyone who's used this tutorial is that the game is similar to Flappy Bird. There seems to be a point where the new cave tables eventually are so close to each other it's impossible to continue. I am wondering what I need to adjust to make it a little more "fair" so that a player wouldn't give up after one or two tries. I'll continue to experiment with how the cave is drawn or added, as well as with player jump gravity. However if anyone has worked on something like this, suggestions are welcome.
Now, as is customary whenever trying a new console, I'm off to search to see if anyone has made Doom on it. After all, someone programmed it to be played on a refrigerator! https://www.reddit.com/r/itrunsdoom/comments/8mv8pt/oc_doom_can_run_on_your_samsung_smart_fridge/
Cave Diver is a Flappy Bird clone, yeah - and I think as written the center section of the screen is always clear, actually?
Also, I don't think anyone has made a Doom clone yet - until recently when tline() was added, texturemapping was prohibitively processor-intensive - but someone did make the first level of Wolfenstein 3D.
Wow, I was really impressed by how smooth that game was. Thanks for sharing!
I'm uploading a screenshot so you can see what kind of issue I'm having. I've double-checked the code in the instructions a few times, but I can't see why they would collide like that unless that's the design of the game.
I think the relevant parts are:
function make_cave() cave={{["top"]=5,["btm"]=119}} top=45 --how low can the ceiling go? btm=85 --how high can the floor get? end |
and from the "add more cave" section within function update_cave()
col.top=mid(3,cave[#cave].top+up,top) col.btm=mid(btm,cave[#cave].btm+dwn,124) |
The three parameters in each mid() function are:
- the highest on the screen (smallest y-value) it allows that cave column to go
- the previous value plus a delta
- the lowest on the screen (largest y-value) it allows that cave column to go
(Order doesn't matter for the mid() function; the zine author just happens to have put them in that order for clarity.)
For col.top, if top=45, then it'll only return cave[#cave].top+up if that's between 3 and 45 - otherwise, one of those will be the middle value instead. Similar for the col.btm assignment and btm=85.
I'm guessing you have those two switched?
Edit: Wait, no - col.top is stopping at a line like it's supposed to - I think col.btm is the only one messed up, going by the screenshot.
Oh, how embarrassing of me! I went back to look at my function make_cave() and realized that I had accidentally typed out the whole word "bottom" instead of shortening it to "btm". I appreciate your explanation of the code. I was working to better understand how the cave updates.
Glad to be of service!
And yeah, abbreviations are tricky like that; I've definitely screwed that up before -_-;
[Please log in to post a comment]