less_retarded_wiki/project.md

Project

Project is a highly planned endeavor. TODO: moar

How To Do Projects Well

Firstly a word of warning: stuff about how to plan projects, lead them, get people "motivated" and so on is a huge, huge milking cow of "productivity" writers and capitalists, to a large degree this is a bullshit topic growing alongside gigantic capitalist bullshit projects and entrepreneurship religions. Never fall into this trap, never let concerns about how to make art take too much of the time that should actually be spent on making the art itself. With this said, we may offer some useful word of advice.

Also let it be said that everyone has to find his own way of doing projects, it's just like with learning for example: everyone has his own ways, what works for one may not work for another. The advice here will come firstly from the author's (drummyfish) personal experience and secondly from general LRS principles. Also even though we'll mostly be talking about programming projects, a project can be anything really, what we say applies also to making a music CD or writing a book. Here we go:

• As always, keep everything free, LRS, well designed, non-commercial etcetc. Just a reminder. Also think with your brain.
• Prefer one man projects to many men projects: Firstly LRS projects should be simple enough to be manageable by a single man, which has many advantages, for example ensuring a coherent artistic vision without any compromise, legal simplicity (e.g. with relicensing), ensuring that the project can REALLY be controlled by a single man (true freedom), and also very importantly the cost of collaboration. Multiple people on a project -- even just two -- introduce many inconveniences, issues and friction, e.g. that of communication (every thought has to be explained, put into words for others and they still may not completely get it, communication tools will have to be set up and maintained, ...), resolving editing conflicts (multiple people working on the same thing at once), making decisions (voting? discussions?), disagreements, arguments, "codes of conducts" and similar bullcrap. LRS does value collaboration, but mainly loose collaboration, i.e. making bigger things out of smaller things that are made by single people. But more people projects are cool, e.g. wikis or maybe projects by very close people who are already used to working together efficiently.
• Do NOT be too ambitious, especially with first projects. This is EXTREMELY important and you have to realize that even if you think something will be easy, it won't be so, a project will always be at least 20 times harder than you estimate (even if you already have experience in estimating project difficulty). Making a game is not just about programming it (which itself means debugging, refactoring, writing tests, debugging tests, organizing repos, designing APIs, studying libraries, ...), you'll also have to document it, play test it (many, many times over), debug it, optimize it, package it, make a website for it and a billion other things. If you decide to make a game like GTA (or even just Pokemon clone or something) but you haven't made at least 10 games already, YOU WILL FAIL, it will be a disaster and completely wasted time. Unless you've done like 10 projects already, choose dead simple things like Tetris clone or something (see exercises for beginner project tips). Remember, the goal of your first project isn't the thing in question but rather learning about making a project and finishing it.
• FINISH THE FUCKING PROJECT. Unfinished project will just have wasted your time, it will leave you disgusted, broken, depressed and defeated, it will be of no use to anyone, you'll just feel like shit. For this it is important to choose something simple -- if you finish the thing, you'll be happy regardless of how simple it really was, you'll be eager to make more things, people will be able to use your project, they'll be thanking you for it which will further make you more happy and so on. Even if it's a freaking minesweeper, you've made your own game now, it brings happiness to people, you can take a look at it every time you'll feeling down and be a bit happier.
• Take long breaks, enjoy the fact this is not a "job" -- when you've become fed up with your project, take a pause. If you have other projects, you may hop onto another one (but if you're simply overall tired, just take a full vacation, go play games or whatever). In a week, month or a year you'll start to feel the urge to get back to it and when you do, it's a sign you'll be enjoying doing it again, it's very likely you'll then get a period of """productivity""" (better said just enjoyment) and inspiration. Also when you get stuck or stand before an important decision taking a break is very much advised, you need a fresh mind and even if you make a decision, take a few more days to see if you still think it's good after some time.
• Have multiple projects in progress. This is cool for several reasons, for example it prevents a burn out of a single project -- if one projects becomes boring, shows to lead nowhere or you simply get tired of it for a while, you switch to a different one. Even if it fails completely and you delete it, you still have many other "children", it won't be a disaster. Sometimes you have a period when you want to program, so there's a programming project waiting for you, other times you feel like you wanna do music, and there is the project that needs some music, just ready for you. So this also stimulates you in different ways. And sometimes you get surprised if some small project turns into something unexpected maybe. It's just good to have this diversity in your art.
• Do everything yourself and keep switching tasks. This is similar to the other point about having multiple projects, just within a single project. Be your own programmer, graphic designer, musician, tester, writer and so on -- at least as much as possible. This not only helps you become a cool generalist, an independent, non-capitalist living being, but also prevents burn out from doing the same activity over and over.
• Publish everything immediately, don't wait until the project is "polished", this NEVER, never ends well. Really just have everything public at all times, keep no secrets, make it public even if it's buggy, shit, cringe, dangerous or whatever. This doesn't mean "go promote your buggy unfinished game", but simply "have your work-in-progress git repo public". This is not capitalism in which you work in secrecy and then "ship" a "product". Just make art and let anyone watch you, give you "feedback", advice and so on, get rid of shame, don't let others waste time on making what you're already making, don't let perfectionism paralyze you so that you'd never release your art.
• If you ARE ambitious, separate the thing into multiple less ambitious projects. Firstly this is just a good design, you shouldn't make a huge monolithic program but rather multiple simple things out of which it is easy to make the big thing. This achieves multiple things: you'll have several parallel projects as advised above and also if you don't finish the grandiose work, you'll still probably finish at least some parts of it that will be useful on its own. So if you really want to make that GTA clone (and have at least 20 years of experience so that you can even think about it), rather make several projects such as a 3D renderer, physics engine, a pack of car 3D models etc. When all of the projects are ready, you may try to merge them into the magnum opus.
• "It would be cool" is not a good enough motivation for a bigger project. You can't start a big thing just out of boredom. Finishing a greater thing will be painful, you'll be through sleepless nights, periods of desperation, headaches and burn outs, you'll sacrifice social life to hunting down bugs and rewriting shitty code. To keep yourself going through this it's not enough to know that "the result will be nice I guess". It needs more -- you must absolutely feel it is necessary to make the thing, you have to think the world NEEDs you to make it, only then you will keep torturing yourself to make it to the finish. So choose very wisely.
• Before making a big thing of type X make a small thing of type X or as it's been said "plan to throw one away". This is to say that you can't make a good game if it's the first game you're making, so you better make your first game small knowing that it ill suck rather than making a big game that would suck. The first thing is just for the experience. You can't prepare yourself for making an operating system just by reading a book, you have to make one to REALLY comprehend what it will be about, to see the whole picture and to properly plan it.
• ...