purkka.fi

The White Tigers » Engine devlog

Engine devlog

The engine is still heavily work in progress. This page right here will act as an evolving list of issues I'm aware of and have already addressed; features implemented and bugs fixed will be colored in green. I hope it will help people keep track of the progress of the game and act as a hub for feature requests and bug reports.

If you see something missing or have an idea, contact me.

User-facing features

User experience. Implement missing settings and convenience features enabling players to customize and control their play experience, ideally matching much of what Ren'Py and other visual novel engines offer.

  • Dynamic text speed setting. Setting to enable/disable punctuation affecting text speed.
  • Hotkeys. Copy useful hotkeys from Ren'Py (for hiding the UI, etc) and enable the player to see and change them in settings.
  • Rename save banks. Allow players to rename the clusters of save files in addition to the saves themselves (will require changing UI so that it works with longer names).
  • Android UI improvements. Important functionality accessed via the keyboard or hovering the mouse (including at least some hotkeys and how information about saves is viewed) should work via some other means or have different UI entirely on Android.
  • Maybe: switch languages in-game. The language setting cannot be changed in-game right now due to some edge cases, questions about partial translations, and architectural decisions. If this feature is requested, solutions can be explored.

Accessibility & translation. Implement settings and mechanisms that increase accessibility of the game.

  • Bundle fonts with translations. Allow translations to change the font, enabling use of languages that need letters the default font doesn't provide.
  • Dyslexia font. Setting for using dyslexia-friendly font.
  • UI scale setting. In-game setting for switching to the larger UI scale, for now used in the Android builds.

Technical changes

Godot 4 upgrade. The project is now using Godot 3.5, the latest stable release, but 4 will bring many useful improvements required for implementing some of the things listed on this page.

  • Move project to Godot 4. When it comes out, transfer the project to Godot 4.
  • Clean code with Godot 4 features. Taking advantage of Godot 4's features like lambdas and improved handling of cylic references, clean up the entire codebase.

Missing features. Some basic VN functionality that the demo didn't need is still missing.

  • Refactor View hierarchy. Clean the code and prepare for new features by coupling standard visual novel features (backgrounds, sprites, etc) into a specific class (StageView?), inherited by Views that use this functionality.
  • Sprites. Load & display multilayered sprites, script commands to move them and change expression, etc.
  • Choices. Display screen with a choice, executing specific actions as a result.
  • Variables. Set and read game state, storing it in the save.

Improved asset loading. As Godot 3.5 has some issues related to loading resources concurrently, asset loading works on a load-as-needed basis in the current version and can be made more efficient after the upgrade to 4.

  • Asset cache. Cache loaded assets based on type, discarding old ones when a limit is reached.
  • Lookahead & concurrent loading. Queue assets for loading in separate thread before they are needed by looking ahead in the script.

Script improvements. The script format much of the game's files use can be made stabler and easier to use.

  • Tests for script grammar. Unit tests for the lexer and parser of the script language, ensuring that the grammar stays stable and codifying edge cases.
  • Better script error messages. Useful error messages for script parse errors; should include the line where the problem is and the engine's best guess about what could be wrong.
  • Maybe: inline text blocks. Enable prose to be typed directly in the script files since some people prefer it that way – would make translation impossible or require separate mechanism? Worth it?

Decouple the game from the engine. As a long-term goal, it would be nice to release the engine to the public, allowing others to use and modify it for their own games. This will require some internal changes and documentation work.

  • Decouple game-specific scenes. Remove references to game-specific scenes (title screen, credits scene, etc) from the engine; define them in configuration files instead.
  • Rename core classes. Come up with a name for the engine and rename core classes to reflect it, preventing name conflicts and making engine code easier to distinguish.
  • Improve API. Make sure that classes and functions intended to be used by users of the engine are properly commented, have sensible names, and are documented.
  • Make engine repository public. Move all game-specific files and assets to another repository, enabling the engine code to be made public.
  • Other documentation. Document script format, list available features, etc.
  • Example project. Create public example project that showcases the engine's features, provides examples of their usage, and can be used as a template.

Bugs

Known bugs. Bugs I noticed myself or were reported to me by users.

  • Minor visual bug with "continue" icon and outline. The icon that appears to indicate that game should be advanced reacts weirdly with outline; investigate (possible Godot bug?)
  • Log doesn't remember first line when loading from save. When game is loaded from a save, the log does not store the first line of text. It's an edge case I didn't have time to fix; log functionality should probably be rewritten to address it.
  • Save renaming weirdness. Renaming a save appears to sometimes affect other saves; investigate.
  • Android: Save thumbnails don't display. The problem may be in writing or reading the relevant files; investigate.

Wontfix. Bugs that were found to be too hard to fix for how minor they are or result from unfixable Godot issues.

  • None yet.