Page 1 of 19

"(File)Size Matters" 64K Compo (Judging not underway)

PostPosted: Sun Feb 14, 2016 3:32 pm
by wildweasel
(File)Size Matters

Ladies and gentlemen, it's been a long time since we had any kind of contest at all around here. So, in the wake of recent discussions about how big mods are getting as of late, it's time we made some efforts into preserving file size as much as possible. So trim the fat, save on costly resources, and let's see what we can do in 64K!

Guidelines for the Contest
  • Mods should be developed for ZDoom-based ports. Please specify which port you developed for when you post your file.
  • Make as many submissions as you like, but only one will be accepted.
  • Your file size limit is 64 kilobytes (65536 bytes) in DOWNLOAD size. Therefore, the file as downloaded should be no larger than this.
  • Any compression method may be used so long as it is clear what the user needs to do with the file (i.e. if the downloaded file needs to be run with ZDoom, make sure the extension is WAD, PK3, or PK7; if it needs to be extracted, make sure the extension is ZIP, 7Z, RAR, or something similarly obvious).
  • You may target any Doom-engine game you like. You might even try making an entire game in 64 KB, if you want to go that route. Just specify which game is needed.
  • You may include any resource file that you see fit. Download size is the only limit, so be careful especially with sprites and sounds.
  • Your submission must be able to run on its own, i.e. nothing but the submitted file and its target port and IWAD. Your submission MAY NOT require any other external files.

What kind of stuff can I make?
Nearly anything! You could make a cool map, a gameplay patch, maybe a demoscene-style visual production, an ACS-based text adventure, maybe you lined up a bunch of Imps and Demons and rigged them up to play music. The sky's the limit (well, outside of the file size, anyway).

How long do I have?
Submissions must be in by midnight, the night of April 30th (Pacific Daylight Time). Here is a countdown clock so that you know exactly how much time you have left. I'll allow one day of grace period to get your entries in with no penalty; beyond that, I'll dock points (small amounts) for each day late.

How will I be scored?

  • Originality (points out of 20) - Considering the Doom modding community has been around pretty much since Doom became a thing, we have nearly 23 years worth of ideas floating around, so it is more important than ever to have a unique idea to stand out from the crowd. Therefore, points will be awarded to truly original ideas. It's not an immensely important score, though, because as said before, there are nearly 23 years worth of ideas already out there.
  • Execution (points out of 50) - Ideas aren't worth anything if they haven't been put into practice with skill; the Execution category covers everything from the overall feel of the project to the presence (or absence) of bugs and glitches. This is a wide-scoped category, since not everything being submitted is necessarily supposed to be playable, so it could cover gameplay, sound effects, graphics, usefulness (if it's a utility), things that specifically have to do with the submission when used directly.
  • Ingenuity/Technique (points out of 30) - Not so much the general idea behind the submission as any special tricks or unusual methods used to build the project. Creative use of Textures compositing to create "new" graphics without actually importing any new graphics, or one sound used to create several through pitch manipulation and mixing, unexpected weapon effects, clever scripting, or even unorthodox methods of keeping the file size down. I'll be dissecting all submissions to see just what makes them tick, and that's where this score will come from.
  • Penalty Category (minus points) - Breakages of rules, late submissions, and outright disqualification will be handled in this category. The only upper limit of how many points can be taken via penalty is the 100 points a submission can potentially earn through the other categories; I won't be giving scores in the negatives. With any luck, I won't have to use this category at all.

But Wait A Minute, You Said Something About Prizes?

I've given it a fair degree of thought, and decided that there won't be any prizes. You'll certainly have the right to brag about your win, in a similar fashion to the Cacowards; I might have to go Photoshop an award or something for you to use as an avatar for a while or something. I do also intend to distribute the entries (barring anything the submitters specifically don't want included) as one large file, sorted by score rankings and including the scoresheet. (I might have to consult the /idgames crew to see if they'd accept that.)

Re: "(File)Size Matters" 64K Competition

PostPosted: Sun Feb 14, 2016 4:14 pm
by jpalomo
I was thinking of posting something like this. I remember seeing the mutator contests on here. I never participated in those, but I might join in this time around. I'm guessing there is no restrictions on which version of ZDoom is required to run your submission?

Edit
Here are all of the entries posted in this thread so far:


And here is a useful tool posted by Dancso that compresses UDMF maps.

Re: "(File)Size Matters" 64K Competition

PostPosted: Sun Feb 14, 2016 5:50 pm
by YukiHerz
Lets hope i can come up with something.

Re: "(File)Size Matters" 64K Competition

PostPosted: Sun Feb 14, 2016 8:36 pm
by AD_79
Possibly stupid question incoming: Does the wad/pk3 itself have to be 64k max or is it the limit just for the compressed download?

Re: "(File)Size Matters" 64K Competition

PostPosted: Sun Feb 14, 2016 9:31 pm
by wildweasel
AD_79 wrote:Possibly stupid question incoming: Does the wad/pk3 itself have to be 64k max or is it the limit just for the compressed download?

The limit is for the DOWNLOAD size, so you can save some space with clever compression.

Re: "(File)Size Matters" 64K Competition

PostPosted: Sun Feb 14, 2016 9:34 pm
by AD_79
Gotcha. I'll see what I can do!

Re: "(File)Size Matters" 64K Competition

PostPosted: Mon Feb 15, 2016 12:30 am
by Nash
The only way anyone is ever going to get away with new graphics and not hit the size limit is through procedurally constructing new graphics - PER PIXEL - with crazy TEXTURE composition work. Or maybe write a tool to convert a graphic into a TEXTURE composite (I think someone did that here once). Even then, I don't know how many new graphics can you create and how well compression would work before the final archive hits 64KB. [EDIT] Busted: viewtopic.php?f=19&t=50859&p=886721#p886721

Too bad you can't procedurally generate sound in ZDoom though. :V

Re: "(File)Size Matters" 64K Competition

PostPosted: Mon Feb 15, 2016 12:47 am
by darkhaven3
I'll make something.

Re: "(File)Size Matters" 64K Competition

PostPosted: Mon Feb 15, 2016 1:04 am
by Arctangent
Nash wrote:The only way anyone is ever going to get away with new graphics and not hit the size limit is through procedurally constructing new graphics - PER PIXEL - with crazy TEXTURE composition work. Or maybe write a tool to convert a graphic into a TEXTURE composite (I think someone did that here once). Even then, I don't know how many new graphics can you create and how well compression would work before the final archive hits 64KB.

Too bad you can't procedurally generate sound in ZDoom though. :V

That's a bit unimaginative. Weasel himself showed exactly what kind of stuff you can do using TEXTURES and stock graphics without resorting to flat-out pulling single pixels.

Re: "(File)Size Matters" 64K Competition

PostPosted: Mon Feb 15, 2016 1:25 am
by wildweasel
Nash wrote:The only way anyone is ever going to get away with new graphics and not hit the size limit is through procedurally constructing new graphics - PER PIXEL - with crazy TEXTURE composition work. Or maybe write a tool to convert a graphic into a TEXTURE composite (I think someone did that here once). Even then, I don't know how many new graphics can you create and how well compression would work before the final archive hits 64KB.

Too bad you can't procedurally generate sound in ZDoom though. :V

From experience doing exactly that - manually! - I can tell you that you'd be better off using really highly compressed low-color PNGs for new graphics, because per-pixel, Textures code takes up more space by far, if you're working in anything bigger than, say, 8x8 pixels. Of course, the entire point is to be as frugal as possible; if you can pull off the effect you want with clever translation and stitching a couple of shotgun pump frames together, then why not? I'd be interested in seeing what kind of clever things people do, and the allowance for extra resources is mainly so people don't need to do crazy crap with Textures.

Besides, you'd be surprised how small you can get a sound effect if you drop the sample rates down to DOS-era standards, and even my most complicated code-only mod, ww-hticstyle, is a mere 35 KB in its current PK3 form.

Re: "(File)Size Matters" 64K Competition

PostPosted: Mon Feb 15, 2016 2:17 am
by Blue Shadow
[semi-serious]I'll be the first to participate: NC HUD -- 51 KB. Beat that, people! Yeah![/semi-serious]

Re: "(File)Size Matters" 64K Competition

PostPosted: Mon Feb 15, 2016 8:40 am
by kodi
What map formats take the least amount of space, in a compressed state or otherwise?

Re: "(File)Size Matters" 64K Competition

PostPosted: Mon Feb 15, 2016 8:55 am
by Captain Ventris
Ha, I've actually had a sort of mutator idea in mind for a side project. This could be a good reason to make it!

Re: "(File)Size Matters" 64K Competition

PostPosted: Mon Feb 15, 2016 9:48 am
by AD_79
kodi wrote:What map formats take the least amount of space, in a compressed state or otherwise?


I did a quick test map yesterday to answer this, as I was wondering the same thing. The test map in vanilla format was, if I'm remembering correctly, 3kb, while the same map in UDMF was 5kb. Note: these were both uncompressed.

Re: "(File)Size Matters" 64K Competition

PostPosted: Mon Feb 15, 2016 10:16 am
by Nash
I imagine UDMF would compress better though, since it's 100% text. I've compressed a procedurally-generated UDMF map from a 56 MB (!!!) .wad into merely 1.2 MB.