The limitations of PICO-8 can feel very strict but finding ways to work around them can be fun. Two of these limitations are map and sprite space. A cartridge can have up to 32 screens worth of map data and four banks of 64 8x8 sprites. However, half of this space is shared. For this game, I want to use as much map space as possible for levels, so I'm limited to only two banks of 64 sprites. With such limited space for sprites, it became apparent early on that sprite-based animation would have to be kept to a minimum.

One way to fit more sprites into less space is by combining two similar, low-color sprites into one, with the differences indicated by color. PICO-8's 16-color palette is indexed, so such sprites can easily be "corrected" to their intended color when drawn. The native function pal(a, b) tells the system to replace all instances of color a with color b until called again with different parameters (or reset by calling it with no arguments).

I've used this technique with the wave and grass animations seen in the first post. The tiles are only one sprite with the palette shifted accordingly at intervals. This is likely more easily understood visually:



The first two rows show the original sprites for the two-frame animations. The third row shows the sprites combined into one, as stored in the cartridge. Because there are two frames and two colors (the dark blue is drawn transparent), four colors are needed to indicate the differences:

yellow = light green only in first frame
orange = dark green only in first frame
red = light green only in second frame
purple = dark green only in second frame

And, of course, the fourth row shows what happens when the palettes are shifted using the code below just before drawing the sprites.

Code:

if wave_timer > 15 and wave_timer < 65 then
  pal(10, 1) -- make yellow dark blue
  pal(9, 1) -- make orange dark blue
  pal(8, 11) -- make red light green
  pal(2, 3) -- make purple dark green
else
  pal(10, 11) -- make yellow light green
  pal(9, 3) -- make orange dark green
  pal(8, 1) -- make red dark blue
  pal(2, 1) -- make purple dark blue
end

I'm making a side-scrolling shmup to introduce myself to PICO-8. It currently looks like this:



The game will have only a few short but challenging levels. The graphics will be relatively sparse, due in part to PICO-8's limitations but due mostly to my limited skill. There is space for 128 8x8 sprites; I'm using roughly half for background tiles and half for things that move.

I'm currently using 28% of the allowed code space and have implemented the following:
map loading and rendering
basic camera
horizontal scrolling
simple environment collision
simple actor-to-actor collision
player projectiles
enemy projectiles
HUD
simple particles
basic enemy AI

To do:
input map data for remaining levels
create AI and draw routines for enemies
determine enemy placement
implement game states and title screen
create sound effects
create music
tweak difficulty
and probably more

Are you familiar with the novels of Joe Abercrombie? This project has a very similar vibe.

Playing with NES restrictions. I'm not a pixel artist so it's pretty rough.

Thanks! We're trying to stay as close to NES games as possible.

The graphics, while excellent, are a bit beyond the capabilities of the NES. If it's simply "NES-inspired", there's nothing wrong with that. The art is great and the gameplay looks fun. But I feel it's only right to let you know it doesn't look very NES-like if that's what you're going for.

First, the aspect ratio looks to be 5:4. The NES screen is essentially square (256x240), and if displayed on a TV, stretched horizontally to fit a 4:3 aspect ratio (e.g. 640x480). Narrowing the display window would go a long way toward making it look more like a NES game.

Second, and probably most importantly, the palette limitations have been exceeded. For example, the screenshot of the "garden" uses eight different background palettes. The NES is limited to four simultaneous background palettes of three colors plus one shared color (usually black). The "fire pit" screenshot is closer; it uses five background palettes but would fit four if the bars in the windows were blue/purple like the rest of the background. The enemy sprites look fine but the character sprite is four colors plus transparency; the NES is limited to three colors plus transparency. Games could simulate more colors per sprite by overlaying separate sprites (e.g. Mega Man's face), but this cuts into the limit of eight sprites per horizontal line. The current character would need three sprites for the head and I believe four for the body, so at the body level, already half of the sprites for that line have been used. The NES is also limited to four simultaneous sprite palettes. If the character uses two, that leaves only two for enemies, etc. Both the "garden" and "fire pit" screenshots use five sprite palettes, assuming two for the character.

And lastly, none of the above takes into account the HUD, which has to fit into these restrictions as well. If using sprites for HUD elements, there can be only eight per horizontal line and they have to use one of the four current palettes. If using tiles for HUD elements, they have to be aligned to the grid and use one of the four current background palettes. This is why you'll often see NES games with HUDs that change color from level to level.

Conforming to these restrictions will make it look more NES-like, but will require compromises. If the compromises make the game worse, it's probably better to stick with "NES-inspired" and not worry about the restrictions.

It's visually fantastic. I especially like the layered environments and the menu screens.

However, I do have one critique: In the concept art, the main character's right wing is from an angel while the left wing is from a devil. In the gameplay videos, the angel wing is always facing the camera. The devil wing should be facing the camera when the character is facing left.

Anywho. I got the day/night cycle done!

I know this is a late response, so maybe you've already changed some things, but fading out the cast shadows as the light gets lower would be cool. It should be fairly easy to do in GML if you create a parent object for all sprites that are cast shadows.

I've played guitar for about 18 years. I started dabbling in piano and then keyboard about 14 years ago. I got into the "being in a band" cycle in high school, which didn't stop until about five years ago. Now, I just play by myself and occasionally record stuff with Reason/Record (which has become difficult with a baby in the house).

A couple bands I've been in:

What are you making this in?

Game Maker 8, using the excellent Grandma Engine by Matt Thorson.

If you're not sick of screenshots... I'm making some progress on area tilesets. The first is the caves and the second is the ruins. The sewers make up the lower portion of the ruins and thus share a similar style. There is a lot more work to be done on the caves but once finished, I'll have the majority of environmental pixeling done. Perhaps I can then move the DevLog progress bar up to 20%.

From the video, I can't really tell what the goal of the game is. Also, the idea seems kind of Kirby-esque, but it has the potential for some really fun gameplay.

I have a rough idea of the overarching goal and story, but haven't yet fleshed it out. Basically, from high-level goals to low-level goals, the game plays like this:

• Locate the main "boss" to finish the game
• Locate several power-ups to make progression through the game less difficult
• Solve puzzles to allow further exploration of the game world

Now that you mention it, the mechanic is very Kirby-like. I didn't really think of it that way because the player will be interacting more with the environment to gain powers instead of with enemies. When it comes down to it, I suppose both are essentially the same.

I don't understand why the color of the water is green while you use blue for some background elements.

That area is a sewer. As shown in the video, getting into the water makes the player smell bad.

I absolutely adore those clouds!

Thanks! I went through about five looks before settling on that one. The others were mostly horrible.


Updates:

I've deviated slightly from the standard Spectrum palette of 255/192 bright/dark. I'm now using 255/160 to create more separation between tones.

Here's a slightly updated version of the area style mockup shown above:



And another area style mockup:



I think I've settled on a general, cohesive style for the tilesets and will be completely redoing the "castle" shown in the screenshot above. It doesn't fit with the direction I've decided to go and was basically placeholder for testing, anyway.

So two more area styles to go and then I can get on to overall game flow and objectives along with general level layout.

Area style mockup with a new tileset I'm working on:

[Chroma]

Chroma is a temporary title for a game I've been working on for the past few months. Progress has been slow because I'm doing this in what little spare time I have, but slow progress is better than no progress, I suppose. It's basically a platformer with some action, exploration, and puzzle elements. Yes, I know, not original. But I like those types of games and I figure I'll be more likely to finish something I like to play.

The core mechanic is that there are six different "elements", each associated with colors. Touching certain objects of a color pass that color on to the player. The different colors provide different powers to the player which allows overcoming obstacles, etc. The drawback is the player can be only one color at any one time. There is no player death, only changing to a color that may be undesirable in the current situation.

Anyway, here is a short gameplay video and a couple screenshots.

Chroma - Gameplay Demo 01:

damn, i'd like to see that in action, it's simple looking, but you've also mixed in quite a bit of detail as well.

I'll make a DevLog and post a video there. Don't want to clutter up this thread with non-mockups.

That's some crazy good-looking retro Spectrum graphics you have there!

I'm using the Spectrum palette and restricting myself to one color with transparency per sprite/tile, but that's about it. I've got some pseudo-particle effects going on (i.e. the flames). The tiles and most sprites are 8x8, which is a bit challenging, but I'm no pixel artist, anyway.

Gorgeous!! 

Thanks! I'm not quite feeling that about it, yet, but I do like the sewer tileset. I did the hill tileset a while ago, have gone through several revisions, and still don't like it that much.

These are actually in-game shots rather than mockups. But I'd still like to know whether the style is worth continuing with or if it's simply awful.

I made an engine partly based on this one that has moving platforms, but I ended up using what you might call a workaround. Basically, the platforms push the player around without taking into account the mechanics of the engine. If there's a better way to do it that incorporates Grandma Engine's system more, I'd like to know too!

I was able to get it working the way I wanted with a similarly "brute force" approach. It's not elegant and I'm not a good coder so it's likely inefficient as well.

But it works for vertical-travel platforms and should be easy to modify for horizontal-travel. The player can fall through by pressing down and jump. If too close to the edge of the platform when hitting a wall, the player will fall off to avoid any stuck-in-wall situations (assuming the player sprite's hitbox is constant between animation frames). And any object can be made a platform by simply setting its parent to the moving platform object. In case anyone is interested in the code:

Added an empty parent object oMovingPlatform.

Added scrCheckPlatform:

Code:

if ((place_meeting(x, (y + 1), oMovingPlatform) or place_meeting(x, (y + 2), oMovingPlatform)) and (global.FallThroughPlatform == false))
{
    if (place_meeting(x, (y - 1), oMovingPlatform))
    {
        return false;
    }
    else
    {
        return true;
    }
}

In the begin step of oMoveable, added this line:

Code:

on_platform = scrCheckPlatform();

In the end step of oMoveable, added this after the similar code for scrCheckBelow:

Code:

else if (scrCheckPlatform())
{
    collide = true;       
    break;
}

In the step code of oPlayer, I added the platform condition to this section:

Code:

if ((on_ground) or (on_platform)) {
    accel = S_RUN_ACCEL;
    fric = S_RUN_FRIC;
} else {
    accel = S_AIR_ACCEL;
    fric = S_AIR_FRIC;
}

Still in the step code of oPlayer, I added this section just before the code for jumping (global.FallThroughPlatform is declared in the create code for oPlayer):

Code:

if (on_ground)
{
    global.FallThroughPlatform = false;
}

if (on_platform)
{
    if (keyboard_check_pressed( key_jump ))
    {
        if (keyboard_check( key_down ))
        {
            global.FallThroughPlatform = true;
        }
        else
        {
            vspd = S_JUMP_SPEED;
        }
    }
}

And then in the user defined event for vertical collision, I added this (the offset is 4 pixels because my player sprite is 8x8 with the origin centered):

Code:

if (scrCheckPlatform())
{
    ActivePlatform = instance_nearest(x, y, oMovingPlatform);
    if ((place_meeting(x, (y - 1), oFloor) == false) and (place_meeting(x, (y + 1), oFloor) == false))
    {
        y = (ActivePlatform.y - 4);   
    }
}

Has anyone added moving platforms, specifically vertical, to this engine?

I've made slight modifications to the original engine, including a tweak that allows the player to fall through a jump-through platform by pressing the jump key while pressing the down key. I'd like to use the jump-through as parent to the moving platform so the player can get on from below and get off by falling through.

My failed attempts, so far, have involved checks in the player step event. This has generally resulted in the player repeatedly falling with the platform (i.e. not "standing still" on the platform) while the platform moves downward, and simply falling through when the platform reaches the bottom of its travel and reverses direction upward. I have a feeling I could solve both of these problems by basing the player's movement in the current step on a look-ahead to where the platform will be in the next step. However, this would require specific code for each platform and each movement pattern. I'd rather do something more low level which would then be applicable to any moving platform without case-specific modification.

With that in mind, I assume I'll need to modify the core code of oMovable, in the end step. But that code is relatively foreign to me and I don't know where to begin modifying it. In general, I'm having trouble wrapping my head around how this should be done and any insight would be appreciated.

[Gladiator vs. Colosseum]

Gladiator vs. Colosseum

The first player controls a gladiator with the keyboard. The second player controls the colosseum, i.e. everything trying to defeat the gladiator, with the mouse. The gladiator has a set of basic moves (kick, punch, dodge) and gains special moves and other benefits by picking up objects thrown into the colosseum by spectators. The colosseum has a stable of enemies (giant insects, large animals, hordes of small animals, other gladiators), of which there are a limited amount per battle. This stable is represented by a grid of icons depicting each enemy and the number of each remaining. By clicking on an icon, the player in control of the colosseum sends enemies toward the gladiator. Once enemies are in the play area, they move and attack according to their own AI.

Doing well as the gladiator unlocks benefits when playing as the colosseum. New enemies, more handlers to allow a faster rate of releasing enemies, etc. The set of enemies for each battle may be randomized or chosen from pre-determined sets of enemies that work well together. Doing well as the gladiator also increases the amount of spectators and therefore the variety of power-ups that may be thrown into the colosseum.

Play style is similar to that of NES-era beat-em-ups (Double Dragon, River City Ransom, etc.) but on a non-scrolling play area; the entire colosseum is visible at once. Because of the keyboard vs. mouse control scheme, the game could be played by two players on the same computer or via network.

The_Maw: The palette and style remind me of Jurassic Park for the Genesis. I like the chunky, protruding rocks. And of course the light gives it all a great mood.