Welcome to the Silverwing's Lair

Graphics

The engine is made for 2D sprite-based games. So no per-pixel painting, no vector operations, no shading, no 3D transformations. Just painting bitmaps on the screen. This is already enough to make a huge variety of games, and most importantly -- this is enough to make (most of) the games we want to make.

Option: it may be cool to support arbitrary transformations on the sprites using matrices, but since this is not needed for our first game, I most likely will not implement it in the first version.

For our games we also need support for rich text. At the very least we need to be able to mix font families, sizes, weights and decorations.

The engine is going to handle anything painted on the screen as a layer. For initial release I plan these types of layers:

• Sprite -- a simple or animated sprite painted on the screen;
• Container -- a layer containing other layers; it's intended to be a convenient way for clipping and grouping layers and can be useful, for example in creating a GUI;
• Text -- a layer containing text; it will natively support everything necessary for rich text handling: formatting, wrapping, scrolling and clipping;

This approach will allow optimising rendering per layer type and renderer used. For the initial version I am also considering a special Tile layer. On one hand it will simplify making tile based games (including our games), but on the other it will make the engine more complex (i.e. harder to port).

Since our games will mostly be pixel-art, we will need some kind of scaling. Using layers will allow doing this transparently. Layers can be scaled independently, depending on their type.

I will likely hard limit resolution to something very large just to be safe. Minimum supported resolution will be 320x200.

For maximising compatibility, we are going to support both paletted and high/true color modes. We will allow using both color-key transparency (for all modes) and alpha transparency (for high/true color).

As I explained above, we are going to strictly limit the supported file formats. For graphical assets these will be PCX (compressed and uncompressed) and PNG (compressed) files. For our games we will likely use PNG in most cases, however uncompressed PCX will load noticeably faster on low-end computers.

Sound

With only 2D games in mind, we don't really need complex audio. No matter how cool it would be to support all kinds of advanced stuff like 3D positioning and environmental effects, at the first stage we can restrict ourselves to only support plain old mono or stereo samples and music.

Once again portability defines the need to limit file formats to the following:

• uncompressed PCM audio with 8 or 16-bit depth and 22050 or 44100Hz sampling frequency; container format is Wav only;
• compressed Vorbis audio with 8 or 16-bit depth and 22050 or 44100Hz sampling frequency; container format is Ogg only;
• For music we are also considering MIDI and tracker formats.

Uncompressed formats are a lot less CPU demanding, so can be used on slower machines; lower sound quality allows saving disk space and also reduces transcoding overhead on slower machines.

Input

This is the point where we cannot really afford any compromises. We have to support all mainstream types of input methods: keyboard, mouse and game controllers. Since input behaviour is highly game specific, we are not going to force any kind of input mapping on the engine level. Instead we are going to provide an optional and configurable library for this purpose. Obviously, we are going to optimise this library for our use-cases first of all.

Data

Usually game engines allow virtual file system approaches to allow seamlessly retrieving files from resource archives as well as local file system. This approach works well, but has an important caveat that file paths and file systems are in general not portable: some file systems are case-sensitive and some are not; file systems have different limits on length of the file name, number of files in the folder, allowed characters and so on. All of this not only forces the developer to constantly keep in mind the limitations of each of the supported systems, but also hinders porting to new systems (since their limitations may not be met by older games). More than that, it makes it extremely easy to make a game that only works in operating systems compatible with the one used by the developer.

It is also important to note difference between game resources, which should be read-only and user data which should be read/write. In general, writing files should be only possible within a specific "saved games" directory, but sometimes it is needed to make a file in an arbitrary place (for example if we are working with a map editor).

To resolve this I will:

• find or implement an archive format, suitable for both reading and writing data (alternatively, I consider using SQLite database for saving games. The downside of this is requiring understanding of SQL language for handling saved games and configuration, as well as an extra dependency);
• implement an extra API that will allow picking files from host file system. Obviously this will require some platform dependent UI, but most likely this will be necessary;
• implement a debug mode that will allow loading files directly from the host file system (this is necessary to avoid repacking step after every change).

Runtime

To make the game truly platform-independent it needs to be run within some kind of virtual machine. It can be an interpreted language, a byte-code VM or straight-away an emulator of a real CPU. I am heavily leaning towards Lua for this due to it's high portability and decent performance. Most of the engine's prototypes also use Lua. However I would like to at least mention some alternatives I am considering:

• Lua -- a big advantage will be runtime's native compatibility with INSTEAD, which will simplify porting of my older games;
• WASM -- a huge issue with it is a lot of different implementations and inconsistent tooling, as well as a compilation step required. Only worth it if performance is at least twice as good as Lua's;
• Pawn -- I know nothing about this language, except that it's compiled and it's designed for embedded systems. Once again, only worth it if performance is at least twice as good as Lua's.

Runtime choice is crucial since we will not be able to ever switch it. This means that I have to carefully consider upsides and downsides of each variant.