I'm making a maze game...I know how to use a tile map but I wanted to have a bigger pool of possible screen (128x128) layouts than the map offers. I'm randomly choosing screen layouts and putting them together.
My solution to this was to create 8x8 sprites that then get translated into a table of wall objects. I then loop over that table to draw the maze walls. Nothing too fancy here...checking pixel color, etc.
And this works great up until a point...that point being once player objects and AI objects starting moving around and need to check for wall collisions, etc. It doesn't take long for things to start slowing down once there are 100+ wall objects to loop through per actor.
So given I don't want to use maps outright yet maps are more efficient processing-wise...is there a way to create a map on the fly? Using coordinates that are derived from the sprite.
There doesn't seem to be a vanilla way to do this (which doesn't surprise me), and I hate looking for hacks to get it done, but thought it was an interesting enough question to ask. It might just be a case where I want Pico-8 to do something it's not really suited to do (at least in the manner I'm doing it and I just need to accept Pico-8 limits).
Anyone have any links, examples or insight on how to make an object move towards a target while also going around obstacles (walls) when they hit them?
Say object A needs to get to object B (which is static). I can calculate the direction A needs to move, that's easy to get and make it move in that direction. But when it hits a wall on the way there, I'm not sure how to have it move around that wall.
I'm not necessarily interested in the shortest path, I just need A to get to B and have it be efficient enough for Pico8 to crunch it for several objects.
I'm aware that this will result in Gauntlet-style movement from the A objects around walls and such, which is fine.
I have a several 8x8 boxes on the screen.
I have a line from a/b to c/d.
I need to find out the line intersects with the boxes.
How I'm doing that right now is by using some line intersection formula I found to check if the line passes through each segment side of each box. So for each box, checking 4 sides for intersection. This works but I'm finding it's dreadfully inefficient once you get many boxes on the screen.
Hoping someone has a snippet or can at least point me in a direction of what to explore.
I've done a little searching and see something about Bresenham's algorithm but I don't have the brain power to translate it into Pico-8 in a manner that spits out a true/false for a given 8x8 box.
Currently, I'm checking each box, which could be up to 100 or more. I'd like to think there's a way to avoid having to loop through all 100 and compare, but maybe not.
Any help is appreciated.
My apologies if this was answered before, search didn't find me much...
Making maps in the IDE is frustrating, especially when they're big, full-width kind of things.
Is there anyway to import a tile map?
Like building it in a text editor and then pasting it in or something. Just the constant zooming/dragging is a mega pain.
Maybe it's just because it's late and I'm a bit fried...but hoping another set of "eyes" can help me think about map numbers.
I'm making another shmup. I have a map that is full-width and full-height (16,64) serving as the background. I have the map moving down with viewport being the bottom 16x16 of the map. So the initial map placement on screen is 0,-384
map(0,0, 0,-384, 32,128)
I have a bunch of flagged sprites in the map that can be hit by bullets. I know how to use fget+mget to check the sprite flag.
The issue I'm having is how to get the x/y of the map tile while it's moving.
I know I need to use the bullet's x/y but I don't know how to match that up to the tile on the map that is scrolling by. I'm guessing it's some sort of offset(?) but I don't know what that would be or how to calculate it into a map tile position.
I'm moving the map down by .25 each tick. It's something that I need to track when a map row goes off the bottom of the screen or something...I dunno...my brain hurts. If you think of something, please share...maybe this will make more sense by lunchtime tomorrow :)
mapy=-384 function _draw() cls() map(0,0, 0,mapy, 32,128) mapy+=.25 end
Does anybody have some methods for creating a boomerang action effect?
You know...player throws a boomerang and it eases out to X distance, hangs there a sec, then comes back to the player regardless where they are. Zelda-style.
I imagine it's a lot of atan2() math and something like that...but wondering if anyone has something they've already made and are willing to share before I spend weeks trying to figure it out. Thanks!
I ran the Dank Tombs demo cart on my PocketCHIP to find it really grinds...almost to a halt. I know the cart is pushing limits technically and the PocketCHIP isn't for every game - as much as I bang the PocketCHIP drum, I get it.
However, through that brief discussion, I learned that the PocketCHIP doesn't/can't run Pico-8 at full speed...??
Totally sucks given that PocketCHIP really pushes Pico-8 hard. And double stinks because as more people get their hands on Pico-8 and make great, top shelf games (like Dank Tombs) the PocketCHIP won't be able to keep up.
I had plans to make a console for Pico-8 using the Next Thing Console Bundle or maybe try to roll my own with a Raspberry Pi or something...however, if the PocketCHIP can't run things at full speed, does that mean these other devices can't either?
I want to play Pico-8 on my TV instead of on my computer so my kid and I can play without having to be in the office all the time. I've seen a lot of others post Pi consoles and such, which look like a great little project, but I want to make sure things will run as they should, unlike the PocketCHIP apparently.
Any thoughts, insight or first-hand stories is appreciated.
I'm currently rebuilding Invader Overload for an update and also plan to extend that title into other shooter games. Invader Overload made generous use of the tweetjam carts as animated backgrounds. It made the game what it is...I just added some space invaders on top of them.
I'm looking for more animated backgrounds. The art carts that made up the tweetjam thread don't come to me naturally but many of you it seems like second nature.
Here are a few examples of the backgrounds I used that were made by others:
If these animated art demo things are you bag or just like making them, please consider posting a cart and/or sharing the code behind them. There's a good chance it will end up as a background in Invader Overload or spin-off game in the near future.
While tokens are an overall concern, I'm not too worried about it. I'm pretty good at refactoring once I have code in my hands, so share what you will.
The only restrictions are:
- The animation must make use of cls() as the rest of my game does so
- No sprites
- Nothing too crazy...remember, it's still a background
I appreciate any and all interest in helping with this project. Invader Overload has gotten a lot of positive reviews and traction when showing it off, so there's an audience that will certainly be seeing your work. Credit will be given certainly within the code as well as secondary credit screens in-game.
Any questions or code, please post a reply or hit me up on Twitter - @morningtoast - Thanks!!
Hey all...Merry Christmas! Or happy holidays, or Festivus, or whatever it is you may celebrate...
I've only been Pico-8-ing since the Spring but it's been so fun learning, making games and playing games...and making friends with everyone in the Pico-8 Community. Good, quality communities can be hard to come by and ours is certainly one of them.
I hope everyone has a fun and safe holiday, and I can't wait to see what we all create heading into 2017. Gonna be good!
Seeing all the LD Jam carts has me wondering about the Jam category here in the BBS...should carts related to LD and others get posted there? Or go into the normal Cartridges category?
Ultimately, I guess it doesn't matter - they all show up in the primary list - but just wondering what the intent is between the two sections.
How far can you make it inside bullet cave?
1) Don't let enemies pass you or spikes will grow from behind
2) Shooting (Z) enemies grows the cave; avoid the walls
3) Use your freeze power (X) to invert enemies and make the cave shrink
4) Collect power-ups to change your weapon and gain freeze power
Can you unlock all 20 items? 10 themes and 10 character ships available
- Ship designs from @guerragames @qbicfeet @westfellapps @joshmillard @pixelartm
- Original music by Brian Follick, @Gnarcade_VGM
- 6 weapons of destruction
- 20 unlockables
Plays great on the PocketCHIP too, just search for "bullet cave" in Splore.
Please report any bugs in a reply or message @morningtoast on Twitter.
Posted some thoughts on Twitter but figured I'd put them here for the masses to debate...
Zep tweeted about adding some more categories to the forum including Snippets, Music and some others. However, I feel one category the BBS is lacking is simply a Games category.
We have a Cartridges category and while every Pico-8 creation is a cartridge but not every cartridge is a game. There are a lot of (wonderful) non-games getting posted everyday...from art to demos to whatever. When I load up Splore, there's a lot of non-game stuff to sift through to find new games (or discover old ones).
I'd also throw in there that since Pico-8 is the promoted gaming feature on PocketCHIP, when new PocketCHIP owners boot up Pico-8, they should be able to dive into the games right away. PocketCHIP owners give us an immediate and captive audience so lets show them the games that make Pico-8 so great.
So that's one thing...
I'll also throw out there that it would be great to see the Featured category in Splore be curated rather than simply ordered by star ratings. The Featured category could change out daily or weekly or whenever to promote all the great carts we're creating (even non-games). New releases, older carts...it would help discoverability more and give newer developers some early smiles. Not that Celeste, Dusk Child Hug Arena, et al aren't awesome games but the well of games is deep so why not take advantage of that?
I know content management is time consuming and maybe the site isn't readily available to support these types of things, but I think it's worth considering. I'd also be happy to help if it's a matter of man power.
And that's that...just some thoughts that have been simmering.
Right now, many of the newer Pico8 games being made won't run on the PocketCHIP (or any older version of Pico8) but unfortunately, there isn't any error feedback when you launch the games from Splore.
Instead of giving feedback, the little load spinner just stops and you're back at Splore (actually, you never leave). No response, no screen flash, no nothing. So you try again and get the same result, thus you give up and move on.
I'd think having some sort of messaging in Splore when something doesn't load would be possible and VERY helpful to users. We get a message when Splore can't connect to the BBS, there should be one when a cart fails.
The response wouldn't have to be specific at all...just something as generic as, "could not load cart" or something - anything that lets the person know something is up. Maybe that "something" might get them to ask around and see what the issue is - or raise an issue - or even update their Pico8 version.
In a perfect world, the error message would know between a bad cart due to some coding error, and a bad cart due to being incompatible with an outdated version of Pico8. Again, some message that lets people know they need to do something rather than just assuming the cart is busted.
Either way, any feedback is better than no feedback.
The more games that start to fail silently, the more credibility Pico8 loses as a good, fun platform.
We can't fix this on 0.1.7, obviously, but would like to think it's something that can be considered for future Pico8 versions, especially PocketCHIP versions.
The Next Thing Co forum has a great thread on how to add a VNC(VPN) client to your PocketCHIP, allowing you to connect and control things remotely from your desktop.
I followed the steps in the thread and it works great. I can now run PocketCHIP install Pico8 on my desktop and do everything I need...mouse even works! I'm not a Linux master by any stretch, so whenever something works as listed, I get excited.
So if you're looking to debug your games on the PocketCHIP without having to constantly switch between devices, this is a nifty way to do it. It doesn't solve the problem/annoyance of having to copy files over to the PocketCHIP but I'm guessing a little network share install would solve that - I'm gonna try that next to see.
Especially since the PocketCHIP version of Pico-8 is way back at 0.1.7, it's getting more difficult to ensure our games actually run on the flagship device (which is a bummer).
Figured I would put this up as WIP for now because I'm not sure if I'm going to put the finishing touches on it. This was intended to be a "quick little game" but it keeps growing and I think I'd rather spend time on a new idea. Anyway...
Fly as far as possible without hitting the walls above/below, and don't get crushed by the spikes behind you. Shooting baddies will build up the floor and ceiling. Enemies that get by you will grow the spikes.
Use Z to shoot. Use X to put on the brakes. Note the limited brake meter at the bottom.
When the brakes are on, bad guys will reduce the walls/spikes when you shoot them.
Collect the little dudes to build up brake time. Collect stars to change weapons.
Given this is a WIP cart, here are things you won't find:
- Alternate color palettes
- A good death transition
- Title screen
- Game over screen
I'll probably come back to this one at some point but might be chill on it for a while...we'll see.
Either way, your feedback is welcomed and thanks for playing.
This is one that only PocketCHIP people will be able to test and use.
By chance, I discovered that the mouse click (touchscreen) detection in Pico-8 looks at the entire screen on the PocketCHIP, not just the 128x128 viewport of the game.
So while the player will always only see the 128x128 box in the middle of the screen, you can detect when the person touches the screen to the left or right of that 128px box. So by all rights, you can make a Pico-8 game that uses touchscreen controls without requiring the player to touch the game screen area.
The width of the PocketCHIP screen is 480px total, so after some quick napkin math, I figured that there's about 176 pixels on each side. I made 2 collision boxes on either side of the game viewport (so -176 and 128, with a width of 176 and height of 127)
Then just a normal collision script combined with the handy mouse click detection function and boom, you have touch controls for your game.
The cart above just moves the little guy left/right and that's it - just proof of concept. Again, you'll have to try it on your PocketCHIP. This doesn't seem to work with the Pico8 client (at least on Windows)...even if you make your window super wide, it won't register the click.
Here's a YouTube video of it in action (couldn't figure out embedding):
And now that I think about it, I think I might add this little feature to my Invader Overload cart. If you're using the auto-fire option, all you do is move left/right, so with this touch thing, you could play the game without ever having to press a key on the PocketCHIP keyboard.
I hit an out of memory error and for once I don't know where the leak is...usually I know because the last change I made triggered it, not the case this time (or I just lost track of my shit) - either way, not sure exactly how to debug to trace it down.
Any tips or tricks are appreciated.
Anyone already have a function coded for checking to see if an x/y point is inside a rectangle with given points?
They're not "straight" rectangles, they'll be moving so I'm drawing them with 4 x/y points. I've found various formulas for getting the answer but wondering maybe someone had that done already? ...just being lazy... :)
After almost 4 months, I finally received my PocketCHIP today, as it looks like lots of you are recently.
Following the quick setup, I booted up Pico-8 without any problems and started loading up games.
What a difference a keyboard can make, huh?
But before that...all our games look awesome on the PCHIP display, it's pretty sharp. All the games I loaded seemed to play fine without any bugs or crashes...at least so far.
Now about that keyboard. Eesh. All the rumors and early reports were true, it's less than great for playing games. So much so that it really has me thinking about how to target my games.
Sure, the PCHIP is just another device but taking in consideration the keyboard when designing/making a game will be difficult. You can't really bank on people having case mods or anything like that. You have to assume anyone with a PCHIP has the off-the-shelf variety and I now see that comes with some serious considerations.
Like I said, all our games play fine but even the "simple" games with minimal controls feel clunky with that keyboard. And for games where you have to hit Z+X to do anything, talk about inconvenient.
Now, given that the PocketCHIP is somewhat of a luxury device with a very limited audience (IMO), making Pico-8 games without taking it into mind is probably safe. Most people will likely play in a web browser so the normal keyboard is a safe bet...but given PCHIPs are landing in mailboxes now, that means more Pico-8 players looking at our games and I know I want mine to feel playable. So I'm kinda bummed but also just try to look at it as another creative solution to overcome with our games.
This is all just first hours of use so some of it is probably pretty rash but hey, that's how I'm feeling right now. But either way, the PocketCHIP seems like a very fun device to play so skies the limit otherwise.
What do the rest of y'all think about this thing?
View Older Posts