CMSC 22000 Final report

Quarter: Spring 2025

Feature: Interactive Fiction

Design and Implementation

Our team was the first to implement the Interactive Fiction (IF) functionality within the ChiGame platform, aimed at supporting creators who use tools like Twine to publish their story-driven, single-player games. The goal was to create a full pipeline—from upload to public play—for showcasing interactive fiction on the platform in a way that preserves the unique traits of IF while staying consistent with the general ChiGame UX/UI principles. Traditional game submission on ChiGame includes elements like player limits and match mechanics, which are irrelevant for IF titles. Interactive fiction is, by nature, self-paced and single-player, and the design of our components reflects this core distinction. To accommodate this, we built a separate game creation interface specifically for IF games, while integrating the rest of the user experience with shared platform components like genre selection, label tagging, and media upload.

We created a dedicated view (InteractiveFictionView) and route for IF game creation, supported by a custom Django form and a new HTML template (IF_create_game.html). This form is entirely distinct from the multiplayer or general game submission form and includes only the fields relevant to an interactive fiction experience. The major sections of the form include:

• Game metadata: Name, Author, Description, Genre, Year Published, Rules
• Media: Cover image upload via a styled drag-and-drop zone
• Game file upload: A .html file exported from Twine
• Optional fields: Content Warnings, Custom Labels, and Rules
• Community features: Toggles for allowing comments and enabling ratings

To simplify the user experience, we implemented two custom file upload zones using drag-and-drop styling:

• A zone for uploading a Twine-generated .html file, which is the actual interactive fiction game.
• A zone for uploading a cover image, with a live preview for user verification.

We use JavaScript to validate file types before submission. The image zone accepts only image/*, while the game upload zone enforces the .html extension. Files are previewed inline: uploaded images are rendered as thumbnails, and HTML file names are displayed with an option to deselect or replace. We also added a Preview Game button powered by the JavaScript FileReader API, allowing creators to open a local preview of their Twine file in a new tab before submission, helping ensure correctness and functionality.

We also built a dynamic label input section using the Choices.js library. This lets creators:

• Select from predefined labels across six categories (Tone, Accessibility, Language, Difficulty, Length, Release Status)
• Add their own custom labels via an input and an "Add Label" button

Though the backend does not yet persist these labels as structured data, the groundwork has been laid for a future Label model. The current implementation adds custom labels only on the frontend for review in the submission modal. Integration with the platform-wide label system (maintained by the Game Management team) is a clear next step.

Another major usability feature is the submission confirmation modal, which allows users to confirm their content before publishing and improves data hygiene across the platform. Specifically, it:

• Displays all user inputs in a clean, readable format
• Prevents final submission if required fields (like Name, Author, Description, and Game File) are missing

We also placed strong emphasis on accessibility and helpful UX design:

• Tooltips are embedded via a custom help icon next to the file upload section. Hovering reveals a step-by-step guide on how to export a Twine story as an HTML file, including links to the official Twine documentation.
• Character counters update in real time for all text fields with limits, turning red as users approach the maximum, which helps reduce frustration and prevents server-side form errors.

Once an IF game is created, it is linked to an Interactive Fiction Game Detail Page. This mirrors the layout of the general game detail page but has several tailored adjustments:

• Replaces the "Play Match" and "Join Match" buttons with a "Play Game" button that directly loads the uploaded .html game in a new view.
• Displays only relevant IF metadata, omitting multiplayer features such as team sizes or match types.

This separation helps preserve clarity in user expectations between standard games and IF experiences, while maintaining a consistent look and feel across ChiGame.

Under the hood, to support Interactive Fiction (IF) on ChiGame, we extended the existing Game model rather than building an entirely new structure. We added a twine_file field to store the uploaded Twine HTML game, as well as fields for genre, content_sensitivity, and content_warning. This approach allowed IF games to integrate seamlessly with ChiGame's core features, including reviews, favorites, and homepage listings. While we created a subclass called InteractiveFictionGame for future extensibility, we currently use the base Game model to keep the system consistent. We also introduced several new views specific to IF games. IFGameCreateView renders a custom form for uploading and editing IF game metadata. It includes support for drag-and-drop file uploads and previewing Twine games using the FileReader API. InteractiveFictionDetailView dynamically displays the correct game detail page based on the presence of a Twine file, filtering out multiplayer elements and highlighting IF-specific fields such as content warnings and a "Play Game" button. We also built UploadFileView to handle game file uploads independently of the form submission, ensuring a smoother user experience. These views are backed by templates that preserve the ChiGame visual identity while removing unnecessary multiplayer elements. Our design choices prioritized consistency and reuse by integrating IF support into the existing model and interface, while allowing flexibility for future divergence. We used Choices.js for frontend label selection and included accessibility-friendly features like tooltips, character counters, and confirmation modals. By building on top of ChiGame's existing architecture, IF games appear alongside traditional games in listings, search, and user dashboards without requiring special routing or filtering logic. Future work can include implementing a full Label model, extending the InteractiveFictionGame class with custom validation, and embedding Twine games directly on the site. This foundation ensures IF games feel first-class while remaining easy to maintain and extend.

---

Next Steps

This quarter, we have been able to implement basic functionality for users to upload interactive fiction games. We have included a few possible next steps and issues to be addressed in order to improve user experience and increase functionality.

The first possible step is to add functionality to genre choice in IF_create_game.html. This step is preliminarily discussed in Issue #1460. In the IF_game_create.html, there is a placeholder drop down for a genre choice that is nonfunctional. Genre choices need to be created, populated, and integrated as potentially another model in Chigame with a ManytoMany feature. Then, drop down functionality should be implemented on IF_create_game.html for users to pick from given Genres to assign to their game.

The second possible step is to fix bug where creating an interactive fiction game doesn't include Description Input. This step is preliminarily discussed in Issue #1422. Currently, when filling in the Create Form, the data input is not correctly implemented into the created Game instance. The name and description input is solved in a later PR #1581 , but has not been pushed. This functionality would need to be integrated so that every data point (rules, warnings, etc.) are also correctly populated when creating a game instance. This edit will be in the UploadFile view. See the later PR for details.

The third possible step is to update User Stories to reflect the interactive fiction game structure. This step is preliminarily discussed in Issue #1497. The current user stories on the chigame wiki are out of date with the current functionality and what interactive fiction creators can do on chigame (those user stories could also give more modifications to make if future implementers want to make those implementations, such as SugarCube games and perhaps a way for creators to make their own Interactive Fiction games on Chigame rather than Twine).

Lastly, Issue #1197 involves implementing a way for created games to be stored in the database. This issue pertains to making uploaded interactive fiction games visible to all users by making uploaded games stored in binary and putting uploaded games in a fixture file. This issue unfortunately had to be dropped due to unsolvable merge conflicts for over the quarter, but perhaps future implementers can figure out how to implement the changes in the git branch and avoid merge conflicts and migration issues.

Overall, next steps mainly involve improving user experience with uploading interactive fiction games. More ambitious implementations can involve allowing users to upload other types of files other than Twine or even creating a template in ChiGame for users to create interactive fiction onsite. It can also be helpful to create greater documentation to guide through the process of uploading an interactive fiction game and the required processes and steps. We strongly recommend that future teams explore how to increase the ways that users can upload and create their games.