This is supposed to be the starting area for the Another Knytt Stories Collaboration Level collab project (the proposed idea being "The Cursed Gallery"). It's currently 16 screens long.

Some notes that may or may not be of interest:

* Features a freshly new tileset made almost from scratch and a couple COs for the lighting effects. There are still 3 unused tiles in the set, suggestions for these are welcome.

* Since this is just a hub area with no challenges, there's not much to do here, but I suppose it can still be somewhat enjoyed as a simple playground level and "appreciate the art" while taking a relaxing walk.

* There are 10 big framed portraits with a golden plaque that can be used as access points to the other upcoming areas of the level (if the final number of areas end up being less, it's just a matter of removing a few plaques).

* All the portrait pictures are just placeholders for now. I made the area in a way that only tileset A is needed in every screen, so tileset B can be used to hold the preview pictures for each area (plus other decorative pictures). The picture for each frame has to be cropped by 4 pixels from the outer border and overlayed over the background texture ("Tileset19.png" may serve as an example).

* The door at the end can be used as an ending room that would only be unlocked once the player has finished the other areas or accomplished any specific goal (collecting a certain power, all KS+ coins/artifacts...)

* The stairs at x1000y1000 and x1005y1000 caused a wallswim when they went all the way up due to the triangular collision mask, so I resorted to cut them off at the upper border and make the last step a simple jump. If anyone knows of a more elegant solution, please tell me.

* No KS+ features used for now, but if the whole level ends up requiring KS+, I wouldn't be opposed to adding some extra lighting effects and bonuses.

Find all bottles to move onto next stage. Avoid skeletons.

Use arrows to move, X to jump.

A tribute to CGA IBM compatible games and to jfroco's Skeletons in the Closet, a tribute to Sinclair ZX Spectrum games.
____________________
Here is my very late submission to this most excellent idea for a game jam! As Danni said about the original Skeletons in the Closet, "This is neat but it needs way more levels." So I present to you, Skeletons in the Closet PLUS! Whereas the original game had only three levels, this enhanced port gives you TWELVE.

jfroco's game is a tribute to the style of ZX-82 games, which they grew up on. I really liked the game when I played it in the GDC Pirate Kart. Personally, I don't have any particular nostalgia for the Spectrum, but my equivalent would be early Apogee-type shareware platformers . So my little headcanon is that this is the MS-DOS port from the late 1980s that alters the original Spectrum game, moves things around, and expands it a bit. All three original stages are adapted for this version!

Link to original game: https://www.glorioustrainwrecks.com/node/3053

(If this game gets too hard, use the secret cheat code for more lives: Hold down L and press Space!)

Shovels are falling, clean the stage!

How to play:
- Move with the left and right arrow keys.
- Jump with the up arrow key.
- Run with Z

Made with Godot.

Source code here: https://github.com/mrcdk/tinned_jam

Type "Two Hours" as many times as possible in two hours. Not fun. Flashing colors warning. PC/Mac/Linux.

GAME INSPIRED BY DESKTOP DUNGEONS

ENJOY RPG FIGHT

It's basically the beginning of a Metroidvania game about retrieving tacos. I didn't come further than that... but has a proper ending, promise!

every day imgur is not dead is another little miracle.

so those in that game would be gems. but what's up with that?

firstly this is all about an upcoming (not anymore, it has already released) version of jumper 4 real.
secondly i should talk about how saves work.

for the most part everything about a save slot is stored in a file named slotN.txt where N is the slot number. it is a pretty human-readable format. here's an example:
https://pastebin.com/raw/HWbdkX6f

gems, however, are stored in a different file, slotN.j4g, in a condensed format. (j4g is a format i came up with short for "jumper 4 gems".) this is partly so collecting a bunch of gems doesn't take up a bunch of disk space, and partly so that it's much quicker for the menu to just read off how many gems each slot has. in future i may put other info the menu wants to read quickly here as well, like how many different rooms the user has triggered the "you win" screen from.
here's the j4g specifications. you'll note there's no header.

big-endian

2 BYTES UINT16 {BLUE GEM COUNT}
2 BYTES UINT16 {RED GEM COUNT}
12 BYTES {RESERVED}
2 BYTES INT16 [THE X POSITION OF THE 1ST BLUE GEM; SIGNED]
2 BYTES INT16 [THE Y POSITION OF THE 1ST BLUE GEM; SIGNED]
2 BYTES INT16 [THE X POSITION OF THE 2ND BLUE GEM; SIGNED]
2 BYTES INT16 [THE Y POSITION OF THE 2ND BLUE GEM; SIGNED]
... {AMOUNT OF BYTES TO READ IS DETERMINED BY BLUE GEM COUNT}
2 BYTES INT16 [THE X POSITION OF THE 1ST RED GEM; SIGNED]
2 BYTES INT16 [THE Y POSITION OF THE 1ST RED GEM; SIGNED]
2 BYTES INT16 [THE X POSITION OF THE 2ND RED GEM; SIGNED]
2 BYTES INT16 [THE Y POSITION OF THE 2ND RED GEM; SIGNED]
... {AMOUNT OF BYTES TO READ IS DETERMINED BY RED GEM COUNT}

up to four versions of this file exist per levelset: slot 1, slot 2, slot 3, and combined (union)

"the x position" and "the y position" refer to the x and y position of the room the gem is in.
(what you would call "levels", jumper 4 real would call "rooms", and every room is somewhere on a grid spanning from -32768 to 32767.)
(if there's multiple gems of the same type in the same room, there is a mechanic where all of them turn out to be holograms except the last one you try to collect.)

"combined (union)" is this:

named "union" because it is the "union" of all gems you have across all savefiles (as well as deleted savefiles). it's like a permanent progress indicator.
whenever you collect some new gems and go back to the menu, when the game writes what new gems you've collected in save slot N, it also tries to update the "union" file. it cross references with all the gems you have in slot N and ticks off whatever gems are already present in the union file, and the remainder gets appended.
well not actually "appended" since the structure of j4g files means new blue gems have to be inserted into the middle of the file, and also i implemented it really weirdly such that the "union" table of gems effectively gets replaced with the "slot N" table of gems and then has the gems that aren't in slot N appended to it, but that part doesn't really matter since lua's pairs function has no defined order and that's how i iterate through all the gem tables anyway (the key is a room position and the value is true).

but now you may be wondering about that number to the right of the /. you may be wondering how the menu knows what the total amount of each type of gem is, without manually scanning every single level for gems.

the answer is... it doesn't! it just checks two variables you set from the editor. (if either of them are 0 or left empty, then it doesn't show the gem total at all. also, there is nothing stopping you from lying about the total amount of gems your levelset contains.)

however, the editor does have a "recount gems" button that automatically totals up the amount of gems every room has.
how are rooms stored? well hey i have another freaking pastebin link woah.
https://pastebin.com/raw/625G65ES

OK THIS PART OF THE POST IS ABOUT HOW ROOMS WORK.

map data itself is two bytes per tile - the first byte being a "bank" (though this, like many other decisions, is entirely arbitrary and not really enforced) - with the additional restraint (for the time being) that every byte has to be printable ASCII. also there's some hacky compression for rows that are all the same tile or adjacent rows that are identical.
you'll notice there's no separator between each tile. this might lead you to believe "oh, ok, so you used some string buffer thing, and you check an initial byte to see if it's | and if so you know it's map data, and from there on you consume 2 bytes at a time" but no!!! i wrote a stupid custom string split function that specifically only splits across multiples of n (2 in this case). that was back when i didn't even know string buffers existed. where were we? oh, right.
so right away there's a problem: we can't just use string.find for the 2 bytes that comprise a blue or red gem, because what if i got really pressed for space for some reason (95 tlies/objects per bank isn't infinite!!) and started using using { or | as a bank? then if it were right next to a tile that ended in O, it falsely finds O{ or O| and thinks it's got a gem. but it don't! and it's not possible to tell what parity a tile is on except relative to the last newline (not to the start of file).
so i COULD just write another hacky mess that's like string.find but only for specific parities and also considers the last line break to be parity 0. but i had a better idea that was way faster.
up to this point i had three agreed-upon "starting characters" for this pseudo-format i saved as .txt:

1. ===. indicates a header, kinda like puzzlescript. and yes it has to be exactly three =s because uhh it looks nice. also there has to be a === at the end too. the main bulk of the header is expected to be ONLY UPPERCASE LETTERS, but it can have a : to denote a "phase", which can be UPPERCASE LETTERS INCLUDING NUMB3RS.
2. |. indicates data of any sort. can rarely have lowercase letters before it, usually to indicate what type the following data is (number, string, bool).
3. >. indicates a "command", like duplicating rows of map data, or switching how data is interpreted (like a sub-header). i think a long time ago i had an internal rule that commands should all be 3 letters long but that doesn't matter anymore, and anything that can follow a | can follow a >.

is there some central parser that knows what to do with all these characters? no! no there isn't. in fact, i've probably written roughly the same parsing code about 4-5 times, with the difference mainly being where data goes and what commands do.
so to store what gems are in a level at the very start of the file more easily, i introduced a fourth character:

1. !. indicates arbitrary-ish bytes follow. all bytes must have the top bit set so none of them will be ascii, and the byte sequence is terminated with a zero-byte. (and then a line break.)

so now every room has a header starting with !, 0x80 (np++ assigns this to €), and a zero-byte..
whenever a room is saved, the process that jots down each tile also checks if that tile corresponds to a blue gem or a red gem. if it's a blue gem, it flips the last of the 2nd byte of the header. if it's a red gem, it flips the penultimate bit of the 2nd byte of the header. i.e. blue gem only is 1, red gem only is 2, blue gem and red gem is 3.
and the "recount gems" button just nips the first 2 bytes of every room in the levelset.
it checks the first byte. if the first byte isn't !, then it notes that the room is using an old version of the level format with no header, and it will print how many such rooms it encountered once it's done counting.
then it checks the second byte. if the last bit is set, it knows the room contains a blue gem. if the penultimate bit is set, it knows the room contains a red gem. so it just sums all that up and then fills the textboxes above it with the results it got.

in retrospect, having introduced a header into my level format, i probably should have had the first byte (well, last 7 bits of the first byte) be a version number instead of gem information, so if i make any more silly changes then i can know definitively what version of the room "format" each room was saved with.
indeed i should. but so far, i haven't.
yay!

I tried making a Playtomic account that can see all the stats but not actually change anything.
site: http://www.playtomic.com
username: PirateKartKontributor
password: 2012inone

After logging in, click "2012 IGF PIRATE KART" on the left.

The per-game data is in Level Metrics. Once you switch to that you can check the boxes for the different "counter metrics" to see how much each game got clicked for each version. (viewing it as values is a little nicer than percents).

Unfortunately, the very high numbers of plays on a few of the v1.0 games isn't indicating popularity, but rather that I screwed up and those games didn't launch, so people clicked them multiple times.

Remember the last time we collaborated on a single Knytt Stories level? How about now? It was pretty awesome, right? Yeah, I thought so too.

Well, Knytt Underground is supposed to come out before the end of the year, which signals the end of an era - an era where Knytt Stories was the only game, ever. I figure that we need to send it out in style with ANOTHER BADASS COLLABORATION from the Trainwrecks club. It'll be like an Irish funeral, where instead of getting all sad about death, we all get drunk and write insane poetry that doesn't make any sense.

Yes I am stereotyping no I don't care.

So, who's down for this? I'm thinking we can do it the first week of December so it doesn't interfere with Thanksgiving, but I'm up for suggestions.

YEAHHHHH.