Bienvenue, Invité. Merci de vous connecter ou de vous inscrire. Avez-vous oublié d'activer ?

Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - marchred

Pages: [1]
1
Hello !

J'aime bien ce style de jeu :)

Sa te dérange pas si je pique l'idée ?

Je suis branché IA ces dernier temps, tu serai chaud pour décrire en détail ce qui est fait et ce que tu compte faire du projet ?

2
Projets SFML / Re : [jeu 3d] Pigami
« le: Juillet 15, 2013, 08:27:42 pm »
Hello !

J'ai visité ton site et les lien de 2 de tes jeux ne marche pas (je télécharge une archive de moins d'1Mo)

Mais icemaze et inthecube me font rever !
Le gameplay est intuitif, le level design... genre t'es dans une école de game design parceque je n'ai rien lu et éxécuté les appli direct et j'ai eu aucun probleme!

Et ya des éléments de gameplay (pour moi) completement inattendu ! Les bloc invisibles ou les angle (icemaze) !

C'est pas des jeux qui de base me tenterai mais l'ambiance, la réalisation et toute ces petites hoses qui font que le jeux se renouvèle... j'aime ;).

PS : j'voudrai vraiment tenter pigami, il y a moyen que tu rétablisse le lien ?
PS : tu es disposé a partager les sources ?
PS : tu m'en veux si j'te pique tes idées ?

3
Rien de mechant hein ?

Juste que je sais que tu tiens a garder la lib user-friendly,
et les avantages de l'udt sont pas forcement flagrant pour un nouveau venu.

Du autre cote c'est vrai que c'est pas une trop mauvaise idee...

Tu as un avis sur la question ? Je me doute que tu as plus urgent bien sur.

4

Salut !

Joking :)

Bye!

5
Suggestions de nouvelles fonctionnalités / Re : SpriteBuffer
« le: Février 17, 2013, 11:24:57 am »
Hello !

Je crois comprendre ton raisonnement, ce serai un outil potentiellement difficile a comprendre.
Juste qu'apres lecture des source de la SFML, je pense que dans certain cas, ya moyen de faire tres rapide.

L'exemple le plus parlant sera surement une TileMap.
Mais cela peut s'etendre a tout objet de scene partageant la meme texture, projectile des bot/player.
Vu la taille/resolution de certaine texture, regroupper plusieurs image en une seule image est logique.

J'ai bien 20 projets utilisant un grand nombre de sprite qui se retrouve dans ce cas.


Apres je te l'ai dis, je comprend ton desir de faire une lib facile d'utilisation.
Mais certains sacrifice sont-ils vraiment necessaire ?

Tu mentionne plusieurs obstacle :


Citer
- on ne pourra pas mettre dans un même buffer des sprites utilisant différentes textures, mais on ne peut pas l'interdire proprement au niveau de l'API (du coup je vois déjà les milliers de posts sur le forum "ça marche pô !")

Exemple parfait, a ce stade la seule alternative que j'ai est d'indiquer le probleme avec un std::cerr.
Assert le programme si on push un Sprite avec une texture differente par exemple.
Box2D semble fan de cette technique, et je ne l'ai pas trouve si inabordable que cela.

Citer
- si on utilise un sf::Sprite il faut gérer tous ses attributs, donc notamment sa transformation courante (c'est pas la mort mais ça peut devenir assez vite inefficace pour des sprites qui ne bougent jamais).

Oui, c'est vrai que gerer le cas de maniere optimise/propre va complexifier le fonctionnement interne de la lib.
Probablement des modifications du Sprite (attribut bool) confirmant qu'il a subit une transformation.
Cela me fait penser qu'un ColorBuffer ne serait pas inutile dans une classe comme le SpriteBuffer.

Citer
- si on met des sf::Sprite dans le buffer, ce n'est à mon avis pas assez clair que ceux-ci sont copiés dans le vertex array ; je m'attend en outre à voir des gens changer leur sprite après ajout dans le buffer, et penser que le buffer va automatiquement prendre en compte ces changements

Vrai, mais a ce stade pourquoi ne pas rendre la chose possible ?
Au lieu de reset puis push des Sprites dans un SpriteBuffer, pourquoi ne pas les lier ?
Le SpriteBuffer attach/detach des Sprites qui sont update dans leur coin.
SpriteBuffer.Render() s'occuperai d'update la pool, qui a ce stade "pourrait" augmenter sa taille si besoin.

PS : dsl pour mon francais probablement mauvais.
PS : clavier QWERTY, pas d'accent pour moi.
PS : quelque soit ta decision, ce topic m'aura permit d'avoir une idee plus complete de ma "mySFML" ;)

6
Suggestions de nouvelles fonctionnalités / SpriteBuffer
« le: Février 16, 2013, 10:18:38 pm »
Idee que certain on du avoir, le but est de fusionner le Sprite et les VertexArray...
...pour en faire un espece de SpriteBuffer.

Je m'explique :
  • Prendre la cappacite SetTexture() du Sprite
  • Lui coller une pool de quatuor de vertices (coord2D + TexCoord)
  • La taille de la pool est parametrable selon les besoin
  • Un compteur indique le nombre de case de la pool a afficher
  • Il est possible de reset a 0 ce compteur entre chaque frame
  • Suite a quoi il est possible de push des donnees de Sprite dans la pool
    • on ne realloc pas la pool, on ecrase les data depuis le compteur
    • on incremente le compteur pour savoir combien afficher et d'ou ecraser dans le futur
  • Enfin, on affiche, et la les avantages sont multiple :
    • Un seul Appel a Bind de texture2D pour plusieurs Sprite
    • Plusieur Sprite rendu en une seule fois
    • Le system de Reset/Push permet de gerer des scenes 2D static et dynamic

PS : dsl pour mon francais probablement mauvais.
PS : clavier QWERTY, pas d'accent pour moi.

7
Projets SFML / Re : mmorpg 2d iso
« le: Juillet 28, 2012, 06:40:44 pm »
Salut ! :)


J'ai plein de question face a un projet aussi ambitieux et pourtant si bien avancée comme le tiens !
  • Tu utilise bien la sfml pour le reseau ?
  • Tu te sers de l'UDP ou tu es Full-TCP ?
  • Tu semble beaucoup orienter ton projet dans le server-side, dans ton développement tu compte prévoir plusieurs « serveur-étape » (serveur de connexion + serveur de jeu pour chaque map) ?
  • Honnêtement j'aime bien les MMORPG mais je suis vieux, déplacement au clavier possible ?

Sinon je comprend ta « peur » (si je puis me permettre) de ce que le client peux faire via les ressources comme la map, mais a pars vérifier en non-stop la position de chaque joueur sur chaque case en prenant la map du serveur comme référence tu aura du mal, et c'est coûteux en charge réseau tout ça.

Mmh, personnellement j'aurai eu tendance a récupérer les events du client en TCP, a calculer le résultat de ces event, puis a transmettre et produire cette réaction sur le serveur et sur le client, d’où peut-être l’intérêt d'avoir un serveur par map et de les repartir sur plusieurs machine qui communique avec une sorte de serveur centrale qui repartie les joueur suivant leur localisation, avec un bon protocole d’échange tu peux sûrement grapiller des octets lors des envois et finir par rendre la chose possible, mais peut etre que je me trompe...

Tu en pense quoi ?

++

8
Projets SFML / Re : [C++][RTS 2D] PolygonWars
« le: Juillet 27, 2012, 10:54:59 am »

@actuenligne

« Si j'ai bien compris, c'est le fait que les unités se déplacent cases par cases qui permet l'utilisation du TCP ! »

C'est peut être valable pour les déplacements 'normaux' je réfléchis beaucoup a ce que sera PolygonWars2 (oui je sais le 1 est pas encore finis ;) ) et je me dis que c'est finalement hautement faisable, mais la priorité c'est de finir correctement ce projet, il est a la portée de beaucoup de monde, il pourra peut-être devenir ce 'tremplin' qui manque dans le domaine des RTS open source (c'est ce que je pense après j'ai peut être mal cherché).

@Rexou

« Tu as pris pas mal de recul sur ton projet et ça c'est cool, ça change des projets un peu trop ambitieux qui ne verront malheureusement jamais le jour. »

Je ne m'en étais pas rendu compte mais tu as raison, sur le coups j'ai compté le nombre de projet personnel inachevé que j'ai produit depuis que je sais programmer, il y en a une bonne centaine, cela va du FPS bancal aux Shoot comme Ikaruga (sans parler de mes tentative de refaire Minecraft...), ils sont fonctionnels mais ne représente pas de jeux a eux seul, la, avec PolygonWars, je compte changer, d'ou mon post sur ce forum, car ce projet la, je vais le finir ! ;)


« Un petit github quand tu auras une version propre et stable ? »

Volontiers ! :)


« Je ne suis pas un exemple pour les accents sur clavier qwerty mais si tu y tiens regarde du cote de la commande setxkbmap »

Je note ! Merci ! :)

9
Projets SFML / Re : [C++][RTS 2D] PolygonWars
« le: Juillet 26, 2012, 01:35:38 pm »
@actuenligne

Hello!

Merci de porter de l’intérêt a mon petit projet :), c'est la première fois que j'en publie un donc c'est plutôt cool !

Pour le tester je pensais fournir directement les sources (je pense beaucoup a faire de l'Open Source), de cette manière cela marchera sur plein de machines tout en ayant des avis externe sur ma façon de programmer, mais avant je souhaite finir plusieurs petite choses, et nettoyer mon code ;), d'ici une semaine ce sera bon je pense.

Sinon oui oui! C'est en temps réel ne t’inquiète pas!
Pour ce qui est du réseau, je comprend que cela choque, pourtant c'est tout bête :
  • a la base, les unités se déplacent case par case
  • donc quand une unité est en mouvement, je précise sa case actuelle et la case voisine ou elle va se rendre
  • le client reçois ces deux case et effectue l'animation de déplacement de l’unité entre les deux cases
  • si la vitesse de déplacement de l’unité cote serveur et cote client est la même alors il n'y a aucun ralentissement
  • A cela se rajoute quelque petite astuce pour économiser des octets a l'envoi des packets
    • l'ID le la requête de déplacement d'une unité tiens sur 1 sf::Uint8, cela me limite a 255 requêtes, mais cela me va
    • l'ID d'une unité tiens sur 1 sf::Uint8, de cette manière je peut créer et gérer 255 unités par camps, honnêtement c'est beaucoup
    • la position d'une case tiens sur 2 sf::Uint8,cela limite a des maps de 255*255, mais c'est pas mal non?
    • donc en résumer mon packet d'update ressemble a cela:
      • (1o requête de déplacement)(1o ID unité)(1o x source)(1o y source)(1o x destination)(1o y destination)
      • 6 octets pour une seule requête de déplacement d'une seule unité, pas trop mauvais non ?
  • Puis je concatène chaque requête de chaque unité de la frame dans un sf::packet encrypté
  • Enfin, j'envoie aux clients du même camps que l’unité, et au client du camps ennemis si ils voient l’unité
PS: je suis sur une clavier QWERTY, dsl d'avance pour les accents qui manquent ;)

10
Projets SFML / [C++][RTS 2D] PolygonWars
« le: Juillet 26, 2012, 11:19:12 am »
Moi

Hello, marchred, 23ans, survie en France.


le Jeu

PolygonWars (nom honteusement pompe d'un jeu du même nom) est un RTS 2D multiple-joueurs

Comme il n'y a aucune IA vous devrez être plusieurs pour jouer, il n'y a pas de limite de joueur au passage.

L’idée c'est de commander a plusieurs une armée ou chacun peut avoir son rôle.
Si par contre les taches viennent a manquer les joueurs peuvent directement prendre le contrôle d'une unité tout en gérant les unités a portée de vue

Il s'agit ici d’être un minimum original en proposant un gameplay a peu près potable.
Car oui, le jeu est moche (bourre de sf::Shape), le titre est pas original et les unités se déplacent case par case.


Gamplay

Vue de dessus

Contrôle a la souris :
  • clic gauche → sélectionner
  • clic gauche enfonce → rectangle de sélection
  • clique droit → déplacer
Les unités sont des polygones :
  • Elles se déplacent par cases, dans les 8 directions
  • Elles possèdent des points de vie
  • Peuvent posséder un effet actif gérer automatiquement
    • Quand elles le peuvent, elles attaquent l’unité ennemis la plus proche
    • Quand elles le peuvent, elles soigne l’unité amis la plus proche
  • Peut posséder un effet passif gérer automatiquement (une sorte d'aura)
  • peuvent évoluer vers un meilleur type si on y met le prix
  • peuvent s’étendre pour devenir des bâtiments si on y met le prix
  • peuvent être contrôle par un joueur, possède alors des avantages :
    • peut passer au dessus des bâtiments et des unités
    • possède un caractéristique lie a son type (vision++, attaque++, etc …)
    • les effets actifs comme l'attaque ou le soin deviennent manuel (c'est plus automatique quoi)
    • doit être relâcher sur une case vide (a moins de la sacrifier ou de mourir...)
Les bâtiments sont des unités plus grande et immobiles :
  • Prennent 3*3cases et sont immobiles
  • Elles possèdent 3 fois + de points de vie que leurs ancienne forme
  • prise du contrôle des joueurs et le sacrifice est toujours possible
  • 255 bâtiments max
Ressource dans le jeu : le triangle
  • vous pouvez obtenir cette ressource en sacrifiant vos unités/bâtiments (sa dépend de son état, sacrifier un truc a 1PV ne rapporte presque rien)
  • un bâtiment (l'octogone étendu) produit constamment l’unité de base, s'il ne peut pas créer de nouvelle unité il la sacrifie automatiquement :
    • 255 unités max
    • plus de place sur la map
Une partie

Vous démarrez une partie dans un des deux seuls camps (bleu et rouge), vous ne possédez qu'une unité, un octogone
sa capacité de base est de pouvoir tirer des projectile qui convertissent toute unité ennemis en unité allie
sa deuxième capacité est qu'une fois devenu un bâtiment, elle produit des triangles, l’unité de base, a une vitesse de 1 toute les 3 secondes

A vous de voir si vous voulez déplacer l'octogone avant d'en faire un bâtiments, bien qu'en général, la production soit plutôt urgente

Le triangle est un unité faible, capable d'attaquer, mais possède surtout la meilleur vision de toute les unités.
A partir de la vous avez le choix
  • explorer la map avec le triangle
  • le sacrifier pour peut être faire évoluer le prochain triangle
  • le muter en bâtiment pour qu'il deviennent l’équivalent d'une tour de guet (avec un encore meilleur champs de vision)

Puis vous êtes tenté de faire évoluer un triangle, il deviendra un carré, le carré n'attaque pas, mais possède un champs de force
Le carré régénère sont champs de force et c'est tant mieux car il est a peine plus résistant qu'un triangle.
Son champs de force mesure 3*3 cases, il peut donc protéger d'autre unité, il passera a 9*9 case si il devient un bâtiment

Viens ensuite le pentagone, équivalent d'un soldat.
Il attaque plus loin, plus vite et plus fort qu'un triangle, et c'est tout ce qu'on lui demandera
Le transformer en bâtiment en fera une parfaite tourelle de défense

La nouvelle évolution sera l'hexagone, un soigneur, il vise les allies les plus faible en point de vie.
En bâtiment, il générera un aura de régénération pour les bâtiments et les unités (non cumulable).

Avec 7 cote, l'heptagone est une unité d'artillerie, ses tirs explosent et font des dégâts de zone.
Inutile de décrire les effets d'une tel unité une fois devenu un bâtiments, un massacre.
Son point faible? sa très faible vision du terrain.

Viens ensuite l'octogone, mais passons, nous la connaissons déjà.

Le Nonagone est une unité invisible quand rien le la touche, même en déplacement.
Elle n'attaque pas et deviens visible en bâtiment tout en rendant invisible tout ce qui se trouve a sa portée (9*9 cases)

Enfin, le décagone est l’unité ultime, il attaque avec des projectiles perforants passant aux des travers des unités, bâtiments et des boucliers
Sa version bâtiment est l’équivalent d'un générateur avec une aura qui boost les autres bâtiment, et si cela cachait quelque-chose ?


Technique

Ce projet est pure SFML, pas d'OpenGL, rien d'exotique donc « il devrais pouvoir marcher sous Windows » (oui je suis sous Linux ;) )

Tout action est « Server-side », recherche de chemin, déplacement, construction, sacrifice, upgrade, action automatique et brouillard de guerre
  • Donc lors des déplacement c'est le serveur qui calcul le chemin des unités, les client reçoivent juste les coordonnes de mouvement pour l'affichage.
  • Lors d'une construction/sacrifice/upgrade d’unité c'est le serveur qui vérifie si les conditions sont remplis
  • Si quelque-chose n'est pas visible pour un camps il n'est pas transmis aux clients du camps en question, explication :
    • si une unité est invisible ou dans le brouillard de guerre, elle n'existe pas pour les client du camps adverse
    • quand elle devient visible, elle est crée est mise a jour pour les clients adverses
    • quand elle n'est plus visible, elle est détruite et n'est plus mise a jour pour les clients adverses
    • cette « technique » me permet d’économiser des envois réseaux et d’empêcher toute triche

J'utilise la version 1.6 de la SFML (juste pour préciser)

Le jeu est Full TCP (pas d'UDP), il faut regarder le protocole réseau si cela vous semble bizarre car sa marche du tonnerre !

Le programme démarre sur une Shell en SFML, pas de menu, c'est plus pratique pour tester, plusieurs commandes :
  • /help : décrit chaque commandes disponible.
  • /duplex (port) : reset les données du programme et lance un serveur puis un client, très pratique pour joueur rapidement
  • /server (port) : lance un serveur de jeu, très pratique pour spécialiser un machine comme serveur sur le réseau
  • /client (port) (IP) : lance un client et le connecte a un serveur
  • /reset : éteins le client et le serveur si ils étaient lance.
  • /msg (string) : demande au serveur de broadcast un message a tous les client
  • /stat : informe si un client ou un serveur sont en cours d'utilisation
  • /exit : ancienne commande (Alt+F4 marche mieux;) ) pour quitter le programme
  • /join (color) : prend « red » ou « blue » comme argument, sert a rejoindre un camps
  • /ip : affiche l'IP locale de la machine, très pratique pour informer les autres de l'IP sur laquelle se connecter si on héberge la partie.



Avancement (dimanche 29 juillet 2012)

  • les unités  et leurs effets actifs/passifs sont finie (enfin, je cheat encore un peu l’unité finale)
  • Tous les bâtiment et leurs effets actifs/passifs sont fait
  • Système d’évolution des unités fonctionnel
  • Système des buffs d'unités et bâtiments fonctionnel
  • Système d'attaque/soin et d'aura fonctionnel
  • Système de camouflage et aura d’invisibilité fonctionnel
  • Réseau stable est optimisé
  • Carte maximale de 255x255 cases
  • transmission et affichage des modification des HP, shieldHP et buff
  • priorité aux bouclier pour les collisions des projectiles adverses
  • Projectiles avec durée de vie et non coordonnée a atteindre
  • optimisation du rendu du brouillard de guerre

En cours :
  • Je pars 2 semaines en Angleterre, je ne pense pas que le projet avancera vite, dsl

Reste :
  • Nettoyage du code avant diffusion
    • revue de la conception globale du programme
    • rendre la partie Network générique
    • Concentrer dans des class communes les nouveaux éléments communs de manière logique
    • Séparer proprement le projet dans des fichier source nommée de manière logique
    • Séparer proprement le projet dans des répertoire nommée de manière logique

A venir :
  • HUD avec les ressources actuelles en triangles
  • HUD avec statut de l’unité sélectionné
  • HUD avec Minimap
  • représentation plus graphique de la vie et de l’état des boucliers
  • Contrôle manuel des unités
  • Véritable carte stockable et loadable

Idees a confirmer :
  • XP aux unités et bâtiments, attribution d'un grade augmentant l'efficacité
  • HUD avec explication de l’unité sélectionnée
  • nouvelle race aerienne : les "double polygon"
  • nouvelle race modifiant le terrain : les "spheres"
  • nouvelle race specialiste des debuff : les "electrons"
  • modification de la carte par certaine attaques
  • unité kamikaze
  • unité poseuse de mine
  • unité avec un tir orbital
  • unité pouvant modifier le terrain
  • unité avec tir d'attaque ou de soin rebondissant plusieurs fois
  • unité avec aura de debuff
  • unité avec aura infligeant des dégâts et laissant juste 1 PV a ses victimes
  • unité radar (différent du triangle, on sait qu'il y a quelque-chose sans savoir quoi)
  • unité avec un tir (ou une aura) ralentissant le temps des ennemis
  • unité pulsar infligeant des degats de zone tout autour d'elle
  • Carte avec élément interactifs, voir des aura fixe qui buff/debuff
  • capacités spéciales obtenu lors de certaine construction
    • balayage radar d'une zone de la carte
    • groupe d’unité clone en leurre holographique
    • bouclier géant temporaire et impénétrable
    • berzerk doublant la fréquence/puissance de tir d'un groupe d’unité
    • surproduction sans pouvoir faire de sacrifice/évolution pendant un temps
    • soin de zone sur les unités et bâtiments
  • arbre de talent modifiant les unités/bâtiments
  • unité expérimentales prenant + d'une case d'espace

Notes Diverses :
  • Le déplacement de plus de 100 unités ralentit le serveur, mettre une limite ou optimiser le pathfinder
  • prévoir ce qu'un tricheur pourra faire des infos reçu du serveur



[attachment deleted by admin]

Pages: [1]
anything