Sortie de Mageia 5

https://fr.wikipedia.org/wiki/Mageia
http://linuxfr.org/news/sortie-de-mageia-5-la-magie-continue
http://blog.mageia.org/fr/2015/06/20/mageia-5-brille-dans-firmament-libre/
https://www.mageia.org/fr/5/
http://www.mageialinux-online.org/wiki/creation-facile-d-une-cle-usb-bootable

Infographic of Debian

source : http://cfnarede.com.br/infographic-of-debian

Easygui

http://www.ferg.org/easygui/tutorial.html
https://media.readthedocs.org/pdf/easygui/master/easygui.pdf
https://www.youtube.com/results?search_query=easygui+python
http://easygui.sourceforge.net/

Apprendre à programmer avec python

http://apprendre-python.com/
http://inforef.be/swi/python.htm
http://python.developpez.com/cours/TutoSwinnen/
http://python.developpez.com/cours/apprendre-python3/
https://openclassrooms.com/courses/apprenez-a-programmer-en-python
http://www.apprendre-en-ligne.net/pj/index.html
http://fsincere.free.fr/isn/python/cours_python.php

Qu'est-ce que le logiciel libre ?

Définition du logiciel libre

Cette définition du logiciel libre a pour but de décrire clairement les conditions à remplir pour qu'un logiciel soit considéré comme libre. De temps à autre, nous la modifions afin de la clarifier ou pour résoudre des questions portant sur des points difficiles. Si vous souhaitez avoir un aperçu des changements que nous y avons apportés, veuillez consulter la section Historique ci-dessous.

« Logiciel libre » [free software] désigne des logiciels qui respectent la liberté des utilisateurs. En gros, cela veut dire que les utilisateurs ont la liberté d'exécuter, copier, distribuer, étudier, modifier et améliorer ces logiciels. Ainsi, « logiciel libre » fait référence à la liberté, pas au prix¹ (pour comprendre ce concept, vous devez penser à « liberté d'expression », pas à « entrée libre »). Pour bien montrer qu'il ne s'agit pas de gratuité, nous utilisons quelquefois en anglais l'expression libre software.

Nous faisons campagne pour ces libertés parce que chacun les mérite. Avec ces libertés, les utilisateurs (à la fois individuellement et collectivement) contrôlent le programme et ce qu'il fait pour eux. Quand les utilisateurs ne contrôlent pas le programme, nous qualifions ce dernier de « non libre », ou « privateur ».² Ce programme non libre contrôle les utilisateurs et son développeur le contrôle. Le programme devient donc l'instrument d'un pouvoir injuste.

Un programme est un logiciel libre si vous, en tant qu'utilisateur de ce programme, avez les quatre libertés essentielles :

• la liberté d'exécuter le programme comme vous voulez, pour n'importe quel usage (liberté 0) ;
• la liberté d'étudier le fonctionnement du programme, et de le modifier pour qu'il effectue vos tâches informatiques comme vous le souhaitez (liberté 1) ; l'accès au code source est une condition nécessaire ;
• la liberté de redistribuer des copies, donc d'aider votre voisin (liberté 2) ;
• la liberté de distribuer aux autres des copies de vos versions modifiées (liberté 3) ; en faisant cela, vous donnez à toute la communauté une possibilité de profiter de vos changements ; l'accès au code source est une condition nécessaire.

Un programme est un logiciel libre s'il donne toutes ces libertés aux utilisateurs de manière adéquate. Dans le cas contraire, il est non libre. Bien que nous puissions faire une distinction entre différents schémas de distribution non libres, en quantifiant ce qui leur manque pour être libres, nous les considérons tous comme équivalents dans leur manque d'éthique.

Dans chacun des scénarios, ces libertés doivent s'appliquer quel que soit le code que nous envisageons d'utiliser ou de pousser d'autres personnes à utiliser. Prenez par exemple un programme A qui lance automatiquement un programme B afin de gérer certaines situations. Si nous souhaitons distribuer A tel quel, cela implique que les utilisateurs auront besoin de B ; il nous appartient donc de juger si A et B sont tous deux libres. Cependant, si nous projetons de modifier A de telle sorte qu'il n'utilise pas B, alors seul A doit être libre ; nous pouvons ignorer B.

La suite de cette page s'attache à clarifier certains détails sur ce qui fait que des libertés particulières sont adéquates ou non.

Avoir la liberté de distribution (libertés 2 et 3) signifie que vous êtes libre de redistribuer des copies, avec ou sans modification, gratuitement ou non, à tout le monde, partout. Être libre de faire tout cela signifie (entre autres) que vous n'avez pas à demander ni à payer pour en avoir la permission.

Vous devez aussi avoir la liberté de faire des modifications et de les utiliser à titre privé dans votre travail ou vos loisirs, sans en mentionner l'existence. Si vous publiez vos modifications, vous n'êtes pas obligé de prévenir quelqu'un en particulier ou de le faire d'une manière particulière.

La liberté d'utiliser un programme est la liberté pour n'importe qui ou n'importe quelle organisation de l'utiliser sur n'importe quel système informatique, pour n'importe quelle tâche et sans être obligé de communiquer à ce sujet avec le développeur ou toute autre entité particulière. Dans cette liberté, ce qui compte est ce que veut faire l'utilisateur, pas le développeur ; en tant qu'utilisateur, vous êtes libre d'exécuter un programme comme bon vous semble et, si vous le redistribuez à quelqu'un d'autre, cette personne est libre de l'exécuter comme bon lui semble, mais vous n'êtes pas autorisé à lui imposer vos conditions.

Que vous soyez libre d'exécuter le programme comme vous le souhaitez signifie que personne ne vous interdit ou ne vous empêche de le faire. Cela n'a rien à voir avec telle ou telle fonctionnalité que possède, ou non, le programme, ou avec le fait qu'il soit utile, ou non, pour ce que vous voulez faire.

La liberté de redistribuer des copies doit inclure les formes binaires ou exécutables du programme, tout comme le code source, que ce soit pour les versions modifiées ou non modifiées du programme (diffuser des programmes sous une forme exécutable est nécessaire pour installer commodément les systèmes d'exploitation libres). Il y a une exception s'il n'existe aucun moyen de produire de version binaire ou exécutable pour un programme déterminé (puisque certains langages ne le permettent pas), mais vous devez avoir la liberté de distribuer des versions de ce type si vous trouvez ou si vous concevez un moyen d'en produire.

Afin que les libertés 1 et 3 (la liberté de faire des modifications et la liberté de publier les versions modifiées) aient un sens, vous devez avoir accès au code source. Ainsi, l'accès au code source est une condition nécessaire pour qu'un logiciel soit libre. Du code source rendu illisible [obfuscated] n'est pas du vrai code source et ne compte pas comme code source.

La liberté 1 inclut la liberté d'utiliser votre version modifiée à la place de l'original. Si le programme est livré dans un produit conçu pour exécuter les versions modifiées de quelqu'un d'autre, mais pour refuser d'exécuter les vôtres – une pratique connue sous le nom de « tivoïsation », de « verrouillage » ou (dans la terminologie pernicieuse de ses partisans) de secure boot³ – la liberté 1 devient un simulacre vide de sens plutôt qu'une liberté concrète. Ces binaires ne sont pas libres, même si le code source à partir duquel ils ont été compilés l'est.

Un moyen important de modifier un programme est de lui incorporer des modules ou des sous-programmes libres disponibles. Si la licence du programme indique que vous ne pouvez pas lui incorporer un module existant régi par une licence appropriée, par exemple si elle impose que vous soyez titulaire du copyright⁴ sur tout code que vous ajoutez, alors la licence est trop restrictive pour être qualifiée de libre.

La liberté 3 inclut la liberté de distribuer vos versions modifiées en tant que logiciel libre. Une licence libre peut également permettre de les distribuer sous d'autres formes ; en d'autres termes, elle n'a pas à être un copyleft⁵. Cependant, une licence qui impose que les versions modifiées soient non libres ne peut pas être qualifiée de licence libre.

Pour que ces libertés soient effectives, elles doivent être permanentes et irrévocables tant que vous n'avez rien fait de mal ; si le développeur du logiciel a le droit de révoquer la licence ou de lui ajouter rétroactivement des clauses restrictives, sans que vous ayez fait quoi que ce soit de mal pour le justifier, le logiciel n'est pas libre.

Cependant, certains types de règles sur la manière de distribuer le logiciel libre sont acceptables tant que ces règles ne rentrent pas en conflit avec les libertés fondamentales. Par exemple, le copyleft (pour résumer très simplement) est une règle qui établit que, lorsque vous redistribuez le programme, vous ne pouvez pas ajouter de restriction qui nie les libertés fondamentales des autres. Cette règle n'entre pas en conflit avec les libertés fondamentales ; en fait, elle les protège.

Au projet GNU, nous utilisons le copyleft pour protéger juridiquement les quatre libertés de manière que chacun en bénéficie. Nous croyons qu'il y a de bonnes raisons de préférer le copyleft. Cependant, les logiciels libres non copyleftés sont éthiques également (consultez les catégories de logiciels libres pour une discussion des relations entre « logiciel libre », « logiciel copylefté », et encore d'autres catégories de logiciel).

« Logiciel libre » ne signifie pas « non commercial ». Un logiciel libre doit permettre l'usage commercial, le développement commercial et la distribution commerciale. Le développement commercial de logiciel libre n'est plus l'exception ; de tels logiciels libres commerciaux sont très importants. Vous pouvez avoir payé pour obtenir une copie d'un logiciel libre ou vous pouvez l'avoir obtenu gratuitement. Mais quelle que soit la manière dont vous vous l'êtes procuré, vous avez toujours la liberté de copier et de modifier le logiciel et même d'en vendre des copies.

Qu'un changement constitue une amélioration ou non est subjectif. Si votre droit de faire des modifications se limite, en substance, aux changements que quelqu'un d'autre considère comme une amélioration, ce n'est pas un programme libre.

Toutefois, des règles qui régissent la manière dont une version peut être modifiée sont acceptables si elles ne limitent pas de manière substantielle votre liberté de produire des versions modifiées, ou votre liberté de créer et d'utiliser des versions modifiées pour votre usage privé. Ainsi, il est acceptable que la licence vous impose de changer le nom de la version modifiée, d'enlever un logo, ou de marquer vos modifications comme étant de votre fait. Aussi longtemps qu'en pratique le poids de ces contraintes ne vous empêche pas de distribuer vos changements, elles sont acceptables. Vous avez déjà fait d'autres changements dans le programme, alors vous n'aurez pas de mal à en faire quelques-uns de plus.

Une règle spécifiant que « si vous rendez votre version disponible comme ceci, vous devez aussi la rendre disponible comme cela » peut aussi être acceptable, sous les mêmes conditions. Serait par exemple acceptable une règle stipulant que, si vous avez distribué une version modifiée et qu'un ancien développeur en demande une copie, vous devez la lui envoyer (notez qu'une telle règle vous laisse néanmoins le choix de distribuer votre version ou non). Les règles qui exigent la fourniture du code source aux utilisateurs pour les versions que vous mettez à la disposition du public sont également acceptables.

Un problème particulier apparaît lorsqu'une licence exige qu'on change le nom sous lequel le programme sera invoqué par d'autres programmes. C'est effectivement gênant pour publier une version modifiée de manière qu'elle puisse remplacer l'original quand il est invoqué par ces autres programmes. Ce type d'exigence n'est acceptable que s'il existe une possibilité de spécifier le nom du programme original comme alias de la version modifiée.

Parfois les règles du contrôle des exportations, ou bien des sanctions économiques, peuvent restreindre votre liberté de distribuer des copies de programmes à l'étranger. Les développeurs de logiciels n'ont pas le pouvoir d'éliminer ou de passer outre ces restrictions, mais ce qu'ils peuvent et doivent faire, c'est refuser de les imposer comme conditions à l'utilisation du programme. De cette manière, les restrictions n'affecteront pas les activités et les personnes se trouvant hors de la juridiction des gouvernements concernés. Ainsi, les licences de logiciel libre ne doivent pas imposer d'obéir à un règlement sur l'exportation comme préalable à l'une des libertés essentielles, quelle qu'elle soit, dans la mesure où ce règlement a une incidence pratique.

Il est acceptable de mentionner simplement l'existence du règlement sur l'exportation sans en faire une clause de la licence elle-même, car cela n'impose pas de restriction aux utilisateurs. Si de fait une règle d'exportation est sans incidence sur le logiciel libre, l'intégrer à une clause n'est pas un véritable problème ; toutefois, c'est un problème potentiel car une future modification du droit de l'exportation pourrait faire que cette exigence ait des conséquences pratiques et donc rende le logiciel non libre.

Une licence libre ne peut pas exiger qu'on se conforme à la licence d'un programme non libre. Ainsi par exemple, si une licence exige le respect des licences de « tous les programmes que vous utilisez », et que l'utilisateur exécute des programmes non libres, cela l'obligerait à respecter les licences de ces programmes non libres, et rendrait par conséquent la licence non libre.

Il est acceptable qu'une licence libre précise la juridiction dont le droit s'applique, la cour compétente pour régler les litiges, ou bien les deux.

La plupart des licences de logiciel libre sont basées sur le copyright, or les types d'exigences que le copyright peut imposer ont des limites. Si une licence basée sur le copyright respecte la liberté de la manière décrite plus haut, il est peu probable qu'elle pose un problème d'un genre totalement imprévu (bien que cela arrive parfois). Cependant, certaines licences de logiciel libre sont basées sur le droit du contrat, et les contrats peuvent imposer un éventail bien plus large de restrictions. Cela signifie qu'il y a de nombreuses possibilités pour qu'une licence de ce type puisse restreindre de manière inacceptable la liberté des utilisateurs et ainsi devenir non libre.

Nous ne pouvons pas passer en revue tout ce qui pourrait se passer. Si une licence basée sur un contrat restreint l'utilisateur d'une manière inhabituelle à laquelle les licences basées sur le copyright ne peuvent pas se conformer, et qui n'est pas mentionnée ici comme légitime, nous devrons y réfléchir et nous conclurons probablement qu'elle n'est pas libre.

Quand vous parlez de logiciel libre, il est préférable de ne pas utiliser de termes comme « donner » ou « gratuit », car ils laissent supposer que la finalité du logiciel libre est le prix et non la liberté. Certains termes répandus comme « piratage » comportent des idées auxquelles nous espérons que vous n'adhérerez pas. Lisez « Termes prêtant à confusion, que vous devriez éviter », un essai sur l'utilisation de ces termes. Nous avons aussi une liste de traductions correctes de free software dans de nombreuses langues.

Enfin, notez que des critères comme ceux qui sont développés dans la présente définition du logiciel libre demandent une réflexion sérieuse quant à leur interprétation. Pour décider si une licence de logiciel particulière peut être qualifiée de libre, nous la jugeons sur ces critères pour déterminer si elle convient à leur esprit tout comme à leur formulation précise. Si une licence inclut des restrictions inacceptables, nous la rejetons même si nous n'avons pas anticipé le problème dans ces critères. Quelquefois les exigences d'une licence soulèvent un problème qui nécessite des réflexions intenses, y compris des discussions avec un juriste, avant que nous puissions décider si l'exigence est acceptable. Quand nous arrivons à une conclusion concernant un nouveau problème, il est fréquent que nous mettions à jour ces critères pour qu'on sache plus facilement pourquoi telle licence s'y conforme, ou non.

Si vous voulez savoir si une licence particulière peut être qualifiée de « libre », reportez-vous à notre liste de licences. Si la licence qui vous intéresse ne fait pas partie de la liste, vous pouvez nous demander des précisions en envoyant un courriel à <licensing@gnu.org>.

Si vous envisagez d'écrire une nouvelle licence, veuillez auparavant contacter la Free Software Foundation, en écrivant à l'adresse ci-dessus. La prolifération de licences de logiciel libre différentes les unes des autres implique un surcroît de travail pour les utilisateurs voulant comprendre ces licences ; nous pouvons vous aider à trouver une licence de logiciel libre existante qui réponde à vos besoins.

Si ce n'est pas possible, si vous avez vraiment besoin d'une nouvelle licence, avec notre aide vous pouvez faire en sorte que cette licence soit vraiment une licence de logiciel libre, et éviter divers problèmes pratiques.

Au-delà du logiciel

Les manuels des logiciels doivent être libres, pour les mêmes raisons que les logiciels doivent être libres, et parce que les manuels font en fait partie des logiciels.

Les mêmes arguments peuvent aussi s'appliquer à d'autres types d'œuvres à finalité pratique, c'est-à-dire des œuvres qui intègrent de la connaissance utile, tels que le matériel pédagogique et les ouvrages de référence. Wikipedia en est l'exemple le plus connu.

Tout type d'œuvre peut être libre : la définition du logiciel libre a été étendue à la définition des œuvres culturelles libres, applicable à tout type d'œuvre.

Open Source ?

Un autre groupe a commencé à utiliser le terme « open source » pour exprimer quelque chose de proche, mais pas identique au « logiciel libre ». Nous préférons le terme « logiciel libre ». En effet, une fois qu'on a compris que ce terme se rapporte à la liberté plutôt qu'au prix, il appelle la notion de liberté. Le mot « open » ne renvoie jamais à la liberté.

Comment j’ai appris à programmer

Programmer est, sans aucun doute, la chose la plus gratifiante intellectuellement que j’ai jamais réalisée. Programmer m’a appris que la vie se devait d’être amusante, remplie de créativité et vécue au maximum de son intensité. Programmer m’a appris que tout était possible  ; je peux faire ce qui me plait en utilisant seulement mon esprit.

Programmer m’a également enseigné qu’apprendre est drôle et ludique. Cela m’a montré que plus vous en savez, plus vous comprenez et êtes acteur du monde qui vous entoure. Programmer m’a confirmé qu’une vie en apprentissage continu est une meilleure vie à vivre. Programmer m’a révélé qui je suis au fond de moi, m’a donné une bonne estime de moi et m’a continuellement aidé à arriver à mes fins.

Je me sens extrêmement chanceux d’avoir eu la volonté et l’opportunité d’apprendre à programmer tôt dans la vie. Et si mes méthodes ne sont certainement pas les meilleures pour tout le monde, elles ont marché pour moi.

Je n’ai aucun regret.

Alors je me suis dit que j’allais partager mes méthodes avec vous, en espérant qu’un débutant lise cet article et en tire quelque chose.

Si vous n’avez pas le temps de le parcourir retenez avant tout ceci  : l’important est de s’amuser.

Installer GNU/Linux sur votre machine

Bien que plus jeune, j’ai découvert les rudiments informatiques sur des ordinateurs MS-DOS Windows grâce aux jeux vidéos, mon véritable apprentissage a commencé le jour où j’ai installé un système GNU/Linux sur mon ordinateur personnel.

Ce n’est pas fondamental d’utiliser ou non Windows (ou Mac OS X) sur votre machine, il y a ainsi beaucoup de programmeurs qui travaillent sous système d’exploitation propriétaires. Mais GNU/Linux est imbattable pour apprendre.

Contrairement aux idées reçues, les développeurs ne font pas que pisser du code. On tape quelque chose, ce qui déclenche autre chose. Il y aurait des entrées et des sorties. Cette vision est erronée.

La programmation est un mode de vie

Les programmeurs sont obsédés par la connaissance. Ils utilisent cette obsession pour alimenter leur soif d’apprendre, de découvrir et de créer. Voilà la vraie définition d’un programmeur.

Une principale raison d’utiliser Linux pour travailler au quotidien est qu’il vous aide à apprendre progressivement et pratiquement la programmation. Sur Windows, si vous voulez copier un fichier d’un dossier à un autre, vous faites du glisser-déposer à la souris. Sur Linux, vous pouvez aussi en faire de même désormais, mais vous pouvez également utiliser scp ou rsync. Parce qu’apprendre à utiliser la ligne de commande vous enseigne des techniques basiques de logique et améliore votre capacité à résoudre des problèmes.

La pratique régulière de l’OS GNU/Linux permet d’acquérir des compétences importante à commencer par l’autonomie. Contrairement à d’autres activités, la programmation ne demande ni de grands efforts de mémorisation, ni de répéter encore et encore les mêmes routines. Ce qu’il faut, c’est surtout énormément de motivation et de détermination. . Même les meilleurs programmeurs n’ont généralement aucune idée précise de ce qu’ils vont faire lorsqu’ils débutent un nouveau projet. Si une seule chose peut résumer mon activité, ce serait la recherche. Les programmeurs se doivent de savoir où trouver l’information, comment la digérer et s’en servir d’une manière utile. Cette compétence demande du temps et de la patience mais il est clair que GNU/Linux aide à cela.

Utiliser Linux vous poussera à rechercher activement des solutions aux problèmes que vous rencontrez. Si vous ne savez pas comment mettre en place un tunnel SSH, et bien vous allez l’apprendre tout simplement. Utiliser Linux vous amènera à découvrir de nouvelles choses auxquelles vous n’auriez jamais pensé en utilisant Mac ou Windows. Apprivoiser petit à petit GNU/Linux fera de vous un meilleur et plus pragmatique développeur. Vous apprendrez à travailler collaborativement pour résoudre un problème, à aller à la chasse aux erreurs, à mobiliser vos connaissances pour créer de nouvelles choses et rendre votre vie (et celle des autres) plus simple.

De plus, en tant que projet libre (tant le système d’exploitation que les logiciels disponibles), GNU/Linux offre un accès privilégié à la culture de la programmation. À coup sûr, vous allez  :

• Trouver un bogue dans une application que vous utilisez
• Chercher des réponses sur internet
• Trouver un système de tickets ou un forum sur le logiciel en question
• Soumettre un ticket concernant le bogue ou poster dans un forum un sujet sur le problème rencontré
• Interagir avec d’autres utilisateurs pour aidez à le résoudre

Tout cela n’a pas l’air très cool, mais patientez. Une fois ces points achevés, vous aurez fait connaissance avec la communauté hacker. Trouver des problèmes, en discuter avec d’autres personnes, résoudre ces problèmes ensemble et vous voici membre de cette communauté.

Si tout était parfait et qu’il n’y avait pas un seul problème à résoudre dans ce monde la vie serait morne. Mettre le nez dehors et corriger des choses, combattre le chaos, donne un sens à la vie. Alors profitez-en  !

Linux peut vous apprendre tout cela, et bien plus encore.

Avoir un désir intense

Pourquoi voulez-vous programmer  ? Quelles sont vos motivations  ? Si vous n’avez pas cette envie pressante d’apprendre à programmer, vous échouerez.

J’ai commencé à coder parce que j’avais une très grande envie de créer des jeux vidéo. Quand j’étais un enfant, les jeux vidéo étaient ma passion. Je rentrais le plus rapidement possible de l’école pour rester scotcher sur l’ordinateur à jouer à des vieux classiques. Mes épiques batailles de Starcraft contre mon frère font parties de mes meilleurs souvenirs.

Plus que tout, je voulais être capable de maîtriser ces jeux. Je voulais les dominer, je voulais rendre servile mon ordinateur esclave afin qu’il fasse ce que je désirais.

Ces vieilles motivations me semblent maintenant un peu idiotes mais je les ressentais alors de manière intense. J’en rêvais la nuit, j’y pensais durant le jour et en était obsédé alors que j’étais derrière mon ordinateur les après-midis.

Quand j’ai décidé d’apprendre à programmer, je savais que je pouvais le faire. Je savais que quoi qu’il arrive dans ma vie, j’apprendrais coûte que coûte à programmer, alors même qu’au début je n’avais aucune idée de comment y arriver et ne connaissais personne dans ce domaine.

Mais j’ai trouvé un moyen. J’ai lu sur le Web des dizaines et des dizaines de pages de documentation. J’ai dépensé sans compter des centaines d’heures à fouiller au hasard les forums à la recherche de bribes d’information. J’étais tellement motivé et entier dans mon désir que cela me semblait facile et m’a aidé à devenir un programmeur à moitié convenable.

Faire de petits programmes en ligne de commande

Aujourd’hui, il semblerait que la majorité apprenne la programmation en plongeant la tête la première dans le développement Web. Même si ça peut marcher pour certaines personnes, ça me semble vraiment fou. Non seulement les technologies Web sont vastes, complexes et vite démodées (construire un site Web moderne requiert des tonnes de compétences différentes qui nécessitent plusieurs années de maturation), mais elles sont souvent frustrantes et décourageantes pour les nouveaux développeurs.

Je suis peut-être de la vieille école (j’ai seulement 23 ans :x), mais il n’y a rien de plus satisfaisant et formateur que d’écrire des tonnes de programmes simples en ligne de commande. J’écrivais des tonnes de choses  :

• Un script simple qui prenait en entrée des noms de fichiers pour les stocker dans des dossiers hiérarchisés et organisés en fonction du type de fichier
• Un bot IRC qui enregistrait toute l’activité d’un channel dans un fichier texte.
• Un programme simple qui télechargeait toutes les images d’une page Web donnée.
• Un outil permettant de convertir des nombres en base dix vers n’importe quelle autre base en CLI
• Un script compilant et mémorisant d’un coup toutes mes personnalisation graphiques  : fonds d’écran, thèmes, etc.
• Un programme basique qui téléverse automatiquement des captures d’écran sur un hébergeur d’images et en copie automatiquement l’adresse dans mon presse-papier.
• Et un million d’autres choses encore.

J’ai tiré grand bénéfice de ces petits exercices. Chacun d’eux était suffisamment simple pour être écrit en quelques heures (pas plus), et ils m’ont tous appris quelque chose  : un nouveau language, nouvelle bibliothèque ou stratégie. J’ai sans aucun doute gagné une grande partie de mes compétences informatiques en construisant là ces applications.

Mais cela joue également au niveau de la confiance. Chaque application créée aura été une petite satisfaction personnelle dont j’étais fier. J’y revenais du reste en les tenant à jour mais surtout en tentant de les modifier sans cesse par du nouveau code et de nouvelles stratégies. Cela m’a appris les bases de la programmation par itération (améliorer au fil du temps) tout en contribuant effectivement à la communauté du logiciel libre.

Si vous êtes un nouveau programmeur, il n’y a rien de mieux et de plus amusant que d’écrire ces petits utilitaires en ligne de commande. Vous ne me croyez pas  ? Essayez, et dites moi si vous ne vous retrouvez pas accro dès la première ligne  !

Écrire, Écrire, Écrire

L’écriture est controversée. Lorsque j’ai commencé à programmer, les nerds avaient une réputation d’être inaptes à tout sauf aux ordinateurs. Pendant une période, j’ai supposé que comme étant bon avec les ordinateurs, j’étais naturellement mauvais pour tout le reste  : même pour écrire.

C’était idiot.

J’en suis venu à réaliser avec le temps que les programmeurs sont, au contraire, d’excellents auteurs. La capacité à penser logiquement et à résoudre les problèmes est un avantage indéniable pour écrire, alors qu’il est parfois si difficile de coucher ses idées sur le papier. Et réciproquement l’exercice d’écriture m’a aidé à devenir un meilleur développeur. En outre nous savons qu’il est important de bien documenter son code.

Posséder un blog par exemple est une excellente manière de pratiquer l’écriture, pour garder une trace de ce que vous apprenez, et aide à s’assurer d’un progrès constant en particulier sur les sujets techniques.

Si vous écrivez une très très utile application en ligne de commande pour commander des pizzas chez Dominos, il vous sera alors difficile d’en parler sans aller dans le détail pour décrire la technologie que vous utilisez, comment l’API de Dominos fonctionne, etc. En prenant le temps d’écrire en structurant votre pensée, en relatant votre expérience, vous en apprendrez forcément davantage.

L’écriture peut être incroyablement utile lorsqu’elle est utilisée pour décrire des choses techniques, puisqu’elle simplifie et clarifie la cause du problème, vous forçant à réfléchir à ce problème de la manière la plus simple possible pour mieux la communiquer.

Un des mes plus grands regrets est de ne pas avoir conservé mes articles. Au fil des réécritures de mon site Web, d’erreurs de gestion de serveurs, j’ai petit à petit perdu la majeur partie de mes écrits. Le blog que vous lisez actuellement existe principalement suite à la décision que j’ai prise de remédier à cela. Ne faites pas la même erreur  !

Rejoindre une communauté en ligne

Internet est un vaste lieu. Programmer est un vaste sujet. Il est tout à fait possible de devenir un excellent programmeur tout seul dans son coin mais il est beaucoup plus facile de le faire avec l’aide d’autrui.

Lorsque j’ai commencé à programmer j’ai eu la chance de rencontrer grâce au Net d’autres programmeurs fascinants avec qui j’ai partagé des jours durant des idées via IRC. Ces personnes ainsi rencontrées comptent parmi les individus les plus brillants et passionnés que je n’ai jamais rencontrés dans ma vie. Nous sommes devenus amis et le sommes encore  !

Avoir des amis aussi motivés a décuplé ma propre motivation, et m’a aidé à tirer le meilleur de moi-même. Nous écrivions ensemble des articles pour partager les choses que nous avions apprises, nous critiquions nos codes respectifs, nous parlions des projets sur lesquels nous travaillions et sur la meilleure manière de les mener à bien.

Connaître un groupe qui partage la même passion et la même envie que vous est inestimable.

Amusez-vous

Programmer est amusant. Programmer est vraiment, vraiment très amusant. Le simple fait d’en parler me met en joie  ! Il est difficile de cacher mon excitation.

Le plus important quand on apprend à programmer c’est de toujours S’AMUSER  ! Peu importe que vous commenciez tout juste à programmer ou que vous soyez un programmeur aguerri et confirmé  : vous ne devez jamais perdre du vue cette dimension fondamentale de l’informatique.

Supposons que vous veniez de commencer à apprendre le Python (à propos, Dive Into Python reste l’un des meilleurs livres sur le sujet), ne démarrez pas par un projet ennuyant. Écrivez quelque chose de nouveau  ! Un truc qui vous semble fun et quelque part utile. Amusez-vous avec, et lancez-vous des defis.

Si votre motivation première pour travailler sur un projet est de le terminer alors vous faites fausse route. Pour devenir un bon programmeur il faut bidouiller des trucs que VOUS trouvez sympa. Le monde est rempli de logiciels tristes alors qu’on a besoin de logiciels GENIAUX. Et la seule façon de faire un logiciel génial c’est de s’éclater en le créant  !

Je pourrais déblatérer pendant des heures ainsi. Mais à la place et pour conclure je veux VOUS mettre au défi (oui vous  !). Pensez à quelquechose que vous adoreriez faire. Un site de partage  ? un éditeur vidéo  ? Peu importe ce qui vous exalte et vous transporte. Vous avez saisi  ?

OK, maintenant allez-y fabriquez-le  !

source:

How I Learned to Program

Randall Degges – 4 février 2012 – Blog perso
(Traduction Framalang/Twitter  : Calystod, Twix, kinou, HgO, monsieurab, Spartition, ametaireau, Grom, alaindalche, Evpok, Grom, Fred)

GNOME 3.18

La version 3.18 de GNOME, l’environnement de bureau libre très populaire sur les systèmes GNU/Linux, est désormais disponible en version stable. Dans cette version, GNOME améliore l'expérience utilisateur générale. L’environnement embarque la fonctionnalité « luminosité automatique » laquelle, lorsqu’elle est activée, va s’occuper de gérer la luminosité de votre ordinateur portant en l’adaptant à la luminosité ambiante si votre ordinateur dispose d’un capteur de lumière. Cette fonctionnalité, qui fait partie des paramètres d’Energie de votre ordinateur, a été pensée non seulement pour vous permettre de mieux voir les images ou le texte sur votre écran mais également d’économiser l’énergie de votre appareil.

GNOME 3.18 améliore également l'expérience avec un écran tactile, en particulier lors de la sélection et de la modification d’un texte. Vous pourrez sélectionner, couper, copier et coller le texte beaucoup plus facilement.

sources :

http://linuxfr.org/news/gnome-3-18-goteborg-est-disponible
http://www.developpez.com/actu/90264/GNOME-3-18-est-officiellement-disponible-et-permet-maintenant-d-acceder-a-Google-Drive-directement-depuis-l-application-Fichiers/

Firefox 41 et 42

source :
http://linuxfr.org/news/parution-de-firefox-41
http://www.developpez.com/actu/90253/Firefox-41-disponible-avec-la-messagerie-instantanee-pour-Firefox-Hello-et-la-reduction-de-l-utilisation-de-la-memoire-par-Adblock-Plus/
http://www.developpez.com/actu/90375/Firefox-42-Beta-arrive-avec-une-promesse-d-une-navigation-privee-encore-plus-privee-grace-a-Tracking-Protection/

Parution de python 3.5

Une nouvelle version du langage Python (et par conséquent de son implémentation principale CPython) sort aujourd'hui. Estampillée 3.5, cette version fait logiquement suite à la version 3.4 parue il y a un an et demi1. Tandis que cette dernière apportait principalement des ajouts dans la bibliothèque standard (asyncio, enum, ensurepip, pathlib, etc.), les nouveautés les plus visibles de la version 3.5 concernent des changements syntaxiques avec deux nouveaux mot-clés, un nouvel opérateur binaire, la généralisation de l'unpacking et la standardisation des annotations de fonctions.

Cette version 3.5 sera certainement perçue par les Pythonistes comme celle qui aura introduit le plus de changements au langage depuis Python 3.0. En effet, nous allons découvrir ensemble qu'avec cette nouvelle version, Python achève d'inclure dans le langage le support d'un paradigme de programmation moderne, revenu au goût du jour avec l'éclosion de Node.js : la programmation asynchrone.

sources :

https://zestedesavoir.com/articles/264/sortie-de-python-35/

http://sametmax.com/jouons-un-peu-avec-python-3-5/

https://linuxfr.org/news/parution-de-python-3-5

Finishing a Game

As I work towards completing my own game, I’ve been thinking a lot about finishing projects in general. I’ve noticed that there are a lot of talented developers out there that have trouble finishing games. Truthfully, I’ve left a long trail of unfinished games in my wake… I think everyone has. Not every project is going to pan out, for whatever reason. But if you find yourself consistently backing out of game projects that have a lot of potential, it could be worth taking a step back and examining why this happens.

We’ve all had that feeling about at least one game, comic book, movie, etc., that comes out: “Gee, I could do better than this! This is overrated.” But it’s important to take a step back and realize that, hey, they put in the time to finish a project and I haven’t. That’s at least one thing they might be better than me at, and it’s probably why they have the recognition I don’t! If you treat finishing like a skill, rather than simply a step in the process, you can acknowledge not only that it’s something you can get better at, but also what habits and thought processes get in your way.

I don’t believe that there’s a right way to make games. It’s a creative endeavor, so there are no hard and fast rules that can’t be broken at some point. But as a game developer who has discussed this problem with other game developers, I feel like there are some mental traps that we all fall into at some point, especially when we’re starting out. Being aware of these traps is a great first step towards finishing something. (Between you and me, codifying these ideas is partly my way of staying on top of them, too!)

So without further ado, here is a list of 15 tips for finishing a game:

1. CHOOSE AN IDEA WITH POTENTIAL

I’ve found that there are three types of games that pique my interest: games I want to make, games I want to have made, and games I’m good at making.

Games I want to make are games where the process itself seems really fun. Maybe the mechanic seems really fun to experiment with, or maybe there’s a character I really want to animate.

Games I want to have made are games where I’m more interested in the result than in getting there. Maybe it’s a “no-limits” concept (“OMG, GTA meets Final Fantasy meets Starcraft meets…”) or just a neat idea that’s not necessarily any fun to implement.

Games I’m good at making are games that are suited to my personality and which I have experience in making. Perhaps there’s a certain genre that you naturally gravitate towards and which you understand the rhythm and flow of very well.

In my opinion, the ideas with the most potential (to be finished, at least) fall into all three categories and also satisfy the requirement “I have the time and resources to actually make this”.

2. ACTUALLY START THE DAMN GAME

Writing your idea down is not starting the damn game. Writing a design document is not starting the damn game. Assembling a team is not starting the damn game. Even doing graphics or music is not starting the damn game. It’s easy to confuse “preparing to start the damn game” with “starting the damn game”. Just remember: a damn game can be played, and if you have not created something that can be played, it’s not a damn game!

So dammit, even creating a game engine is not necessarily starting the damn game. Which brings me to the next tip…

3. DON’T ROLL YOUR OWN TECH IF YOU DON’T HAVE TO

There are pros and cons to writing your own engine. But ask yourself, do you really have to? Is what you want to do impossible to do with what’s already out there or would you be reinventing the wheel? Of course, if you write your own engine you can make it just perfect the way you like it. But be honest, how often do you ever get past the engine to the game itself? Do you find yourself making game engines more often than you do games?

I made the original version of Spelunky in Game Maker, and it’s that “finished” game that eventually gave me the opportunity to work on an Xbox 360 version. So don’t ever feel that game-making software or other simplified tools are somehow illegitimate. The important thing is the game.

Link: The Independent Gaming Forums Technical Forums

4. PROTOTYPE

This goes with #2: prototype first with whatever you have available. Sometimes you find out right off the bat that it’s a bad idea. Sometimes you stumble upon an even BETTER idea. Either way, I usually find it difficult to figure out what I want to commit to until I actually start making something. So make something!

5. MAKE SURE THE CORE MECHANICS ARE FUN

Find core mechanics that are just fun to play around with. It should be fun to execute the most basic interactions, because that’s what players will be doing the most when they play your game. Ultimately, you want this core to drive your development. This will make it a lot easier for you later on when you have to cut out parts of the game (#13) - you’ll always have this core to fall back to.

It’s possible, while prototyping, that you discover a mechanic that’s MORE fun than what you originally thought the core mechanic was - consider making that the new core mechanic!

6. CHOOSE GOOD PARTNERS (OR WORK ALONE AS LONG AS YOU CAN)

Finding a good game-making partner is like dating in a lot of ways. You may think that all that matters is skill: “Oh cool, I’m a programmer, and this guy’s an artist… let’s DO THIS!” But no, there are other things to consider, like personality, experience, timing, and mutual interest. Like a romantic relationship, you don’t want to be in a position where either you or the other person is far less dedicated. Test each other out a bit with some smaller projects, because it can really be devastating when a key person drops out after months or years of development.

Another great thing about having finished projects is that your partners will know what you’re capable of and will feel more comfortable working with you. It’s hard to convince anyone experienced to work with you on an idea alone, considering how few ideas actually see the light of day (and how hard it is to see the value in some ideas until they’ve been executed). Good partners will want to see your finished games. So finish them!

Alternatively, find free graphics and music to use online, at least as placeholders (at The Independent Gaming Source we had a competitionin which a lot of free art and music was created). Use ASCII if you have to. As an artist, I know I’d much rather contribute to a project that is already done but just missing art. And if you need a coder… consider learning to code yourself (if I can do it, you can, too!) or picking up some game-making software (see #3).

7. GRIND IS NORMAL - FACTOR IT INTO YOUR PLAN

A lot of game-making is tedious and downright unfun. It’s not play, it’s work (and this is why you should choke out ANYONE when they joke about you “playing games all day”). At some point you’ll suddenly realize that there’s all this stuff you never thought about when you were planning your project and prototyping - stuff like menus, screen transitions, saving and loading, etc. “Shoot! I was imagining this amazing world I was going to create, or this fun mechanic I was going to experiment with… I didn’t think I’d be spending weeks making functional menus that don’t look like crap!" Or, you know, there’s stuff that’s fun in small doses, like animating characters, that becomes nightmarish when you realize you’ve set yourself up for 100 different characters.

Once you go through it a couple of times, you’ll realize how important it is to scale your project so that you don’t spend too much time in this inevitable quagmire ("too much time” being however long it takes before you quit). You’ll also realize that a lot of this boring stuff is what makes the game feel complete! A nice title screen, for example, does wonders to make a game feel legitimate.

8. USE AWARDS, COMPETITIONS, AND OTHER EVENTS AS REAL DEADLINES

When Alec and I were working on Aquaria, the Independent Games Festival submission deadline forced us to make hard decisions about the direction we were taking and it also forced us to look at our schedule more realistically. Had we not had that deadline, I’m not entirely certain we would have finished! Competitions are great to participate in because the deadlines are very real and because the rewards (recognition, awards, possibly money) are very real. Also, they can give you a way to connect with a community of like-minded people.

Links: Independent Games Festival, Ludum Dare

9. PUSH FORWARD

Feeling stuck? Push forward. Start working on the next level, the next enemy, the next whatever. Not only is it helpful for motivational purposes, but you want to get a sense for how your whole game will play out. Just like writing - you don’t want to go through it sentence by sentence, making sure every sentence is perfect before you move on. Get an outline down.

10. TAKE CARE OF YOUR MENTAL AND PHYSICAL HEALTH

It can be surprisingly hard to take care of yourself when you’re focused on finishing a game. But honestly, you’re only doing your game-making a disservice by not sleeping, exercising, or eating right. At best, you’re preventing yourself from working at your full potential and making it more likely that you’ll quit. Having some doubt about your project is perfectly natural, but getting depression or falling into illness is not. It’s amazing how much you can not want to work on your dream project when your mind and body feels like crap!

11. STOP MAKING EXCUSES FOR STARTING OVER

“My code’s a mess. And I’ve learned so much already. If I started over I could do it a lot better and faster, and then the rest of the game will go a lot faster, too!”

STOP. NO. This is true at some point during every game’s development. Your code will always be a mess. You will have learned a lot. It will never be perfect. And if you start all over, you’ll find yourself in the exact same situation when you get to this point again. It’s a terrible trap to think like this.

Here’s a joke: a man spends his entire life working on a game engine so perfect that all he has to do is press one button and the perfect game will come out of it. Actually, it’s not much of a joke, because the punchline is that he never finishes it! No such engine or game exists.

If bad organization is really slowing you down, go back and do some surgery on it so that you feel better. If it works but it’s a bit hacky, then be brave and press on!

12. SAVE IT FOR THE NEXT GAME

So partway through development you have this great new idea that’s going to blow everyone’s mind, but you’ll have to redo your whole game to implement it? Save it for the next game! Right? This won’t be the last game you ever make, hopefully. Save it for the next one… but finish this one first!

13. CUT. IT. OUT.

Oh shit, you’re way behind schedule. You have all these ideas but they’ll colonize Mars before you have a chance to implement half of them. Oh woe is you… BUT WAIT!

Well, that’s great, actually! Because now you’re forced to decide what is really important to your game, and what you could cut. The fact is, if we all had unlimited resources and unlimited time, we’d all make the same crappy, meandering everything game and there’d be no reason to play at all. It’s our limited resources and time that forces us to make tight games that feel like they have a purpose.

If you’ve been building upon some core concepts that are provably fun, just keep cutting until you get to the very edge of that core. Everything else is probably just fluff you could do without. Or worse, it’s fluff that’s preventing people from seeing the best parts of your game.

14. IF YOU DO QUIT, SCALE DOWN, NOT UP

Okay, sometimes it is time to call it quits. Maybe there’s just no way you’ll ever finish, and what you have is too big a mess to cut anything out. Maybe the rest of your team has quit already. My hope in writing this list is to help people avoid this possibility, but hey, maybe you’re just coming off of such a project. And sometimes… shit just happens.

If there’s no salvaging it, at least make sure that you scale down your next project. It’s easy to set your sights higher and higher, even as your projects become less and less finished. “My SKILLS are improving! I’m learning from my failure,” is a common excuse. But I think this is why it’s important to treat finishing as a skill, too.

So go back down, down, down, down to a point where you may even find it somewhat beneath you. For example, instead of jumping from your 4x space sim to your 4x space sim IN 3D, try making a great game that focuses on one small element of space sims. And if you can’t finish that, try something more like Asteroids. It’s very possible that it’ll still end up being a bigger struggle than you thought (and/or more fun to make than you thought)!

15. THE LAST 10 PERCENT

They say the last 10 percent is really 90 percent, and there is truth to this. It’s the details that end up taking a long time. Sure, maybe you coded a competent combat system in a week… but making it great and making it complex (and bug-free)… these things can take months. The honest truth is that you’ll probably do a “final lap” sprint many times before you get to the real final lap.

If this sounds discouraging, it shouldn’t. While the last 10 percent is harrowing, I’ve also found that is an enormously satisfying time in the development. Because more often than not, stuff really does seem to “just come together” at the end if you’ve been spending your time properly, and turning a jumble of mish-mashed ideas and content into sweet gaming manna is a magical feeling.

It’s all about the details.

AND FINALLY… RELEASE!

Holy crap, you released a game! Congratulations, you just leveled up, big time. Benefits include: increased confidence, a reputation for being able to complete projects, and an understanding of the entire process of game creation! The best part, though, is that you have a nice little game that I can play and enjoy! And I do like playing games, almost as much as I enjoy making them.

No more standing on the sidelines, friend: YOU ARE A GAME DEVELOPER.

source : http://makegames.tumblr.com/post/1136623767/finishing-a-game

Making it in Indie Games: Starter Guide

Every now and then someone will ask me for advice on making it as a professional indie game developer. First, it’s a huge honor to be asked that. So I want to say “Thank you!” Second… damn, if I really want to help out it’s a serious endeavor. Of course, I could always say “Give it your best! Work hard! Be true to yourself!” and it wouldn’t be a terrible reply… just not a terribly useful one, either.

So here it is. Here is what I’m going to link when that rare situation arises again, because it’s too much work to write it up more than once! This is advice that I feel may actually be practical to someone who is just starting out as an indie game developer. Hope it helps!

INDIEPENDENT

So yeah, what does being “indie” even mean? Is “indie” short for independent? Is this game “indie”? Is “indie” a genre? IT’S CONFUSING - WHY DO WE NEED THE WORD “INDIE” AT ALL.

To answer the last question, I offer the following scenarios. Scenario 1: a person wants to make games, and perhaps start their own studio. They type “game development” into a search engine. The results, to say the least, are underwhelming. Dry. Academic. Programming-centric. (Try it yourself and see.)

Scenario 2: the person instead types “indie games” into a search engine. Instead of pages upon pages of conferences, bachelor’s degrees, and programming tools, that person is met instead with pages upon pages of games to play and vibrant communities filled with people who are doing exactly what he or she wants to be doing. Some of them went to school, but many did not. A wealth of different ideas and tools are used. There are even documentaries about making games! It’s not just something where you get a degree and wait in line for a job. You can start making games RIGHT NOW.

The word “indie” is more than just a way to describe a type of developmental process… like any label, it actually provides an avenue for people to explore that process and then flourish within it. It has a real purpose. It serves real lessons on game creation and entrepreneurialism. It offers real motivation!

Of course, it can be irritating to see the term misused, or become a vehicle for pretentiousness and arrogance. Like any label, “indie” also breeds a certain amount dogmatism, croneyism, and other -isms. But the net result is really worth something. As someone who once gave up on professional game-making because I thought it meant a 9-to-5, I can tell you that it’s genuinely valuable.

As for what games are “truly” indie, we’ll never fully agree, and that’s probably for the best. But I can tell you the criteria I’ve devised for The Independent Gaming Source to determine whether a game is fit for coverage:

1. “Independent”, as in no publisher.

2. Small studio (roughly 20 members or less).

I choose that definition because it’s the most useful one. Someone who is looking to become an “indie” game developer is interested in what is possible under those constraints and how those types of studios operate. It excludes companies like Valve and Double Fine, which are certainly independent but too large to be “indie”. It also excludes “feels indie”-type games that are not self-published.

Under that definition you still run into gray areas, but hey, just because we don’t know when “red” turns into “purple” doesn’t mean the words aren’t useful. Just think about someone who wants to make a game with a small team and self-publish it… what should they type into Google for inspiration, advice, community, etc.? “Indie” is still as good a word as any, in my opinion.

So, should I go to school to learn how to make games?

The most important thing to know about video game development and schooling is that no one, whether it’s an indie studio or big company, cares about degrees. How could it, when some of its most prominent members are drop-outs or never-beens? John Carmack, Cliff Bleszinski, Jonathan Blow, and Team Meat are all prominent members of this club.

A degree is a piece of paper that says you can do something in theory - game developers want to know that you have enough passion to do real work, regardless of whether you’re being graded on it. And if you’re thinking of going indie, it won’t matter what other people think - you’ll simply need that passion to succeed or else you won’t. You’re the only one holding the door open in that case.

This isn’t to dissuade you from going to college, per se (I studied computer science in college, and while it was far from a perfect experience, I also gained a lot from both the curriculum and the friends I made there). The point is make something - games, mods, art, and music. If school helps you with that, great. If it doesn’t, then you need to rethink how you’re spending your most valuable resources: time and money (both of which can be exorbitant costs for schooling).

If I go to school, what should I study?

At a regular university, I would suggest majoring in computer science, even if you “just want to be a designer”. The design of games is very much tied to how they are made.

At an art school, illustration, concept art, and 3d modeling courses are probably the most useful for games. This Polycount thread has lots of advice for student artists trying to get into games.

At a game school, they will hopefully try to involve you in all aspects of game creation, from programming to design. I would stay far away from design-only schools or curricula - those are either scams or are better suited to academia than actual game-making. Also, it’s worth finding out whether or not the school owns what you make while you’re a student there.

See also: Jonathan Blow - How to Program Independent Games (read the comments as well as watch the video)

Okay, you say make something. How do I start?

My best advice for those starting out is not to get ahead of themselves. It’s easy to start worrying about tools, teams, platforms, deals, marketing, awards, and whatever else before you’ve even gotten a sprite moving around the screen. Those stars in your eyes will blind you. They’ll freeze you up. You need to be actively making games all the time.

If we were talking about painting, I’d tell you to pick up a painting kit and a sketchpad at your local art store ASAP and just have at it. You’d proceed to put absolute crap down on the pad and get frustrated. But it’d also be kind of fun - so you’d keep doing it. Along the way you’d read some theory and study other people’s work. With good taste and under a critical eye, you would keep doing that until the day you painted something good.

We’re talking about games, though. I recommend Game Maker andUnity as two all-purpose game-making suites. They both have a good balance of power versus ease-of-use; they’re both affordable or have free demos, and they both have a wealth of tutorials and plug-ins online. Both are used by professional developers (Unity in particular). Grab one of those and start running through the tutorials. When you run into trouble, ask for help. Give help back when you begin figuring things out. Get active in a game-making community.

But above all else, keep making games. It’s the only way to truly answer all of those questions in your head right now.

Also, watch this:

LASTLY, MY TOP 10 TIPS

1. Finish your games.

2. Don’t skimp on artwork. It’s easy to underestimate the importance of artwork to a game. And even if you don’t, it’s easy to underestimate the importance of having a unique style of artwork. The result is that there are many ugly or generic-looking (i.e. “clip-arty”) games failing to capture people’s attention.

If you have no artistic talent, go for style and coherency as many successful indie developers do. And even ugly is probably better than generic, all told. Remember: this is most people’s first impression of your game.

3. Don’t blame marketing (too much). In the indie community it’s become popular to write “how I failed” articles where the screenshots and comments tell the story of an ugly, boring game and yet the article itself tells the story of bad marketing decisions. Let’s face it, no one wants to admit that they lacked any amount of creativity, vision, or talent. It’s much easier to put the blame on release dates, trailers, websites, and whatever else.

This is the internet, though. A good game will make its way out there. Marketing will certainly help, and hype may get you quite far in the short term, but it’s not going to make or break you - it’s only a multiplier of however good your game is. Saying otherwise is only hurting your ability to self-criticize and therefore improve your craft. It’s also encouraging others to do the same.

4. Indie is not a genre or aesthetic. Make the game you want to make, not what you think an indie game “should be”. Recently, the very small and very independent team behind The Legend of Grimrockannounced that their very traditional first-person dungeon crawler sold over 600,000 copies. Don’t feel pressured to be dishonest about what you’d like to do - after all, what is independence if not freedom from such pressures?

5. Build yourself a working environment that’s healthy for you. Are you introverted and lose energy around other people or are you extroverted and gain energy that way? Or something in-between? What do you want your average working day to be like?

You’ll want to focus all of the energy available to you toward creating, and it’s amazing how much of it can be lost to seemingly mundane things. Figuring out your physical working space as well as your personal support system is a key part of the solution to this problem, and its vitally important to you as an independent creator.

6. Stay independent! To be sure, going indie can be daunting. There is always going to be the temptation of selling yourself or your ideas to someone else for a bit of a feeling of security. But honestly, once you go down that road it’s hard to come back - every moment you’re simply securing may not be a moment you’re progressing. I’m not recommending recklessness, but it’s important to stay committed and focused on the task at hand. Life is short.

Also, don’t give up your IP or in any way limit your opportunities long term. Keep exclusivity timed. When Aquaria released we weren’t aware of Steam. The Humble Bundle did not yet exist. iPad did not exist. Being on all of those platforms has been great for us. You need to keep your hands untied to take advantage of what future will bring.

7. Create your own luck. As an artist, I owe a lot to the people around me - my family, friends, peers, and idols. I accept that a lot of my success was simply the luck of being born with these people in my life.

But it’s important to realize that you create many of your own opportunities, too. For example, I met Alec (my friend and Aquaria co-creator) because he offered to help work on I’m O.K. I’m O.K. was a game started on the Pix Fu forums. The Pix Fu forums were part of my personal website and its members were friends of mine I’d made much earlier during my Blackeye Software/Klik n’ Play days.

You could trace a similar path from the XBLA version of Spelunky to the original PC version and the TIGSource forums.

The point is - put yourself out there. Make things (I can’t stress that enough!). You never know when serendipity will strike, but when it does it will likely be related to situations in your past when you chose to actively engage someone or some idea.

8. Avoid “business as war”. As a professional you’ll need to do business and make business-related decisions at least occasionally, and as a creative type you might not be that interested in that stuff. Hell, you might even be downright scared of it.

Well, I’m here to tell you that you don’t have to be Gordon Gekko to make it as an indie. And please, don’t try to be. In fact, avoid the Gordon Gekkos. Avoid the people who try to confuse you. Avoid the ones who try and nitpick. Avoid the ones who try and rush you.

If you have a great game, there is no distributor you will absolutely have to work with, platform you have to be on, or person you will have to team up with. Always be willing to walk away from a bad deal, especially if it’s to maintain your independence as a creator. In turn, be a direct and generous person yourself.

People get defensive when they’re scared. Don’t sit at the table with someone like that or as someone like that and doing business should be fairly pleasant! This isn’t Wall Street!

9. No gimmicks. Simply put, focus on making a good game - a deep, interesting, unique game - rather than devising cheap tricks to grab people’s attention. Whether we’re talking about clever-sounding-but-ultimately-shallow game systems or off-the-wall marketing ideas, a gimmick is a gimmick. And you should stay away from them because they’re short-term, high-risk solutions that ultimately cheapen you as an artist, perhaps literally as well as metaphorically.

Certainly, one should take risks in game design as well as in life. My point is that they should be honest, worthwhile ones - those tend to be less risky in the long run.

10. You are your game - understand and develop yourself. As an indie game developer your game will likely be more “you” than a game made by hundreds or thousands of people. You have to understand yourself quite well in order to make a truly successful game. Fortunately, the unraveling of what makes you “you” - your taste, what you care about, your abilities - is one of the great pleasures in life and goes hand in hand with your goal of being an independent creator. Treasure it!

source : http://makegames.tumblr.com/post/44181247500/making-it-in-indie-games-starter-guide