-L0Lock- a écrit:

C'est un peu beaucoup 30% non? Presque un tiers...

C'est pour les tests pour le moment

entwanne a écrit:

-L0Lock- a écrit:

C'est un peu beaucoup 30% non? Presque un tiers...

Oh ça dépend des régions, 30% c'est peu par endroits

Mais justement, il serait intéressant de varier les taux de pluie suivant la carte.

Sûrement oui Ajouter un champ 'rain_percentage' dans le code de la carte / monde serait effectivement intéressant, je vais en parler à iReplace

Manyrio a écrit:

Et pourquoi ne pas faire un vrai temps qui prend en compte le climat et tout et tout ... ? Le bruit de perlin pourra bien t'aider

Le perlin noise est lui même aléatoire. Alors pourquoi utiliser un générateur de bruits aléatoires quand tu peux faire un simple random.random() < PERCENTAGE xD ?

-L0Lock- a écrit:

Même au chnord je suis pas sûr qu'on atteigne ça.

Ca dépend quel chnord j'ai envie de dire x) Près de Berk, il pleut genre au moins 1 jour par semaine, des fois plus

Bah un jour par semaine, ca fait à peine 14%

-L0Lock- a écrit:

Même au chnord je suis pas sûr qu'on atteigne ça. :p

C'est loin d'être le département le plus pluvieux de France (que ce soit en terme de quantité ou de fréquence).

Support de l'affichage de la carte (chemins, villes, ...) : fait !

Optimisation avec la pluie (si on ne voit pas toute la map, de lapluie va spawn en dehors de la fenêtre, ca va tuer les perfs ... bref wala) : fait !

Screenshot parce que c'est boo : en cours ..

c'est mis n'importe oui, et alors ? C'est juste un test

Haha c'est mieux de la pluie optimisé x)

Hello everyone !

La minimap devient enfin entièrement opérationnelle (et est super facile d'édition)

Le code qui régit son contenu (pas le placement des chemins et tout, c'est dans un autre fichier ça) est celui ci :

{
    "chemin": {
        "name": "c",
        "used": [
            "-",
            "*",
            "/"
        ]
    },
    "chenal": {
        "name": "h",
        "used": [
            "o"
        ]
    },
    "lieux": {
        "name": "l",
        "used": [
            "#"
        ]
    },
    "ville": {
        "name": "v",
        "used": [
            "0",
            "1",
            "2"
        ]
    },
    "descriptions": {
        "*": {
            "name": "Chemin sans nom",
            "desc": ""
        },
        "-": {
            "name": "Un autre chemin",
            "desc": ""
        },
        "/": {
            "name": "Encore un chemin",
            "desc": ""
        },
        "o": {
            "name": "Mon petit chenal !",
            "desc": ""
        },
        "#": {
            "name": "Tour super sacrée",
            "desc": ""
        },
        "0": {
            "name": "Paris",
            "desc": ""
        },
        "1": {
            "name": "Tokyo",
            "desc": ""
        },
        "2": {
            "name": "New-York",
            "desc": ""
        }
    }
}

Et on obtient ceci :

Je précise que tout se fait au clic

Tu ne devrais pas utiliser les mêmes couleurs pour le fond de la carte et les nomenclatures. C'est pas lisible (surtout quand les mêmes couleurs se chevauchent) et ça ne ressort pas assez bien.

Par nomenclatures, tu entends Paris, New-York, Encore un chemin, ... etc ?

Effectivement je devrais mettre un fond

Hum... Erreur de vocabulaire. Je voulais parler de tous ce que tu ajoutes au-dessus fond d'une carte pour indiquer ce qu'on y trouve. Que ce soit des symboles, les figurés des chemins, routes et villes, etc. Là justement, tu as mis les chemins en jaune, les chenaux en bleu, ... Et je pense que de manière générale, il y a plus lisible comme choix de couleurs. Du blanc et du noir par exemple, pour détourer ou remplacer même tout-ça. Que ça ne se confonde pas avec le fond.

Ca va etre changé ça, t'inquiète pas

J'ai déjà modifié le fond pour le texte (semi transparent noir, texte en blanc)

Sinon, voic une nouvelle video : https://www.youtube.com/watch?v=VAR4hX7upA0

(flemme de résumer les news, tout est dans la video xD)

On peut maintenant avoir des cinématiques

https://youtu.be/EjRxGb4BP-c

Mini map : faite

la voir ici : http://folaefolc.hostux.fr/pic/39.png

en train d'ajouter des cheats code (à vous de les trouver !)

Je vais aussi essayer de tourner 2 vidéos (sûrement une en anglais pour résumer le projet à nos amis mangeurs de bacons)

J'ai aussi les déplacements et collisions à refaire xD (pour passer ca en mode old Zelda, déplacement "chunkisé")

belle saison, mauvais jour, mauvaise nouvelle.

le projet est mort (tout comme ses différents repo github/gitlab qui n'acceptent plus les push malgré multiples reconfigurations) pour une durée indéterminée

une nouvelle encore pire (ou pas), j'arrête de publier unamed sur github. les sources vont être retirées prochainement

et enfin, ce merdier va etre recodé de 0 normalement. normalement. en partant sur GK, un tool développé par iReplace. donc pas de nouvelles avant longtemps.

adios.

Oh....

Dommage, ça partait bien...

Pourquoi tu recommence tout ?

cf le topic zeste de savoir

https://zestedesavoir.com/forums/sujet/4155/unamed/?page=1#p75404

mais entre autres, c'est trop de problèmes dans la source (malgré une ptn d'archi) et avec github/gitlab

-
Edité par Anonyme 7 mai 2016 à 19:02:37

Peut-être enfin le passage à Unity3D ?

Tu ne lâches pas l'affaire Str4nger haha

De toute façon Unity ça vaut rien par rapport à Unreal Engine

*Fuite à la zoïdberg*

Str4nger a écrit:

Peut-être enfin le passage à Unity3D ?

toi t'abandonnes jamais. et c'est non. clairement. unity3D servira à rien ici. suffit de modifier le système de rendu pour s'en rendre compte. mais bon, c'est pas à la portée de tout le monde.

Peut-être qu'avec Unity tu finirais un projet au lieu de réinventer le millième moteur de rendu 2D...

-
Edité par Anonyme 7 mai 2016 à 22:42:59

Y a pas plus simple sinon que de transformer de manière barbare un moteur 3D en moteur 2D ? (Après je connais pas bien unity, si ça se trouve il y a un outil spécial pour la 2D)

Et puis sinon c'est toujours amusant de réinventer la roue, au moins pour mieux la comprendre...

On fait aussi des jeux 2D avec Unity.

-
Edité par Lauloque 7 mai 2016 à 23:22:02

Reiex a écrit:

Y a pas plus simple sinon que de transformer de manière barbare un moteur 3D en moteur 2D ? (Après je connais pas bien unity, si ça se trouve il y a un outil spécial pour la 2D)

Il n'y a pas plus simple qu'Unity pour faire des jeux 2D. C'est pas par hasard que c'est ce que tout le monde utilise.

donc je dois deviner que tu es au dessus des autres, gwenn ? bah oui, tu utilises unreal engine

réinventer un moteur de rendu ? tu rigoles j'espère. le rendu c'est pygame qui le fait (plus précisément, gk maintenant (mais avant c'était le ree)). le "moteur" de rendu, c'est un truc tout con de 4 lignes environ qui choisi quoi afficher.

là on réinvente que dalle, on code ce que l'on appelle le "core". tu sais, ce truc énorme qui gère ... tout. des combats aux pnjs en passant par les collisions et plein d'autres choses très utiles.

Je ne suis au dessus de personne, j'utilise juste le même moteur depuis 2006, et à l'époque où Unity est apparu je suis resté sur Unreal. Quel rapport avec ta situation ?

C'est le deuxième projet que tu abandonne en chemin, c'est le deuxième projet où tout le monde te dit de passer à Unity3D pour avoir une architecture propre et des performances décentes. C'est étonnant que tu continue à rester sur du fait maison.

j'abandonne pas, je recommence, nuance

et pour info, urworld est mort pour laisser la place à un autre, encore en prod

"tout le monde me dit de ..." ah bon ? y a que toi qui me dis ca

Tout dépend des objectifs pour le projet Le "fait maison" permet d'apprendre un plus large éventail de compétences que lorsqu'on utilise un moteur. Enfin, quand je dis plus large, il faut prendre en compte les proportions bien évidemment. Si le but du projet est d'apprendre, alors le "homemade" est un chemin (bien que semé d'embûches) assez gratifiant lorsqu'on arrive à destination. Mais évidemment ça prend du temps avant de s'attaquer au contenu du jeu. Si le but est de finir un jeu, alors oui, il conviendra d'utiliser un moteur qui mâche certaines parties et permet d'attaquer directement sans s'embêter à construire une architecture qu'il faudra modifier moultes fois avant d'arriver à quelque chose de potable :) 

Si tu veux continuer sur du homemade Yaalval, je te conseille le C++ qui impose une architecture plus propre que Python (qui est un peu trop libre), pour bosser

Sinon comme dit Str4nger, Unity pourrait également être un compagnon de choix pour ce projet (ou tes futurs projets). 

Str4nger, pourquoi ne pas le laisser créer son propre moteur ? Tu apprends beaucoup en faisant ça, regarde moi par exemple, avec UP, je n'utilise rien sauf Löve2d qui est une librairie pour afficher des images et autres comme pygame.

Mais c'est pas pour autant que mon jeu est mal fais, avec des performances médiocres ...

Voilà voilà, bisous

Perso j'arrive pas à savoir ce que tu cherches en fait.

T'as l'air quand-même de vouloir finir tes jeux : tu recrutes, tu en fais la promo et tu annonce même des publications de versions jouables, comme là :

Mais deux jours après, le projet est mort sans crier gare !

C'est quand-même la deuxième-fois qu'un projet meurt. Deux projets pour lesquels tu as fait plusieurs pages de topic, de la comm et du recrutement. Tu dis ne pas réinventer le moteur de rendu, qu'Unity ne servirait à rien, mais d'un autre côté on a quand-même plusieurs posts (et pas qu'un peu) où tu tripatouilles pour les performances alors qu'avec Unity... Tu as déjà lu ça il me semble.

Donc bon. Si ton but est de faire maison pour fun ou l'apprentissage, ok. Mais alors n'affiche pas ton projet comme un jeu à finir et demandant un recrutement. Contente-toi de faire de la prog et advienne que pourra.
Mais si ton but est réellement de faire un jeu, de le publier, etc. Alors je pense sérieusement que tu devrais reconsidérer Unity. Parce-que là c'est juste un peu l’hécatombe.

Enfin j'dis ça, j'dis rien. D'ailleurs les canards savent pas parler alors @+