Suckless Libre Games?

Suckless Libre Games?

Postby drummyfish » 31 Dec 2020, 19:39

So, after releasing Anarch, a game on which I "tested" some of my specific development philisophies, I would like to talk with you about those philosophies, having something concrete to back them up. There are other projects created with similar ideas in mind, e.g. the Simon Tatham's Portable Puzzle Collection.

My goal with this post is to perhaps gain a fellow programmer or programmers to make similar games with me. Let's create a comfy suckless libre game collection!

Let me preface with saying that it is of course okay not to follow these, you can make your games however you wish, I am not here to bash your programming style etc., I am here to possibly start a small community of developers who create a specific kind of games that the world is currently lacking.

I think my way is a legitimate way with many advantages, which however isn't much practiced because of the huge prevalence of the mainstream game dev and pressure of the business world, consumerism, short term planning, resulting school education etcetc. In a mostly non-commercial/hobbyist community like this one I am offering this alternative development style. As the suckless philosophy many times sparks heated debates, let me again stress this is not an offense to anyone's programming or tastes, this is not a promotion of the suckless group, this is a friendly invitation to join and explore a game development area holding some potential, an area that would maybe deserve a distinct name.

What is this philosophy?

I will call this the "suckless" or "Unix" philosophy because these are the closest, but we can invent another term as there are some specifics. While a lot of libre games try to imitate or chase the AAA games, with this philosophy we try to go the other way, towards minimalism and simplicity. Basically, we try to:

- Create games simply, to be minimalist and easy to use, compile, modify, reuse, distribute etc. Not just on paper, but also in practice. For all people.
- Create time-proof games, mainly by dropping dependencies and big frameworks. Achieve true independence on any other project.
- Create very portable games, again by dropping dependencies and keeping things simple.
- Get rid of burdening "bullshit" in games as well as in development. This means e.g. dropping fancy graphics, huge development environments etc.
- Utilize the less is more principle. I.e. a pixelated graphics can be better than HD graphics in some situations, so try to put yourself in that situation.

So, specifically, SOME of the guidelines are these:

- Write games in pure C99, because that is the most portable, efficient and suckless language. No C++, no Python, no Java, ... If that is possible.
- Do not use OOP and many of so called "good practice". These are considered "bloat", corporate style programming for HUGE projects. They teach you these for "safety" and because they are standard in the commercial sphere, but are burdening and limiting to us. Avoid unnecessary abstractions. Use simple imperative programming with functions, global variables etc.
- Avoid ANY dependency that is not completely necessary. This means mainly libraries, but also for example hardware. If your game can run without floating point (it most likely can), only use integers! Many CPUs (embedded) do not have floating point coprocessor and floating point operations are slow there! Even if you don't plan porting to embedded, don't use it if you don't need it. Don't even use standard library if not necessary.
- Use as little computational resources (RAM, CPU, ...) as possible. This helps portability and accessibility, and is simply just a good engineering habit.
- Drop "bullshit features" which are also dependencies and burdens. Will your game be less fun with pure ASCII non-antialiased font rendering? Then don't use Unicode and don't use anti aliased font rendering library. Is the only purpose of mouse in your game to click on things in the menu? Then don't use mouse, use only keys.
- Be smart and hacky. For example using arbitrary sized textures can be a burden if you don't need this feature. In mainstream dev no one cares, everyone simply uses an "image library" and doesn't care about any overhead. However, it can help if you e.g. purposefully limit yourself to textures of size 32x32, as this will have quicker access (powers of two dimension, compile-time known bounds, ...), smaller code, fewer bugs etc.
- Don't use "bullshit" complex/complicated licenses and rules (whateverGPL). Don't multi license. Preferably use completely public domain (CC0) or simple permissive licenses (MIT) for whole repository.
- Avoid hard I/O dependencies by creating a simple abstraction so that your I/O library can be very easily switched for whatever is available on given platform. E.g. in Anarch I write to screen via simple abstract function drawPixel(), which each frontend implements its own way, usually as a single line call to its own pixel drawing function.
- If you can, avoid using harddisk storage and compile your resources into the executable. Many platforms don't have harddisk, or the libraries further bloat your program.
- Make things optional, don't force anything. E.g. in Anarch saving/loading is optional. In case the platform doesn't have persistent storage for saves, you can simply access all levels from the start.
- Do not use config files, write configuration and settings right in the source code, e.g. in a special "settings.h" file. Remember, your game recompiles in less than a second with a single command.
- Use single compilation unit, best if you can fit your whole program into a single file (which also forces you a bit to keep the code short and simple). If you can compile your code with a single call of the compiler, you're doing it right. Avoid build systems such as CMake, at worst use a simple Makefile.
- Don't write level editors/formats if you can use existing generic tools and formats. E.g. in Anarch I don't have a special level editor, my levels are editable right in the source code or can be created as images in any simple bitmap editor.
- Don't use dynamic scripting languages if not needed. You can "script" your game in the language you are writing the game in, especially if your game is so easy and fast to recompile.
- Don't rely on GPUs, try to use SW rendering.
- Make your game work with as few buttons as possible to help portability. You can add additional keys for comfort as long as they are optional.
- Write nice, self-documenting code, make it accessible to other programmers. Explain what each file does in the file header comment, suppose someone else will be trying to understand your code with just the source code available. There are people who work offline etc.

Why?

These games have many values that are pretty underappreciated by today's society, but they are still there and useful to many people.

Yes, this does cost something. You may spend more time on making your game consume less resources than if you simply made it in a premade framework and accepting that "everyone has a good CPU nowadays". But your extra time and effort will pay off.

For example, don't you hate it when you find a game that is completely libre, but you still cannot compile it because some of the dozens of dependencies is broken? Or because there pops up an error in the build system that you don't understand and the original author is long gone and uninterested in fixing it? Even though the game is libre legally, it is NOT libre in practice, because you can not compile it in practice. Personally I am very sad that even libre games die this way, and I am often discouraged from playing a game that I think may die soon.

It doesn't have to be this way! A suckless game greatly avoids this issue. For example, my game Anarch only requires C99 compiler, which is something that will most definitely exist there as long as there exist computers, as so many things are written in it and depend on it. Java and C++ may die one day, but C will be there forever.

Yes, Anarch also requires SDL for its PC frontend, but this is a very soft dependency that can be replaced by anything that can draw pixels and read keyboard. Even if SDL dies, there will always be something like it you can use AND it takes only a few hours to write a new frontend. I have actually written many frontends for the game with many other libraries.

Having ported the game to all the different platforms also helped me test it for hardware-specific things like endianness etc.

Similarly if the game is too complex, it can be seen as little less "libre" or "free", simply because fewer people can truly modify it. Even if the game is under a free license, if it has hundreds of thousands of lines of code, it resists modification by simply being very complex and requiring very much effort to modify. A game written in a simpler way is much more accessible to programmers and "more free" in practice.

A libre game will have close to zero maintenance cost, because firstly it will have fewer bugs, and secondly it will almost eliminate the dependency maintenance. Much of the maintenance of the big projects consists of keeping up with library updates, which you don't need to do here.

A suckless game runs on many platforms and is accessible to more people! It doesn't make you buy a specific platform or expensive hardware. It also respects the people in the future, who may have completely different operating systems, platforms and libraries, and perhaps even less powerful computers (e.g. after technological collapse). If there is one piece of technology that will remain from today, it is the C compiler.

A suckless game thinks long term, it is not a game you consume and throw away, as most mainstream games. It may require a little more effort from you, but in the end pays off much more, as it will be like the legendary Doom, resisting decades and technological changes, to always be there for the people.

It also encourages forking and creativity, by being simple to tinker with. It may be used by a scientist for research, because it is so fast and efficient it is possible to run many thousands of these games at once and help e.g. with machine learning. It may be used by a programming teacher for his students to experiment on. You never know what will be, all you can do is to try to create the best engineering work you can.

And last but not least, programming a suckless game is simply joy :) You stop caring about frustrating bugs deep inside your framework, of which you don't even know how they work. You stop caring about painstakingly debugging GLSL shaders. You create most of your game from scratch, and that's quite a rewarding accomplishment. And it doesn't have to take longer than creating the game the mainstream way.

-------------------

So, what do you think? Would you want to give this a try? I think there's a good motivation in knowing almost no one is doing this -- quite some people are writing suckless software, but not games. No one is writing completely public domain games. You may be among the world's first people and create something truly new, unlike with "classical" indie/libre dev.

I was thinking a good project to start with might be a minigame collection, something like the famous 99 in 1, that would be super portable. Despite the simplicity of games like snake or chess, there are still very few of these done completely right. Something like a Super Mario clone would be even better.

I have written two libraries that might help you in your projects: small3dlib and raycastlib.

Is anyone even remotely interested in this please? :)
socialist anarcho-pacifist
Abolish all IP laws. Use CC0. Let's write less retarded software.
http://www.tastyfish.cz
User avatar
drummyfish
 
Posts: 330
Joined: 29 Jul 2018, 20:30
Location: Moravia

Re: Suckless Libre Games?

Postby dulsi » 31 Dec 2020, 22:08

Have you watched:
https://meetings-archive.debian.net/pub ... how-t.webm

Your suckless libre games has the same problem as id tech's fork methodology. If everyone needs to edit the code to modify the keys used to play the game, you will end up with lots of forks. Finding fixes become very difficult. Making a version that includes improvements from multiple forks becomes a nightmare. Yes a game that can't build anymore isn't libre but what good is libre if none of the forks have all the features I want.

Personally I think the disadvantages of what you advocate outweigh the advantages. But if you can make cool games with it, it's fine with me.
dulsi
 
Posts: 491
Joined: 18 Feb 2016, 15:24

Re: Suckless Libre Games?

Postby ffaf » 31 Dec 2020, 23:39

Your game was really thought provoking and made me revisit some of my programming practices. Thanks for having written this explanation: I do not agree with some of the items (I would rather pick GPL instead of a permissive one, in general; I agree with dulsi on config files) but many others are true and I will for sure think about them the next time I will code something.
ffaf
 
Posts: 66
Joined: 04 Dec 2019, 08:59

Re: Suckless Libre Games?

Postby drummyfish » 31 Dec 2020, 23:45

> Your suckless libre games has the same problem as id tech's fork methodology.

Not everything has to be a fork, mods in form of patches are preferred, and these can be combined. Maybe it doesn't solve your issue completely (TBH I don't understand too much what you're saying, will have to take a listen to the link), but it definitely works with other suckless programs that aren't games, I think it will work with games as well. Anyway, "normal" programs/games also have issues with combining different forks together, it's not like they have something special in this regard -- a fork, after all, is something meant to diverge, otherwise it can stay part of the original program -- reinventing wheels and incompatibility of different forks is a syndrome of bloated programming. Mods/extensions/patches are the solution here.

> Your game was really thought provoking and made me revisit some of my programming practices.

Thanks, it took me many years of "mainstream" programming to arrive where I am now, just give it a chance and I think you'll see for yourself it makes a lot of sense. Maybe not everything, but the core idea is very unexplored and underrated... so please share any experience you gain :)
socialist anarcho-pacifist
Abolish all IP laws. Use CC0. Let's write less retarded software.
http://www.tastyfish.cz
User avatar
drummyfish
 
Posts: 330
Joined: 29 Jul 2018, 20:30
Location: Moravia

Re: Suckless Libre Games?

Postby dulsi » 01 Jan 2021, 01:24

drummyfish {l Wrote}:Not everything has to be a fork, mods in form of patches are preferred, and these can be combined. Maybe it doesn't solve your issue completely (TBH I don't understand too much what you're saying, will have to take a listen to the link), but it definitely works with other suckless programs that aren't games, I think it will work with games as well. Anyway, "normal" programs/games also have issues with combining different forks together, it's not like they have something special in this regard -- a fork, after all, is something meant to diverge, otherwise it can stay part of the original program -- reinventing wheels and incompatibility of different forks is a syndrome of bloated programming. Mods/extensions/patches are the solution here.

Let's say I want different keys than you do for Anarch. Now I have a fork. Someone complained about the way enemies move so I make a patch for that. It increases the CPU requirements and makes it unplayable on Pokito. You won't merge that. Someone else takes my fork and adds a crafting system. Unfortunately it depends on some of my changes so it is not easy to merge into your version. Another user forks your version to add higher resolution graphics. Again something you won't merge. A third user add ten new levels and some new monsters. It takes too much space to work on Pokito so you won't merge.

Maybe I'm wrong but my reading of this is that you wouldn't accept a large number of build options because it makes the code harder to read and maintain.

Obviously not every change is accepted by every project but a lot of modding can be done without changing the code. Or a small amount of code can be added to enable a mod to implement some feature even if the project is interested in that. Those sorts of changes all become forks in your suckless libre game environment. (Granted most games will never have much of a modding community and many open source project have only one contributor but most hope for greater success.)
dulsi
 
Posts: 491
Joined: 18 Feb 2016, 15:24

Re: Suckless Libre Games?

Postby Rampoina » 01 Jan 2021, 01:52

I agree with the principles of making simple software (although I don't agree with every one of your rules)

Check out the tinycode movement (not the OP specifically, for everyone):

https://old.reddit.com/r/tinycode/

MAGFest 2020: Tiny Coding: Making Big Games With Little Code
https://yewtu.be//watch?v=8ogKnN3t7Nw

CubicDoom, a ray-casting game that fits in a boot sector (510 bytes)
https://github.com/nanochess/cubicDoom

Please go ahead and make awesome simple games!
Rampoina
 
Posts: 2
Joined: 01 Jan 2021, 01:24

Re: Suckless Libre Games?

Postby drummyfish » 01 Jan 2021, 12:25

@dulsi

> You won't merge that.

OK, I see what you mean. Patches are not to be merged! They exist as separate "mods" (see e.g. https://st.suckless.org/patches/), that each users applies to his/her own personal version. This way the base program/game stays an unbloated, bare minimum version, while each user can extend with any combination of patches. This is another great aspect of suckless, everything is distributed in source form, as it should actually be in an ideal world. Mods don't require an extra "mod system", they use an already existing and well working diff/patch tools. Everything is also more decentralized, patches live on their own.

@Rampoina that's so awesome, I can't believe I didn't know about CubicDoom.

EDIT: Watching the tiny coding presentation, it is a great movement, I am loving it! For others, it's still different: as I understand it tiny code is more about pushing the limits, programming exercise and treating programs like puzzles -- a bit like demo scene, but focusing on small source code. That is great -- BTW I love dwitter. The suckless game dev will produce comparatively much bigger source code, in order of hundreds to thousands LOCs, and will have additional rules (no JS, no OOP, ...), with the goal of focusing more on actual utility of the result. I now see it as finding the right balance between overcomplicated mainstream development and extremely tiny development like tiny coding or demo scene, a balance at which we give up costly things with small benefit (build systems, GPU accelerated graphics, ...) but keep the important things like portability (no assembly), freedom of artistic expression (not forcing procedural generation), some amount of gameplay complexity etc. However, many techniques of tiny coding and demo scene will be reusable in suckless game development -- for example, I used bytebeat for music in Anarch. In this sense the exercise in writing extremely small code/programs can be seen as a very useful research whose results are utilized in suckless programming.

Regarding the search for right balance in program size, here is my interpretation of Unix philosophy, for those interested.
socialist anarcho-pacifist
Abolish all IP laws. Use CC0. Let's write less retarded software.
http://www.tastyfish.cz
User avatar
drummyfish
 
Posts: 330
Joined: 29 Jul 2018, 20:30
Location: Moravia

Re: Suckless Libre Games?

Postby Rampoina » 01 Jan 2021, 18:02

For others, it's still different: as I understand it tiny code is more about pushing the limits, programming exercise and treating programs like puzzles -- a bit like demo scene, but focusing on small source code.

It does have some focus on golfing but it doesn't need to be so. Actual suckless programs are perfectly valid examples of tinycode. The important part is making more things with less code (it can be clear code, no need to golf it out)

I'm going to comment on your guidelines:

- Write games in pure C99, because that is the most portable, efficient and suckless language. No C++, no Python, no Java, ... If that is possible.

I don't necessarily agree with this guideline.
I would say, use simple languages that can fit in your head and that can be easily implemented.

One example of a really simple language that can be as portable as C and as low level is Forth (Forth can run on anything):
https://github.com/cesarblum/sectorforth (obviously going for the extreme examples here but you get the point)

Another would have to be Lisp:
https://www.piumarta.com/software/maru/ (Lisp interpreter in 1750 lines of code that has 30% of the speed of C)

Yes, Lisp is garbage collected but that doesn't really matter for some games (is a garbage collector pause going to matter in a text adventure?, turn based puzzle? etc)
Constraining yourself to C just because it's ubiquitous seems really limiting to me. Understanding your tools is better.
Can you say that you understand the whole C language and how the compiler works? (gcc is the opposite of suckless) You can for those 2 languages.

And obviously there's many other languages that I don't know of that might be suitable.

- Do not use OOP and many of so called "good practice". These are considered "bloat", corporate style programming for HUGE projects. They teach you these for "safety" and because they are standard in the commercial sphere, but are burdening and limiting to us. Avoid unnecessary abstractions. Use simple imperative programming with functions, global variables etc.

Yes, avoid unnecessary abstractions. However, do use the right abstractions for the job. If some some part of the code benefits in simplicity for using OOP or some functional abstraction or whatever don't avoid it just because. I dislike OOP but it can be a tool that simplifies code greatly for some problems.

- Use as little computational resources (RAM, CPU, ...) as possible. This helps portability and accessibility, and is simply just a good engineering habit.

Yes, but don't over-optimize. Have a minimum target machine and make it run on that. It makes little sense to optimize your game for a TI calculator for example. That can be done afterwards by someone else (as has been the case with Doom)

- Be smart and hacky. For example using arbitrary sized textures can be a burden if you don't need this feature. In mainstream dev no one cares, everyone simply uses an "image library" and doesn't care about any overhead. However, it can help if you e.g. purposefully limit yourself to textures of size 32x32, as this will have quicker access (powers of two dimension, compile-time known bounds, ...), smaller code, fewer bugs etc.

Sure, as long as it keeps the code simple.
Rampoina
 
Posts: 2
Joined: 01 Jan 2021, 01:24

Re: Suckless Libre Games?

Postby drummyfish » 01 Jan 2021, 19:14

@Rampoina very nice input!

Rampoina {l Wrote}:I would say, use simple languages that can fit in your head and that can be easily implemented.


I have to admit you're probably right. Forth, Lisp, perhaps even Freepascal, Haskell and others are valid alternatives to C. Maybe I am pushing C too strongly, I know that despite it being so good it has many flaws. The main reason for C to me is the right amount of abstraction, it really is like portable assembly with some basic code structuring, plus it is the language that's most strongly rooted in computing, therefore it is the one least likely to die, and a C compiler is something that each new platform has to implement as a bare minimum. Something like Lisp is extremely elegant, but it's a bit more distant from the hardware, its computational model is different from that of the CPU, which loses you some efficiency and control. I tried to compile different languages to Pokitto, many times it is very difficult to figure out.

I would now say something more general, like that you should choose a language that creates the least amount of dependency and risk for your project.

The guidelines are made on spot so we can try to fine tune them together :)

Rampoina {l Wrote}:However, do use the right abstractions for the job.


Yes, people don't give much though to this. What I mean by unnecessary abstraction is e.g. a fixed point math library -- it is not needed, you can simply work with integers without any abstraction. Object abstraction is not bad per se, I just see its native integration into a programming language (at least in the "hybrid" way of Java, C++ etc.), or even forcing it, as a bad thing. Avoid these languages. Either way, needing such a high abstraction as "objects" or even "classes of objects" is hinting that your project may be too complex, in which case it is good to think about splitting it somehow. The simple data type abstraction should be enough for most programs I think.

Rampoina {l Wrote}:Yes, but don't over-optimize.


I'd say make it run on what it should be able to run -- e.g. if you're making a chess game, ask yourself "could an 8bit calculator run chess?", and if so, make that your target machine. With that version you can then work upwards by extensions, e.g. 3D graphics etc. Extending something simple is much easier than simplifying something complex. Of course, don't take this 100% literally, but try to not kill platform support with your software design.

This goes deeper when you think about tradeoffs and decisions about them. You can usually trade computing power for memory efficiency and vice versa. Demo scene typically gives up computational efficiency for gaining the smallest size possible. In suckless, we (at least I) again try to find some balance, with an effort to minimize both, but your decisions in this are inevitably affected by existing computers -- with Anarch for example I minimize RAM usage rather than CPU usage, because CPUs on embedded are relatively fast nowadays compared to RAM size.

-----------------

There are things I think I didn't do well enough with Anarch, for example it's not so modular. Ideally, as in Unix philosophy, the game shouldn't e.g. have integrated menu, it should be run from command line with specific flags instead of clicking items in menu -- a menu should be a separate module, reusable in any other game, which would offer the comfort of clicking items and would then run the actual game with correct flags. Modularity is something I would want to do better in next projects.
socialist anarcho-pacifist
Abolish all IP laws. Use CC0. Let's write less retarded software.
http://www.tastyfish.cz
User avatar
drummyfish
 
Posts: 330
Joined: 29 Jul 2018, 20:30
Location: Moravia

Re: Suckless Libre Games?

Postby PeterX » 21 Jan 2021, 17:34

I like the general concept of this proposal. Imho it should be taken not as puristic "ideal" but rather as a rough guideline.

I was reading this:
https://noobtuts.com/articles
and thought "I want to do both: Make an MMORPG and make a minimalistic game." So I came up with this kind of absurd idea to make a mini MMORPG. I don't know yet if I will succeed, because I'm not the world's fastest or most enduring programmer. But I started the project.

Greetings
Peter
User avatar
PeterX
 
Posts: 59
Joined: 01 Oct 2020, 21:44

Re: Suckless Libre Games?

Postby onpon4 » 22 Jan 2021, 04:54

I find "suckless" "philosophy" to be terribly lacking and short-sighted. It seems to be to be nothing more than conservative elitism which arbitrarily rejects modern ideas as things that "suck". The only common thread I can see is that it seems to reject anything which makes the lives of users easier, as if salty about the fact that they don't have a special place atop a "computer users" hierarchy and seeking to reestablish that sort of inequality. Supposed justifications for the "philosophy" are entirely incoherent, as I'd like to demonstrate below.

C99... is the most portable, efficient and suckless language.

Is it really, though? I'm pretty sure the most portable language is clearly JavaScript. It can run literally everywhere since that's what it's designed to do. As for speed, C++ performance is generally the same as C performance, and in both cases this depends on you (the developer) spending many, many hours doing very basic things.

If your game can run without floating point (it most likely can), only use integers! Many CPUs (embedded) do not have floating point coprocessor and floating point operations are slow there!

How prevalent is this really? FPUs have been standard for decades at this point. For any computer which has one, reimplementing floats with confusing integer representations is likely to lead to a slower implementation. (And if you don't need floats to begin with, then you're not using floats anyway because of the fact that floats are inherently imprecise.)

Also, this is an incredibly tiny portion of what affects performance in a game. It quite frankly doesn't matter in the bigger picture. Making a frame take (say) one nanosecond less is meaningless when a frame takes 17 milliseconds by design, and when looping through objects that collide takes (say) 500 nanoseconds.

Will your game be less fun with pure ASCII non-antialiased font rendering?

It certainly will for Japanese players; Japanese simply cannot fit into ASCII, there's thousands of characters you have to include. That's why when someone translated Project: Starfighter, which "simply" uses pure ASCII, the Japanese version had to include new code for interpreting escape sequences for whatever character encoding they used. Whereas now that Project: Starfighter uses UTF-8, all a Japanese translation has to do is... translate, using Gettext. No messy code changes, no need to maintain a separate version, no need to sort every single Japanese character into a massive raster image.

Before Unicode, Japanese was encoded with various Japanese-specific encoding schemes, which would mean that if your software wasn't expecting it, it would display garbage. This kind of thing is exactly why Unicode exists. ASCII or an 8-bit extension of it like Latin-1 may be sufficient for European languages, but it's not sufficient for Chinese, Japanese, Russian, Hindi, Korean, etc. (Mandarin Chinese, by the way, has the largest number of first-language speakers in the world, more than double the number English has.) Unicode unites all languages under one standard and makes things simple. UTF-8 is even entirely compatible with 7-bit ASCII.

Also, regarding anti-aliasing, not doing anti-aliasing can legitimately make text nearly impossible to read at small resolutions. I've seen this personally with the "~" character, which shows up under some fonts identically to "-" without antialiasing and at small sizes. This usually doesn't affect English text, but in the case of a language like Japanese, where you have to be able to identify characters with over a dozen strokes (can't show an example here because the forum software doesn't support Unicode), either you need to have large text, or you need to have antialiasing.

Do not use config files, write configuration and settings right in the source code, e.g. in a special "settings.h" file. Remember, your game recompiles in less than a second with a single command.

This strikes me as horrible advice. It means suddenly developer tools (a compiler, at the very least) are now a dependency. Regardless of how easy it is for you to recompile, how exactly do you expect this to be user-friendly on Windows or Android?

Use single compilation unit, best if you can fit your whole program into a single file

Yeah, no, bad advice. ReTux and Hexoshi have been developed as single-file programs and I've regretted that decision ever since. At some point I'm hoping to split them into multiple files for the simple reason that a single file is difficult to read and edit. This is also exactly why the SGE is now multi-file (it was converted from a single-file mess years ago).

Avoid build systems such as CMake, at worst use a simple Makefile.

Also bad advice, at least unless you want to discover on your own all the peculiarities of distros that you hadn't thought of and painstakingly fix each one. There's a reason these complex build systems exist, and it's because it makes building code more portable.

For example, don't you hate it when you find a game that is completely libre, but you still cannot compile it because some of the dozens of dependencies is broken?

I can't say I've ever experienced that. What I've usually experienced is code that doesn't follow language standards and then at some point stops compiling as a result. Usually when this happens someone will take over and fix these problems.

Personally I am very sad that even libre games die this way, and I am often discouraged from playing a game that I think may die soon.

Why? The only game I've ever seen break is Super Mario War, and that ended up getting fixed by volunteers. (Also, it broke because of code which wasn't in line with standards, not because of dependencies.) What game has "died"?

Yes, Anarch also requires SDL for its PC frontend, but this is a very soft dependency that can be replaced by anything that can draw pixels and read keyboard.

Wouldn't that apply to any game? Jump'n'Bump originally used something that I think was DOS or Windows-specific, and then someone replaced that with SDL when it was made open source. Games from the past which required SDL 1.2 like Project: Starfighter have been migrated to work with SDL2. Heck, SDL is open source, if it stopped being maintained why wouldn't you just... fork and maintain it?

It may require a little more effort from you, but in the end pays off much more, as it will be like the legendary Doom, resisting decades and technological changes, to always be there for the people.

You do realize that Doom had to be ported, right? And that it used hardware acceleration? It was a AAA game in its time with groundbreaking graphics. It's hardly an example of the "suckless" "philosophy" as you describe it. If anything, Doom's success is an example of why the "philosophy" as you describe it makes no sense.
User avatar
onpon4
 
Posts: 598
Joined: 13 Mar 2014, 18:38

Re: Suckless Libre Games?

Postby drummyfish » 22 Jan 2021, 15:38

PeterX {l Wrote}:So I came up with this kind of absurd idea to make a mini MMORPG.


Very nice @PeterX, great idea, I don't think it's conflicting anything here, I'll be very curious about your project. I've been also thinking about making a minimalist RPG, something in the style of the Elder Scrolls, but only capturing the pure essence of it and keeping it as minimal as possible -- it could be a top-down ASCII rendered view (like roguelikes, allowing graphical frontends as an extension, even 3D rendered ones), or just a pure text adventure.

onpon4 {l Wrote}:I find "suckless" "philosophy" to be terribly lacking and short-sighted.


No no no, it's the exact opposite, let me explain.

The mainstream tech is short sighted because it mirrors the commercial style of development which has evolved to serve the market, i.e. quick profit without long-term planning, as anything on the market. Therefore the mainstream is developed rapidly and with many dependencies that have very high probability of dying withing let's say 5 years -- which no one in the business cares about, of course. And also no one simply has the long term questions on their mind when deveping mainstream programs, which leads to many small decision that endanger the project (e.g. not commenting the code properly, not considering slower HW etc.). Suckless is to a big degree a mindset that directs all your decision, often times subconsciously.

If you dislike suckless specifically, let's just call it Unix philosophy, minimalism, or just good and proper engineering.

onpon4 {l Wrote}:It seems to be to be nothing more than conservative elitism


Nooo, firstly I hate conservative rightist too, I know a lot of them are in suckless, and I don't care, what matters are the ideas. Secondly it's not elitism, suckless is literally easier to use. It's only that people are spoiled by capitalist tech, are force-fed it from birth to think bloat is easier, and it does take a bit of effort to relearn the new way of doing computing. You're argumenting like the "noooooo linux hard windows just werks" people.

onpon4 {l Wrote}:I'm pretty sure the most portable language is clearly JavaScript.


Nah, when you consider embedded and other non-PC platforms, like open consoles and Arduinos, you'll see they're programmed in C/C++. 8bit Arduboy with 2.5 KB RAM won't eat no JavaScript.

onpon4 {l Wrote}:As for speed, C++ performance is generally the same as C performance


C++ is just unnecessary shit complicating C language and therefore complicating the compiler, you don't want that, not talking about poisoning the mind.

onpon4 {l Wrote}:and in both cases this depends on you (the developer) spending many, many hours doing very basic things.


Speak for yourself I guess :) Nah really, it may take a bit longer, but the program will be better, that's the point. I say that at the beginning of the thread.

onpon4 {l Wrote}:FPUs have been standard for decades at this point. For any computer which has one, reimplementing floats with confusing integer representations is likely to lead to a slower implementation. (And if you don't need floats to begin with, then you're not using floats anyway because of the fact that floats are inherently imprecise.)

Also, this is an incredibly tiny portion of what affects performance in a game. It quite frankly doesn't matter in the bigger picture. Making a frame take (say) one nanosecond less is meaningless when a frame takes 17 milliseconds by design, and when looping through objects that collide takes (say) 500 nanoseconds.


Firstly I'm not reimplementing floating point, I'm just using fixed point represented as integers instead. It's literally good enough for most things you normally do with floating point, soydevs don't even realize this.

Secondly, embedded often times have no FPU, it is emulated in SW and it does make a huge difference to use integers instead, literally from unplayable framerate to 30+ FPS.

onpon4 {l Wrote}:It certainly will for Japanese players; Japanese simply cannot fit into ASCII, there's thousands of characters you have to include. That's why when someone translated Project: Starfighter, which "simply" uses pure ASCII, the Japanese version had to include new code for interpreting escape sequences for whatever character encoding they used.


Yeah that's fair, but it depends on each individual project. If your game is story-based with a lot of text and you want to support Japanese, then sure, use Unicode. But if it's an action game with only text being in the menu or if you're using text for rendering (like roguelikes) then no need to do that.

If it's too much of a hassle to support Japanese, then just don't and make Japanese learn English ;) Really their writing system is extremely ugly, better avoid that whenever possible. English is bloat too, eventually we should all just learn Esperanto and then we can even ditch Unicode.

onpon4 {l Wrote}:Also, regarding anti-aliasing, not doing anti-aliasing can legitimately make text nearly impossible to read at small resolutions. I've seen this personally with the "~" character, which shows up under some fonts identically to "-" without antialiasing and at small sizes.


This happens when you use bloat vector fonts, just use bitmap fonts like old computers did and it's solved.

onpon4 {l Wrote}:Regardless of how easy it is for you to recompile, how exactly do you expect this to be user-friendly on Windows or Android?


I don't ever expect Windows or Android to be user friendly.

onpon4 {l Wrote}:single file is difficult to read and edit.


Please explain exactly why. I think you may just be using a shit editor.

onpon4 {l Wrote}:There's a reason these complex build systems exist, and it's because it makes building code more portable.


Yes, there is a reason, it's called inherently shitty design of short-sighted capitalist technology that now has no other way to deal with the monstrosities it has created.

onpon4 {l Wrote}:What game has "died"?


Lazy to look up the names now but I was once searching git hosting sites for small games to add to libregamewiki (many can now be found in suggested games), and probably most of them wouldn't compile because the dependency packages have changed since the author abandoned the game years ago. They were legitimately good looking games but I couldn't get them to compile so I couldn't add them to LGW.

onpon4 {l Wrote}:Wouldn't that apply to any game? Jump'n'Bump originally used something that I think was DOS or Windows-specific, and then someone replaced that with SDL when it was made open source. Games from the past which required SDL 1.2 like Project: Starfighter have been migrated to work with SDL2. Heck, SDL is open source, if it stopped being maintained why wouldn't you just... fork and maintain it?


Yes of course most games do have frontends that can be replaced, but they don't go far enough and use too much of the frontend library and replacing that frontend is non-trivial. My game's front end only consists of a few functions like drawPixel or buttonPressed which any platform can implement usually with a single line, so replacing the frontend and porting the game to a new platform only takes a few hours, most of which is playtesting. Any time a get a new console I usually have my game ported to it the same day.

Forking and maintaining SDL? No, thanks, can you even imagine what amount of work that means?

onpon4 {l Wrote}:You do realize that Doom had to be ported, right? And that it used hardware acceleration? It was a AAA game in its time with groundbreaking graphics. It's hardly an example of the "suckless" "philosophy" as you describe it. If anything, Doom's success is an example of why the "philosophy" as you describe it makes no sense.


Yes, I didn't really say Doom was suckless, it was far from it, but I wanted to bring up how well Doom was designed compared to today's games, as everyone knows the "can it run Doom" meme. Sure, Doom was imperfect, that's why I have written Anarch.
socialist anarcho-pacifist
Abolish all IP laws. Use CC0. Let's write less retarded software.
http://www.tastyfish.cz
User avatar
drummyfish
 
Posts: 330
Joined: 29 Jul 2018, 20:30
Location: Moravia

Re: Suckless Libre Games?

Postby dulsi » 22 Jan 2021, 16:30

onpon4 {l Wrote}:
For example, don't you hate it when you find a game that is completely libre, but you still cannot compile it because some of the dozens of dependencies is broken?

I can't say I've ever experienced that. What I've usually experienced is code that doesn't follow language standards and then at some point stops compiling as a result. Usually when this happens someone will take over and fix these problems.

Personally I am very sad that even libre games die this way, and I am often discouraged from playing a game that I think may die soon.

Why? The only game I've ever seen break is Super Mario War, and that ended up getting fixed by volunteers. (Also, it broke because of code which wasn't in line with standards, not because of dependencies.) What game has "died"?

Games not working is a problem. I encounter it a lot but I seek out and try a lot of games. It's why I did a presentation on game restoration at the last LibrePlanet. I have resurrected several games but there are more broken games that I don't have the time for. Some are awful and probably not that important to save. Dependencies are the biggest problems I encounter. Sometimes it is minor compile errors either because it isn't in line with the current standard but that isn't always the creators fault. Python 3 is not compatible with python2 in all cases. auto_ptr is being removed from C++ so old code will not compile when the compilers default to C++17 or greater.

https://github.com/TheRedSpy15/The-Trail/ - Not able to build anymore.
Warlock's Gaunlet - I wasn't able to build this one I believe.
https://github.com/Blecki/dwarfcorp - Relies on XNA which Microsoft discontinued.
dulsi
 
Posts: 491
Joined: 18 Feb 2016, 15:24

Re: Suckless Libre Games?

Postby onpon4 » 22 Jan 2021, 17:55

dependencies that have very high probability of dying withing let's say 5 years

I can't say I've ever used those. SDL has been maintained for over two decades. Python has been maintained for 3 decades. Pygame has been maintained for over two decades.

Even if they went unmaintained (as Pygame did for a while), that wouldn't mean that they're dead, it would just mean that someone new has to pick up and start maintaining them.

Secondly it's not elitism, suckless is literally easier to use. It's only that people are spoiled by capitalist tech, are force-fed it from birth to think bloat is easier, and it does take a bit of effort to relearn the new way of doing computing.

You claim that it's not elitism and then defend it with an elitist statement?

This isn't a "new way of doing computing". It emulates the hacker era of the late '70s and early '80s. It is by definition conservative, rejecting anything remotely modern (like systemd) in favor of outdated, klunky software (like SysV-init).

Claiming that people are just too incompetent to know what's easy to use is patently absurd. The reason we do computing the way we do is precisely because of ease of use and convenience.

Nah really, it may take a bit longer, but the program will be better, that's the point.

Yeah, no. It's much, much harder to write a program just as capable in pure C than it is in Python, or even with Lua scripting. I can spend 15 minutes on a Python script to do something that would take me hours to do in C. And no, the C program isn't better at the end, just harder to extend and maintain in exchange for a performance benefit which probably doesn't even matter.

It's literally good enough for most things you normally do with floating point, soydevs don't even realize this.

Not if you want to do accurate trigonometry, or do accurate floating-point division, or otherwise actually use floating point for something that matters.

If it's too much of a hassle to support Japanese, then just don't and make Japanese learn English ;) Really their writing system is extremely ugly, better avoid that whenever possible.

Did you not read the part where I said that Mandarin Chinese is has the largest number of first-language speakers on the planet? That's not even counting other languages that use the Chinese writing system, like Cantonese and Japanese. Your opinion that all of these people should abandon their native language is both Eurocentrist and imperialist. You're suggesting that Europeans have a right to impose their culture on the entire world and force the entire world to use their language. Why? Because you think "their writing system is extremely ugly"? Korean has a writing system that is regarded as one of the best in the world. Chinese is an entire family of languages as various as European languages all unified by a language-agnostic writing system, and it has influenced southeast Asia for thousands of years. These are not bad languages, and the fact that they have characters that ASCII doesn't support is not a deficiency. Only your eurocentric attitudes lead you to think that it is.

This happens when you use bloat vector fonts, just use bitmap fonts like old computers did and it's solved.

"Just" use bitmap fonts and waste a whole lot of space storing rendered bitmaps, not to mention have to re-export those bitmaps if you ever want to resize them (or worse, have to completely redraw everything)?

Or you could just use anti-aliasing which has been standard for decades.

I don't ever expect Windows or Android to be user friendly.

Any Windows user can fire up Project: Starfighter no problem and change the options through the options menu, no compiler needed. Same goes for ReTux, Hexoshi, Naev... there's no need for a compiler, just have config files like everyone else does.

Please explain exactly why [single file is difficult to read and edit]. I think you may just be using a shit editor.

Or, when the number of lines is in the thousands, it takes an inordinate amount of effort to scroll to exactly the place I need to go to, even if I know what that place is.

My game's front end only consists of a few functions like drawPixel or buttonPressed which any platform can implement usually with a single line

Having looked at Anarch's source code... really? You actually draw everything by using a setPixel function?

What you basically did was design a game engine that makes work harder for you. It almost certainly is leading to worse performance, too. And why? Because you want to support a device that doesn't support libraries as common as SDL or OpenGL? SDL is so portable that Project: Starfighter is literally running on AmigaOS, and here you are not even trusting your graphics library to provide a blit function.

And guess what? It still doesn't run on all hardware. Good luck getting it to run on a TI-84+ calculator. You're just setting a portability cutoff which is just as arbitrary as anyone else's, but deeming yours superior.

Incidentally, I've actually written a game on the TI-84+ calculator. That's not hypothetical.

Forking and maintaining SDL? No, thanks, can you even imagine what amount of work that means?

Probably far less than the effort you're going to to reinvent drawing functions because you don't trust a portable graphical library to do that for you. Not to mention, SDL is so widely used it's not going to come to that. Someone will pick it up and maintain it.

I wanted to bring up how well Doom was designed compared to today's games, as everyone knows the "can it run Doom" meme.

...Except the universality of Doom running pretty much everywhere has absolutely nothing to do with the way it's designed. Did you not read what I said? Doom was a AAA game in its time that required high-end hardware and whose engine had to be ported and partially rewritten many times. One of those ports was a Linux port, which was released as open source, and then the popularity of the game led to people improving the Linux port so much that it became nearly universally available. You know what else this happened with? ScummVM. Adventure games, which were written in some of the shittiest engines imaginable that weren't even open sourced, are now very often universally available on pretty much any hardware. That, again, is because these games were popular.
User avatar
onpon4
 
Posts: 598
Joined: 13 Mar 2014, 18:38

Re: Suckless Libre Games?

Postby drummyfish » 22 Jan 2021, 18:10

Sorry I have no more mental strength to respond to that @Onpon4. Thanks for sharing your opinions. I also have a feeling that if we two continue a debate an angry moderator will appear and lock the thread :D
socialist anarcho-pacifist
Abolish all IP laws. Use CC0. Let's write less retarded software.
http://www.tastyfish.cz
User avatar
drummyfish
 
Posts: 330
Joined: 29 Jul 2018, 20:30
Location: Moravia

Re: Suckless Libre Games?

Postby PeterX » 22 Jan 2021, 18:13

I definitely have tried a lot of games which broken dependencies, for various reasons. Sometimes it's a special version of that dependency which is needed but I haven't it. Sometimes there are really A LOT of dependencies. Sometimes the dependency is outdated. Sometimes it's broken code that calls the dependency, which is a problem which should not be underestimated.

Also my kind of coding fits more to the suckless/minimalistic way of programming. It takes me more effort to learn a complete game engine/framework than to learn using a basic, simple low-level library/module.

I'm also not a big fan of Javascript and all this web-game-thingy, but it depends on the project. I personally don't like C++ and it is surely more complicated than C, but I use it anyway for my game project because when then project becomes large, OOP is a kind of simplification. (Yes, for small projects OOP is making things more complicated.)

Onpon4 definitely likes a different approach than myself. So be it... Let the games we make speak for themselves! :)

Greetings
Peter
User avatar
PeterX
 
Posts: 59
Joined: 01 Oct 2020, 21:44

Re: Suckless Libre Games?

Postby drummyfish » 22 Jan 2021, 19:00

Thanks PeterX, you're right, we're different people, let our creations speak.

I don't hate JavaScript, it's actually not such a bad language and I often use it to write simple tools or not so serious small programs that I want to run from the browser, e.g. http://www.tastyfish.cz/wikimap/.

For some time now I've have an idea for another suckless game. Maybe it would be for another thread but let me throw the idea here for now:

It would be an exploration/zen/walking simulator game on the same engine as Anarch, but taking place in an abstract mostly procedurally generated colorful blocky land, vaguely resembling Minecraft style games, however it would not be about creating but rather exploring the alien world and its mechanics. There would be no goal, just exploration and goals the player would impose on himself. I would like to make it more suckless by not using any textures or sprites and not even any text (no language barriers) -- there could be animals like butterflies but only composed of very simple geometric shapes. There would be no menu, you would just be thrown into the world at the beginning, and there would be no real position saving -- you'd unlock locations simply by discovering how to get to that location. The goal of the game would be to provide a nice slow world to escape to from the real world, e.g. when you're in depression (I used to deal with depression like this with proprietary games, but since I stopped playing them I've had no place like that anymore, so I'd like to create one).

I wonder how far I could push the size of that game when I drop all assets like images and sounds.
socialist anarcho-pacifist
Abolish all IP laws. Use CC0. Let's write less retarded software.
http://www.tastyfish.cz
User avatar
drummyfish
 
Posts: 330
Joined: 29 Jul 2018, 20:30
Location: Moravia

Who is online

Users browsing this forum: No registered users and 1 guest

cron