The Sonic Hacking Contest takes quality control very seriously, but we also try to keep things reasonable so that newcomers with a unique, interesting project to showcase are still able to comfortably pass and participate in the event. Let’s start with a couple basic guidelines that apply to all categories:
- All entries submitted must be playable in some capacity. The Sonic Hacking Contest is not an appropriate venue for cutscene-only entries, techdemos, or entries which feature a minimal amount of gameplay or interactivity. This is a video game centric competition, after all.
- All entries submitted must be relatively stable. A few minor glitches here and there or an occasional crash on a non-standard hardware configuration is expected and permissible, but if your entry contains consistent errors or crashes that disrupt normal gameplay for a plurality of Judges, we will unfortunately have to reject your entry.
- All AI usage in entries must be thoroughly and honestly disclosed. Every entry that makes use of AI-based tools in the creation of code or assets must disclose that they have done so and to what extent when submitting their entry. Overeliance on AI tools or use of AI-authored assets, such as generated images, music, and other audiovisual elements, is grounds for rejection from the contest. We are evaluating entries based on human effort and artistry, so please, be human.
If two-thirds of Judges agree that an entry is not up to the standard of quality we wish to showcase at the Sonic Hacking Contest, the entry will be rejected. The authors of any rejected entries will be given formal notice and reasoning as to why their entry was rejected, with a chance to appeal the decision if they disagree with the assessment provided.
In addition to the cross-category guidelines, each category has its own set of category specific guidelines, presented as an example-based list of do’s and don’ts. Please take a look:
Simple palette, art, music, and sound changes.
Simple code edits or player handler changes.
Simple layout modifications of dubious quality.
Noticeable changes to audio-visual assets of acceptable quality.
Custom levels and/or extensive layout modifications of acceptable quality.
Custom game logic/code edits that extend beyond what is achievable through publicly available guides and tutorials (i.e. custom level events or objects).
Major changes which affect the core gameplay formula, ruleset, or other mechanics.
Simple art or audio changes.
Simple physics changes.
Simple layout modifications.
Custom or modified levels that are beatable and around the same duration or longer to the original game's levels.
Collections of art changes, including sprites, textures, models or audio.
Collections of small noticeable changes, such as bugfixes.
Major changes to the way a playable character works.
Additional mechanics or major changes to a core mechanic of the game, like Special Stages or a general mechanic.
Simple texture only hacks.
Simple object layout modifications.
Simple model swaps of existing game models.
Collections of custom models, assets, objects.
Custom levels and/or playable stages of acceptable quality.
Custom game logic/code written in assembly or existing game logic hooked using arbitrary programming language (C/C++/C#/D etc.)
Modification(s) that change features in the playable game itself.
The following entry types are acceptable submissions to the Contest regardless of whether they meet the above Quality Control Criteria.
Pick at least 1 of the following:
A. Complete change to the rules of a Sonic game. (Example(s): Sonic Bash v2, Boss Rush Hacks, Dungeons of Soleanna, Roller in S3AIR)
B. Overhaul into a whole new game. (Example(s): Sonic Forces Overclocked, Hellfire Saga, Sonic Essence)
C. Technical feat(s). (Knuckles' Clackers, Lantern Engine, DOOM in Sonic Mania)
D. Translation entries that translate a game into a language it was never originally localized into, while offering no other changes (Unjudged only).
Effective this year, submissions that have appeared previously at the Sonic Hacking Contest will undergo additional conditions.
If your entry has been submitted to SHC in the past, before being considered for the event, it will be tested for Quality Control against itself. This means that your entry will be compared against the latest version that has been submitted to the Contest previously.
Entries that have not made significant changes since their last submission to the Contest may be rejected.