So, I just barely got started with PICO-8, and I'm very excited to do so.
The idea of implementation so far:
-Title Screen (Simple and straightforward; shuffles the collection of powers and allows the player a selection of game lengths, short being 4 powers, normal being 7 powers, long being 10 powers, and hardcore being 13 powers for the session)
-Starting Screen (a single start/end screen that produces the first neighboring "hub" scene)
-Hub Scene (a single screen blocked on two walls, the layout flips horizontally and vertically to create a four-screen block; with which to branch off transition rooms and corridors)
-Transition Screen (here's where the For loop takes the first 'n' powers, and applies them to the layout; before making the feedback loops relating to the items)
-Horizontal/Vertical Corridors (two endpoints with two or three screens of obstruction along the way, and mechanics defined in part by the powers used so far... the corridors go out from the transition screen, link to a second hub screen, and immediately double-back the same direction, to another corridor, that takes you to the item/prize room.
-Item/Prize Room (has the items, along with a one-way door often utilizing this power, to feed you back to the chamber you came from)
Finally, find a place in the feedback loop to hide two upgrades: a shot class, health up, or damage up, in the terrain that's generated along the way. This completes the item distribution cycle and accomplishes one important thing - it adds a new Hub scene, so now subsequent powers can be chained similarly from more Hubs, expanding the world while basically using the same fundamental setpieces.
Finally, these will function like transition rooms, but for a thing you can collect for completion by utilizing your acquired powers; preferably in a resettable puzzle-like setting. I haven't thought this much through yet, so I'm not sure what I'm going to make these objectives be; but it's certainly part of the original Gentrieve formula that was missing. Perhaps generate a puzzle room that transitions to an objective room?
The powers, so far:
-Rollerball (planned to use more like Sonic Spindash more than traditional "morph ball")
-Shot Power Up
-Piercing Laser Shot
-Shot Eraser/Blade Up
-Shot Deflector/Blade Up
*Shot effects are planned to stack up this time, rather than be toggled; charge shot for Grapple Hook.
Hopefully, the base sprite and rotations thereof will provide the variation of animations and mobility options I'd like to consider featuring...
So here we have the four main kinds of chambers I'm aiming for using.
The "blank" screen in the upper left is for stuff like the Title Screen, Pause Screen, Game Over, You Win, Settings, etc.
The 1x1 room is mainly used for item and transition rooms, although the start room is one as well. The 3-screen corridors (I suppose) will be the branch-out areas, in order to work within the map limits I had to condense those; and finally, that big 2x2 screen is a hub screen.
In the finished product, I'll probably have doorways jump you straight from one place to another, and invalid doorways will auto-convert to the appropriate wall/floor tiles for the area (or damage tiles?); and then fill each "instance" of it with scripted instances of obstacles and enemies.
You can't really tell from the shot here alone, but I managed to squeeze in SIX BIOMES' worth of scenery! :D
Now, the planned player movement.
Gonna level with you, new to going this low-res, so I'll probably have the usual speed be 2 px per step; give or take some acceleration (3 px?) if you have Speed Booster. Likewise, I want a little bit of inertia, especially while airborne - probably 2-3 steps where you -1 your horizontal speed, depending on your momentum. Nothing hugely drastic, mind you, but just enough to make the players work for that precision.
The Rollerball will act like a Sonic Spindash, and be the fastest-moving thing at the player's disposal, whipping them across at 4 px per frame. And being able to ball-jump isn't so special that it's deserving of it's own item; that's kind of an archaic limitation anyhow.
Initial jumping height is 5.5 tiles - enough to get from the middle of the screen out the top to the next room if need be, with that extra half-tile of wiggle room providing a cushion for the player. No reason to force absolute precision on anyone. Only catch so far being that this makes the player able to clear an entire screen via double jumping, so it's likely this will tone back down to 3.5 or 4.5 by final release; but for level-testing, it'll be alright for now.
You may not be able to tell from the spriteset, but I also intend on letting the player aim down in the air (by rotating the "crouch" sprite forward - that's doable, right?), and I have an interesting schema for wall-jumping plotted out, although it risks confusing some players. So long as you're maintaining upward momentum (or evening off), you can wall jump by holding the jump button and simply alternating between left and right. But once you pick up more than 4 px/frame of downward momentum (maybe even 2 px?), you're falling until you hit the ground. The idea is that you can explore vertically this way, but not use it as a cheap way to prevent falling. The wall-collision will probably have the "crouch" sprite rotated to face upwards.
Scuba will change the player's water controls from slippery inertia with regular physics to freeform directional control; and will change the animation so that it's like the upward-facing sprite, with the "walking legs" kicking behind it - all rotated to face the direction the player is travelling in; or just treading upright if the player is still or near the surface. I'm also, so far, planning on using the Jetpack as a dedicated Shinespark item (again, body facing in the direction ala swimming, just not kicking/animating), hence it's seperation from the Dash Drive and Speed Booster; but time will tell if one or the other of those will be replaced or scrapped - there is some redundancy between them, isn't there?
Of course, this is all assuming PICO-8 lets you rotate and manage compound sprites like that, and without taking too much code to do so.
Cool to know.
Well, I mashed out the manually-rotated sprites, and then I noticed something that wasn't apparent to me to begin with - that the map data actually consumes sprite data?! Well, now I'm really gonna have to focus on the meat-and-potatoes now, aren't I?
That said, enemy variety and simplicity are of fairly paramount importance, now. And I think I'm gonna have the area-coding revolve around 4 stages of gameplay - the opening that's pretty straightforward and low-punishing, one that requires mobility items to get around, one with tougher enemies that revolve around increased firepower, and then the endgame area that combines the two together.
Coming from a VB.NET/C++ background, this kind of "console development" is kind of new to me, and I'm still getting a grip on LUA. It may take some insight I don't quite have yet, but this'll be exciting to finally ball out.
Reminds me a lot of this:
More progress, got some creatures sprited out, and a mess of pieces to boss creatures that can be configured in a variety of ways. Originally, I wanted to broaden the creature features, but I didn't know that map data overwrote sprite data - I'm glad I did my mapping before my spriting now! Nevertheless, I'm sure I can at least get a decent variety of movements out of the few creatures available, which may vary from region to region.
Just today, I started sequencing the soundtrack to the game. Delighted to find that there's 64 patterns which works perfectly into the scheme I was aiming for, 8 tracks. It's my first time working with a tracker, so I'm a bit fresh to it, but I know what influences I'm going with... although I hit my first hiccup when I went to do the second sequence, which conveniently copies, which is terrific... but then I went to edit the second one, and it copy-edited the first to match it still. I tried the "A" key toggle to no effect. >.>'
Am I missing something here?
-Catchy Simple Title Screen jam
-Heroic Anthem (Metroid 2? MegaMan 7/X intro?) style jam
-Chemical Plant Zone/AM-3P hiphop~house jam
-MMPR/Mute City guitar riffing hard alternative rock jam
-Some kind of "weird zone" piece, like Potential For Anything
-MegaMan 9'ish piece, like Splash Woman meets We're The Robots or something
-Tense, DnB-style boss battle; like something between DKC2 and Sonic 3's final boss themes?
-Nifty Game Over/Credits song with upbeat 80s eurodance influence
PS: In advance, how would I make one song loop like:
(00, 01, 00, 02, 00, 01, 00, 03, 04, 05, 04, 06, 04, 05, 04, 07) repeat
...? Like I said, total n00b.
I SAW THAT A LONG TIME AGO!! But nothing more than the little demo came of it, that I know of. It's one of the reasons I want to do this, actually! I was so looking forward to it. Y.Y I guess I still am, really.
I hadn't actually heard of Gentrieve until now. This looks pretty great, though. I'll give your games a look later.
As for music editing, most of the action actually takes place in the SFX editor! The number above each strip in the music tracker is what SFX it's currently editing. As for looping, each pattern has a set of flags that determine it's loop behaviour.
Right above the mouse are the flags. The first one is a beginning loop point, the second is the end loop point, and the third is just a stop. When you say "music(0)", you're really saying "start at pattern 0 and continue until an end flag is reached"
http://tonythetgr.itch.io/gentrieve = available here, totally free. This is also a kind of reconception, I realized what was off designwise in the original project (which was actually made for XBLIG, before that became a non-issue); but that doesn't make it unfun to play still.
Originally, I was gonna make a short/medium/long/full options like Gentrieve had; but now looking at it - it's probably best to break it into segments, distribute all of the powers (4-5 each?), then make scenarios that only require some of the powers to be collected. Like:
Starting area: basic stuff
Branch A: recommending some mobility upgrades
Branch B: recommending some weapon upgrades
Next area: recommending two levels of each
Branch C: recommending three of weapon upgrades
Branch D: recommending three of mobility upgrades
Endgame: recommending four of each?
Then just work the swamp/water/lava into the biomes as progression?
Working on level-generation code, and really hitting the wall right about there. Either not enough familiarity with LUA, or with console dev, and not sure which it is, specifically. growls
The music thing still makes edits to all previous channels too, and I'm not sure why.
/month of struggle with the real world interferes
Found out what's up with the music channel thingy. I feel derp now. Will get back to the compositional part for now. Far as the programming goes, I do need a little insight/feedback:
Progressing pretty well with level/world generation and FSM. I do still need to know if PICO has an equivalent of "Select Case," or a way to shuffle an array/list and then cherry pick a particular ID of the list. Anything? This is mostly related to scene-level generation (tile placement) and door IDs/management thereof.
The third and fourth sets of sprites have pixels that appear to represent map data - so if I were to edit sprites there, would it overwrite/wreck my maps?
And can MGET work with decimal values? It seems my scenes don't exactly line up with the mapgrid (they're 9 tiles tall, and 12 tiles wide per screen); so I've been having to use multiples of 1.5 horizontally, and 1.125 vertically... and is there a way to select a map range (IE: the 2-across, 2-down rooms) all in one shot?
Thank you for all the help and support!
PS: I'm taking on a holiday job soon that's ~10 hours a day, 7 days a week; and then washing dishes about another 5 hours a day on top of that. It'll probably be mid-January before I can continue much further... but it'll be worth it! Bookmarking progress for now.
Okay. So here's how my map screens are layed out. The corridors (vertical/horizontal) are not "three screens," however; they're coded to copy, for example, the left side, a number of the centerpieces, and then the right side; and then fill them with content. The trick I'm hitting with this is assigning "door IDs," to correctly connect them to neighboring corridors. Granted, most of the time it'll be at the endpoints (an easy enough 1-2-3-4); but there are occasions where I want to branch perpindicularly to those, particularly in placing things like item rooms.
If there's someone on this level here, I'd love to hear a method of properly assigning and managing door IDs like that.
Ideally, I'd like to make this a table where every new scene modifies the existing table; and simply assigns values to the corresponding "column + 1" of the room ID's row; then anything that's null is simply walled off; but the input will be a pair of values (destination, weapon ID to open/tile type)...
Sorry for the HUGE delay of game here. Got ridiculously overemployed for awhile, and then had some damage control to take care of as a result of that.
One possibility is that you could keep a separate list of door IDs with starts and targets. Then, when the player is over a door sprite, you can search through the list to find out which particular door the player is over, and where to teleport to.
This list could either be hand-coded, or maybe you could populate it by searching through the map and finding the next door of the same color. For example: let's say I scan and find horizontal door with sprite H1. I could then look for the nearest door that has sprite H2 and pair those doors together. (Mark them somehow in the list so that you don't find them multiple times...)
I don't know whether you have easy access to your individual map cells though, so this method could end up being convoluted.
I'm excited to see how your map compression scheme works!
The idea is kind of similar; it's that when you hit a door of "door ID" with the appropriate weapon (like Metroidy doors are prone to do; this could also be "nothing"), it makes a "transition tile" that you collide with to go to the next room.
But rather than being premapped; it will search a history of the past 4 previous rooms and reload that; or if it's not in that history, it will redraw the scene that the door transitions to (and drop one from the history). This way the map can be as big as it needs to be to place all of the items.
I'm starting a Zelda-like one that's similar, but it uses basic Perlin Noise to generate one of 15 variants to borders; and toggles between "overworld" (relatively open sides) and "underworld" (more centered doorways) sets.
The thing making it tricky to relay door IDs here is the variability of the corridors; and keeping the transition points consistent.
OMG, I am such a derp.
Here, I'm used to working with XNA and trying to make a big, universal, three-dimensional array/table to manage everything in one big database; but I shouldn't do that here, should I? Just make a small, simple one for each scene. (facepalm)
On second thought; having a two-tile high character in a 9-tile high/12-tile wide corridor is WAAAY too confining for a Metroidy experience. Reworking the compressed map to something more standard-sized (16 each direction); and just using the biome ID as an additive variation to the ground sprites.
So... making and managing tables. What's up with that? Ideally, I'm making a table with a label of the scene's ID (to be referenced alongside it), then to make each new corridor tie to a door ID, the scene it transitions to, and the door's "type."
So the table should be something like:
Door1, SID(22), 0
Door4, SID(24), 0
Door7, SID(25), 2 **let's say this looks like a standard wall, explosives open it
...and then everything "null" will simply be filled in with standard wall/floor tiles.
So what's the P8 equivalent of this?
[Please log in to post a comment]