j´ai un problème avec le scénario de mon prochain jeu: www.serhum.fr.st

si vous vous sentez capable de me trouver un nouveau scénario (le jeu doit garder le meme nom !) donc l´histoire peut etre tres proche mais voila le probleme:

ce scénario est irrealisale en jeu, ce n´est pas un jeu c´est un film, et amoins kil n´y ait ke de la cinématique tout le long ce ne sera pas un jeu.

donc SVP cherchez une deviante de ce scénar et si j´accepte votre modification je la garde.
sinon vous aurez réfléchi pour rien.
je ne vous offre rien d´autre que votre nom dans le générique.

up

Ton scénario actuel, je le trouve vraiment très bon, pourquoi changer, en effet, tu risque de devoir faire pas mal de cinématiques ,surtout au début de l´ histoire(jusqu´au moment ou le mec arrive chez lui), mais tu peut les racourcir, et pour certains moments ou il n´y a pas d´action (pas d´ennemis à buter), tu n´est pas nécessairement obligé de faire des cinématiques, regarde par exemple les Resident Evil où à certains moment, il n´y a pas de cinématiques , mais des dialogues. Bon pis pour ce qu´on ait moins cette impression de film, tu n´as qu´à rallonger les moments d´action (par exemple, au lieu de faire que le mec butte trois flics depuis sa fenêtre, il peut les trouver un peu partout dans et autoure de sa maison; mais bon tout dépend aussi du genre de jeu que tu désire faire, si par exemple c´est un jeu d´ action à la première personne, tu pourait être emmerdé, prend donc plutôt un style de jeu ou tu voit le héros évoluer.Un truc que je trouve par contre qui ne colle pas vraiment, c´est le fait que tu veuille que cette deuxième partie soit un autre jeu. Pour finir, j´ai une petite question: vous utilisez quoi comme outils pour faire ce jeu?

c trop tard g deja commencé le développement depuis janvier 2002 se sera un FPS (First Person Shooter: doom like koi).
pour l´instant le seul outil que j´ai utilisé c´est "Microsoft Visual C++ 6.0 service pack 5"
et l´editeur de niveaux c´est Worldcraft (3.3 seulement).
mais Worldcraft tout seul PAS worldcraft + les compilateurs.

Oups! T´as déjà beaucoup avancé?

C quoi Worldcraft3.3 comme programme?

c´est l´editeur de niveaux d´half-life.

Ohla! je comprend maintenant mieux ton problème. Mais tu pense pas qu´en recommançant ton scénario, tu devra recommençer aussi les graphismes? Tu pourrait peut-être garder les textures, mais recommencer la modelisation avec 3dsmax (ou un autre programme de 3d) puis programmer avec Dark Basic ou en C++.

Juste une question: tu prévois quoi comme armes?

???? _dawmic_ je programme DEJA en C++ ya deja plus de 3400 lignes.
kel probleme ? mon seul probleme c ke pour un scénario de FPS il va pas y avoir bcp de jeu.
puis pour 3d max non je prefere worldcraft il est plus simple et plus rapide.
puis toute maniere c trop tard je me suis deja cassé le cul pour faire un algorithme de malade pour extrapoler les faces j´aimerait pas kil me reste sur les bras.

pour les armes, j´avais cette liste.
mais il se trouve kelle n´est plus bonne et je v devoir la refaire. mais bon je la post kan meme:

categories:

----------------------------------
sans munitions:

taille: 15 cm
poid: 400 grammes
couleur: jaune
nom: "Jouet pour chien qui fait squik."

-----------------------------------
pistolet:

marque: IMI (Israel Military Industry)
modele: Desert Eagle
chargeur: 7 + 1 balles
calibre: 12.7 mm
portée: 100 metres
longeur: 273 mm
poid: 2 kg
voir photos

-----------------------------------
shotgun:

marque: fabrique nationale
modele: police action shotgun
chargeur: 7 dans le chargeur + 1 dans le magasin
longeur: 984 mm
poid: 2.94 kg
voir photos

-------------------------------------
mitraillette:

marque: Colt
modele: M4A1 Assault Rifle
calibre: 5.56 mm
chargeur: 30 balles
portée: 1000 metres
longeur: 760 mm crosse rentrée, 840 mm sortie
poid: 2.54 kg
rafale: 700 ou 1000 balles/minute
voir photos

---------------------------------
sniper:

marque: Heckler & Koch
modèle: MSG 90
calibre: 7.62 mm
chargeur: 20 balles
poid = 6.4 kg
longeur = 1165 mm
voir photos

--------------------------------
grenade:

grenade a fragmentation classique avec goupille et explosion retardée
apres avoir laché le clapet a 4 secondes.
rayon des degats: 5 metres

J´ai pris connaissance de ton scénario, disons que vu les différents intervenants je verrais assez cette collection-là:

GIGN = mp5 A2, mp5-sd, benelli m1, PSG-1,sig Swat
armée de terre = Famas, m249 saw, hk g36.

Armes de poing = hk mark23, beretta 92FS, hardballer...

Voilà, si ca peut t´aider

en effet je suis allé voir sur le site du GIGN et ils utilisent bien des h& mp5.
toute maniere comme je l´ai deja dit la liste est a revoir fondamentalement et il est evident qu´il faut equiper les gens de leurs armes respectivent et ne pas les inventer si ont veux faire crédible.

Je dois pas etre extremement loin de la réalité là... Mais la seule chose auquel tu devrais faire gaffe c´est à ne pas mettre des trucs qui reviennent trop souvent dans d´autres jeu.

Je m´explique, ta liste semblait un peu calquée sur CS, et pour une fois qu´on verrait un jeu sans M16, M4, m14, m60 et j´en passe... CE serait bien cool

ah

ahahah g envie de rire parce ke tu as on ne peu plus raison. je sais g des modules de merde ki font 1700 lignes chacun c n´importe koi.
mais ca fait 3 jours ke je travaille sur un découpage bien plus lisible.

pour le BSP: pas question je deteste ce format je veu un BiTree ke je vais faire moi meme.
je reflechi en ce moment a un Hidden Surfaces Removal (l´equivalant de HlVis.exe, pour les ZHLT et vis.exe tout court pour les calssiques)
mais moi je ne vais pas proceder par CSG union comme il le font car ca peu ajouter bcp de polygones en particulier si la face "disque" d´un cylindre touche une surface plane.
je vais juste enlever les petites faces ki sont contre des plus grandes ki les englobe sans partager la plus grande comme le font les ZHLT.
c´est pour ca ke g appelé mon algo un HSR et pas un CSG union.

mon jeu n´est pas fini et la en effet pour le moment tout est affiché comme tu le dis.

10 polygones ? non non essaie la map essai2.brut elle en contient 6700 dans mon souvenir et ca rame pas trop, DirectX est kan meme assez optimisé pour afficher sans ramer 10000 polygones.

je vais tout de meme tenter de faire un Potentialy Visible Set grace a mon BiTree ce qui pourrait permettre de ne pas afficher les secteurs invisible depuis chacun des secteurs mais ca me semble tres compliké a trouver et je crois ke je pourrai pas le faire.

et encore apres ca c pas fini il faut calculer l´eclairage et la ca devient interressant parce ke ma technique va fonctionner a peu pres comme les ZHLT mais en plu simple.
je vais créer des lightmaps (texture en 32*32 par exemple etirée en 5*5 (par exemple) pour avoir une basse resolution) et faire un rayon a partir de caque texel de la lightmap ki va vers chacune des lampes, detecter la collision l´angle et la distance et calculer le niveau d´eclairage pour cacun des texels. le calcul sera direct il n´y aura pas de rebonds donc pas de radiosité (bcp trop compliké ! !) contrairement a half life.

et apres ca il faudra faire la detection des collisions la aussi je vois pas comment faire g cherché milles fois il va falloir ke je tente avec l´elipsoide si je ne trouve encore rien.
j´aimerai mieu utiliser une boite englobante mais ca fait des mois ke j´essaye de trouver le calcul de detection de collision entre 2 polygones convexes et c trop chaud, meme ma prof de math a dis ke c t compliké, je vais surement pouvoir faire une approximation mais c un peu nul il va falloir ke je change de technique. toute maniere c pour dans longtemps et g le temps d´encore relfechir.

changement d´auditeurs: je m´addresse mmaintenant a tout les gens ki se disent "amateur" et ki veulent 100 milles personnes pour faire un jeu et ki pense ke ca sera leur jeu alors kils ont juste trouvé le scénario, et bien si vous avez lu tout ca vous pouvez peut etre comprendre 1/100eme de ce k´est la véritable création de jeux !

@#; Lightness1024!

1. include <iostream.h>

class moi
{
protected:
UINT age;
public:
void moi (void);
UINT GetAge (void);
void SetAge (UINT age);
};

void moi::moi(void)
{
age = 0;
}

UINT moi::GetAge (void)
{
return age;
}

void moi::SetAge (UINT age)
{
this->age = age;
}

int main(void)
{
moi Moi;
moi.SetAge (18);
cout << moi.GetAge() << endl;
return 0;
}

oula oula, je suis d´accord pour la notation hongroise mais attention les definitions des fonctions membres au sein meme de la déclaration de la classe c carrément moche.
utilise plutot l´ORP comme moi..
ma seule erreur c ke g mis un void devant le constructeur

Moi je trouve que c pratique et moins encombrant d´inliner les fonctions courtes directement dans la classe.

Enfin après c´est un peu une question de gout.

"ma seule erreur c ke g mis un void devant le constructeur"

Ah non, t´as fait une erreur de casse aussi :

int main(void)
{
moi Moi;
moi.SetAge (18); // t´aurais dû mettre Moi.Set...
cout << moi.GetAge() << endl;
return 0;
}

(bon Ok j´arête de chipoter

attention tu m´offenses la.
la classe c moi ki l´ai tapée en premier.
je sais tres bien ce que c´est qu´un accesseur et un mutateur. de plus les gros projets je les ait deja attaqué Projet SERHuM en est l´objet !
mais les fonctions définies dans la classe ne sont pas inlinées, il faut les déclarer inline pour ca.
je préfere avec l´Operateur de Resolution de Portée kan meme ta raison on ne discute pas l´égout. et autre chose on perd ke tre legerement de vitesse avec si la fonction n´est pas inlinée et on peu ratraper la pertes en passant des pointeurs.