Diary of a game 1 - Capturing architectural decisions

It's been 35-years since I first made a computer game, and while the text-only Horse never made it off the school's BBC B computer, I recently decided it was time I create my second game, a classic platformer with the working title, Cornucopia.

Although I've been reading everything I can on game development, I'm acutely aware I'm liable to make a pile of horrendous decisions developing the game and wanted a simple mechanism to capture the architectural decisions for posterity.

While a notebook seems ideal for concepts, it's not so great for technical design, so I've therefore decided to capture key decisions in lightweight architecture decision records, and once Cornucopia's  finished I'll review them to see what mistakes I can avoid for the next game, due in about 35-years time.

Having thought LÖVE would make a good framework for a beginner, I'm currently missing the familiarity of C# and the low-level crispiness of C++, but what's great is being forced to concentrate on the game, and not getting lost in the complexities of my tools.

Only time will tell if I ever feel anything but meh for Lua, and whether Cornucopia's going to top the heady heights that Horse reached, but at least ADR-01 will remind me why in my wisdom I chose LÖVE and why I eschewed a game engine.

Architectural Decision Record 01: LÖVE for Game Framework ==========================================================

## Context
Creating games from scratch requires significant development effort, and a game framework or engine carries out much of the heavy lifting, allowing developers to focus on game mechanics and content rather than primitive functionality. Game frameworks provide the foundations to build games, while game engines provide broader toolsets and functionality to handle advanced features, but often have an increased learning curve.

## Decision
We will use LÖVE (https://love2d.org/) as the game framework.

## Status
Accepted (e.g Proposed, Accepted, Rejected, Deprecated(requires ref))

## Consequences
The game will use LÖVE functionality wherever possible and will be closely tied to the framework's standard features, which will restrict the game to 2D. Code will be developed using Lua (https://www.lua.org/) which is quick to learn, and will take advantage of existing functionality from Lua's standard library, LÖVE tutorials and libraries wherever possible.

The game can easily target multiple platforms-including Android, IOS, Windows, Mac, and Linux,and—while more complicated—PS4 and XBox could be considered for future ports if warranted.

Although LÖVE uses C++ to provides a performant base platform, the use of Lua for scripting means complicated or large games could suffer from lower levels of performance. This will need to be monitored via proactive performance testing, and mitigation might require simplifying the game's complexity to meet suitable performance levels. In addition, the use of an interpreted language without compile time checks, clearly defined coding standards, and rich debugging tools, means extra vigilance will be needed in structuring the code to ensure it stays manageable, maintainable, and correct.

Finally, since LÖVE doesn't provide all the capabilities of a game engine, it will need to be augmented with a significant number of additional libraries. Wherever possible the choice of these libraries will be based on standard industry approaches or technology, to make it as easy as possible to port the game to a different engine in the future.