First cart! Made this demake of our jam game, Sumo Puckii for some practice! It's 2-player only, so I recommend both gamepads and some friends <3
Mwuah <3 kisses
3 comments
An asteroids-like game for PICO 8.
Controls:
UP: thrust
LEFT/RIGHT: rotate
Z: shoot
X: blast (area attack radiating from ship; uses energy)
Don't get hit by the asteroids; shoot the asteroids for points. Big ones split into medium, medium ones sometimes split, small ones never do.
Each player starts with 3 lives, and also has a "power" gauge. The longer you stay alive, the higher the gauge goes. When it passes certain points, you automatically upgrade (upgrades: more bullets, longer distance bullets, multi-shot). When you die, it resets. The secondary attack ("blast") uses up 1 "tick" of energy (3 ticks per upgrade), so you can choose to use it to save yourself and rack up points, but it will slow down your upgrade path.
At this point, probably all that I'm going to polish on this is sfx and maybe some graphical tweaks.
[b]Original Post
13 comments
I got to wondering whether you could rotate a sprite in PICO-8. Of course this facility is not provided, but it should be achievable, I thought.
How this works: 3 rotating objects. Arrows move the green cursor among them, and Z or X to toggle each object on or off.
The rotations are slightly ugly, but I think accurate. Smoothing could probably make them look better, but maybe not at reasonable cost. I don't know! Rotating the large sprite is CPU-intensive (and ugly!). I think for small objects this could be used in a game.
Issues:
- Sprites are rotated about their top left corner. I think this is needed to guarantee that atan2 is one-to-one. But it would be better to rotate around an arbitrary center!
- I forgot what the other issues are.
12 comments
just lettin u know press x 2 shoot and space bar 2 fly(yes fly) and c 2 fall. u also have 1000 hearts.Enjoy!
0 comments
ADDED (7/31): Fixed some missing interactions; elastic collisions apply to the ship; re-did overlay; you can switch views; gravity calc is dropped at high distances.
Press 'Z' to switch views among ship and planetoids. Current view is displayed in overlay.
ADDED (7/31): Only detect collisions for nearby objects (fixes integer overflow issue).
ADDED (7/31): Elastic collisions (for planetoids), sound and music.
I've implemented perfectly elastic collisions between the planetoids. (I haven't done collisions for the ship, yet, partly because it's easier to detect collisions for circles.)
When two planetoids collide, a crashing sound plays and the planets exchange some energy and momentum (details). I'm pretty sure the math is accurate -- at least, the collisions look reasonably accurate. As with gravity, however, the math involved can involve large numbers and integer overflow could be a problem -- I don't know whether it actually does cause issues in the conditions I've built. (EDIT: I think it does. In particular, collision detection uses distance. But, because of integer overflow and sqrt, distances over ~181 roll back to 0. So very distant objects constantly collide with each other and go crazy. This makes the system less stable than it should be. A solution would be to only check collisions for nearby objects, using some cheap and safe heuristic (e.g. Manhattan distance).)
15 comments
Update:
Finally fixed the map issue from changes in Pico8 and fixed the 10 minute game freeze bug.
Some dialog stuff and fixed a bunch of bugs, cabins now work and there are caves you can rest in.
How to survive your first day:
- When you wash up you're nearly dead, hungry, tired, and exhausted.
- Your health will drop if any statuses (hungry,tired,exhausted,cold) are in the red.
- Resting while your statuses are ok will restore health
- Quickly drink some water from your flask. (x -> items -> flask -> drink)
- Find some fruit/berries and pick them then eat them.
- Salvage wood from your boat, and chop down another tree and get the logs
- Build a shelter, eat, drink and rest, stay warm
- After this, focus on finding freshwater (it has white sparkles) so you can drink and fill your flask
- Then try and find some stone and build a cabin which will replenish your stamina fully
- Build bridges to new areas
Features:
- Day night cycle
- Weather
- Temperature (it's colder at night and when it's raining, stay warm in your shelter/cottage)
- Simple menu system
- Procedurally generated world
- Bridge building
- Building wells that fill with water when it rains
- Plants grows overnight while you're resting
- In progress
- Farms and farming
Plans
- Fishing minigame
- Wild animals and fences to keep safe
- Disallow some stuff at night to incentivise you to work during the day
I suspect code size optimisation will be quite critical =\
78 comments
I'd like to be able to tag my cartridges with a simple set of license terms, e.g. all rights reserved/GPL 3/Apache 2/MIT license for the code, all rights reserved/CC4 ATTR-NC-SA/CC0 for the art. There are other potential uses for cartridge metadata fields.
Tagging the cartridges instead of using freeform comments would allow forums or databases to offer queries or different behavior. Tagging the catridges themselves instead of their corresponding lexaloffle forum posts would allow the license terms to follow the p8/png files as they are distributed.
Separate licenses are necessary for the code and for the art. You can't apply a CC license to code and have the intended effects, nor can you apply a code license to art without introducing ambiguity.
Tagging could take the form of simple specified fields in comments at the top of the source area. We already use the first two comment lines for the cartridge label. Possibly improved would be a set of optional "field: value" comments in the same block. Title, author, version, code license, art license, maybe even author contact fields (forum handle, Twitter handle, email address).
-- title: galagala -- version: 1.2b -- license_code: mit -- license_art: cc4-attr-nc-sa -- author: dddaaannn |
12 comments
This is a really basic test of a supercover algorithm (for determining which grids in a square a line from square 1 to square 2 crosses). Potentially useful for collision detection or line of sight.
Algorithm is cribbed from online (with minor tweaks), and this is otherwise quite simple. Mostly a proof of concept, and to see how well it performed within PICO 8.
Up / Down / Left / Right: move the end point.
Z: change which end point you're moving
0 comments
SOME WOULD SAY IT'S TOO SOON. TO WHICH I SAY... Yeah, yeah it probably is. The original JELPI isn't even technically finished. But hey, I got the deadly spikes to work and made a whole cutscene...
plz tell me if you get to see the ending plz
19 comments
so based on a conversation from another thread, I decided to do an implementation of the one line program :
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
now i'm a hobbyist programer at best, so I pose the challenge to the community, what's the smallest program you can write to recreate this effect?
this is my effort - using sprites and in 50 tokens
11 comments
I have started working on a version of " Combat" during the Outofthebit game jam.
blogpost
The game is far from finished, but I really think a 4 or 6 player version could be amazing.
to do :
- rotation of the sprites of the tank
- bullet creation
- bullet collision
- score
- explosion
- spawn the tanks randomly
- victory screen
- rematch
I
1 comment
Per this thread, I wanted to figure out a method for pixel-perfect collision for a project I'm working on, and snaggled the in-project attempt so badly that I decided to start from scratch in a separate cart. This is the result, a little demo that shows pixel (and basic box) collision feedback in real-time on a couple of sprites.
As far as I can tell, the collision test is accurate under the assumptions this cart makes: each sprite is an 8x8 sprite referenced directly off the sprite sheet by sprite number, and any non-0 pixel is considered solid. But beyond that I am making no assumptions about it: I'm sure there are cleaner/faster/neater implementations of the same idea, and I'd encourage anyone who feels like taking a shot at cleaning it up to go for it.
This should also in principle be generalizable to arbitrary rectangles of sprite sheet info for e.g. larger multi-tile player sprites, and in fact I made some progress last night trying to generalize it, but that hasn't totally come together. Anyone who feels like tackling that, go for it.
2 comments
Hey there, I just wanted to have a very quick play with PICO-8 and this seemed like a fun quick test. Single "large" sprite blitted across the screen while being flipped at random, no interaction. Pretty simple and painless, based on an old screen-saver.
Now onto something a bit more involved (but I expect not much).
8 comments
This is again just a test for the web player, both on the music playing and the gfx rendering. I couldn't get the renderer to render a 1x1 thing, but I haven't tried too hard and I have absolutely no idea of what I'm doing when it comes to high perf pixel pushing. My hope is that this will be my first proper music release for the Pico-8, hopefully in August.
1 comment
Hi! I'm enjoying getting started with Pico-8!
Does anyone here use IRC or is there already a pico8 channel somewhere?
Happy to start one if not.
6 comments
Added:
- flowers
- a couple sfx.
Todo:
- more sfx
- music
- splash screen
Controls:
- move with arrow keys
- change tool with x
- use tool with z
Added:
- sun/moon
- clouds
- rain
1 comment
So I noticed this odd behavior in v0.1.1 when you press two arrow keys quickly but not at the same time. Pressing down, then left while still holding down causes the cursor to move first down one space (correct), then diagonally down-left one space (incorrect). So the end result is moving 2 spaces down and 1 space left, instead of 1 and 1.
If I had to guess, I think this is because the directions are treated like a gamepad, so when any of the four keys are pressed new events are handled for all currently down directions, instead of just-pressed keys. But this behavior is very frustrating when you're trying to navigate lines in the code or music editors, because the cursor often goes wrong when you move too quickly. Please fix!
Additional note: pressing down and left at the same time causes the cursor to move two spaces down AND two spaces left. Really odd behavior. XD
4 comments
I had a syntax error due to an unclosed paren, and the error message tried to help by telling me the line number of the unclosed opening paren, but the line number was a fraction:
SYNTAX ERROR LINE 54
<EOF>
')' EXPECTED (TO CLOSE '(' AT LINE 0.0008621) NEAR 'THEN'
|
The actual line number of the opening paren was 53 (9 chars in). Lines 53 and 54 were:
if ((neighbors == 3) or
((get(cur_base,x,y)==7) and (neighbors == 2)) then
|
I can repro this with an empty file and just these two lines with a closing "end" statement (getting a line number of 5.341e-05).
0 comments
