Summer is almost over, but there is still time for Gynvael Summer GameDev Challenge 2019 - nobody's favorite gamedev competition with a set of arbitrary constrains/limitations put in place just to make it more challenging! And there are even prizes!

Newest rule update: 2019-08-31 (initial version, no changes yet)

P.S. If you actually like this challenge, please help spread the word around - there were 25 submissions last time, and we would love to beat that record!

Previous Editions:

• GWGC2018/19: games (online), rules, winners
• GSGC2018: games (online), rules, winners
• GWGC2017/18: games (online), rules, winners
• GSGC2017: games (download), rules, winners

Table of Content:

• Constrains and Rules
  • Game constrains / rules
  • Contest related rules
• Prizes
• How will the games be judged
• Hints, protips, random thoughts
• FAQ
• Final words

Constrains and Rules

Please read all the points - the game needs to meet all of the criteria below. See also FAQ section below for some official clarifications. And do note that the rules might be further clarified during the competition (based on past experience the clarifications will not restrict any options, but rather officially allow some loophole/gray area things). Any updates or changes to these rules will be in red prepended with the edit date.

Game constrains / rules

Create a game that meets the following requirements:

• The game must use a 2D side view (example 1, 2, 3, 4). The exact genre is up to the authors.
• The game must use only vector graphics. No bitmaps allowed! 3D models are disallowed as well.
• The game must have at least 15 second vector-animated intro (the intro can use any perspective, it doesn't have to be 2D side view).

The game also needs to meet the following technical requirements:

• The game must be made in client-side web technology that runs by default on the newest stable Chrome on Windows 10 (1903) - yes, that means HTML/CSS, JavaScript and/or WebAssembly (C/C++/Rust/etc). Flash/Java applets/ActiveX/etc are dead, don't use them.
• The game will be tested on a 1920x1080 LCD with Chrome in full screen mode - please make sure it works correctly in these settings.
• The size of the whole game (i.e. sum of sizes of all the files) must be at most 65536 bytes (everything, including all art, fonts, etc).
• All the game files and directories must use the 8.3 filename format (i.e. 8 letters for the filename and 3 letters for the extension or less). There cannot be more than 20 files + directories in total. Minor exception: feel free to use .html and .wasm extensions as well (but only these two; the 8-character file name limit still applies in these cases).
• The text in game, if any, must be in English.
• The game must have a title and a README.md file containing a description how to play.
• When in doubt, ask in the comment section below.

Contest related rules

• Submission deadline is 28th of September 2019 at 11:59pm (23:59) AoE - please mind the timezone!
• Games must be uploaded to GitHub and submitted by sending a link to the repository to e-mail addresses: gynvael+summer2019@coldwind.pl and gynvael+summer2019@vexillium.org.
  Note: if you wish you can make the repository private and add me (github.com/gynvael) as collaborator so we have access to it; after the deadline however you must make the repository public.
• Please be sure to include the title of the game and the author(s) of the game (names will be published; these can be nicknames) in the e-mail or/and readme file.
• Source code and all the scripts used to build the game (if any) must be included in the repository (alongside the ready-to-test directory with the game). By submitting the game its author(s) agree to the game being re-hosted by us for anyone to download and test once the competition is over. We won't be doing anything weird with the game after the competition, but we want participants to learn from each other after the compo is over.
• If you are using assets/sfx/music/etc created by someone else, please make sure their license allows you to use them for commercial purposes and redistribution. Please note that some licenses require proper attribution - be sure to meet these requirements.
• Games not following the rules/constraints will not be able to compete for prizes (i.e. in some cases, where it's obvious that the authors tried their best, we might feature them anyway, but they will not be able to win any prizes). That being said, we reserve the rights to still fully accept submissions that break the rules in a minor way (we define this as problems that are fixable within a minute or so and do not give the submission any unfair advantages). We basically do not want to ban submissions that have trivial mistakes like e.g. using a 9-character long file name (assuming it wasn't used to gain a few extra bytes of space of course), etc - these things won't change the result of the competition anyway, but it would be against the spirit of GWGC/GSGC to just ax these games.

Prizes

All prizes will come in a form of a giftcard for either amazon.com / .co.uk / .jp or .de, or steam (author's choice).
In some cases we might agree to the winners request for a giftcard at a different internet store, but this will be considered at a per-case basis.

Best Game Award:

• 1st place: 200 USD (or equivalent in different currency)
• 2nd place: 150 USD (or equivalent...)
• 3rd place: 100 USD (or equivalent...)
• Honorary awards (if any): 50 USD (or equivalent...)

How will the games be judged

• There are no written-in-stone rules about that, but...
• We'll focus on the overall game quality (gameplay/is it fun to play, aesthetics, graphics, sound, story, etc).
• We will totally ignore source code quality - please focus on the gameplay/etc. If the game crashes, but is in general playable (i.e. crashes are rare), we'll ignore the crashes too. Otherwise, for early submissions (i.e. early before the deadline), we'll contact the game authors about a fix.
• Our computers must be able to run the game smoothly (assume we have high-end PCs; assume we don't have military grade computational clusters).
• We will generally try our best (including consulting the game author if needed) to make sure that the game is running as intended by the creator, as long as eventual patches / resubmissions are within the deadline mentioned in above sections (submit early!).
• If we will invite more judges to participate (e.g. if we feel the need for a second/third/etc opinion or it turns out half of our family is taking part in the competition) they will follow the same guidelines.

Hints, protips, random thoughts

• Words of the day: rotoscoping (see this and this video), clipart, vector, tracing.
• Be sure to remember to include some sound effects. Music is a nice-to-have, but we don't mind if it's not there.
• Browse through OpenGameArt.org and similar sites - you can find good quality art there. But remember: no bitmaps/sprites/textures allowed!
• Browse through the FAQ section below - there are some additional hints / explanations there.
• Look at older / indie games for inspiration.
• You might also want to take a look at an archived video of this livestream - #46: How to approach competitions.

FAQ

Q: Can I use gradients?
A: Yes.

Q: Can I use SVG?
A: By all means!

Q: Can I use 2D canvas?
A: Yes, but only if you write your own vector-rendering engine that uses it. No textures/sprites/etc allowed.

Q: Can I use WebGL?
A: Yes, but only for 2D (no 3D models allowed). Also, no texturing allowed (gradients are fine).

Q: Can I use font / text rendering capabilities of SVG/HTML?
A: Yes, default fonts are fine since they are all vector. No bitmap fonts allowed obviously.

Q: To what extent can I use shaders?
A: Vertex shaders are fine, so are gradients in pixel shaders. No texturing and no bitmap-based effects though (e.g. no post-processing that would add blur).

Q: Can I use cel-shading shaders? These look like vectors...
A: These require 3D models, and 3D models are not allowed. And these aren't vectors technically.

Q: So, if my vector art is made of 1px x 1px rectangles and I put them in a matrix that just by accident looks like a bitmap image...
A: Please don't try to bypass the rules. There is no need to, and the style difference will be obvious at the first glance (and frowned upon).

Q: So, if I configure an SVG gradient to be really really fine grained and start to resemble JPEG compression more than a gradient, can I introduce bitmaps like this?
A: Please don't. See the answer to the question above.

Q: So, if I use this other trick I know to get a similar effect to when I would use a bitmap/sprite/texture, can I use it?
A: Again, the goal is to get a vector-style graphic. Focus on this instead. You will not get a high place if you try to mimic bitmap graphics.

Q: JavaScript? In Chrome? Seriously?!
A: Yes. Think of it as a challenge! Also, with a little bit more tinkering you can use e.g. C++ or Rust and compile it to WebAssembly (there are tutorials out there on how to e.g. connect WebAssembly with canvas, or how to minimize the size of a WebAssembly binary output file).

Q: But I don't know JS...
A: Isn't this a great opportunity to learn then? Also, see the above note on WebAssembly.

Q: People who know JS have a HUGE!!1 advantage.
A: Please note that we won't be looking at the source code of the game, but at the game itself (the gameplay, the overall feel, the aesthetics). And somewhat (un)surprisingly, you can win a gamedev competition without being an expert in a given programming language.

Q: Can my game download something from the Internet?
A: No. The test machine(s) will not have any network connection.

Q: Can I grab resources which are by default on the disk?
A: This won't work. The game will be hosted on a local HTTP server before testing, and the server will be set in such a way that only the files from the game directory will be served.

Q: So if I create a symlink that resides in the game directory but points to a resource in a different part of the filesystem...
A: No. Assume that symlinks won't work. Don't use them.

Q: What will be MIME types of the served files?
A: Whatever you need them to be - feel free to write down special requirements in a readme file. By default I'll rely on simple extension to MIME mapping, maybe with some help from libmagic.

Q: Can you add this specific HTTP header to be sent with some files?
A: No. No additional headers I'm afraid.

Q: Will your HTTP server send any Content-Encoding headers (gzip/br/deflate/etc)? I.e. can we benefit from HTTP transport encoding (compression) possibilities with regards to the file size limit?
A: The server will not send any Content-Encoding header at all. As far as we previously, tested Chrome does not attempt any decompression algorithms in such case. So no, this will not work.

Q: What if let's say... I have a trick that actually makes newest Chrome decompress such compressed data stream?
A: Should be fine, but please contact us first so we can double-check this.

Q: Why the file number / file name length limit?
A: The file name (especially of the main .html file) can be used in a clever way to bypass the size limit. Let's not go there this time.

Q: Does "20 files + directories" mean 20 files and 20 directories?
A: No, that would be 40. The number 20 stands for the total number of both files and directories (so e.g. '10 files and 10 directories', but not '11 files and 10 directories').

Q: What fonts do you have installed on the test machines?
A: Assume the default (i.e. fonts present after the operating system is newly installed). If you need to use any more fonts be sure to embed them in the submission (keep in mind the size limit though).

Q: Can I use any minifier / this custom compression trick I know?
A: Sure. As long as it works on the newest stable Chrome on Windows 10 that's fine with us.

Q: Will this one specific feature be enabled in the browser during judging?
A: Please ask in the comments - I'll check. A safe rule of thumb is to assume only the features which are enabled by default in the newest Chrome version (at the moment of judging) are actually enabled, and no other features are.

Q: Will WebGL / Webassembly be enabled in the browser during judging?
A: Yes (these are enabled by default).

Q: Will the Same Origin Policy be disabled?
A: No, it will be enabled.

Q: Can my game be a Chrome Extension / Plugin?
A: No. The game must basically be a standalone website.

Q: Are Flash / Java Applets / ActiveX / etc enabled?
A: No.

Q: What Chrome Extensions / Plugins are going to be present on the test machine?
A: None.

Q: Can I use this one specific library/engine/etc in the competition?
A: If the given library's/engine's/etc's license allows using it for commercial purposes and redistribution (without others having to pay any fees), then it's OK to use it. Please remember that its size still counts towards the 65536 byte limit and that the file names / directory names must adhere the rules.

Q: 65536 bytes? That's not a lot...
A: It's enough :) Size optimization is quite fun and there is a multitude of ways to approach this.

Q: 65536 bytes? That's way more than in some of the previous editions!
A: Yes! Think of all the possibilities! :)

Q: Does the game have to explain the basics ingame, or can a simple guide/manual be part of the submission?
A: No, please put these in the required README.md file. Please note the README.md file won't count towards the size limit.

Q: So, can the game load the README.md file and use resources/code hidden in it?
A: No, the README.md is not part of the game per se and so the web server will not allow the game to download it.

Q: Does the source code package count towards the size limit?
A: No, it doesn't. Only the files required to run the game count towards the limit.

Q: What size will the browser window be when testing?
A: We will test on full screen (F11) on an 1920x1080 LCD.

Q: There is no color limit this time?
A: Nope, no color limit! Use as many colors as you like! Though do keep in mind we will be testing the games on typical LCD displays.

Q: Uhm, typical LCD displays? What does that mean?
A: Most typical computer LCD monitors display only 6 bits per color (so 18 bits in total instead of 24 bits we're used to as programmers) and use tricks like FRC to try to emulate additional colors. The result is pretty good, but don't rely too much on the last two bits of each color value.

Q: What? Really? How do I check my LCD?
A: This website has a nice database of displays - lookup your monitor and check the "Panel bit depth" entry.

Q: When will the results be announced?
A: Assume mid October. We'll try to be as fast as possible, but it does usually take some time (it also depends on submission count).

Q: I never took part in any gamedev compo like this. Can I still participate?
A: Sure! It's a great learning experience!

Q: Can I blog / tweet / livestream the making of my game?
A: Sure. Keep in mind that you will be revealing your ideas to other participants this way (it's within the rules to do it though).

Q: Can I create a game with my friend(s)/team/etc?
A: Yes! That's actually pretty encouraged!

Q: My friends are graphic/music/etc artists, can they help me?
A: By all means!

Q: My English is'nt gret and theer will bee mistakes in an game's text. Is that a problem?
A: That's OK, we won't penalize bad English.

Q: Can I send a new version of my submission?
A: If it's within the deadline, then yes, feel free to submit a newer version (just push it to your GitHub repo). Please note that we'll only look at the newest version submitted before the deadline when judging the games.

Q: Can I submit more than one game?
A: Yes, but not more than 3 games. However please keep in mind that perhaps using more time on one game might yield better effects then spreading kinda thin on multiple entries.

Q: I would like to become a sponsor to make the awards more awesome!
A: Sure, get in touch :) (you can find our e-mails in the rules section above)

Q: What keyboard layouts will be used for testing?
A: Assume typical en-US QWERTY.

Q: I don't have a 1920x1080 monitor. What now?
A: You'll still have to somehow make sure the game works as intended in 1920x1080 before submitting it. To tests this you can open Chrome's Dev Tools and open the device toolbar (Ctrl+Shift+M shortcut; it's a "cell phone next to tablet" icon on top left of dev tools). The device toolbar allows you to specify the display resolution (i.e. type it in) and Chrome will auto-scale the website so you see everything on the screen.

Q: Can I have custom mouse cursors?
A: Yes, but they have to be vector.

See also the comment section for possibly more questions and answers. Feel free to also ask there if you have any questions.

Final words