Opera GX Game Jam - Technical Guide To The Rules
Opera GX Game Jam - Technical Guide
The Opera GX Game Jam gives you a chance to become part of Opera GX history, by creating a game for the ‘No Internet’ page of the browser. There are a lot of rules you need to follow to make sure your entry is qualified, and this post aims to answer some of your technical questions regarding these requirements.
For information on all the rules and guidelines, please see the jam page on GameJolt.
Here are the rules we’ll cover in this post:
- The game must incorporate the mystery theme
- The game should be playable on HTML5
- The game should be around 5MB or smaller
- The game should be playable offline (no remote data loading)
- The game should have a high score counter
- The game should be available to play in an endless mode
- The game should have local multiplayer OR be compatible with multiplayer
“The game must incorporate the mystery theme”
A mystery theme will be announced when the jam starts, and your entry must incorporate this theme in any way, whether it’s the art, the story, the gameplay or anything else where the use of the theme is clear.
“The game should be playable on HTML5”
Ever played a game in your browser? Chances are those games were made in HTML5, unless you’re playing something from the ancient Flash era.
GameMaker Studio 2 has an HTML5 export that you can purchase separately, but luckily all GX Jam participants will receive a free HTML5 licence that will be valid throughout the jam period. This means that even if you don’t own any GMS2 licences, you will still be able to compete and create your own browser game.
Using HTML5
Starting your game in HTML5 is fairly straightforward: you need to open the Target Manager (from the top-right corner of your IDE) and select the HTML5 platform.
You can then run the game, which will be opened in your default browser. Even if you have the Desktop licence, it is recommended to use the HTML5 platform for testing your game during development, so you can see any HTML5-specific bugs early and ensure maximum compatibility with that platform.
During development, you can press F6 to run your game in debug mode which will open it much faster (as this doesn’t perform code obfuscation).
For more information, see Setting Up For HTML5 on the helpdesk.
Debugging HTML5
As a simple rule of thumb, make sure to clean your asset cache every once in a while, especially if you’re facing graphical issues in-game using the HTML5 export.
When your game has an error or a bug that causes a fatal crash, you will, in most cases, see a black screen, which indicates that you have an error. For debugging such errors, make sure to run the game in Debug Mode (by pressing F6 or clicking on the 
Debug button). Once the game has loaded in your browser, you can click on the URL bar and then press F12 to open the Developer Tools.
From the Developer Tools, select the “Console” tab where you will see the output log of your game. Any errors will appear here in a red colour and you can expand them and look at the stack trace to find the culprit.
Note: It’s important to run your game in Debug Mode if you want to look at the console, otherwise all of your code will be obfuscated and you will not be able to recognize any asset or function names in the stack trace.
You can also use show_debug_message() in your code, which will output the given string into this console.
Note that in some cases, your HTML5 game might not even throw an error. For example, if you try to use a variable that wasn’t created or wasn’t given a value, it will not throw an error and will instead return undefined.
For more information, see Debugging Your Game In The Browser on the helpdesk.
“The game should be around 5MB or smaller”
This is an important requirement as the game will need to be small in size so it loads as fast as possible and takes the least amount of space.
Compressing Textures
One easy way of reducing the size of your game is to use the PNGCrush pragma. Basically, you can create a script and drop this inside it:
[object Object]
This will compress all of your textures at compile time, however it may increase the time it takes to build your game, which is why you should only use this when you’re creating a final executable for your game.
For more information, see gml_pragma().
Compressing Audio
You can compress your sound assets by changing their attributes. Make sure to use a compressed option for each sound asset, and your audio files will be much smaller.
See the manual page on The Sound Editor for more information.
“The game should be playable offline (no remote data loading)”
You can usually make the main game package smaller by loading most of your game assets at runtime from a web server, however that is not allowed for this jam. The game must be fully self-contained and require no internet access for any of its features.
In most cases you will have nothing to worry about, as GameMaker Studio 2 will always package all game assets into the generated ZIP file so it can be played offline.
“The game should have a high score counter”
The game should store the player’s highest score in a separate variable, and have it displayed on-screen either all the time or when the player loses.
This can be achieved by performing a simple check whenever the player loses:
- If the new score value is GREATER than the high score value
- Set high score value equal to the new score value
The high score variable can simply be initialized at 0, and then displayed on-screen using draw_text() within a Draw GUI event.
The Fire Jump tutorial has a section on highscores, and although it is created using Drag And Drop, the same technique can easily be applied to GML.
“The game should be available to play in an endless mode”
This means that the game should be playable endlessly/infinitely until the player loses. Here are some examples of great endless mobile games: Android Authority
Obstacle Generation
Creating an endless game involves generating obstacles that the player has to dodge, which can easily be achieved using Alarms.
You will need to have a manager/controller object that can run these alarms behind the scenes. Set an Alarm in the Create event, create an instance of your obstacle in that Alarm event and set it to run again after a certain number of frames. This way it’ll keep looping and creating those obstacles until the end of time.
In the above example, rocks are spawned at the top of the room and given a random X position. The rock object has a positive vspeed so it moves down.
Our official tutorials Fire Jump and Space Rocks are all about creating an endless game, so make sure to check them out!
Difficulty Scaling
An infinite game isn’t fun if it keeps going at the same pace. You want the obstacles to get faster, spawn more frequently, and/or become harder to defeat.
For any of these purposes, you can create a global “difficulty” multiplier that keeps going up, and factor it into other values such as the spawn rate, speed, etc.
For example, you can use this multiplier on the spawn alarm and rock speed so they get faster over time:
Note that the alarm value is being divided instead of being multiplied as it’s a time value, and the shorter that value is, the more frequently the rocks will spawn.
You can also display this multiplier on-screen during development, so you can easily see what difficulty the game is running at and how fast it’s progressing.
“The game should have local multiplayer OR be compatible with multiplayer”
The game should either have a local multiplayer mode, or be compatible with local multiplayer design. Being “compatible” with local multiplayer simply means that the game’s design should allow for a local multiplayer mode to be added, meaning that your jam entry does not necessarily have to have local multiplayer -- although having it will may give you a higher chance at winning.
Local multiplayer simply involves there being two player instances instead of one, where each one is controlled using a different set of inputs. Then the game could only end when both players have lost, making it a competition between the two players to see who survives longer.
Note that if you add a multiplayer mode, it should be entirely playable on the keyboard and not require a gamepad to be connected -- so, for example, player 1 could use the A/D keys while player 2 uses the left/right arrow keys.
Again, if you feel like you cannot add a local multiplayer mode, you can submit a single-player game: just make sure the game’s design is not strictly single-player and allows for a second player to be added later.
Have Fun!
That sums up all the rules! Make sure to join the Opera GX Game Jam and create your own entry; also don't forget that you can get a free HTML5 export for GMS2 for the jam period!
Happy GameMaking!
Related blog posts
