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.
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.
- 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.
- Use as little computational resources (RAM, CPU, ...) as possible. This helps portability and accessibility, and is simply just a good engineering habit.
- 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.
Rampoina {l Wrote}:I would say, use simple languages that can fit in your head and that can be easily implemented.
Rampoina {l Wrote}:However, do use the right abstractions for the job.
Rampoina {l Wrote}:Yes, but don't over-optimize.
C99... is the most portable, efficient and suckless language.
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!
Will your game be less fun with pure ASCII non-antialiased font rendering?
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
Avoid build systems such as CMake, at worst use a simple Makefile.
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?
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.
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.
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.
PeterX {l Wrote}:So I came up with this kind of absurd idea to make a mini MMORPG.
onpon4 {l Wrote}:I find "suckless" "philosophy" to be terribly lacking and short-sighted.
onpon4 {l Wrote}:It seems to be to be nothing more than conservative elitism
onpon4 {l Wrote}:I'm pretty sure the most portable language is clearly JavaScript.
onpon4 {l Wrote}:As for speed, C++ performance is generally the same as C performance
onpon4 {l Wrote}:and in both cases this depends on you (the developer) spending many, many hours doing very basic things.
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.
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.
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.
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?
onpon4 {l Wrote}:single file is difficult to read and edit.
onpon4 {l Wrote}:There's a reason these complex build systems exist, and it's because it makes building code more portable.
onpon4 {l Wrote}:What game has "died"?
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?
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.
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"?
dependencies that have very high probability of dying withing let's say 5 years
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.
Nah really, it may take a bit longer, but the program will be better, that's the point.
It's literally good enough for most things you normally do with floating point, soydevs don't even realize this.
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.
This happens when you use bloat vector fonts, just use bitmap fonts like old computers did and it's solved.
I don't ever expect Windows or Android to be user friendly.
Please explain exactly why [single file is difficult to read and edit]. I think you may just be using a shit editor.
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
Forking and maintaining SDL? No, thanks, can you even imagine what amount of work that means?
I wanted to bring up how well Doom was designed compared to today's games, as everyone knows the "can it run Doom" meme.
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.
drummyfish {l Wrote}:... SmallAbstractFish (I'll create a new thread when the time comes): it's a platform for small suckless games -- something like a fantasy console, but also something like an extremely simple "SDL" that can run on very very tiny embedded consoles. The point is that you can write a game with SAF very easily as it's super simple (64x64 256 color display, fixed palette, 7 buttons, beep sounds), and your game will automatically run on all SAF supported platforms that are powerful enough to run it (it's a generalization of what I've done with Anarch).
drummyfish {l Wrote}:@Pix3l thank you, I'd love to see your game!
drummyfish {l Wrote}:I'll take this opportunity to post a link to my current project, SmallAbstractFish (I'll create a new thread when the time comes): it's a platform for small suckless games -- something like a fantasy console, but also something like an extremely simple "SDL" that can run on very very tiny embedded consoles. The point is that you can write a game with SAF very easily as it's super simple (64x64 256 color display, fixed palette, 7 buttons, beep sounds), and your game will automatically run on all SAF supported platforms that are powerful enough to run it (it's a generalization of what I've done with Anarch).
https://gitlab.com/drummyfish/saf
Users browsing this forum: No registered users and 1 guest