Update

game.md

@@ -24,6 +24,20 @@ Some games are pretty based as they don't even require [GUI](gui.md) and are onl
 
 Another kind of cool games are computer implementations of pre-computer games, for example [chess](chess.md), backgammon, go or various card games. Such games are very often well tested and fine-tuned gameplay-wise, popular with active communities and therefore [fun](fun.md), yet simple to program with many existing free implementations and good AIs (e.g. GNU chess, GNU go or [Stockfish](stockfish.md)).
 
+## Games As LRS
+
+Games can be [suckless](suckless.md) and just as any other software should try to adhere to the [Unix philosophy](unix_philosophy.md). A [LRS](lrs.md) game should follow all the principles that apply to any other kind of such software, for example being completely [public domain](public_domain.md) or aiming for high [portability](portability.md). This is important to mention because, sadly, many people see games as some kind of exception among software and think that different technological or moral rules apply -- this is wrong.
+
+If you want to make a simple LRS game, there is an official LRS [C](c.md) library for it: [SAF](saf.md).
+
+Compared to mainstream games, a LRS game shouldn't be a consumerist product, it should be a tool to help people entertain themselves and relieve their stress. From the user perspective, the game should be focused on the fun and relaxation aspect rather than on pleasing look, i.e. it will likely utilize simple graphics and audio. Another aspect of an LRS game is that the technological part is just as important as how the game behaves on the outside (unlike mainstream games that have ugly, badly designed internals and mostly focus on impressing the consumer).
+
+The paradigm of LRS gamedev differs from the mainstream gamedev just as the Unix philosophy differs from the Window philosophy. While a mainstream game is a monolithic piece of software, designed to allow at most some simple user modifications, a LRS game is designed with [forking](fork.md) and code reuse in mind. 
+
+Let's take an example. A LRS game of a real-time 3D [RPG](rpg.md) genre may for example consist of several independent modules: the RPG library, the game code, the content and the [frontend](frontend.md). Yes, a mainstream game will consist of similar modules, however those modules will probably only exist for the organization of work and better testing, they won't be intended for real reuse or wild hacking. With the LRS RPG game it is implicitly assumed that someone else may take the 3D game and make it into a purely non-real-time [command line](cli.md) game just by replacing the frontend, in which case the rest of the code shouldn't be burdened by anything 3D-rendering related. The paradigm here should be similar to that existing in the world of computer [chess](chess.md) where there exist separate engines, graphical frontends, communication protocols, formats, software for running engine tournaments, analyzing games etc. [Roguelikes](roguelike.md) and the world of [quake](quake.md) engines show some of this modularity, though not in such a degree we would like to see -- LRS game modules may be completely separate projects and different processes communicating via text interfaces through [pipes](pipe.md), just as basic Unix tools do. We have to think about someone possibly taking our singleplayer RPG and make it into an MMORPG. Someone may even take the game and use it as a research tool for [machine learning](machine_learning.md), and the game should be designed so as to make this as easy as possible -- the user interface should be very simple to be replaced by an [API](api.md) for computers. The game should allow easy creation of [tool assisted speedruns](tas.md), to record demos, to allow [scripting](script.md), modifying ingame variables, even creating [cheats](cheat.md) etc. And, importantly, **the game content is a module as well**, i.e. the whole RPG world, its lore and storyline is something that can be modified, forked, remixed, and the game creator should bear this in mind.
+
+Of course, LRS games must NOT contain such shit as "[anti-cheating](anti_cheat.md) technology". For our stance on cheating, see the article [about it](cheat.md).
+
 ## Legal Matters
 
 Thankfully gameplay mechanisms cannot (yet) be [copyrighted](copyright.md) (however some can sadly be [patented](patent.md)) so we can mostly happily [clone](clone.md) proprietary games and so free them. However this must be done carefully as there is a possibility of stepping on other mines, for example violating a [*trade dress*](trade_dress.md) (looking too similar visually) or a [trade mark](trade_mark.md) (for example you cannot use the word *tetris* as it's owned by some shitty company) and also said patents (for example the concept of minigames on loading screens used to be patented in the past).
@@ -41,4 +55,5 @@ Trademarks have been known to cause problems in the realm of libre games, for ex
 - [minigame](minigame.md)
 - [open console](open_console.md)
 - [fantasy console](fantasy_console.md)
+- [SAF](saf.md)
 - [chess](chess.md)