I wanted to wait until stage 2 was complete but I have to take a one-week leave for a short holiday so here it is:
Stage one demo of my R-Type pico-8 port, showing almost all game and graphic system working.
Music once again courtesy of the great @dhostin (YouryKiki) based on Masato Ishizaki's original score
❎ button to shoot, hold to charge the beam
🅾️ to detach/recall the force sphere
The force can be positioned in front and behind, has 3 power up levels and can be used defensively too, absorbing the small enemy bullets.
(I strongly suggest to play with keyboard or pad as on the phone it might be a bit harder)
The idea for this came as a way to expand and improve the background graphic system of my previous Masters of the Universe game with scrolling, implementing more functionality in picodraw as explained here. If I have the chance in the following days I will detail a bit further what's new behind the scenes.
Except being one level only, this demo is still missing the option power up (the little spheres flying above and/below the ship) and a proper game/over - continue screen. The power-up capsule enemy AI is also unfinished.
The code is not completely optimized as the more enemy I introduce, the easier it is to refactor common parts an streamline functions, so it will get another pass after stage 2 is in. As you can see there's still plenty of sprite/map space unused so a bunch of things I am doing in code could be simplified using these instead.
Programming the enemies is the hardest and most tedious part because I have to play the original game a lot and try to guess what's going on but I will try to implement stage 2 and 3 for sure and maybe the last stage, then we'll see if there's enough interest to add something more, maybe going multi-cart.
Let me know what you think and please give me some feedback on performance, specially on lower-end machines.
*R-Type is a side-scrolling shoot'em up game, and the first game in the series. It was originally released in July 1987 by Irem for the Arcades, with ports to home consoles and computers in the following years.
got much more custom drawing code than I would have expected.
I assumed everything was picodraw’ed - I suspect that’s not tenable perf wise?
what about creating the various gfx elements and storing them in lua ram and brigging them to spritesheet during rendering?
Picodraw gfx is mainly for big static backrounds\object chunks and help preserve sprite space for small\detailed\animated objects.
The new functionality allows to mix sprites with shapes at litte extra cost and without the masters ram mirror trick and be scrollable, mirrored etc.
Other things like the lasers, beam explosion are too connected to procedural parameters. It would be posible but they will become way more static.
But... Lately I had an idea for another use case where it would be almost used for 100% of the graphics. I will develop it when i am done with this
A quick update to fix the force not firing behind you and tweak one enemy that was too much of a choking point.
Also, @freds72 you gave me a good idea, and now that weapons are finalized , it is indeed possible to draw them with picodraw, saving a few tokens. I tried with the circle lasers and I think the beam and the bouncing lasers could be done the same way, maybe even looking a bit better.
Right now the main limitation is that Pico draw commands are all 6 bytes long for simplicity and compatibility with MOTU's backgrounds. What I have planned is to make variable length commands, and add support for pal() commands, clipping and other stuff directly in the drawing byte stream. Then it would be possible to do a bit more with less customized code.
The ram to spritesheet is something I'll look into when I have all the sprites I need and can better decide what and how to swap. It is actually the "caching" I was thinking about when I posted about project dragon and it was confirmed by your virtual sprites technique in POOM! but it's a bit further down the line
Cool, very interested to see the latest iteration of your tech here.
Only thing is, I haven't been able to get to any of the interesting graphics yet. Maybe it's just that I'm not that great at shmups, but I can hardly go more than 20 seconds without getting blown up. At first I thought it was the controls on my phone, but then I tried on my computer, and same thing. I wonder if the relatively cramped screen dimensions are contributing to that, not much room to maneuver around bullets that suddenly show up from amidst enemy explosions.
@JadeLombax it might seem hard but it's possible to clear the level without dying with a bit of practice. Some enemy can be forced to stop\shoot by getting closer.
Or... You can hack the code and give yourself more lives\invincibility.
Maybe I'll add a cheat in next update
This is a pitch perfect reproduction within Pico 8, I'm amazed! I love the use of colours, it really looks like R-Type and not your usual brightly coloured Pico 8 game.
It's like playing the Game Boy version actually, with the relative sizes of the sprites.
Have you adjusted the speed of the enemies and bullets to be a little slower than the original to compensate for the vastly reduced reaction time owing to the very small screen real estate?
Thank you, @Domarius I looked at a lot of the past console's version when adapting the graphics, including the Gameboy one, specially to see how they dealt with the reduced scale.
So far for speed I just tried to feeling as close as possible to the original and I hoped that the chunkier enemies made them easier to hit. I will adapt the final version based on feedback. Now that the enemy placement/spawn system is set it's easier to adapt.
I want to keep the challenge of these hard old games but I think I will add a stage selector so you can start playing form the last stage you reached to make it a bit more forgiving.
I second comments on difficulty being actually higher than arcade (just played it on MAME).
Game aspect ratio between pico and arcade is different.
Pico version is "larger", making enemies really closer than original.
(fantastic work otherwise still!!)
Yeah, you can see i cut out 2 tiles of bg worth if space to fot it in pico's aspect ratio, but this made it easier graphic wise. Scaling it widescreen would make everything smaller and waste sone sprite space. I'll maybe slow down enemy bullets a bit but it's very easy to clear the stage with one life with a bit of practice. Also i will reset the ship hitbox to 1x1 pixel like the arcade. I made it 4x4 for the demo because i felt it was too easy 😅
Awesome that this is coming to pico-8, but as others have mentioned, the demo is way too hard. Much more difficult than the coin-op. Also the player bullet collisions seem off. Given the amount of effort you've put into this, I'm confident this will all be ironed out before release.
@timeandspace another demo with stage 2 is coming, with slower enemy bullets to account for the rediced screen space, but keep in mind my difficulty is following the arcade on normal mode, not easy, because the final cart will probably have 3 stages only and i want to give a bit of a challenge. For the collision seeming off, i think its coming from the player hitbox being much smaller than the ship. I was seein this in mame too and i found a developer interview here http://shmuplations.com/rtype1/ confirming it's only a single pixel in the middle of the ship. Right now on pico it's a bit bigger but ill reduce it to make it easier. This gives you a bit of safe zone unless you collide way into the ship.
After more feedback from next demo I'll plan further adjustments.
If you tell me which points seems too hard i can consider some tweaks to enemy placement\shooting rate
[Please log in to post a comment]