@criket : Visuel très stylé, curieux de savoir comment tu t'y es pris. Par contre utiliser un Master Spark sur un youkai minable de forest of magic ? Un gros gâchis de SP moi j'vous l'dis.
@daheji : Mon préféré. J'adore ton style. J'étais tombé dessus par hasard sur deviantART il y a des mois et j'ai décidé depuis d'en faire mon écran de Loading (j'ai coupé le bas et donc la signature mais je t'ai rajouté dans les crédits pour compenser ).
@Ephy : Respect pour l'originalité. Pour un ancien adepte de danmakufu comme moi, cet award prend tout son sens.
Estheone - posté le 04/06/2013 à 19:58:45. (312 messages postés)
Citation:
En revanche, là où je bloque, c'est comment notifier le click au joueur.
Le top de mon point de vue ça serait une combinaison des 2 premières solutions, à savoir une anim sur la case au moment du clic et la case en rouge jusqu'à ce que le joueur soit dessus.
Citation:
Ca fait beaucoup d'interface, et j'avoue que j'ai beaucoup de mal à trouver un équilibre entre visibilité de la carte, et interfaces. Tout en restant lisible
Tu pourrais envisager de changer la résolution de ton jeu genre en 800x600. Ca nécessite de faire des menus adaptés évidemment mais vu ton ambition pour ce projet ça devrait pas te faire peur.
Estheone - posté le 30/05/2013 à 00:27:34. (312 messages postés)
Fais pas trop attention aux remarques acides, l'ambiance est tendue sur Oniro ces derniers temps (est-ce lié à la pluie depuis des mois ? à yurina ? va savoir ^^).
Tout ça a l'air intéressant et bien plus original que la moyenne des projets.
Ton système de jeu va nécessiter de grosses modifications dans les scripts d'origine, mais bon si tu sais programmer, que tu es motivé et que tu as du temps, je ne vois rien d'insurmontable.
Bref, bon courage et n'hésite pas à faire un tour dans la section entraide si tu as besoin d'un coup de pouce.
Estheone - posté le 29/05/2013 à 01:50:10. (312 messages postés)
@Widoo : Le problème vient bien de là mais c'est plus compliqué que ça, il faut quand même que l'xp et les levels accumulés par les techniques restent sauvegardés.
#==============================================================================# ** Scene_File#==============================================================================class Scene_File
#--------------------------------------------------------------------------# * Alias List#--------------------------------------------------------------------------alias gbp_dsls_sf_wsd write_save_data
alias gbp_dsls_sf_rsd read_save_data
#--------------------------------------------------------------------------# * Write Save Data# file : write file object (opened)#--------------------------------------------------------------------------def write_save_data(file)
gbp_dsls_sf_wsd(file)
skill_data ={}for i in0...$data_skills.sizenextif$data_skills[i].nil?
skill_data[i]=[$data_skills[i].exp,$data_skills[i].level]endMarshal.dump(skill_data, file)end#--------------------------------------------------------------------------# * Read Save Data# file : file object for reading (opened)#--------------------------------------------------------------------------def read_save_data(file)
gbp_dsls_sf_rsd(file)
skill_data =Marshal.load(file)for i in0...$data_skills.sizenextif$data_skills[i].nil?
if skill_data[i]$data_skills[i].exp= skill_data[i][0]$data_skills[i].level= skill_data[i][1]endendendend#class
Avec ça ton pote devrait pouvoir créer des nouvelles techniques et modifier ces anciennes tout en conservant les gains d'xp et de level sur ses sauvegardes (évidemment ça ne marche qu'à partir de maintenant, toutes les sauvegardes avant l'intégration de cette modif sont bonnes à jeter).
Après j'ai pas regardé en profondeur le script, il y a peut-être d'autres variables qui doivent être conservées. Faudra faire d'autres modifs dans ce cas.
Estheone - posté le 27/05/2013 à 20:13:36. (312 messages postés)
%dégats élémentaires ET dégats élémentaires fixes, pourquoi pas.
Par contre %résist élémentaire et resist élémentaire fixe ça commence à faire beaucoup.
Tu pourrais envisager une seule stat de resist qui fonctionne comme ça :
(2) => (1)^^2 / ( (1) + resist )
En gardant ton exemple précédent des 50 dégats :
- avec 0 de resist eau ça donne 2500/50 soit 50 dégats (100% des dégats d'origine, logique)
- avec 25 de resist eau ça donne 2500/(50+25) soit 33 dégats (2/3 des dégats d'origine)
- avec 50 de resist eau ça donne 2500/(50+50) soit 25 dégats (1/2 des dégats d'origine)
Bref, ça donne un juste milieu entre le fonctionnement par % uniquement et la réduction de dégats par soustraction.
J'ai déjà vu des jeux pros qui fonctionnaient avec ce genre de formules pour les dégats élémentaires.
Mais hé, c'est ton jeu, c'est toi qui vois.
Je trouve juste que ça fait beaucoup de données à prendre en compte en tant que joueur. ^^
Estheone - posté le 27/05/2013 à 17:17:47. (312 messages postés)
Je déconseille les formules trop simples dans le genre de attaque_base * bonus - défense ennemie, c'est le meilleur moyen d'avoir une stat de défense trop efficace en début de jeu et quasi inutile en fin de jeu.
Personnellement je privilégie les formules assez complexes mais dont les variables sont visibles par le joueur et assez faciles à comprendre.
Pour la défense j'ai tendance à m'en servir dans un coef qui n'est pas lié à la puissance de la technique mais uniquement à la stat d'attaque de l'adversaire.
Genre coef_atk = atk/(atk/def).
Puis total_degats = formule_degats*coef_atk.
Ca permet d'uniformiser l'efficacité de la défense sur toutes les techniques d'un même adversaire.
Et comme dit verehn attention aux gros nombres, ça devient rapidement hors de contrôle.
Estheone - posté le 27/05/2013 à 00:35:37. (312 messages postés)
Citation:
Et retour de Sakuya omg omg en perso jouable.
Quel copieur ce ZUN. Les mêmes persos jouables que dans Wandering Souls. [/megalo]
1cc normal aussi. J'ai tenté en hard mais le last boss est plus de mon niveau, j'étais en spammage de bombes en permanence.
J'ai pas testé toutes les versions de perso mais pour l'instant Reimu A est ma préférée.
Les mécaniques de jeu ont l'air assez simples comparé à UFO et TD et je trouve ça pas plus mal.
Estheone - posté le 23/05/2013 à 20:07:50. (312 messages postés)
J'ai une légère préférence pour le 3 même si le 2 est excellent lui aussi. J'ai l'impression que le style chibi du 1 et du 3 s'intègre mieux aux décors que le 2.
En tout cas la patte graphique est vraiment impressionnante.
Bon courage pour la suite !
Estheone - posté le 10/05/2013 à 07:23:54. (312 messages postés)
Il faudrait rajouter un self.opacity = 160 dans l'initialize des fenêtres concernées.
Mais bon d'origine il n'y a que du noir derrière le menu donc à moins d'y rajouter quelque chose ça ne sert à rien.
De plus, quelques-unes de ces fenêtres servent plusieurs fois (Window_Command par exemple est utilisée pour l'écran-titre et les combats aussi) donc la modif d'opacité s'appliquerait aussi dans ces cas là.
Estheone - posté le 09/05/2013 à 23:23:56. (312 messages postés)
Citation:
juste les lignes de code qui permettent de changer le windows-skin quand on entre dans "équipement"
Je t'avais déja donné la ligne pour changer le skin des messages, il te suffit de faire pareil dans l'initialize des classes Window_EquipLeft, Window_EquipRight et Window_EquipItem.
Estheone - posté le 09/05/2013 à 23:20:12. (312 messages postés)
Je tiens pas à te décourager mais tu te lances dans quelque chose de très compliqué.
Greffer correctement de nouvelles classes qui concernent les statuts nécessite de comprendre le fonctionnement global du système de combat de base de RMXP, avec toutes les classes qui y sont associées.
Rien que pour ton système de heal sur la durée il va falloir faire de profondes modifs sur Game_Battler et Scene_Battle.
Mais bon si tu tiens vraiment à te lancer là-dedans, je te conseille de commencer par voir le fonctionnement de base des tics de poison en faisant une recherche globale dans les scripts (ctrl+shift+f) avec slip_damage.
Tes classes de tic sont liées à chaque combattant donc je pense que tu devrais créer les instances à partir de Game_Battler (un peu comme pour la classe Game_BattleAction).
Tu vas aussi rencontrer de sérieux problèmes pour l'affichage des tics, le système d'origine est incapable d'afficher 2 nombres de dégats sur un perso en même temps (c'est la classe RPG::Sprite qui n'est même pas visible dans l'éditeur de scripts, mais tu peux y accéder à partir des fichiers d'aide).
Par contre les stats vont augmenter de manière linéaire selon les valeurs que tu mets dans les tableaux pour le niveau 98 et 99. Par exemple si il y a 6 de diff pour la force entre le 98 et le 99, ton perso gagnera 6 de force entre le 998 et 999 aussi.
Si tu veux faire une sorte de courbe il faudra rendre la formule plus complexe.
Note aussi que j'ai mis 999 en niveau max mais tu peux mettre bien plus si ça te chante.
Estheone - posté le 23/04/2013 à 11:18:06. (312 messages postés)
Citation:
Utilisation normale = picture viewport2
Appel en script = picture viewport1 avec z = 2
Les sprites des pictures sont initialisés à l'avance donc je suis pas convaincu que tu puisses changer leur viewport par la suite.
En revanche tu peux toujours modifier la façon dont ils sont initialisés pour en avoir sur le viewport 1 et d'autres sur le 2 :
for i in1..25@picture_sprites.push(Sprite_Picture.new(@viewport1,$game_screen.pictures[i]))endfor i in26..50@picture_sprites.push(Sprite_Picture.new(@viewport2,$game_screen.pictures[i]))end
Citation:
si je veux faire 2 intervalles, je fait comme ça ?
Estheone - posté le 23/04/2013 à 11:00:40. (312 messages postés)
Normalement avec un z de 99999 ou un truc comme ça ton image devrait être au-dessus de n'importe quel tile et même au-dessus des fogs, du coup je sais pas quoi te dire.
Estheone - posté le 22/04/2013 à 12:56:53. (312 messages postés)
J'ai vu des lolis en petite tenue que c'était fait avec danmakufu donc j'ai eu envie d'essayer.
C'est pas mal, on sent qu'il y a du boulot derrière, surtout quand on connait le logiciel utilisé et ses limites (les menus sur danmakufu... ).
La difficulté est progressive et plutôt bien géré même si l'ensemble est vraiment facile pour quelqu'un qui a déjà un peu d'expérience dans les danmakus (fini le jeu au premier essai ).
Le coup des cartes à détruire est sûrement le plus intéressant vu qu'il force le joueur à se déplacer sur l'ensemble de la zone disponible au lieu de se contenter de micro dodging.
Quelques patterns bien sympas aussi, même si la plupart sont assez basiques.
Par contre le plus gros défaut du jeu c'est qu'on se fait tuer instantanément dès qu'on monte trop haut, j'ai perdu 2 ou 3 vies juste à cause de ça. Et aussi on rez trop haut et donc si on descend pas dans les 2 secondes on se refait tuer direct. Mais bon je suppose qu'il n'y a pas moyen de bloquer le joueur...
Bref, ça casse pas trois pattes à un canard mais c'est un petit jeu sympa pour s'initier au danmaku sans trop de sueur et de larmes.
def process_ok
if current_item_enabled?
if index ==0
Audio.se_play("Audio/SE/NomDuSon",100,100)else
Sound.play_okend
Input.update
deactivate
call_ok_handler
else
Sound.play_buzzerendend
et règle le son comme tu veux à la ligne Audio.se_play.
Avec ça tu peux bloquer/débloquer le mouvement de la caméra selon les déplacements du héros à tout moment avec l'interrupteur en question.
Le défilement via la commande faire défiler la carte fonctionnera même avec l'interrupteur activé.
Estheone - posté le 12/04/2013 à 22:30:00. (312 messages postés)
Tu as bien mis le tag <one animation> dans la note de la technique ?
Chez moi je vois clairement la différence.
Ca fait l'animation sur chaque ennemi d'abord puis le calcul des dégats après.
COMMANDS =[:item,# Opens up the various item categories. Default.:weapon,# Opens up the various weapon categories. Default.:armor,# Opens up the various armour categories. Default.:key_item,# Shows a list of the various key items. Default.:gogototori,# Requires Kread-EX's Go Go Totori Synthesis.:custom1,# Custom command 1.# :custom2, # Custom command 2.]# Do not remove this.
Dans le tableau en-dessous tu peux choisir le nom qui va s'afficher (disons Bestiary) :
Et évidemment tu règles MENU_COMMAND sur false dans le script du bestiaire pour ne pas qu'il soit accessible depuis le menu de base.
Tant que tu y es, ajoute un Input.update à la fin de la fonction execute_loop de la classe Monster_Book, sinon tu vas carrément sortir du menu objet en faisant annuler à partir du bestiaire.
Estheone - posté le 11/04/2013 à 21:05:56. (312 messages postés)
C'est dans la fonction update_transfer_player de Scene_Map.
Tu peux modifier les nombres entre parenthèses de fadein, Graphics.wait et fadeout pour réduire la durée de la transition. Ou carrément virer les lignes pour obtenir une transition instantanée.
Estheone - posté le 11/04/2013 à 18:42:48. (312 messages postés)
Il y a plusieurs problèmes qui vont se poser donc tu vas devoir faire plusieurs modifs importantes.
Déjà, les images et les charas ne sont pas sur le même viewport d'origine, donc même en mettant à l'image un z négatif il sera toujours au-dessus du héros.
Dans l'initialize du Spriteset_Map, remplace :