Hi guys, I like to make retro themed games, and write about game development, at my website - Domarius Games
With the excitement around the Alex Kidd remaster, I thought it would be a good time to remind people there is a DE-master of Alex Kidd right here in Pico 8 :)
0 comments
I'm just really curious what libraries etc. Zeb used to make Pico8, and make it cross platform. SDL2 maybe?
3 comments
Hi guys, so this is just an old version of my game with alternate music, the full game is in this thread. Please don't play it as if it's the final game!
0 comments
Hi guys, I have a game uploaded in this thread. The main cart is fine, but there is a secondary cart I linked to in the post, it's just there as a demo for some alternate music.
The problem is, that secondary cart is showing up in the "Finished carts" section of this forum, and people are playing it as if it's a finished game and telling me there are bugs.
EDIT: Okay I worked around this by just making it its own post in the WIP forum and linking it from there via the actual page URL instead of the cart reference ID. Now I can't delete this post now that I've solved my own problem!
2 comments
| "After Miracle, Techno, and Shinobi, Alex has found yet another world to adventure in, and it wasn't easy! Cramming yourself into a world which only exists inside an 8192 token limit is no mean feat! But that's no problem for Alex's mean fist!" |
After I don't know how many months, this is finally "finished", bang on the token limit (that part was easy and fun), but staying under the compression limit was a literal impossibility, and I had to run it through PicoTool to get it under. For that reason, I've made the un-garbled code available in a Google doc at this link. But that is exactly at the token limit! No room for edits... so I've also provided this version, which gives you a bit of breathing room if you want to experiment, it's missing some tweaks that the final game has, which are bug fixes and extra minor features like the level intro.
13 comments
I want to do a de-make of "Another World", this game is built of many static screens (no scrolling) and the backgrounds are drawn using very creative, data efficient, free-form "polygons".
To increase the number of screens I can have, and match the free-form polygonal art style, it seems better to discard the tile map, and use the map data to store "screens" and each screen would store "polygon info". So it would just be the points for the polygons, or something simpler - maybe just indexes of known shapes and a colour value to apply to them, something like that.
However it's stored - it would be expensive to re-draw the entire thing every frame, so I would have to use the old school technique of;
- draw the background once,
- capture the area behind a sprite,
- draw the sprite,
- then to re-draw, paste the captured area back over it, adjust the sprite x,y and repeat
How do I prevent the normal re-draw, and how do I capture an area of the screen?
Any thoughts on my approach?
4 comments
Hi, I'm still learning about Pico-8.
Given that there is ONE map (count-em, one!), if a game wants to give the impression of a bigger world, it's going to have to resort to some old school techniques, yes?
A lot like how Mario on the NES was done by making levels out of "chunks" of tiles, eg. one chunk is a set of stairs with a gap in the middle, another is 2 platforms above each other, etc. Thus the level data can just be a serialised list of chunk indexes.
I ask because, for fun, I want to try making "de-makes" of classic games. One might be "Another World". I was coming up with a level storage format which might just be a series of types of shapes, or points, and draw the polygons to create a 2D image, much like the original did, but this would have to be plotted out once, and then I'd have to use old school method of; every frame, capturing the small screen area behind the player, drawing the player, then erasing the player with the stored screen area, apply the movement, and repeat. To avoid re-drawing the background every frame because it might be computationally expensive.
7 comments
