Update

game.md

@@ -1,6 +1,6 @@
 # Game
 
-In computer context game (also gayme, video game or vidya) is [software](software.md) whose main purpose is to be played and entertain the user. Of course, we can additionally talk about real life games such as [marble racing](marble_race.md). *Game* is also a mathematical term in [game theory](game_theory.md). Sadly most computer games are [proprietary](proprietary.md) and toxic.
+In computer context game (also gayme, video game or vidya) is [software](software.md) whose main purpose is to be played and entertain the user. Of course, we can additionally talk about real life games such as [marble racing](marble_race.md). *Game* is also a mathematical term in [game theory](game_theory.md). Sadly most computer games are [proprietary](proprietary.md) and [toxic](toxic.md).
 
 Among [suckless](kiss.md) software proponents there is a disagreement about whether games are legit software or just a [meme](meme.md) and harmful kind of entertainment. The proponents of the latter argue something along the lines that technology is only for getting work done, that games are for losers, that they hurt [productivity](productivity_cult.md), are an unhealthy addiction, wasted time and effort etc. Those who like games see them as a legitimate form of relaxation, a form of art and a way of advancing technology along the way. The truth is that developing games leads to improvement of other kinds of software, e.g. for rendering, physics simulation or virtual reality.
 
@@ -18,7 +18,7 @@ A small number of games nowadays come with a [free](free_software.md) engine, wh
 
 Yet a smaller number of games are completely free (in the sense of [Debian](debian.md)'s free software definition), including both the engine and game assets. These games are called **free games** or **libre games** and many of them are clones of famous proprietary games. Examples of these include [SuperTuxKart](stk.md), [Minetest](minetest.md), [Xonotic](xonotic.md), [FLARE](flare.md) or [Anarch](anarch.md). There exists a wiki for libre games at https://libregamewiki.org and a developer forum at https://forum.freegamedev.net/. Libre games can also be found in Debian software repositories.
 
-{ NOTE: Do not blindly trust libregamewiki, non-free games ocassionaly do appear there by accident or even intention. I've actually found that most of the big games like SuperTuxKart have some licensing issues (they removed one proprietary mascot from STK after my report), so if you're a purist, focus on the simpler games. Anyway, LGW is a good place to start looking for libre games. ~drummyfish }
+{ NOTE: Do not blindly trust libregamewiki, non-free games ocassionaly do appear there by accident, negligence or even by intention. I've actually found that most of the big games like SuperTuxKart have some licensing issues (they removed one proprietary mascot from STK after my report). Ryzom has been removed after I brought up the fact that the whole server content is proprietary and secret. So if you're a purist, focus on the simpler games and confirm their freeness yourself. Anyway, LGW is a good place to start looking for libre games. ~drummyfish }
 
 Some games are pretty based as they don't even require [GUI](gui.md) and are only played in the text shell (either using TUI or purely textual I/O) -- these are called TTY games or command line games. This kind of games may be particularly interesting for [minimalists](minimalism.md), hobbyists and developers with low (zero) budget, little spare time and/or no artistic skills. Roguelike games are especially popular here; there sometimes even exist GUI frontends which is pretty neat -- this demonstrates how the [Unix philosophy](unix_philosophy.md) can be applied to games.
 
@@ -30,14 +30,74 @@ 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 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).
+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 rapid development and impressing the consumer with visuals).
 
-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. 
+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, limited user modifications, a LRS game is designed with [forking](fork.md), [hacking](hacking.md), abuse 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.
+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 internal 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) or as a VFX tool for making movies, 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).
 
+## Types Of Games
+
+Besides dividing games as any other software ([free](free_software.md) vs [proprietary](proprietary.md), [suckless](suckless.md) vs [bloat](bloat.md), ...) we can further divide them by the following:
+
+- by genre:
+  - [minigames](minigame.md)
+  - [shooters](shooter.md)
+  - [role playing](rpg.md)
+  - [tower defenses](tower_defense.md)
+  - [racing](racing.md)
+  - [platformers](platformer.md)
+  - [strategy](strategy.md)
+  - [adventures](adventure.md)
+  - [sport](sport.md)
+  - ...
+- by game design:
+  - [easy to learn, hard to master](easy_to_learn_hard_to_master.md)
+  - [hard to learn, easy to master](hard_to_learn_easy_to_master.md)
+  - [easy to learn, easy to master](easy_to_learn_easy_to_master.md)
+  - [hard to learn, hard to master](hard_to_learn_hard_to_master.md)
+  - [symmetric](symmetry.md) vs assymetric gameplay
+  - ...
+- by number of players:
+  - [zero player](zero_player.md)
+  - [single player](single_player.md)
+  - [multiplayer](multiplayer.md)
+  - [massively multiplayer](mmo.md)
+- by information:
+  - [complete information](complete_information.md)
+  - [incomplete information](incomplete_information.md)
+- by interface:
+  - [2D](2d.md)
+  - [3D](3d.md)
+  - ["pseudo3D"/primitive3D](pseudo3d.md)
+  - [command line/text](cli.md)
+  - audio
+  - ...
+- by time management:
+  - [realtime](realtime.md)
+  - [turn based](turn_based.md)
+- by platform
+  - [real life](irl.md)
+  - [computer](computer.md) ([console](console.md) vs [PC](pc.md))
+- by budget/scale/financing:
+  - amateur
+  - [indie](indie.md)
+  - [AAA](aaa.md)
+- by [business model](business_model.md):
+  - [freeware](freeware.md)
+  - [shareware](shareware.md)
+  - [free to play](free_to_play.md)
+  - [subscription](subscription.md)
+  - buy once
+  - [pay to win](pay_to_win.md)
+  - [pay what you want](pay_what_you_want.md)/donation
+  - [adware](adware.md)
+  - [spyware](spyware.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).
@@ -46,7 +106,7 @@ Trademarks have been known to cause problems in the realm of libre games, for ex
 
 ## Some Nice Gaymes
 
-[Anarch](anarch.md) is an example of a game trying to strictly follow the [less retarded](lrs.md) principles. [SAF](saf.md) is a less retarded game library/fantasy console which comes with some less retarded games such as [microTD](utd.md).
+[Anarch](anarch.md) and [microTD](utd.md) are examples of games trying to strictly follow the [less retarded](lrs.md) principles. [SAF](saf.md) is a less retarded game library/fantasy console which comes with some less retarded games such as [microTD](utd.md).
 
 { I recommend checking out [Xonotic](xonotic.md), it's completely libre and one of the best games I've ever played. ~drummyfish }