Update
This commit is contained in:
parent
7a4c69819f
commit
94c2c620d2
8 changed files with 43 additions and 14 deletions
2
game.md
2
game.md
|
@ -28,6 +28,8 @@ Games can be [suckless](suckless.md) and just as any other software should try t
|
|||
|
||||
If you want to make a simple LRS game, there is an official LRS [C](c.md) library for this: [SAF](saf.md).
|
||||
|
||||
A LRS game will be similar to any other [suckless](suckless.md) program, one example of a design choice it should take is the following: while mainstream games are built around the idea of having a precompiled engine that runs [scripts](script.md) written in some interpreted language, a **LRS/suckless game wouldn't use run-time scripts** but would rather have such "scripts" written as a part of the whole game's source code (e.g. in a file `scripts.h`), in the same language as the engine (typically [C](c.md)) and they would be compiled into the binary program. This is the same principle by which suckless programs such as [dwm](dwm.md) don't use config files but rather have the configuration be part of the source code (in a file `config.h`). Doing this in a suckless program doesn't really have any disadvantages as such program is extremely easy and fast to recompile, and it brings in many advantages such as only using a single language, reducing complexity by not needing any interpreter, not having to open and read script files from the file system and also being faster.
|
||||
|
||||
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 impressive visuals (i.e. photorealism etc.), 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 rapid development and impressing the consumer with visuals).
|
||||
|
||||
The paradigm of LRS gamedev differs from the mainstream gamedev just as the [Unix philosophy](unix_philosophy.md) differs from the [Window philosophy](windows_philosophy.md). While a mainstream game is a monolithic piece of software, designed to allow at best some simple, controlled and limited user modifications, a LRS game is designed with [forking](fork.md), wild [hacking](hacking.md), unpredictable abuse and code reuse in mind.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue