Update
This commit is contained in:
parent
ee83d8a6b6
commit
362a9efe1f
27 changed files with 2107 additions and 2019 deletions
|
@ -14,7 +14,7 @@ Also let it be said that everyone has to find his own way of doing projects, it'
|
|||
- **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](free_software.md)), and also very importantly the cost of collaboration. Multiple people on a project -- even just two -- introduce many inconveniences, issues and [friction](friction.md), 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](exercises.md) 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](finished.md) 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](shit.md). 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 be feeling down and be a bit happier. On the other hand however if your project still ends up failing don't become too depressed and try to take the best of it -- it's not the end of the world, you have acquired some experience and you may still try to reuse parts of the failed project elsewhere, just try to extract maximum good.
|
||||
- **Take long breaks**, enjoy the luxury of it not being a "[job](work.md)" -- once you're fed up and sick of the project, take a pause. If other projects are waiting, you may hop elsewhere, and if you're simply just overall tired, take a full vacation without feeling guilty, go play [games](game.md) or whatever. In a week, month or a year you'll start to feel the urge to get back and when you do, you know it's time, it's a sign your enthusiasm is returning, it's very likely you'll now experience a period of """[productivity](productivity_cult.md)""" (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.
|
||||
- **Take long breaks**, enjoy the luxury of it not being a "[job](work.md)" -- once you're fed up and sick of long work, indulge a pause and relaxation. If other projects are waiting, you may hop elsewhere, and if you're simply just overall tired, take a full vacation without feeling guilty, go play [games](game.md) or whatever. In a week, month or a year you'll start to feel the urge to get back and when you do, you know it's time, it's a sign your enthusiasm is returning, it's very likely you'll now experience a period of """[productivity](productivity_cult.md)""" (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. On the other hand, however, **leave the "official release" part for the very end** -- i.e. have the project public, but don't go actively showing it to people, don't waste time on adding it to repositories, making websites and similar stuff. Firstly this leaves you a kind of "reward" at the end, something you get for FINISHING the project. If you show a 50% finished game to the Internet and get a praise, you've gotten your treat ahead of time, you will no longer want to pursue finishing the thing. Secondly you may very likely abandon the project (and more so due to what's just been stated), leaving just a spam of unfinished half-baked ideas behind. Take a look a libregamewiki, vast majority of games are "50% finished" prototypes of no value to anyone.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue