Creating web-based controls for Pico-8 games is not a new topic but after just finding a great template, I jumped back into the fray with the idea and need some help testing.
Please visit this link ON YOUR PHONE and see what works. It's my Invader Overload game from last year.
http://www.morningtoast.com/games/invaders
When you land, you should see a page asking you to add it to your phone's home screen. Once you do, you can launch from the icon and it should be a web player with big red buttons for controls.
It's all very ugly right now but I'm just testing to see how much of it works and how well.
On my iPhone 6 with Safari, the game loads and plays just fine with controls but there is no sound. I've had a few others report the same for iPhone and one report that Android doesn't work at all.
Please post with your findings. This feels like the closest I've seen to having Pico-8 be viable on a phone without needing to port things over to an actual app of some sort.
Here's the template I used and modified:
https://github.com/headjump/pico8_html_template
5 comments
So apparently I'm an idiot...or at least never read this in the manual (never thought to)
| When saving in .png format, the compressed size of the code must be less than 15360 bytes. To find out the current size of your code, use the INFO command. The compressed size limit is not enforced for .p8 format. In most cases you don't need to worry about the compressed size, as the token limit (8192) will be reached first. |
Given you can upload carts to the BBS by pasting in code, and exporting to HTML is also a separate process...you can ignore/avoid the compression limit entirely unless you want to pass around the PNG cartridge.
Dammit.
Here I spent a ton of time getting my game under that compress limit when I didn't need to. I was within token/character limits just fine. Arg!
Well...lesson learned...and maybe this call out can help someone else avoid the headache.
Dylan Burke is finishing the job his father failed to complete on LV-426. He must be stopped. Explore planets and collect 12 alien eggs before Burke can get to them. |
Sound and headphones are recommended for the best experience
.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.
Player manual. Complete with hints and tips!
http://slides.com/morningtoast/alien-harvest-manual#/
Browser gamepad support is availble through Itch.io:
http://morningtoast.itch.io/alien-harvest
Keyboard controls
- Arrows, Move character
- Z, Map / Continue
- X, Use weapon
.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.
.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.
What people are saying...
"I nearly jumped outta my seat when it chased me..." - @Liquidream
"Yeah, headphones are a must" - @enargy
"Hats off to you for bringing that element into your games. Brilliant." - @beetleinthebox
"The game is cool!" - @pineconegraphic
"That's some cute manual action!" - @rtrntospielburg
"You’ve found a really nice style in this one." - @johanpeitz
"Are you still making that damn game?" - @barneysangels
.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.
This game has been a long time coming. I started it back in June and worked on it for about a month. Then I hit a wall and got distracted by other stuff...it sat on the shelf. I came back to it after a couple months and finally finished it up. Very happy I did.
The idea got seeded when I read an article in Retro Gamer about the Sega SG-1000 and the game "Girl's Garden". In it you're a girl that has to collect flowers while avoiding bears to keep her boyfriend happy. Somehow that got me thinking about applying that model to an Aliens motif...and I had just so happened to find a spritesheet rip of Rebelstar from the ZX Spectrum that had alien characters in it. I took those and started designing around that.
Prior to this, most of my Pico-8 games have been arcade shooters, so making a maze/map game was new to me (especially one with a story). It was nice to try something different and I learned a lot. I'm not sure I'll try to make another one...while rewarding, this experience was exhausting. I'll just have to spread out my efforts when it comes to this genre.
What I think made the most difference with this game was that I came back to it after some time away. It felt good coming back to something that was a) half done and b) still familiar enough code to dive back into without a lot of re-learning. Plus I could look at it with fresh eyes to determine if it was worth finishing. It held up well and I was motivated to get it done.
But man...the last 10% of development is killer. For one, I hadn't quite figured out the last act and then when I did, Pico-8 compression limits came around and tried to crush my dreams. To combat that, I simply started over...kinda. I opened a blank cart and copied over code chunks one-by-one, inspecting and refactoring each one as I went. I had to trim some design fat but in the end that had little impact on the gameplay and that's what matters. All that effort paid off and I got in under the limits with a solid game.
Since this game has an actual ending, I kept playing and I kept failing to win. Usually that's a sign of the balance being off but this time it was just a good solid challenge. By design or by luck, the game trade-offs worked out wonderfully. The game isn't easy but not too difficult. It never feels overly unfair and has some wonderful emotional impact as well. Even with insider knowledge, it took me quite a while to win but only after plenty of "just one more time" moments.
Thanks to everyone that helped along the way, whether on Twitter on here in the forum...all of it made a difference.
Please see the manual for more credits, acknowledgements and original source material
Super thanks to @pineconegraphic for the character animations
Awesome thanks to @gnarcade_vgm for the original music
Some lessons learned:
- Use shorter variable names
- Using the pair() loop is better than the all() loop
- Large arrays are bad
- Story text is troublesome, as are long strings in general
- Code comments seem to count toward compression limits, remove them
- I need to figure out how to get more use out of tile maps
- I need to learn more about memory functions
- Pathfinding is difficult and taxing
- Aliens chasing you is terrifying, even when they're 16x16 sprites
Please report any crashes you experience.
If you have any questions about how this game was made or what was used, please don't hesitate to ask.
I think some variant of this has been discussed before but if I recall it turned into a debate about the lack of being able to customize the keyboard controls in Pico-8.
Please don't debate that here...go find that thread :)
I'm interested in hearing thoughts on whether you think it's a better "standard" to label controls in your game as the letter - like Z, X - or to label them as the special characters (X),(O).
While I personally prefer the aesthetics of the icons, I do know it is difficult to know which button is which on your gamepad when doing that. I used the icons on the game I'm making now and when had people play, confusion followed, so I changed it to letters.
Plus, after some very limited polling on Twitter, most play Pico-8 games with their keyboard...so that tells me that labeling controls with keyboard letters is more helpful across the board. Thought being if you want to use a gamepad you'll a) figure it out, or b) can map things accordingly. Gamepad=Power user, of sorts.
Hmmm...I might have just answered my own question...helps to say it out loud, I guess. But I'd still be interested in hearing thoughts/experiences.
I'm using stat(1) to see what type of CPU usage my game is using and in certain spots it's a lot, sometimes hitting 100% and causing some serious jitters.
When that started happening, I went back through my code and did some refactoring of things...removing dupe code, nesting conditions, removing methods, limiting loops per tick...and that helped.
I'm not so dumb as to not realize that bloated code will impact CPU usage, but what else increases that usage?
Maybe that's a big question...I dunno, I'm looking for a somewhat high level answer, I guess. Just general "things to pay attention to" kind of stuff.
I'm not using any fancy techniques like poke/peek or memory storage or anything like that. Very straight forward coding. I don't feel like my game(s) are very complex or doing a whole lot, which tells me I'm probably missing something in managing overhead.
I've been rebuilding/refactoring a recent game in efforts to reduce clutter and increase performance, as well as get under the dreaded compression limit.
For whatever reason, I've started to nest functions...mostly as a way to better organize code. This works just fine but I'm wondering if there's any real downside to it?
I've been nesting functions that are relative only to code of the parent function, so as to reduce some code. Usually some math or condition checking or something...
As of yet, it doesn't seem to impact on my games at all. Just wondering...
function myParent()
function myNested()
...often repeated task code...
end
if Something then myNested() end
if Something and SomethingElse then myNested() end
...you get the idea...
end
myParent()
|
New York City is being overrun by ghosts! Who you gonna call?
Take control of your favorite Ghostbuster and try to stop the onslaught of Slimers through 5 frantic levels of arcade action. Choose from Peter, Ray, Egon, or Winston and try to stop Gozer and her minions from taking over the world. Good luck!
Keyboard controls:
- Use Z to fire your proton beam
- Use X to throw a trap
- Up/Down arrows switch levels
Stop the Slimers from reaching the city. Use your proton beam to bust ghosts and destroy the portals. Your slime meter will fill as ghosts get by you. If your slime meter gets full, it's game over. And watch out...you don't want your proton pack to overheat!
You have ghost traps but they're limited and you can only throw one at a time. And keep an eye out for the Stay Puft marshmallow man...he means the city is almost filled with slime.
=====
Updated 10/2021:
To celebrate the new upcoming Ghostbusters movie, the game has been tweaked a bit to add Gozer to the script as well as setting default play to the original Ghostbusters characters. You can still switch to the girl Ghostbusters by hitting Up/Down on the title screen.
Ghost traps are no longer unlimited! You start with 3 traps and can earn more as you bust more ghosts. Keep an eye out for the orange Slimers...bust him and you'll get an extra trap.
About this game:
My 5-year-old daughter loves Ghostbusters and while she's not really into video games just yet, I decided to make her a Ghostbusters game to maybe nudge her along a little bit. She's seen all the movies but likes the new Ghostbusters the most, so this game features the lady Ghostbusters...but don't worry, you can unlock Peter and the gang...just keep bustin'!
All in all, it's a simple game...basically Tapper with Ghostbusters. It's not that difficult but I pretty much made with my kid in mind. It'll be a tough challenge for her but for us "experienced" gamers it'll be a fun but brief playthrough.
Feedback and bug reports are welcome and encouraged. Thanks to everyone that helped in development. Brian Follick for turning the Ghostbusters theme into a Pico-8 track. @BeetleInTheBox for the extra graphics in short notice. And the great Pico-8 community for the support, snippets and encouragement to actually finish a game...thanks!
I'm not surprised that I'm hitting the "out of memory" error when I put a big table of coordinates into the global scope...I'm figuring out how to deal with that right now. My question is why does it take up so much memory in the first place?
I created a table with indexes for x/y coordinates, which in turn correspond to objects in the game.
My map is made up of 16x16 tiles, so 8 per screen. When I have a 7x7 map, that's 3136 slots in the table containing tile information. That's a lot, I know. Each table element has attributes for the tile. When there are 8 attributes in the object, Pico8 shows memory at 70% - adding just one more key-value pair takes me over the limit.
How does adding a single pair take up 30% more memory?
level_grid={}
map=7
for x=1,map*8 do
level_grid[x]={}
for y=1,map*8 do
level_grid[x][y]={
tx=x,ty=y,n=0,f=0,g=0,h=0,p=0,status=0,
o=0, -- This pair puts me out of memory. Remove it and we're under.
}
end
end
|
I know that memory is used up by everything so the 70% I'm seeing is not just the array, but it's certainly a big chunk of it. Even after stripping out everything except the array, it's still at 59%.
I'm not good with memory sizes or the math that goes into it or what uses up memory and how. I'm pretty sure I'm just going to have to accept that my game will have to have smaller maps, which is fine, but more so just for my own education, I'm wondering why this happens.
I'm doing this a lot through my games in loops and I feel like there should be a shorthand for it...?
a-=1 if a<=0 then a=0 end |
And similar type of counting, etc...
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
Featuring...
- 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.
View Older Posts
