minimalism started as an art movement. it was a way to break the expectations of traditional art, opting to follow the recently-born expectations of modern art. the way they did that was by reducing. not reducing anything in specific, but just reducing in general. less materials, less colors, less shapes, less harmony, less beauty citation needed for this entire paragraph (im minimizing explanations!)
minimalism also extends to other areas of human experience, including: furniture, houses, sports, relationships, ideas, religion, politics, food, emotions and so on.
even having harsh criticism against minimalist art, i actually quite enjoy this idea. not for art though, i don't think it fits there at least, not without some modifications. as someone who at 6yo spent days obsessing over those old factorio-inspiring industrial minecraft mods, the idea of reducing the resources and the work used, optimizing the ways to achieve some goal is hypnotizing.
i have started to consider minimalism when i was first introduced to c++ context: i was a unity c# gamedev at the time
for those who don't know, c++ is a complex programming language, but uses relatively simple tools to build a relatively simple program.
think for example: godot. every game made on godot, assuming it follows the default way of using the engine, will require all of the dependencies the godot engine needs to run, plus all of the extra dependencies the game itself might need, like a dialogue system, a room editor, loot dropping libraries and etc.
compare that to just c++: c++ is just a programming language, there is no dependencies other than a c++ compiler. you can either build all of the rest yourself or use external dependencies for it, like the standard c++ library, which provides extra functionality to c++
a game made in godot will require all of the baggage godot brings. and it is quite a lot check the dependencies here. this does not cover the first-party dependencies of godot. of couse it needs to be. godot has to support every type of game! and support every hardware architecture! and every modern operating system! and accommodate every type of developer! you get the idea. the more generic something is, the larger it gets. compare that if godot only had to support visual novels for the windows 98 for english-speaking fortran developers. how much of the engine could you throw away?
the same principle applies to games made in c++. if you need graphics, you will have to use the api available for the operating system of choice. if you choose all operating systems, a good portion of your game is dedicated to wiring and domesticating every graphics api. even if you outsource this work to someones project, the cost is still there. and probably larger than if you wrote it yourself, since it probably will try to be generic and try to work for every other use case
but if you don't need something, you can easily not implement it. not so easy in godot, where even if you decouple something from your project, there is the cost of the decoupling system itself.
i have thought about this concept for a while now, and i have been thinking on how to implement to my other projects. i have been struggling minimizing some of them but others have been really smooth to do. this comes down to what the project is about. i could easy apply minimalism to my software and code, since they are practical tools, but i found it hard to apply this idea to my art, which i'm always trying to make more elaborate works every time
i did try to apply minimalism to some of my songs and, although most people doesn't seem to care too much about the result, i noticed i can do better if i ain't trying to make the song purposely simpler. although it really helps to actually finish lots of songs
my idea to circumvent this limitation of minimalism is to set a clear goal first, then find out the minimum we need to achieve this goal. using this method we can take advantage of simpler execution but retain the goal first. this goes somewhat against minimalism, which would lower the goal
here are some rules i found to be useful when trying out this concept:
- be objective: if your goal depends on the state of a mutable property, it is probably better to abandon it. examples include: fame (requires attention from other people) money (requires other people willing to give you money) health (you dont know when you are going to get sick, or die). examples of good properties: mathematically possible (immutable) truth in general
- be precise: somewhat ties into the previous rule. avoid ambiguity or relying on terms you don't know. this requires some introspection and humility so it might be somewhat hard to do.
- thunder: when you do it, do it all at once and then move on. i named this rule thunder because of some part in art of war
- think before doing it: i rarely do this but when i do its really great. you can avoid getting into bad situations in the middle of your project. although, it is best not to think too much or else you might overcomplicate it
based on all of these ideas, i've spent a lot of time refactoring this website so that it would be simpler. some examples include: removal of all span tags, removal of all divs, using mostly just simple html tags, which every browser should support and render them correctly. i have even added a little bit of colors via css, so that it stays colorful and pretty. i like it. and hopefully you liked it too
i would write a little bit more about lynx and gopher and etc but i think this is getting really long and i have been procrastinating this update a lot now so thats it goodbye