Therefore, welcome to the GWGC2018/19!
Submission deadline reached! Thank you for participation!
You can play all the submitted games at http://gwgc2018.gynvael.tv/
Newest rule update: 2019-01-31 (decided to accept submissions with trivial mistakes - see details below)
P.S. If you like this challenge, please help us spread the word around - there were 22 submissions last time, let's again aim at beating that record! :)
Previous editions:
• GSGC2018: games (online), rules, winners
• GWGC2017/18: games (online), rules, winners
• GSGC2017: games (download), rules, winners
Video brief by LiveOverflow:
Constraints:
Create a game that meets the following requirements:
• The game must be an unrealistic hacking simulator.
• The game setting must be: the player is a space marine's tech/hacker that aids a squad of space marines while they explore an abandoned space station.
• The game must be made in client-side web technology that runs by default on the newest stable Chrome on Windows 10 (1803/1809) - yes, that means HTML/CSS, JavaScript and/or WebAssembly (C/C++/Rust/etc).
• The game has to render in a 1920x1080 resolution (please assume Chrome in full screen mode at that exact resolution), however it must render this 
(EDIT 2019-01-26) One minor rule relaxation: the overlay doesn't have to be on top of the two screen areas, i.e. it's OK for the two screen areas to be rendered on top of the overlay's glass effect (rationale: we've received multiple submissions that technically broke the "on top" rule and decided that it was not the purpose of this rule to ban submissions that technically have some DOM element on top of the dedicated screen area). Please note that you still cannot render anything outside of the two screen areas (we might ignore minor off-by-one-pixel differences, but that's about it).
• The size of the whole game (i.e. sum of sizes of all the files) must be at most 128000 bytes (everything, including all art, fonts, etc). Please note that the provided overlay image does NOT count towards the limit (neither do the readme file, nor the source package - see FAQ for details).
• 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 text readme file containing a description how to play.
Contest related rules:
• Submission deadline is 31st of January 2019 at 11:59pm (23:59) AoE - please mind the timezone!
• Games must be submitted by sending a link to a downloadable package (hosted e.g. on Google Drive or something similar) and SHA256 of the package (see FAQ on how to get SHA256 of a file - it's near the very bottom), to the following e-mail addresses: gynvael+winter201819@coldwind.pl and liveoverflow+winter201819@gmail.com (please also add a comment under this post to confirm that you've sent an e-mail - otherwise we won't know that we didn't get an e-mail and can't debug it).
• 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 must be included in the submitted package (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). (EDIT 2019-01-31) 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 wrong name for the overlay file (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.
• When in doubt, ask in the comment section below.
Any updates or changes to these rules will be in red prepended with the edit date. Please check a couple of times during the competition if the rules weren't altered (in previous competitions we did update the rules a couple of times, but these were either really minor changes or some small exceptions to the rules; don't expect big changes).
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.
The prizes are sponsored by us - LiveOverflow and Gynvael Coldwind :)
Best Game Award:
Top 1: 250 USD (or equivalent in different currency)
Top 2: 200 USD (or equivalent...)
Top 3: 150 USD (or equivalent...)
Top 4: 125 USD (or equivalent...)
Top 5: 100 USD (or equivalent...)
Top 6: 75 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:
• Be sure to remember about the game having 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.
• 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: Why mention the "unrealistic" in the "unrealistic hacking simulator" phrase? Are there any special expectations there?
A: Real-world hacking requires a tremendous amount of knowledge and technical skills from the player, and in all honesty it can be a bit boring at times and takes a lot of time - this sadly doesn't make it a fun game. So let's not go there. Given this, we would prefer game authors to simplify things to make it a fun and enjoyable experience. In other words: do what Hollywood does in hacker movies - go wild :)
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 Gynvael has 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 enabled?
A: No.
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 128000 byte limit and that the file names / directory names must adhere the rules.
Q: 128000 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. Also, note that .kkrieger was below this limit.
Q: 128000 bytes? That's way more than in 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 text readme file. Please note the readme file won't count towards the size limit.
Q: So, can the game load the readme.txt file and use resources/code hidden in it?
A: No, the readme.txt 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 (excluding the foreground image, as mentioned in the rules).
Q: What size will the browser window be when testing?
A: We will test on full screen (F11) on either a 1920x1080 LCD or another one scaled down to 1920x1080.
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. One of our test monitors is like that, the other one is 8 bits without FRC.
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 February. 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!
Q: My friends are graphic/music/etc artists, can they help me?
A: By all means!
Q: My English isn't great and there will be mistakes in the 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. Please note that we'll only look at the newest version 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: What's SHA256? How to get SHA256 of a package?
A: In short, SHA256 is a (256-bit) number calculated out of a data set (e.g. file). Basically you give whatever-tool-calculates-it a file as input, and it gives you the number as output. The number is semi-unique for each content of the file, and it's pretty hard to fake the number or have another file (with different content) generate the same number by accident (i.e. it's proof that your package didn't change after submission and we can use it to verify whether the file was downloaded correctly).
An example SHA256 looks like this: 559aead08264d5795d3909718cdd05abd49572e84fe55590eef31a88a08fdffd (that's SHA256 of a file containing single letter A).
To calculate SHA256:
- on Linux/OSX run (in a terminal): sha256sum game_package.zip
- on Windows run (in a terminal): certutil -hashfile game_package.zip sha256
(assuming that the game_package.zip file is the game package you want to upload and submit for the competition)
If none of the above work for you, it's quite easy to google out another tool to calculate the SHA256 of a file :)
NOTE: If you're re-submitting a newer version of the game, you need to send us the new SHA256 as well.
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)
(EDIT 2018-12-25)
Q: What's with that funny overlay image rule?
A: We wanted game authors to do a game for two monitors. But we didn't want to force them to buy a second display. So the overlay image with two separate regions (two "displays") is what we decided on.
(EDIT 2019-01-06)
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.
(EDIT 2019-01-13)
Q: Can I have custom mouse cursors (it will render on top of the overlay)?
A: Custom mouse cursors are allowed, but they have to be sane/normal mouse cursors (and NOT e.g. 1920x1080 bitmap with hotpoint being shifted when the mouse is moving).
Q: The rules do say a "squad" of space marines - does this mean if there is only one marine you'll be disqualified?
A: After chatting with LiveOverflow we decided this part of the rules is not super important. So if you put in the backstory something like 'there was a squad, but most died, one is left standing' we're fine with that and won't take it against you.
See also the comment section for possibly more questions and answers. Feel free to also ask there if you have any questions.
Final words
Have Fun, Good Luck!
Comments:
Things are a bit busy so I might need to skip on this one.
Will do my best to make it happen tho :)
I did something similar last year when we were limited to a single file containing everything, and 20KB. I inlined and minified all my html/CSS/js source, gzipped + base64d the result and wrote it into a new html file, along with a script to unpack the base64d, ungzip, and write the result to document. This saved me a significant amount of space but was rather tricky to implement.
Generic space soldiers are fine :)
Fingers crossed that you can participate! :)
@luky
As long as everything is within size limit, file count limit, etc, then you're fine. I actually encourage using compression/minification (e.g. like the one Vassildador described) to fit more stuff in, but you do have to decompress it somehow at runtime :)
Note that you cannot use Content-Encoding headers for this purpose (see FAQ), but there is a whole bunch of different tricks you can use.
When submitting the game the overlay image file has to be the one which is linked in the ruleset (please note it will change around Jan 7th, so the gradient will change as well), i.e. it has to be identical (and if it's not, we will overwrite it with the proper one for testing).
When developing the game you are of course free to just remove the gradient if it annoys you. Just remember to bring it back when submitting :)
And can I submit it as a GitHub release?
Per QA, source code doesn't count (although it needs to be included in your submission). Only the files that are being sent to the web browser.
To quote
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 (excluding the foreground image, as mentioned in the rules).
You can host the files on GitHub, even during development as per FAQ [1], however the submission package has to be submitted as, well, a package [2]. So you would have to upload z ZIP or whatever to GitHub - this is related to the SHA hash requirement [3].
(I do realize that this requirement is *probably* redundant to what GitHub already offers, but then again just packing the files and calculating SHA256 is easy enough, so I would prefer not to make any exceptions there).
[1]
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).
[2] and [3]
• Games must be submitted by sending a link to a downloadable package (...) and SHA256 of the package (...)
@mishaor
Well, Thing1 already answered your question :). I'll just add another quote from the rules (note the second sentence):
• The size of the whole game (i.e. sum of sizes of all the files) must be at most 128000 bytes (everything, including all art, fonts, etc). Please note that the provided overlay image does NOT count towards the limit (neither do the readme file, nor the source package - see FAQ for details).
PS: I absolutely love the idea of working with two screens.
Q: Can I create a game with my friend(s)/team/etc?
A: Yes!
I would assume so, since that is more of a clarification of the rule, "The game must be made in client-side web technology that runs by default on the newest stable Chrome on Windows 10 (1803/1809)." So, unless using Unity broke any of the other rules, should be fine?
@Ziscus
"Q: Can I create a game with my friend(s)/team/etc?
A: Yes!"
Ad "can Unity be used?"
There are two key parts to the answer here:
1. Yes, you can use ANY library/framework/engine as long as it meets the other rules.
2. Please note that one of the other rules is that the submission is size-limited to 125KB (pretty unlikely Unity will squeeze into the limit?) and the test machine will NOT have Internet access (so it's not possible to download anything from the Internet).
Please check FAQ for more details.
@Zicsus
Ad "can we participate in teams?"
Yes, by all means! :)
Game files.
Game files must be 125KB (not 128KB, 125KB as in 128000 bytes).
Submitted package size is irrelevant.
@sunny
Sorry, I really don't have any specific recommendations. I usually use MDN (https://developer.mozilla.org/), various W3C specifications, sometimes W3Schools (while it's pretty limited on details, it is sometimes pretty handy for fast checking basic things), and then google out everything which is not there.
You might want to look for any resources with JS for game developers in mind. I loosely recall NoStarch having some books like that, but those might have been targeted for kids.
@Nickname
Size limit is calculated like this:
Sum of size of game files minus size of overlay image that is provided by us
Game files are files submitted by you which are required for the game to run correctly (usually one HTML file, zero or more JS or WASM files, any art resources like images, etc).
Please note that the submission package must contains the game files (these are limit bound), README file as well as game sources if these differ from the game files; e.g. if you've used a minifier on JS, then you must submit the unminified JS as well (neither the sources nor the README file count towards the limit).
@bor
A great question.
For simplicity sake let's assume that the overlay image must ALWAYS be on top for entries for this competition.
(Feel free to release a post-competition version which does things differently of course.)
@JosefKuchar
:)
Yes and no. As mentioned before, if you are able to carve stuff out from the framework to make it (and the game content) fit the 125KB limit, then it's OK for you to use it.
If you're not able to squeeze it (and game content) into the limit, then it will not be possible to use it.
A good question is whether it's even worth trying to carve out / compress framework code, or whether it's better to just write things from scratch.
Technically according to the rules the game's key element is the unrealistic hacking simulator - this part MUST be in the game. However the exact way you implement it, and whether or not you add e.g. a tactical layer on top of that, is up to you :)
Noted! I'll make sure the final template is less aggressive on the screens so the visibility there is better.
Q: What's with that funny overlay image rule?
A: We wanted game authors to do a game for two monitors. But we didn't want to force them to buy a second display. So the overlay image with two separate regions (two "displays") is what we decided on.
"
since the intent of the overlay image is to design a game with 2 'monitors', can we use our own overlay image so we can change the position of the screens and the overlay art? (Still keep the screen at 1024x768 & 720x480)
if were not allowed to change the overlay please tone down the glare effect as its very pronounced.
if the glare needs to be there are we allowed to use css blend filters / canvas effects to tone it down?
For the sake of rule simplicity, let's stick with NOT doing any changes by the players to the overlay.
As mentioned in the comment before, the glare on the screens will be trimmed down on the final overlay image.
Sizes were mentioned above in comments (1024x768 and 720x480)
top-left corners' coordinates are 183px:61px and 75px:1137px respectively if I am correct
It's as az said :)
The bigger screen is 1024x768 at x=61 y=183.
The smaller is 720x480, at x=1137 y=75.
@WoofWoofDoggo
See the FAQ entry quoted below.
In addition, to say it in a different way: Unless you're going to do a full x86/ARM/RISCV/MIPS/PPC emulator, or e.g. an HTTP(S)/WebSocket/DOM/HTML/etc emulator, then your game is going to be 'unrealistic' :)
Whatever you do, please make sure it's fun to play. It's not obligatory to make it non-technical if that is your question. But I would advise to simplify things vs real world hacking.
"""
Q: Why mention the "unrealistic" in the "unrealistic hacking simulator" phrase? Are there any special expectations there?
A: Real-world hacking requires a tremendous amount of knowledge and technical skills from the player, and in all honesty it can be a bit boring at times and takes a lot of time - this sadly doesn't make it a fun game. So let's not go there. Given this, we would prefer game authors to simplify things to make it a fun and enjoyable experience. In other words: do what Hollywood does in hacker movies - go wild :)
"""
A main menu without background music might be a bit boring, but perhaps finding a way to have your game start silent is a fun challenge as well.
There were no problems with this in the past competitions, so I don't really expect any problems now. The games will be probably tested and retested multiple times in random order, plus (as mentioned in the post above) we will try very hard to make sure the game is actually working as intended.
If you would like us to test a specific piece of code and how it behaves on our setups, just send it our way.
I don't think it's going to be a problem either, but I've been spending some time getting autoloaded background music to work and I'm just wondering if it's worth putting in the effort if autoplay is going to be disabled anyway. With autoplay, the ambient background noise sounds super nice on my localhost:8080 (As it has a very high MEI), but when rendering offline, there is only sound for a second or so before the menu animations end and the game begins. And this might be a problem with my code, but sometimes it just threw an error, blasted the background sounds on full volume, or played several instances over each-other when the user interacted with the site. Like I said, I've been trying to get a nice result either way, but it seems pretty hard to detect if autoplay is enabled, so I'd like to know what to expect.
I guess for simplicity we should all just expect the autoplay policy to be fully disabled (even when in reality there is a high chance that autoplay will work anyway)? I wouldn't want to torture anyone's ears :)
You can also get the SHA256 hash of a file in Windows using PowerShell (if you don't like using Command Prompt, just like me lol). Just run the command:
Get-FileHash -Algorithm SHA256 path\to\game_package.zip
This is easily Google-able, and some people might know this already, but it's fun to share. :)
Also, will the cookies be enabled, like to save the best score or the game progress?
And just for practical use, will you use QWERTY keyboards (to map the correct move keys)?
I'll discuss this with LiveOverflow and we'll decide whether to add a specific rule, or just assume 'Default' setting as is currently within the rules. Regardless, as mentioned in the contest details - we will try to make sure every game is playable as the author intended. Requiring autoplay to work for a game doesn't seem too far fetched as far as I'm concerned, so don't worry about it (but do note that it is required for ambient in the README file).
@Ineedhelp
Make sure the game works as intended in 1920x1080 when 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.
@ProgrammaticNajel
Will do, thanks!
@Originals
Sure, it's fine to have game instructions in game. Just make sure there are some instructions on how to play the game in the README as well (especially how to start playing the game if there is a high learning curve; not that required if it's easy to start).
About cookies: default settings, which means yes. Local Storage/etc will be there as well.
Both me and LiveOverflow use QWERTY.
Happy you like it :)
@kWeb24
Sadly no. Main reason is that I would prefer not to change such important rules so deep into the competition - sorry.
I know this is a wasted opportunity, but it's just too late for this level of change. Background story is that initially that part of an image was assumed to not contain anything like that, and the keyboard there appeared only after the artist tried a few things and decided it works best.
@ProgrammaticNajel
Only actual files on the filesystem. So if you bundle some files into an archive and somehow handle that in you're games code - that's totally fine with the rules :)
5-10 minutes is fine.
There is no strict rule about this, but the game should be playable long enough to sufficiently test it.
And if it's too short, the "is if fun to play" part of judging might not go to well :)
But 5-10 minutes is totally fine.
(e.g. top2 from GSGC2018 was beatable in 3 minutes; I do admit I was attempting to speedrun it over and over again though ;>).
@thePlayer
Excellent question!
We've chatted with LiveOverflow about it, and the decision is:
Custom mouse cursors are allowed, but they have to be sane/normal mouse cursors (and NOT e.g. 1920x1080 bitmap with hotpoint being shifted when the mouse is moving).
I'll add this to FAQ.
@ottomated
Hah, good question as well.
After chatting with LiveOverflow we decided this part of the rules is not super important. So if you put in the backstory something like 'there was a squad, but most died, one is left standing' we're fine with that and won't take it against you.
Are you asking in context of WebAssembly? If so, look in the WASM specification - it defined endiannes:
https://webassembly.github.io/spec/core/binary/values.html#integers
TIL. I must admit that in my wildest dreams I did not expect a high-level language like JS to have platform's endianness exposed anywhere. Woah.
Anyway, we'll be using standard x86-64, which means little-endian.
To quote my reply from one of the above comments:
"Sadly no. Main reason is that I would prefer not to change such important rules so deep into the competition - sorry.
I know this is a wasted opportunity, but it's just too late for this level of change. Background story is that initially that part of an image was assumed to not contain anything like that, and the keyboard there appeared only after the artist tried a few things and decided it works best."
The initial reports the space marines got is that it's abandoned. But what's really on the station and why was is abandoned... who knows :)
Sadly no, sorry.
I plan to load some local resources that are included in game package (e.g. JSON file) and I want to know if I could expect issues with CORS.
Nah, don't worry about that - we'll run the game in full-screen mode.
Per FAQ:
Q: What size will the browser window be when testing?
A: We will test on full screen (F11) on either a 1920x1080 LCD or another one scaled down to 1920x1080.
@jamro
We're going to be using a local web server.
Per FAQ:
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.
Maybe someone can use this as an inspiration. Happy coding, have fun and good luck for all participants.
I have just submitted my game: Sigma-18
@Silverdark
Ah, too bad :) You still have a couple of days to finish and submit it though!
I have just submitted my game: H4x0r's Quest
I sent "Haxor2000" game to you.
I prototyped a couple of gameplay ideas, but none of them were particularly fun to play. As I'm mostly joining these challenges to test mechanics for potential future games I wasn't willing to spend the little time I had on making something unfun. While previous editions' restrictions kept me incredibly focussed, cutting all extra fluff, to get to a good core gameplay loop, this one couldn't do it for me.
Hopefully I'll have another shot in summer!
Good luck to all the participants, I'm looking forward to finding out what everyone created!
@Vassildador: Haha yeah, the topic is quite different from the other ones this round. Hope you can come back for GSGC2019 :)
Cheers,
GameMoon and Rou Bang
I have just submitted my game: Hax4Space
-Max
Resent my e-mail to confirm I am now "Tech Support (in space)"
When I came back today to check on the progress and saw the final overlay I instantly knew what I wanted to make, only to be dismayed I missed the boat... at least on the bright side I know what I'm doing this weekend :-D
Thanks for the awesome competition & inspiration!
Add a comment: