Page 1 sur 2

[PROJET] Biblic Rage

Publié : lun. 27/sept./2004 12:28
par BuCkSh0t
Voila,j'ai decouvert le Pure basic il y a de sa 5 jour.
Comme j'ai deja des bases en prog# surtout dans le basic et le visual basic je me suis dit "Mon bon BuCkSh0t tu vas pouvoir realiser le truk ke tavais toujour eu envie de faire"

c'est a dire : Biblic Rage


Un truc bien gore,violent et stylé en 2d....

Résumé
---------
Je voudrais faire le jeux basé sur un pretre....oui mais attendez partez pas....c'est pas n'importe qu'elle pretre,c'est plus un pretre genre "Le justicier" plutot que celui de "sept a la maison"


Du style du héro de Blood si vous voyez,Longue cape noir a la matrix,2 gun dans les mains et qui extermine du paiens a coup de shotgun et de crucifix...

Mais j'hésite sur quelque points :

[1] je le fait en 2d mais j'hesite entre une vude du dessus ou une vue a la mario...
[2] Le scrolling je connais deja un peu mais pas le scrolling qui suit ce que fait le personnage(genre j'avance le decor avance,je marrette le decor se fige)
[3] Comme il n'y a pas encore beaucoup de tutos sure le pure,dois-je me contenter d'imprimer les sources pour les comprendre ou existe t'il des livre(peut propable) ?
[4] Me conseillez vous de faire d'abord d'autre truk (genre pong,space invader) avcant de me mettre a un projet de grande envergure ?

[5] Tout simplement merci d'avance


Image

Publié : lun. 27/sept./2004 13:20
par Thyphoon
Salut

Il existe plein de tutorial pour le pure basic fait une recherche sur le forum il y a quelques adresses de site avec plein de code a étudier !
ou vas sur www.purebasic.com et regarde les liens qu'ils donnent

pour ton scrolling voici un peu comment faire c'est du vite fait et de la théorie

Code : Tout sélectionner

widthscreen=800 ; la resolution horizontal de ton ecran
WidthDecor=8000 ; la resolution horizontal de ton decore

Et par exemple ton perso doit  être a la position Xperso=2000

pour afficher ça et bien

XDecor=Xperso-Widthscreen/2
if Xperso<Widthscreen/2 
  XDecor=0
Elseif Xperso>WidthDecor-Widthscreen/2
 Xdecor=WidthDecor-Widthscreen/2
Elseif

Affiche decore au coordonnée XDeco_temp=0-XDeco
Affiche ton perso au coordonée XPerso_Temp=Xperso-XDeco


Affichele decore au coordonée Xdecor
Affiche ton perso au coordonnée (Xperso-Xdecor)

voilà j'éspère que tu aura compris le principe !!! :P si quelqu'un voit que je dis une bêtise qu'il n'hesite pas a me corriger :lol:

Et perso je te conseille de commencer par ton projet ! d'abord tu commence par voir comment on ouvre un screen ensuite afficher une image ou un sprite etc... c'est comme ça qu'on apprend le mieux :P

Publié : lun. 27/sept./2004 14:14
par BuCkSh0t
Sympa,merci...


Je tiens vraiment a ce projet...

Du coup je drvrais l'avoir fini d'ici 5-6 mois

Sinan c'est que je suis mort ou que j'ai ete absorbé dans un vortex transdimensionel :drinking: :drinking: :drinking:

Publié : lun. 27/sept./2004 15:10
par Le Soldat Inconnu
Pour le scrolling, j'ai fait un exemple ici :
http://purebasic.hmt-forum.com/viewtopi ... =scrolling

Publié : lun. 27/sept./2004 16:25
par Oliv
En règle générale surtout si tu débutes, fais une recherche sur le forum il y a des chances d'avoir. Sinon vas sur http://forums.purebasic.com les codes son pareils en anglais comme en français. Et pis histoire de faire un peu de pub, va voir mon site :D . Sinon pour la question [4] je te conseille la vue comme Mario car j'adorre ça mais je pense que c'est un peu plus difficile que la vue de dessus enfin c'est pas sur

Publié : lun. 27/sept./2004 17:10
par comtois
Polux a fait un site dédié au jeu sur Purebasic , c'est tout beau , c'est tout neuf , mais tu pourras déjà y trouver quelques tuts .

http://perso.wanadoo.fr/darkprograms/pbtutorial/

Publié : lun. 27/sept./2004 17:23
par BuCkSh0t
merci a vous ....

Mais je pense que je vais separer ca :


Je vais d'abord faire un pitit jeux,pour m'habituer o -_Pure_- genre un jeu de navette....


Et apres je serais mature pour

Publié : lun. 27/sept./2004 18:13
par Oliv
Pas contre je sais pas si je suis le seul mais je trouve que ta signature (l'image) qui prend la moitié de la page c'est plutot embêtant, pourrais-tu la réduire ? Merci.

Publié : lun. 27/sept./2004 18:19
par BuCkSh0t
va te faire..... loooolllll


Bien sur pas de prob...si dotre personne trouve ca chiant je le virerais


:cry: tant de temps pour le faire et snif.....personne ne laaprecie :cry:

Publié : lun. 27/sept./2004 19:33
par Le Soldat Inconnu
Oui, j'allais faire la même remarque Oliv.
donc merci de la réduire. la taille d'un bandeau de pub (468*60) sera accepté mais pas plus.
Sinon, je la supprimerai, tout simplement.

Publié : lun. 27/sept./2004 19:44
par BuCkSh0t
ok ;)

Publié : lun. 27/sept./2004 19:45
par BuCkSh0t
Bon tant pis,ca ne vas pas quand je reduis le truk


Donc je le vire

Publié : mar. 28/sept./2004 18:07
par Patrick88
document en anglais (désolé)

Finishing a Full Game

Michael Labbe
July 31st, 2004

Games can be big business, but they can also be a hobby. Quite a few people build games on their own time. And why not? Making games can be fun.

Sadly, the majority of hobbyist games never reach a completed state. Some may be playable, but most are not. Even if the author had the best intentions going in, the games never even reach beta status most of the time.

This article takes a look at how to choose an achievable scope and examines the hobbyist game developer's most common pitfalls.
The Steps

Technically speaking, creating a game can be summarized by a three step process.

First, you must adopt or create supporting routines to take care of mundane tasks such as image loading, memory management and joystick initialization.

Second, you build art assets for your game. You need at least placeholders before you proceed.

Finally, you have the sound basis required to develop your game. This is the time to write your gameplay code and build your levels, generally speaking.

The funny thing is, the majority of games never get past the first stage. Too many developers visualize technical perfection and see it as an achievable milestone early in their game's development, which brings us to pitfall #1:

Pitfall #1: Refactoring your tech when it is good enough.

I don't care if money isn't a factor, you're still trying to beat the clock. Instead being handed a deadline, the race is psychological. You're trying to get the game done before your ideas become tired and boring to yourself and you feel compelled to start something new.

You need to get through technology development as quickly as possible. If you disagree with this statement, you care about something else besides finishing your game. This is a conflict of interest, and you need to sort this out before dedicating your time to your game.

The best programmers know when to stop refactoring and when to deliver without relying on outside forces to force them forward.

Pitfall #2: The almighty pipeline.

When working on a commercial game, a decent producer will learn the costs of building content for a given technology. This is factored in when evaluating the developing team's proposals. This is the content production pipeline, and every game has one. Commercial games have massive pipeline requirements which become even more insurmountible with every passing console generation.

So then, why would it make sense to make your technology mimic the hottest thing from Id Software? Even if you were able to conjure up an engine on par with Doom 3's (and you aren't going to without a team sanity checking your work by creating a game in parallel) you'll never be able to produce enough content to make your endeavor worthwhile. This doesn't seem to stop a shocking number of would-be game developers who get caught up creating content for a pipeline that is not designed for the people who will be developing in it.

Critically examine every feature before implementing it. Scrolling means more content is necessary. Ogg Vorbis means you're playing music for ears attuned to quality production values. Multiplayer means having to carefully manage arcane game states. (What were you planning on doing when client 3 is unacked-disconnecting on client 1 and disconnected on clients 2 and 4?) Were you planning on testing your fallback DX5 software rasterizer on Matrox cards before release?

Some features cause your pipeline to bloat, and some make life a little easier. Orion, Frogtoss's tech, has remote debug logging. It does not have bump mapping. If you can, place higher priority on features which make life easier, not harder. Game development is tough enough.

Don't build your pipeline by accident. Build it by design.

Pitfall #3: Non-commital Componentization

I can't count the times I've walked in the door at 8 in the morning, to find a bleary eyed programmer leaning back in his chair, with a satisfied look on his face. "No component depends directly on any other component." He then fires up his build of the game, and I watch a 60% complete implementation of the feature whiz by.

While it may be good practice to not shove DirectDraw code into your game logic, encouraging extreme componentization behooves the fact that you will most likely be compelled to throw away the majority of your code on the next game anyhow. You're probably using C++, which means you already have the annoyance of declaring function prototypes. Defining interface or intermediary classes increases the time necessary before you get results. Standardize and organize when you know you've got something cool. That could possibly mean waiting until the second game before defining your generic interfaces if you must at all.

With Orion, we have a core library subset which we unabashedly depend on throughout our codebases. There are satellite "toolkits" such as the interface or networking components. These still depend on the core library, but not on each other, and the dependency is only one way. I can #if 0 out the networking toolkit and the rest of the engine will continue to function. Not sexy, but it gets the job done.

Pitfall #4: Exploration Games

The last sign of big budget game envy: exploration games. Exploration games are the underlying design direction in some of the most successful titles out there. It is also the cornerstone of big budget single player titles: consumption of content.

Rather than have your users consume content for fun, pick a gameplay idea that works in a small play area. A few years ago, I would have recommended a puzzle game, but that genre's pretty well sewed up.

Please do not attempt to make Metroid Prime, or Wind Waker. While they are wonderful games, you cannot create a spiritual sequel to either on weekends.
Summary

The majority of hobbyist developers imitate big budget development houses. This is an insane undertaking. Independent movies don't have big explosions and million dollar effects; they focus on strength areas like plot and storyline.

In my opinion, games do not have a successful and vibrant independent underground movement like movies and music. There are no largely successful independents left for beginners to look up to. As a result, the developers bite off more than they can chew and the work is never completed.

Ultimately, pragmatism is the only thing that matters. If you follow another God, your path may never lead to a finished product.

Publié : mar. 28/sept./2004 18:11
par Heis Spiter
T'es quand même un peu dur de la compronette ;)
LSI a écrit :donc merci de la réduire. la taille d'un bandeau de pub (468*60) sera accepté mais pas plus.
Et tu nous met un beandeau 600*100 :lol: Bouarf, ça va mal se finir ça ;)

Publié : mar. 28/sept./2004 19:23
par BuCkSh0t
moi.....nan j'ai pas de bandeau :p