-
Notifications
You must be signed in to change notification settings - Fork 20
Design Choices
The primary goal of this project is to develop a functional game, not develop a sophisticated and perfectly elegant code base and engine. To that end, a number of design choices were made that reflect this.
Most choices are intended to make the code simpler to deal with and less verbose at the cost of requiring changes to be recompiled versus reloaded from disk.
OutpostHD is primarily developed by a native English speaker. That stated, OPHD is in English.
To keep the code simple, most of the string literals used in the program are hard-coded and don't load from an external definitions file.
The string literals are represented by std::string -- this means that Unicode encoding, while possible, is not implemented. This mostly has to do with a lack of support for extended character support in NAS2D's handling of font's and font glyph's. Its functions, in order to be compact, supports up to 255 character entries and follows the ASCII character codes for the first 128 characters and CP-1252 for the remaining 128 characters.
Basically, most European languages can be represented by using character codes from 0 - 255. Translations will need to be recompiled. This does make it more painful to translate but makes the code far simpler to deal with.
Instead of using an external definition and a lot of generalized code to handle behavior and possible scripting language extensions, Structures are hard-coded into the game code. They all derive from a base class called Structure and implement their own logic as needed.
This means that any changes, extensions, etc. will need to be recompiled instead of just saving a script or definition file and reloading. Since this is an open-source project there is little difficulty in making and including any changes.
I opted to use XML for the savegame format specifically so that I could inspect written values in a human-readable form and easily edit it as needed to test various parts of the code. This isn't expected to change though I do understand that ultimately we'll be looking at potentially very large savegame files. Disk space is no longer at a premium and loading is very fast in release builds.
As the game nears completion and the savegame formatting and fields required are frozen, this may be changed to a binary savegame format to improve read/write speeds for savegames.