Je souhaite tout d’abord citer cet excellent article, qui peut servir de référence et de point de comparaison pour évaluer ses tarifs en tant qu’indépendant :
Quels tarifs appliquer pour un indépendant ?

Je vous invite également à lire les différents retours d’expérience des articles listés ci-dessous, car il est toujours bon, lorsqu’on débute, de savoir comment les autres fonctionnent. Même si cela peut sembler enfoncer des portes ouvertes sur certains points, certaines méthodologies valent la peine d’être (au moins) entendues.

• 7 questions pour 5 freelances web
• Interview de Aymeric Jacquet, freelance depuis 6 ans (au moment de l’écriture de l’article)
• Interview with a freelance web and graphic designer since 5 years
• Un an de freelance, eclaireur.net
• Interview de David Marchesson après 6 mois d’activité

Vous êtes freelancer ? N’hésitez pas à partager votre expérience, ou à linker des articles similaires !
J’essaierai de mon côté de compléter cet article, afin d’en faire un petit dossier.

Bonne chance à tous !

J’ai choisi Box2D (Get Box2D Flash), utilisé par pas mal de monde, mais par contre, mauvaise surprise, j’ai eu un peu du mal à trouver des tutos pour poser les bases. Tant pis, je me suis dit que s’il le fallait, j’irais parcourir la doc technique directement !
J’ai quand même fini par trouver un bon tuto vidéo pour les bases : sur le site Kerp.net ! Thanks a lot !

Donc voilà, je viens de manger le chapitre 1, je vais attaquer le chapitre 2 en espérant qu’il réponde aux problématiques laissées en suspend à la fin du premier volet !

• Pour la version anglophone de Words Trap :

- 233 jours d’existence sur MochiAds,
- 53 179 parties jouées,
- 228 parties jouées par jour en moyenne.

Il s’agit pour moi d’une petite réussite, puisque ce jeu continue à l’heure actuelle de bien fonctionner et de plaire à des milliers de joueurs ! En espérant que les futurs projets que j’ai en tête suivent le même chemin en mieux encore !

Vous constaterez par vous même qu’il manque encore beaucoup de choses pour que ce jeu soit complet, mais c’est un début et il n’a pour prétention que de poser les bases !

Quelques infos :

• Graphisme : environ une semaine « homme », utilisation de Poser, par PixieDaydream
• Développement : environ 7 jours « homme », AS3, par PixieDaydream
• Publicité : MochiAds API, AS3

Alors, voyons voir, un time management avec des fleurs … ça ressemble à quoi ??? Vous le découvrirez bientôt dans la « version mini » du jeu !

Mais avant quelques difficultés abordées pendant ce début de projet, développé en Action Script 3 :

• Une gestion d’évènements très carrée et des évènements spécifiques pour s’adapter à un modèle MVC,
• Les graphismes grrrrr … Merci au logiciel Poser qui m’a bien aidée pour les personnages, bien que je l’ai trouvé assez difficile à prendre en main (très peu de tutoriel sur le net),
• Déplacer un personnage dans 8 directions possibles, avec un ou 2 objets en main, qui suivent l’animation,
• Une gestion du travail complètement itératives, histoire d’être sûre que les bases de l’application sont bien stables avant de rajouter des fonctionnalités.

Pour le moment, c’est tout, mais bientôt, une petite démo !

A bientôt !

Nous avons décidé et mis en place une rémunération « au prorata du temps passé ». Partant du principe que nous étions tous professionnels et compétents (et donc que nous avancerions à peu près à la même vitesse), nous avons compté chaque jour les heures passées sur le projet, pour pouvoir à la fin de celui-ci nous partager le montant du devis. Cette démarche s’inscrivait donc dans un climat de bonne entente et de confiance. Heureusement pour nous, cette confiance sur les temps comptés par chacun n’a jamais été remise en cause, bien que le problème puisse peut être se poser dans certaines équipes.
Mais à la fin du projet, pour de nouveaux projets potentiels, nous avons décidé de ne pas renouveler ce système. Pourquoi ? Car au final, il n’est pas du tout rentable pour l’indépendant ! Je m’explique.



En temps normal, un indépendant devise une tâche ou un projet, pensant qu’il va passer dessus un certain temps. Afin de rentrer dans ses frais, ce travailleur acharné va soit se modérer afin de rentrer dans ses frais, soit passer plus de temps que prévu, et il va tout faire pour limiter la casse. Je ne parle pas du « passionné » qui ne comptera absolument pas ses heures.

Avec le système du « prorata du temps passé », la tendance est de prendre le temps de faire les choses bien. En effet, sachant que le temps sera facturé, il est moins nécessaire de s’auto-limiter ! Et de plus, involontairement, une « course aux heures » peut apparaître, histoire de ne pas être moins payé que les collègues ! Au final, ce n’est pas nécessairement le plus productif qui gagne le plus, sans parler de celui qui tient à sa vie sociale et ne désire pas travailler les week-ends.
Je ne parle absolument pas ici de contrefaçon volontaire, soyons d’accord ! Mais plutôt d’un état d’esprit « pragmatique » qui se met tout seul en place pour chaque personne de l’équipe. On compte oui, mais on fait beaucoup moins attention au final aux nombres d’heures passées par rapport aux nombres d’heures facturées.



Ce constat a été fait par les 5 personnes de l’équipe. Et pour information, nous avons décidé pour la suite de repasser à un système un peu plus contraignant mais plus réaliste et moins dangereux : le découpage du projet en tâches et leur répartition. Chaque développeur est payé pour la tâche qui lui a été attribuée. Qu’il passe deux fois plus ou deux fois moins de temps que prévu, seule sa rémunération en sera impactée. L’inconvénient de cette méthode est de quasiment prévoir les tâches dès le devis, de découper le projet de la manière la plus précise possible puis de partager et planifier ces tâches.

Ca démarre doucement, après 2 mois d’existence. Quoi donc ? Mini Jeux Web ! Portail de casual games flash gratuits, mon petit bébé propose un contenu régulièrement renouvelé pour offrir des jeux sympas pour toute la famille. Vous ne connaissez pas ? Allez donc jouer 5 min 36 (pour rester dans la moyenne) !

Je vous mettrai régulièrement des nouvelles, même si mes expériences prennent du temps à aboutir car je ne suis pas experte en référencement etc.

Je profite également de ce post pour faire signe aux développeurs de casual games Français, n’hésitez pas à me contacter à l’adresse webmaster at mini-jeux-web.com si vous souhaitez que j’héberge votre jeu. Eh oui, ce n’est pas facile de faire un portail francophone : il y a très très peu de jeux fr !
Même adresse si certains sont intéressés par des échanges de lien !

A bientôt !

PS : merci à ceux qui soutiennent ce site (que ce soit par des liens, ou des conseils ) !

Ce jeu est basé sur Facebook uniquement, ce qui signifie :

• les internautes – et les éventuels joueurs donc – passent en général une à plusieurs fois dans la journée, quelques minutes seulement.
• Facebook, nos amis : des possibilités multiples, simples ou complexes.
• Tout public : tout âge, toute expérience web, toute expérience jeu.

Une cible très vaste donc, avec des exigences particulières, du plus simple au plus extrême !

Ce que propose Café World :

• Une interface épurée, simple, mais extrêmement parlante.

Des icônes claires, bien dessinées, parlantes. Des menus agréables, bien étudiés, très intuitifs. Des animations rendent l’interface vivante et amusante à regarder « vivre ».

• Des actions à réaliser, qui peuvent être étalées dans le temps au gré du joueur.

Achat d’options en direct (mobilier, décoration, extension …). Mais surtout préparation de plats, en 3 min ou en 2 jours, fournissant une dizaine d’assiettes ou 1500, à choisir dans le livre de recettes. Libre au joueur de ne venir qu’une fois par jour, d’être connecté toute la journée, de venir qu’une fois toutes les deux heures… pour servir ses plats.

• Des objectifs divers permettant de correspondre à plusieurs types de joueurs.

Gravir les échelons pour avoir plus de plats disponibles, gagner de l’argent, personnaliser son restaurant, son avatar, être le meilleur chef …

• Une utilisation de la liste d’amis qui amène un intérêt au jeu et permet en même temps de le faire connaître et de relancer les joueurs.

Pouvoir offrir des cadeaux à ses amis pour les aider – déjà inscrits ou non, pouvoir visiter les restaurants de ses amis – voir leur déco, leurs plats – , pouvoir les ajouter en tant que voisins et comparer les scores, gagner des points en goûtant leur plat du jour …

• Un modèle économique simple et efficace

Basé sur la personnalisation du restaurant, nombreuses options uniquement disponibles en « café cash » payables en $$$.

Vraiment, un jeu très adapté à Facebook ! Extrêmement addictif, si vous passez plusieurs fois par jour sur Facebook, l’habitude d’aller gérer votre restau vient très vite !

Bien sûr pour être objective, je dirais qu’il manque également quelques petites choses ! Notamment pouvoir tester des décorations (papiers peints, carrelage, mobilier …) avant d’acheter, avec un mode Aperçu. Peut être un peu plus de choses à débloquer par niveau (un objet, ou une recette par niveau). Et encore plus de choix de mobilier (personnellement, les chaises ne sont pas à mon goût !).

Un très bon jeu selon moi, vous l’aurez compris. Ca donne envie de faire le sien ….. !

Ces deux méthodes peuvent être comparées lorsque vous pouvez générer une BitmapData aux couleurs simplifiées, le mieux étant bicolore, afin de tester la couleur en un point donné.

L’inconvénient des hitTest est qu’ils ne s’appliquent qu’à un seul objet DisplayObject à la fois pour être précis. Si vous avez de nombreux objets à tester, cette méthode risque de beaucoup ralentir votre application.

Principe du test

Voici le test que je vous propose : je souhaite savoir si un sprite nommé bille entre en collision avec un sprite nommé mur. Mais je veux également savoir si la collision se fait sur l’axe des x, sur l’axe des y ou les deux, chacun ayant un traitement distinct.

Il me faut donc deux tests :

• Détection de la collision en x sur les deux côtés

• Détection de la collision en y haut et bas

Spécificités des bitmaps

Pour le test du hitTest, aucune modification spéciale n’est à ajouter, il vous faut les deux clips à tester sur la scène.
Pour le getPixel, vous devez tout d’abord construire (ou charger) votre bitmap :

<div class="code">
var _oBmpData: BitmapData ;
var _oBmp : Bitmap ;
_oBmpData = new BitmapData(mur.width, mur.height, false, 0x000000);
_oBmp = new Bitmap(_oBmpData);
addChild(_oBmp) ;
_oBmpData.draw(mur); // ici nous donnons le motif du Sprite pour composer le bitmap
</div>

Les tests

Les tests proprement dits :

• Avec le hitTestPoint :

<div class="code">
if (mur.hitTestPoint(zone.right , bille.y ) != false || mur.hitTestPoint(zone.left, bille.y ) != false)
test = true ;
if (mur.hitTestPoint(bille.x, zone.top  ) != false ||  mur.hitTestPoint(bille.x, zone.bottom  ) != false)
test = true ;
</div>

• Avec le getPixel :

<div class="code">
if (_oBmpData.getPixel(zone.right , bille.y ) != 0 || _oBmpData.getPixel(zone.left, bille.y ) != 0)
test = true ;
if (_oBmpData.getPixel(bille.x, zone.top  ) != 0 ||  _oBmpData.getPixel(bille.x, zone.bottom  ) != 0)
test = true ;
</div>

Résultats

Voici le test ci-dessous, vous constaterez que la difference de performance est du simple au triple en faveur du getPixel.