aiuto programmazione videogioco [Archivio]

erdice

07-09-2009, 17:43

_Claudio

07-09-2009, 18:01

wingman87

07-09-2009, 18:32

Penso che in giro per internet si trovino dei programmi per creare giochi di questo tipo, io ho cercato un po' e ho trovato questo, prova a dargli un'occhiata: LINK (http://www.adventuregamestudio.co.uk/)

^TiGeRShArK^

07-09-2009, 18:46

...tra 120 anni...:D

ottimista... :O

PGI-Bis

07-09-2009, 19:11

Monkey Island non era un punta e clicca? Se sì più che 120 anni direi 120 minuti.

^TiGeRShArK^

07-09-2009, 19:38

Monkey Island non era un punta e clicca? Se sì più che 120 anni direi 120 minuti.

era IL punta e clicca per eccellenza. :O
A te l'onore di farlo in 120 minuti in C++. :asd:

_Claudio

07-09-2009, 19:44

...tra 120 anni...:D

Appunto. Ecco perchè il primo consiglio era di "comprare" un programmatore...

PGI-Bis

07-09-2009, 20:40

Dio mio un punta e clicca signori non è mica rocket-science. Definisci le aree, carichi le immagini, due o tre transizioni e sei a posto. Puoi farlo anche in 3D in cinque minuti.

Y3PP4

07-09-2009, 20:50

salve a tutti,

vi chiedo gentilmente di aiutarmi per un progetto che ho in mente. io e alcuni amici vorremmo creare un viodegioco in stile Monkey Island. abbiamo il disegnatore, le idee sono già tutte scritte, ma non sappiamo nulla di programmazione. Dato che da ignoranti di questo argomento crediamo non sia una cosa troppo difficile, lo volevamo sapere da voi!
se è una cosa fattibile, di quale programma abbiamo bisogno? e dove possiamo trovare una guida per questo eventuale programma?

vi ringraziamo in anticipo.

Edoardo

Programmi esistono, per progettare giochi 2D e alcuni anche per i giochi 3D. Molti sono ovviamente sotto licenza. Per i 2D esiste anche il noto Game Maker (http://it.wikipedia.org/wiki/Game_Maker).

Se le idee sono tutte scritte bisogna organizzarle. Per lavorare in un team quanto meno decentemente - suppoendo anche solo poche persone - bisogna che l'idea sia la stessa per tutti. Tanto più che non è un progetto che frutta denaro le persone vengono quando han voglia, quindi ti sfido a spiegare a tutti tramite msn o anche a voce tutto il progetto. Già una volta sarebbe stressante, se poi devi ripetere l'operazione per ogni membro che si connette in seguito, fidati, ti passa la voglia. Le idee anche se son già scritte ma non organizzare non servono a nulla. Le capisci te che hai l'idea del progetto completo ma non gli altri. Se in un file trovi: "livello delle scimmie" -> uccidere tutte le scimmie in X minuti e in un altro "livello dei pesci" -> pescare tutti i pesci in Z minuti, sò che hai in mente questi livelli ma non sò quale viene prima, non ho idea dei dettagli, di come nella storia arriva Tizio ai livelli, di come interpretare una eventuale relazione tra i livelli - anche semplicemente una comparazione del livello di difficoltà... in base a cosa decido il tempo a disposizione? Qual'è la relazione tra il livello precedente e quello successivo in termini di difficoltà-numero nemici /tempo ?-

Una volta che sarai certo di dare a tutti la stessa idea inizia pure lo sviluppo. Per un lavoro decente anche il GM richiede studio. Lo sviluppo non è immediato, logicamente. Se comunque credi di poter fare un buon lavoro con il solo programma sbagli. Si usano parecchi script esterni. Anche quelli a pagamento, realizzano qualcosa ma per lavori di un certo livello la mano del programmatore ci vuole.

Questo per giochi semplici, per quelli che siamo abituati a vedere per PC o console sono tutt'altra storia.

Ciao.

Tommo

08-09-2009, 09:05

Altrimenti per cose semplici c'è Multimedia Fusion che è un tool di game dev del tutto "punta e clicca" che non richiede nemmeno una riga di codice, e ha l'editor dei livelli incorporato.
Per un'avventura grafica potrebbe andarvi di lusso, però si paga.

Devo dire che tante cose a saper programmare si fanno prima scrivendo che cliccando, ma partendo da 0 è un programma simpatico ;)

M4rk191

08-09-2009, 10:22

http://sparcs.kaist.ac.kr/~lacrimosa/ds/c++/The%20C++%20Programming%20Language%203rd%20Edition/3rd_front.jpg

oppure questo, che ho appena letto :ave: :ave:

http://www.codinghorror.com/blog/images/the-c-programming-language.png

devi anche tenere conto delle librerie grafiche OpenGL, Direct X, etc.

diciamo che fra 2-3 anni ce la fate a scriverlo il gioco

banryu79

08-09-2009, 12:27

Quoto: se si sta a zero dal punto di vista della programmazione e si vuole scriversi da se' i sorgenti del proprio gioco, il tempo in ballo non è poco.
Dovete mettere in preventivo:
- tempo per imparare il linguaggio di programmazione da usare;
- tempo per imparare a usare in modo familiare e rapido l'ambiente di sviluppo con il quale si programma;
- tempo per imparare le librerie di utilità basilare per quel linguaggio;
- tempo per imparare i concetti specifci delle specifiche astrazioni/tecnologie coinvolte nell'implementazione del gioco, viste dal punto di vista del linguaggio di programmazione scelto (oltre le relative librerie);
In tutto parlo di mesi, non di settimane.

Certo, concordo con PGI che bastano 120 minuti, per uno che alle spalle ha anni di esperienza in questo mondo, e l'unico tempo da spendere è quello della pura digitazione dei caratteri componenti il codice sorgente, tramite la tastiera.

Per chi invece parte da zero, resto sempre dell'idea che ci voglia un pasto di tempo, e che possa anche capitare di stancarsi molto prima di vedere una fine tangibile per l'implementazione del gioco.
Perchè per programmare non basta la conocenza del linguaggio, ma del supporto di tutta una pletora di conoscenze di contorno, che, dopotutto, semplicemente "di contorno" forse non sono (se si parla di implementare qualcosa di non banale).

Se parti da zero e ti scegli C++, passi le prime settimane a fare a pugni con i puntatori e le allocazioni della memoria, come fate a dire che per chi è digiuno di tutto questo basta pochissimo tempo per mettere in piedi un gioco punta e clicca in C++ funzionante?
Cioè qui qualcuno la racconta storta: o sono io che sono troppo ignorante e incapace e la vedo anche più oscura di com'è o qualcuno si è scordato di mettersi nei panni di un wanna be programmatore che comincia quello che, per chiunque, è un lungo cammino...

shinya

08-09-2009, 12:52

Se oltre a creare un clone di Monkey Island vuoi anche sentirti come uno degli sviluppatori originali puoi usare SCUMM e far girare il tuo gioco su questo...
http://www.scummvm.org/
:)

marco.r

08-09-2009, 13:21

Se oltre a creare un clone di Monkey Island vuoi anche sentirti come uno degli sviluppatori originali puoi usare SCUMM e far girare il tuo gioco su questo...
http://www.scummvm.org/
:)

Era quello che stavo suggerendo io, ma poi ho dato una occhiata e mi sembra che non ci sia molta documentazione su come scriversi i giochi per la SCUMM :P.
Pero' ci sono prodotti simili anche gratuiti nati proprio per la creazione di avventure grafiche 2d... e' una scelta che potrebbe portare a risultati in tempi abbastanza rapidi

M4rk191

08-09-2009, 13:44

fero86

08-09-2009, 14:06

perché consigliate tutti solo il C++? forse sarà obsoleto, ma conosco solo il C per adesso, e non trovo limitazioni. L'approccio OOP e la divisione in classi, imho, è meno intuitivo della divisione in funzioni :stordita: non siete d'accordo? il C++ offre costrutti che permettono di scrivere molto meno codice per fare le stesse cose. inoltre se si sa scrivere bene in C++ é raro che ci si debba preoccupare di memory leaks ed in generale di resource leaks, invece in C stai sempre con l' "affanno" di dover chiamare la free o chi per lei in ogni possibile caso.

comunque io eviterei di partire dal C++ viste le condizioni: andrebbe sicuramente meglio Java o C#.

Tommo

08-09-2009, 14:24

IMHO avete una visione a dir poco parziale dello sviluppo di un gioco, senza offesa...

primo: non appoggio per niente la fissa col C++ di questo thread.

Chiaramente l'autore del thread non è interessato alla programmazione; è interessato all'aspetto artistico e narrativo del gioco, con buona pace degli smanettoni che in un gioco vedono solo le righe di codice ;)

secondo: la parte più complessa di un gioco, quella che fa perdere tempo, NON E' il codice. Mai. Specie con l'esperienza.
E' al contrario la gestione del team, dei contenuti, del gameplay e di tutti quanti i tools necessari alla loro gestione...
Quindi pensare che un gioco sia contenuto nel suo codice è quantomeno romantico: voglio vedere se nei 120 minuti di PGI bis ci sta anche il tempo necessario a fare l'editor delle cutscenes, quello delle animazioni quello del.... eccetera.
Senza contare la teoria che c'è dietro un gioco anche solo 2D (image processing, rotazioni, collisioni, animazioni, ecc) che di certo non la insegnano insieme al C++.

Per cui sebbene io ami il C++ all'autore del thread consiglio Multimedia Fusion o simili, che permettono di concentrarsi sull'aspetto ludico del gioco, fornendo tutti quanti gli strumenti ben integrati e "predigeriti"... per dire, ci ho sviluppato giochi simpatici a 14 anni :asd:

Altrimenti a voler salire di difficoltà consiglio PyGame o un'engine basata su XNA, o magari Flash (che permette far apparire il tutto su internet).

C++ insieme a una buona engine 2D già fatta potrebbe anche andare, ma dubito che uno che non ne sa niente sappia usarla questa engine, per non parlare di sceglierla.

Augh :D

PGI-Bis

08-09-2009, 14:29

perché consigliate tutti solo il C++? forse sarà obsoleto, ma conosco solo il C per adesso, e non trovo limitazioni. L'approccio OOP e la divisione in classi, imho, è meno intuitivo della divisione in funzioni :stordita: non siete d'accordo?

Sono solidale con la tua impressione circa una maggiore comprensibilità delle funzioni rispetto alle classi. Che, adesso te ne dico una, non sono assolutamente centrali nell'orientamento agli oggetti.

L'OOP è affascinante ED elementare ma è traviata da una marea di guru della stupidaggine che te la fanno apparire come fosse il mitico briareo con tutte e cento le sue braccia.

Ci sono testi che ti fanno veramente ammazzare dalle risate. Alcuni partono con un "oggetto è ogni cosa", tiè, così a bruciapelo. Che uno già ci resta male perchè dalle elementari sa che una definizione omnicomprensiva non può essere la base di un discorso razionale: se parli del tutto puoi dire qualsiasi cosa che tanto va sempre bene. Che razza di discorso è?

Anche sull'astrazione se ne sentono di fantastiche. Lì vedi veramente le frasi che si ingolfano, con 'sta astrazione che ti capita in braccio a mo' di ordalia. Bisogna astrarre perchè così riusi e se non devi riusare allora astrai perchè...perchè sì, in fondo ragioni per classi, e se non ragioni per classi allora... e checcazzo astrai e non rompere i marroni!

E la questione invece sarebbe così elegantemente "terra terra"... ehhhh, tragedie della cultura pop :nono:...

_Claudio

08-09-2009, 16:49

perché consigliate tutti solo il C++? forse sarà obsoleto, ma conosco solo il C per adesso, e non trovo limitazioni. L'approccio OOP e la divisione in classi, imho, è meno intuitivo della divisione in funzioni :stordita: non siete d'accordo?

Diciamo che riguardo l'uso intensivo della OOP ci si fa troppe seghe mentali.

Va usata quando serve, per programmini semplici non c'è nulla di meglio che un programmino procedurale (fatto anche in C++ come fa il sottoscritto) di poche righe che risolve il risolvibile, perchè complicarsi la vita?

Quando il programma inizia a diventare complesso e i concetti sono ben esprimibili in OOP, direi che il passo è dovuto, ma al di là del linguaggio bisogna a mio avviso passare da una fase di progettazione su carta che copra se possibile anche i minimi dettagli, altrimenti più che OOP si fa una schifezza.

^TiGeRShArK^

08-09-2009, 18:27

perché consigliate tutti solo il C++? forse sarà obsoleto, ma conosco solo il C per adesso, e non trovo limitazioni. L'approccio OOP e la divisione in classi, imho, è meno intuitivo della divisione in funzioni :stordita: non siete d'accordo?

è la cosa peggiore che puoi consigliare a chi non ha mai programmato per scrivere un gioco da zero.
E cmq non è l'OOP ad essere poco intuitivo è il C con la sua PESSIMA filosofia di programmazione che ormai ti ha traviato la mente (come a tutti quelli che hanno iniziato prima col paradigma procedurale per approdare poi a quello ad oggetti). Resettati il cervello, rimuovi tutto quello che hai imparato col C e dopo un pò di tempo sarai in grado di imparare a programmare nella realtà odierna.
Mi chiedo come ancora sia possibile consigliare a chi si approccia alla programmazione un paradigma procedurale che ormai è de facto in disuso da parecchi anni. :muro:

^TiGeRShArK^

08-09-2009, 18:28

il C++ offre costrutti che permettono di scrivere molto meno codice per fare le stesse cose. inoltre se si sa scrivere bene in C++ é raro che ci si debba preoccupare di memory leaks ed in generale di resource leaks, invece in C stai sempre con l' "affanno" di dover chiamare la free o chi per lei in ogni possibile caso.

comunque io eviterei di partire dal C++ viste le condizioni: andrebbe sicuramente meglio Java o C#.
:mbe:
si.. se scrivi l'hello world forse...:doh:

^TiGeRShArK^

08-09-2009, 18:31

Diciamo che riguardo l'uso intensivo della OOP ci si fa troppe seghe mentali.

Va usata quando serve, per programmini semplici non c'è nulla di meglio che un programmino procedurale (fatto anche in C++ come fa il sottoscritto) di poche righe che risolve il risolvibile, perchè complicarsi la vita?

Quando il programma inizia a diventare complesso e i concetti sono ben esprimibili in OOP, direi che il passo è dovuto, ma al di là del linguaggio bisogna a mio avviso passare da una fase di progettazione su carta che copra se possibile anche i minimi dettagli, altrimenti più che OOP si fa una schifezza.

Io non lo chiamo nemmeno programma un insieme di codice per cui basta il paradigma procedurale.
Lo chiamo scriptino.
Ne scrivo ancora oggi diversi, ma non li considero assolutamente programmi.
Tutti i programmi che scrivo utilizzano il paradigma ad oggetti (o oggetti/funzionale) e sarebbe semplicemente folle utilizzare il procedurale puro nel 2009. :mbe:

shinya

08-09-2009, 18:57

conosco solo il C per adesso, e non trovo limitazioni.
Ti sei praticamente risposto da solo. Come diceva qualcuno di più intelligente di me:"The limits of my language are the limits of my world".
Prova a ragionare di fisica quantistica se la sola lingua a tua disposizione è lo swahili... :)
Se conosci una sola lingua non vedi i limiti della tua possibilità d'espressione per definizione.

Vincenzo1968

08-09-2009, 19:19

è la cosa peggiore che puoi consigliare a chi non ha mai programmato per scrivere un gioco da zero.
E cmq non è l'OOP ad essere poco intuitivo è il C con la sua PESSIMA filosofia di programmazione che ormai ti ha traviato la mente (come a tutti quelli che hanno iniziato prima col paradigma procedurale per approdare poi a quello ad oggetti). Resettati il cervello, rimuovi tutto quello che hai imparato col C e dopo un pò di tempo sarai in grado di imparare a programmare nella realtà odierna.
Mi chiedo come ancora sia possibile consigliare a chi si approccia alla programmazione un paradigma procedurale che ormai è de facto in disuso da parecchi anni. :muro:

Che mi prenda un colpo!

:bimbo:

PGI-Bis

08-09-2009, 19:26

ma al di là del linguaggio bisogna a mio avviso passare da una fase di progettazione su carta che copra se possibile anche i minimi dettagli, altrimenti più che OOP si fa una schifezza.

http://www.parafiaswaleksego.plock.opoka.org.pl/santo%20subito.jpg

_Claudio

08-09-2009, 22:30

http://www.parafiaswaleksego.plock.opoka.org.pl/santo%20subito.jpg

:sofico: :fagiano: Grazie grazie...

È una cosa che nessuno dice mai e tutti trascurano trastullandosi con le minuzie di questo e quel linguaggio ma a mio avviso è fondamentale...

^TiGeRShArK^

09-09-2009, 00:02

:sofico: :fagiano: Grazie grazie...

È una cosa che nessuno dice mai e tutti trascurano trastullandosi con le minuzie di questo e quel linguaggio ma a mio avviso è fondamentale...

La progettazione su carta che copra anche i minimi dettagli, nei casi pratici comuni, è solo dannosa.
E non è una mia opinione. ;)

_Claudio

09-09-2009, 00:22

La progettazione su carta che copra anche i minimi dettagli, nei casi pratici comuni, è solo dannosa.
E non è una mia opinione. ;)

Se non la si sa fare... o non c'è il tempo per farla perchè bisogna consegnare subito e al diavolo la qualità del software.

Ho visto molti casi in cui c'erano persone che pensavano che era dannosa e hanno prodotto software di dubbia qualità con "accorgimenti" (leggi, pezze) di dubbia professionalità.

Per software di uguale complessità io sono sempre riuscito a fare una buona progettazione su carta (usando uml ma soprattutto diciture grafiche di mia invenzione) e non c'è dubbio che il software era decisamente migliore, e prescindeva per quanto possibile dal linguaggio scelto.

Sono pure consapevole del fatto che sono poche le persone a cui ho visto fare le stesse cose, così come la progettazione su carta diventa difficile in caso di progetti grossi e svolti in team e comunque deve poi essere smussata in base alle scelte fatte a posteriori, in primis il linguaggio scelto.

Purtroppo con la mentalità del "è dannosa" si è relegata la fase di progettazione a un mero esercizio accademico, mentre sul mercato del lavoro ci si butta sul codice senza quasi conoscere nemmeno i requisiti, è inutile dire che a fronte di milioni di nuove tecnologie software inventate negli ultimi decenni per "facilitare" lo sviluppo quello che si è visto è un peggioramento evidente della qualità del software, questa cosa dovrebbe far pensare, forse alle volte un pizzico di umiltà nel prendere carta e penna e "abbassarsi" a fare gli esercizietti da scolaretti giusto per riordinare le idee non fa poi così male.

^TiGeRShArK^

09-09-2009, 00:27

Se non la si sa fare... o non c'è il tempo per farla perchè bisogna consegnare subito e al diavolo la qualità del software.

Ho visto molti casi in cui c'erano persone che pensavano che era dannosa e hanno prodotto software di dubbia qualità con "accorgimenti" (leggi, pezze) di dubbia professionalità.

Per software di uguale complessità io sono sempre riuscito a fare una buona progettazione su carta (usando uml ma soprattutto diciture grafiche di mia invenzione) e non c'è dubbio che il software era decisamente migliore, e prescindeva per quanto possibile dal linguaggio scelto.

Sono pure consapevole del fatto che sono poche le persone a cui ho visto fare le stesse cose, così come la progettazione su carta diventa difficile in caso di progetti grossi e svolti in team e comunque deve poi essere smussata in base alle scelte fatte a posteriori, in primis il linguaggio scelto.

Purtroppo con la mentalità del "è dannosa" si è relegata la fase di progettazione a un mero esercizio accademico, mentre sul mercato del lavoro ci si butta sul codice senza quasi conoscere nemmeno i requisiti, è inutile dire che a fronte di milioni di nuove tecnologie software inventate negli ultimi decenni per "facilitare" lo sviluppo quello che si è visto è un peggioramento evidente della qualità del software, questa cosa dovrebbe far pensare, forse alle volte un pizzico di umiltà nel prendere carta e penna e "abbassarsi" a fare gli esercizietti da scolaretti giusto per riordinare le idee non fa poi così male.
Veramente i grossi software fatti male sono praticamente TUTTI fatti con montagne di UML e minchiate varie.
E ho visto con i miei occhi due esempi abbastanza grossotelli.
Progettare tutto all'inizio è all'atto pratico impossibile (a meno di casi particolari), dato che in corso d'opera i requisiti sono praticamente sempre destinati a cambiare.
E se cambiano i requisiti con una progettazione monolitica devi riprogettare tutto.
Una progettazione incrementale invece è soggetta molto meno a questi problemi.
Inutile dire che poi con tutto il tempo che si è perso per formalizzare il tutto in UML le n volte che si è reso necessario riprogettare ci si sarebbe potuti concentrare sul software vero e proprio e renderlo migliore. :fagiano:

banryu79

09-09-2009, 07:48

Per me funziona bene progettare con matita e carta: ci sono parti "portanti" del software da implementare che richiedono qualcosa di più che un pensiero, per buttarle giù bene.
Vanno designate con coscienza e per farlo bisogna prima raccogliere e elaborare bene i requisiti.
Uso un po' di uml, e un po' di schemini fatti da me, specie per definire la struttura delle interfacce grafiche o gli eventuali formati personalizzati di file per i dati persistenti.

Poi ci sono parti del software più "soft" che possono meglio essere definite solo dopo aver messo in piedi qualcosa e che sono più sensibili al problema del cambio dei requisiti (o adirittura alla scoperta di nuovi, dato che capita di non accorgersi di tutto in prima battuta).

Un misto di progettazione su carta e unit testing, tanto per avere le mani libere e l'animo tranquillo quando verrà (e verrà sempre prima o poi) il momento di modificare/introdurre qualcosa.

Ovviamente parlo di "roba piccola" che un singolo programmatore può gestire: si parte dai semplici programmini da 3-4K loc a quelli di 30-45K loc (nella mia esperienza).

^TiGeRShArK^

09-09-2009, 07:51

Per me funziona bene progettare con matita e carta: ci sono parti "portanti" del software da implementare che richiedono qualcosa di più che un pensiero, per buttarle giù bene.
Vanno designate con coscienza e per farlo bisogna prima raccogliere e elaborare bene i requisiti.
Uso un po' di uml, e un po' di schemini fatti da me, specie per definire la struttura delle interfacce grafiche o gli eventuali formati personalizzati di file per i dati persistenti.

Poi ci sono parti del software più "soft" che possono meglio essere definite solo dopo aver messo in piedi qualcosa e che sono più sensibili al problema del cambio dei requisiti (o adirittura alla scoperta di nuovi, dato che capita di non accorgersi di tutto in prima battuta).

Un misto di progettazione su carta e unit testing, tanto per avere le mani libere e l'animo tranquillo quando verrà (e verrà sempre prima o poi) il momento di modificare/introdurre qualcosa.
Ma infatti è esattamente quello che sostengo. :)
Il che è totalmente diverso da dire che un sistema va progettato fin nei minimi dettagli prima dell'implementazione. ;)

cionci

09-09-2009, 07:57

L'approccio OOP e la divisione in classi, imho, è meno intuitivo della divisione in funzioni :stordita: non siete d'accordo?
Io trovo che sia assolutamente il contrario, basta entrare nella mentalità giusta. Le facilitazioni sono ovunque. Già parli di "divisione in classi" come se dovessi suddividere il codice in classi e questo è sicuramente un approccio sbagliato.
L'OOP parte dall'idea di oggetto e questo ti permette di concentrarti su un sotto problema più piccolo rispetto all'intero programma. Quando abbiamo identificato un oggetto possiamo implementarne la classe ed i metodi.
Soprattutto per un gioco 2D punta e clicka è facilissimo identificare gli oggetti, ad esempio giusto per tirarne fuori qualcuno: GameEngine, StoryLine, RenderingEngine, Texture, Sprite, Menu, Character, Dialog, Scene, Backpack, Object, etc etc
In 20 secondi che ho scritto questa cosa ho già in mente l'interazione fra vari oggetti per farne un programma...più intuitivo di così.

Anche io sconsiglio assolutamente C e C++, visti i tempi di apprendimento.
Meglio XNA Game Studio e C# se proprio si vuole imparare un linguaggio di programmazione. In alternativa consiglio i vari tool già esistenti per creare avventure grafiche, anche se non ne ho esperienza diretta.

banryu79

09-09-2009, 08:00

Ma infatti è esattamente quello che sostengo. :)
Il che è totalmente diverso da dire che un sistema va progettato fin nei minimi dettagli prima dell'implementazione. ;)
Chiaro, mi chiedo però, dalla parzialità della mia esperienza, se non esistono nella pratica casi in cui parte del software da implementare comprende un sotto-sistema che, per sua intrinseca natura, è più "rigido" e richiede più "rigore"... nel qual caso magari, si porrebbe bene una progettazione più minuziosa.

Parlo, per esempio, dell'implementazione di un componente software i cui requisiti non sono quelli estrapolati direttamente dal committente ma definiti in qualche documento tecnico di specifica di una qualche tecnologia (magari un protocollo per il trasferimento dati via seriale con un dispositivo esterno, o altra "roba" del genere).

marco.r

09-09-2009, 09:42

Chiaro, mi chiedo però, dalla parzialità della mia esperienza, se non esistono nella pratica casi in cui parte del software da implementare comprende un sotto-sistema che, per sua intrinseca natura, è più "rigido" e richiede più "rigore"... nel qual caso magari, si porrebbe bene una progettazione più minuziosa.

Se devi progettare qualcosa che abbia bisogno di certificazione (e.g. strumento medicale), giova cercare di essere un po' piu' rigidi ed avere una fase di progettazione piu' prolungata.
Similmente se devi lavorare su un sistema embedded dove produci sia HW che SW, anche se per motivi un po' diversi (devi arrivare ad avere chiaro come e' fatto l'hardware, che e' piu' difficile da cambiare dopo :D, ma la cosa ha ripercussioni anche sul software).
Questo non vuol dire che si debba o possa progettare tutto nei minimi dettagli, anche perche' comunque un po' le specifiche cambiano, ma la struttura poi puo' essere cambiata entro certi limiti.

M4rk191

09-09-2009, 09:50

Ti sei praticamente risposto da solo. Come diceva qualcuno di più intelligente di me:"The limits of my language are the limits of my world".
Prova a ragionare di fisica quantistica se la sola lingua a tua disposizione è lo swahili... :)
Se conosci una sola lingua non vedi i limiti della tua possibilità d'espressione per definizione.

Io trovo che sia assolutamente il contrario, basta entrare nella mentalità giusta. Le facilitazioni sono ovunque. Già parli di "divisione in classi" come se dovessi suddividere il codice in classi e questo è sicuramente un approccio sbagliato.
L'OOP parte dall'idea di oggetto e questo ti permette di concentrarti su un sotto problema più piccolo rispetto all'intero programma. Quando abbiamo identificato un oggetto possiamo implementarne la classe ed i metodi.
Soprattutto per un gioco 2D punta e clicka è facilissimo identificare gli oggetti, ad esempio giusto per tirarne fuori qualcuno: GameEngine, StoryLine, RenderingEngine, Texture, Sprite, Menu, Character, Dialog, Scene, Backpack, Object, etc etc
In 20 secondi che ho scritto questa cosa ho già in mente l'interazione fra vari oggetti per farne un programma...più intuitivo di così.

Anche io sconsiglio assolutamente C e C++, visti i tempi di apprendimento.
Meglio XNA Game Studio e C# se proprio si vuole imparare un linguaggio di programmazione. In alternativa consiglio i vari tool già esistenti per creare avventure grafiche, anche se non ne ho esperienza diretta.

vorrei aggiungere che programmo anche in Java, quindi conosco la programmazione OOP. Sicuramente è divertente imparare il Java, perché non ha niente di complesso, ma il fatto che è necessario creare le classi mi sembra restrittivo, mentre l'approccio del C è diverso, in quanto si dà epr certo che quello che fà il programmatore sia fatto con criterio, e le regole sono poco restrittive. Detto questo, ho in tenzione di comprare il libro di Bjarne Stroustrup così da vedere realmente le differenze e trovare il linguaggio adatto a me, l'unico timore è che quando avrò finito di studiare il C++ saranno uscite le specifiche per il C++0X :(

_Claudio

09-09-2009, 10:17

Nel mio intervento oltre a specificare "nei minimi dettagli" era anche specificato "per quanto possibile" ed era volto a far notare che anche quando è possibile farla la progettazione su carta e aiuterebbe nello sviluppo questa non viene fatta perchè ritenuta a priori "dannosa".

Sono poi d'accordo anche io che l'ecessiva formalizzazione su uml e l'accanimento nel definire correttamente i dettagli sia quantomeno dannoso sapendo soprattutto che i requisiti cambieranno, difatti per questo esiste la progettazione incrementale.

fero86

09-09-2009, 11:57

Sono solidale con la tua impressione circa una maggiore comprensibilità delle funzioni rispetto alle classi. Che, adesso te ne dico una, non sono assolutamente centrali nell'orientamento agli oggetti.

L'OOP è affascinante ED elementare ma è traviata da una marea di guru della stupidaggine che te la fanno apparire come fosse il mitico briareo con tutte e cento le sue braccia.

Ci sono testi che ti fanno veramente ammazzare dalle risate. Alcuni partono con un "oggetto è ogni cosa", tiè, così a bruciapelo. Che uno già ci resta male perchè dalle elementari sa che una definizione omnicomprensiva non può essere la base di un discorso razionale: se parli del tutto puoi dire qualsiasi cosa che tanto va sempre bene. Che razza di discorso è?

Anche sull'astrazione se ne sentono di fantastiche. Lì vedi veramente le frasi che si ingolfano, con 'sta astrazione che ti capita in braccio a mo' di ordalia. Bisogna astrarre perchè così riusi e se non devi riusare allora astrai perchè...perchè sì, in fondo ragioni per classi, e se non ragioni per classi allora... e checcazzo astrai e non rompere i marroni!

E la questione invece sarebbe così elegantemente "terra terra"... ehhhh, tragedie della cultura pop :nono:... POST DA INCORNICIARE!!! :ave:

edit - e la questione invece quale sarebbe? :D
scusa se te lo chiedo, non é per metterti alla prova, ma il post mi é piaciuto molto e quindi volevo sentire la fine! :)

Mi chiedo come ancora sia possibile consigliare a chi si approccia alla programmazione un paradigma procedurale che ormai è de facto in disuso da parecchi anni. :muro: beato te.

fero86

09-09-2009, 12:14

Sicuramente è divertente imparare il Java, perché non ha niente di complesso, ma il fatto che è necessario creare le classi mi sembra restrittivo, non é restrittivo: potresti anche programmare in Java usando solo metodi statici e non istanziando mai le tue classi, le specifiche del linguaggio non lo vietano e staresti praticamente facendo programmazione procedurale con qualche ammennicolo sintattico inutilizzato ("class", "static", ecc.); ma non ti converrebbe perché la OOP ti permette di eliminare un parametro dalla segnatura di ogni metodo non statico (il parametro this) rendendo quindi di fatto piu semplice il tuo codice.

l'unico timore è che quando avrò finito di studiare il C++ saranno uscite le specifiche per il C++0X :( devono essere giá uscite perché il C++0x é una realtá, puoi sperimentarlo nella beta di Visual Studio 2010 per esempio. comunque non vedo il problema: impari le novitá e sei di nuovo up to date. che io sappia la novitá principale sono le lambda expression, poi credo che ci sia qualche introduzione nella libreria standard (forse con prelievi dalle Boost).

M4rk191

09-09-2009, 12:18

non é restrittivo: potresti anche programmare in Java usando solo metodi statici e non istanziando mai le tue classi, le specifiche del linguaggio non lo vietano e staresti praticamente facendo programmazione procedurale con qualche ammennicolo sintattico inutilizzato ("class", "static", ecc.); ma non ti converrebbe perché la OOP ti permette di eliminare un parametro dalla segnatura di ogni metodo non statico (il parametro this) rendendo quindi di fatto piu semplice il tuo codice.

devono essere giá uscite perché il C++0x é una realtá, puoi sperimentarlo nella beta di Visual Studio 2010 per esempio. comunque non vedo il problema: impari le novitá e sei di nuovo up to date. che io sappia la novitá principale sono le lambda expression, poi credo che ci sia qualche introduzione nella libreria standard (forse con prelievi dalle Boost).
già non sò dove leggere le differenze tra C89 e C99, mi immagino quanto sia difficile trovare le specifiche complete del C++0X, tra l'altro il sito web di bjarne sembra un pò anacronistico :asd:

cionci

09-09-2009, 12:28

Detto questo, ho in tenzione di comprare il libro di Bjarne Stroustrup così da vedere realmente le differenze e trovare il linguaggio adatto a me, l'unico timore è che quando avrò finito di studiare il C++ saranno uscite le specifiche per il C++0X :(
Il C++ non si impara sullo Stroustrup ;) Lo Stroustrup è solo un manuale di riferimento.

Ti ripeto: se conoscessi solo il paridigma procedurale mi sarei fatto tanti di quei giri in testa prima di costruire una struttura adeguata.
In teoria poi volendo potrei anche cercare di adottare la struttura che ho pensato ad oggetti con il C, per strutture abbastanza semplici come queste si può fare tranquillamente. Ciò non toglie che io abbia pensato "ad oggetti" e quindi il linguaggio migliore per rendere codice quello che ho pensato sia un linguaggio che supporta il paradigma ad oggetti.

M4rk191

09-09-2009, 12:34

Il C++ non si impara sullo Stroustrup ;) Lo Stroustrup è solo un manuale di riferimento.
:eek: veramente?
devo trovare un altro libro. Ad ogni modo anche nel libro di Ritchie e Kernigham c'è il manuale di riferimento, e nonostante sia più utile agli implementatori mi è risultato comunque utile per una migliore comprensione del linguaggio.

Ti ripeto: se conoscessi solo il paridigma procedurale mi sarei fatto tanti di quei giri in testa prima di costruire una struttura adeguata.
In teoria poi volendo potrei anche cercare di adottare la struttura che ho pensato ad oggetti con il C, per strutture abbastanza semplici come queste si può fare tranquillamente. Ciò non toglie che io abbia pensato "ad oggetti" e quindi il linguaggio migliore per rendere codice quello che ho pensato sia un linguaggio che supporta il paradigma ad oggetti.[/QUOTE]
allora mi viene da pensare che il miglior linguaggio è quello che meglio si adatta al modo di pensare del programmatore :D

banryu79

09-09-2009, 13:00

...mi viene da pensare che il miglior linguaggio è quello che meglio si adatta al modo di pensare del programmatore :D

Già, ma tra i possibili modi di pensare che un programmatore può avere quale conviene adottare? Quanti e quali sono i vari modi di pensare? (relativamente all'ambito della programmazione e della soluzione dei problemi con essa, si intende).
E' possibile imparare a pensare in modi nuovi? Potrebbe essere conveniente?

shinya

09-09-2009, 13:10

allora mi viene da pensare che il miglior linguaggio è quello che meglio si adatta al modo di pensare del programmatore :D
Io la vedo all'opposto. Preferisco pensare che il miglior linguaggio sia quello che si adatta meglio al problema.

^TiGeRShArK^

09-09-2009, 13:14

Io la vedo all'opposto. Preferisco pensare che il miglior linguaggio sia quello che si adatta meglio al problema.

*
Il programmatore si può adattare a qualsiasi modo di pensare (certo.. con MOLTA difficoltà se dopo anni e anni di procedurale puro ci si ritrova a cambiare paradigma), ma è più conveniente pensare nel modo che renda + facile la risoluzione del problema.
E l'astrazione permessa dall'OOP ad oggi imho è quanto di meglio ci possa essere.
Se conoscete qualcosa di meglio fatemi un fischio. :p

M4rk191

09-09-2009, 13:27

*
Il programmatore si può adattare a qualsiasi modo di pensare (certo.. con MOLTA difficoltà se dopo anni e anni di procedurale puro ci si ritrova a cambiare paradigma), ma è più conveniente pensare nel modo che renda + facile la risoluzione del problema.
E l'astrazione permessa dall'OOP ad oggi imho è quanto di meglio ci possa essere.
Se conoscete qualcosa di meglio fatemi un fischio. :p
il fatto è che tu la pensi così, e io ti posso rispondere che come ogni problema può essere suddiviso in classi, allo stesso modo può essere suddiviso in funzioni :asd:

In sostanza quello che cerco di dire è che se un programmatore riesce a scrivere un programma più velocemente (tralasciando brevità o complessità del codice) con un approccio invece che con un altro, allora gli conviene usare l'approccio che gli faccia risparmiare tempo, perché rientra nella sua logia, nel suo modo di pensare e operare.

shinya

09-09-2009, 13:41

E l'astrazione permessa dall'OOP ad oggi imho è quanto di meglio ci possa essere.
Beh io ovviamente penso che non lo sia. Non in modo cosi categorico almeno. Ma del paradigma a me interessa poco, trovo sia giusto usare quello che mi permette la migliore espressività possibile per il problema che devo risolvere. La questione è che siamo limitati dal nostro linguaggio (in senso assoluto, non solo nella programmazione).
Ad esempio, per il problema "Lavare il bucato", quale di queste due soluzioni trovi più espressiva?

OOP:

WasherMachine washer = new WasherMachine();
while (washer.hasDirtyClothes()) {
washer.wash();
washer.rinse();
}

Altro:
wash rinse repeat

PGI-Bis

09-09-2009, 13:49

La soluzione orientata agli oggetti è:

lavatrice lava bucato

shinya

09-09-2009, 13:56

La soluzione orientata agli oggetti è:

lavatrice lava bucato
+1 :)
Ma se la mettiamo su questo piano allora meglio questa:

Lavanderia.apriAlle(9);

PGI-Bis

09-09-2009, 14:16

Il punto è esattamente quello. Il linguaggio è OO, il codice è OOP, nel momento in cui usa i predicati di uno o più oggetti.

Perchè questo non è OOP:

WasherMachine washer = new WasherMachine();
while (washer.hasDirtyClothes()) {
washer.wash();
washer.rinse();
}

?

Perchè "while" non è un predicato. Chi è che "while"? Boh.

Invece:

washer.clothes.foreach(x=>x.wash x.rinse)

E' orientamento agli oggetti. Perchè ogni operazione è il predicato di qualcosa. Se un programma orientato agli oggetti è un insieme di oggetti che fanno qualcosa, quando trovi qualcosa che non è fatto da alcun oggetto sai che lì la prospettiva non è OO.

_Claudio

09-09-2009, 15:16

Beh io ovviamente penso che non lo sia. Non in modo cosi categorico almeno. Ma del paradigma a me interessa poco, trovo sia giusto usare quello che mi permette la migliore espressività possibile per il problema che devo risolvere. La questione è che siamo limitati dal nostro linguaggio (in senso assoluto, non solo nella programmazione).
Ad esempio, per il problema "Lavare il bucato", quale di queste due soluzioni trovi più espressiva?

OOP:

WasherMachine washer = new WasherMachine();
while (washer.hasDirtyClothes()) {
washer.wash();
washer.rinse();
}

Altro:
wash rinse repeat

Fosse realizzabile la seconda soluzione...
la OOP è il metodo più espressivo e human-like tra quelli IMPLEMENTABILI ad oggi... poi magari un giorno ognuno parlerà in un microfono, farà vedere i compiti da svolgere alla macchina e quella eseguirà senza errori e domande, e da allora i programmatori saranno solo roba da ricchi in un mondo povero...

marco.r

09-09-2009, 15:19

Invece:

washer.clothes.foreach(x=>x.wash x.rinse)

E' orientamento agli oggetti. Perchè ogni operazione è il predicato di qualcosa. Se un programma orientato agli oggetti è un insieme di oggetti che fanno qualcosa, quando trovi qualcosa che non è fatto da alcun oggetto sai che lì la prospettiva non è OO.

Direi che e' orientato agli oggetti tanto quanto e' funzionale, visto che l' x=> x.wash x.rinse e' una lambda expression.
Anzi dovendo tenere solo uno dei due terrei solo l'aspetto funzionale, che poca fatica mi costa usare piuttosto un

map ((wash washer) . (rinse washer)) clothes

shinya

09-09-2009, 15:28

Fosse realizzabile la seconda soluzione...
Mica me lo sono inventato! Esiste eccome! Quello è codice perfettamente valido in un qualsiasi linguaggio stack-based...factor, forth, joy, cat, ecc...ecc...

_Claudio

09-09-2009, 15:30

Mica me lo sono inventato! Esiste eccome! Quello è codice perfettamente valido in un qualsiasi linguaggio stack-based...factor, forth, joy, cat, ecc...ecc...

Lo so, ma quei linguaggi sono poco diffusi... perchè danno molto da una parte ma levano parecchio da un'altra.

PGI-Bis

09-09-2009, 15:59

shinya

09-09-2009, 16:13

Lo so, ma quei linguaggi sono poco diffusi...Questo non c'entra col discorso.
perchè danno molto da una parte ma levano parecchio da un'altra.Non è vero. Basta vedere la montagna di codice che è stato scritto, ad esempio, in factor http://gitweb.factorcode.org/gitweb.cgi?p=factor/.git;a=tree

Tommo

09-09-2009, 16:22

washer.clothes.foreach(x=>x.wash x.rinse)

è OO limitatamente al fatto che "ogni metodo ha il suo oggetto". Certamente _=>_ è una lambda expression tuttavia vorrei precisare che NON consiglio assolutamente il suo uso così come non appoggerei neppure sotto tortura l'uso di un approccio funzionale alla scrittura di programmi se non limitatamente a questi "shortcut" (nella fattispecie invocare due metodi in un colpo).

Che comunque, non è un problema riscriverlo in modo OOP: basta mettere tutti i Clothes dentro una Lista e quindi passare quella lista a washer.
All'interno di washer poi ci sarà un ciclo che itera ogni elemento, ma a quel punto è chiaro di chi è il while: di Washer...

Cmq OT a fiumi, e da domande concrete si finisce sempre a parlare dei massimi sistemi :asd:

fero86

09-09-2009, 16:41

il fatto è che tu la pensi così, e io ti posso rispondere che come ogni problema può essere suddiviso in classi, allo stesso modo può essere suddiviso in funzioni :asd:

In sostanza quello che cerco di dire è che se un programmatore riesce a scrivere un programma più velocemente (tralasciando brevità o complessità del codice) con un approccio invece che con un altro, allora gli conviene usare l'approccio che gli faccia risparmiare tempo, perché rientra nella sua logia, nel suo modo di pensare e operare. questo te lo quoto per intero :)

peró aggiungo qualche considerazione mia: il paradigma a oggetti, in molte sue realizzazioni, é oggettivamente (lol :asd: ) migliore di quello procedurale perché spesso i linguaggi a oggetti sono piu moderni e offrono costrutti piu sofisticati che permettono di ridurre le dimensioni del codice e quindi di fare di piu con meno codice (ho in mente il confronto tra il C e C#, ma vale con molti altri linguaggi sul "lato destro": C vs. C++, C vs. Java, C vs. Python, ...); inoltre anche senza andare a pensare alle singole implementazioni riporto all'attenzione una mia precedente osservazione, cioé che la OOP di per se' semplifica il codice in quanto permette di eliminare un parametro da ogni "funzione" (che a quel punto prende il nome di "metodo").

di conseguenza se un programmatore si ritrova ad essere significativamente piu produttivo con un linguaggio procedurale (e ci sta benissimo) farebbe bene a considerare un sano periodo di training.

banryu79

09-09-2009, 16:58

...
Certamente _=>_ è una lambda expression tuttavia vorrei precisare che NON consiglio assolutamente il suo uso così come non appoggerei neppure sotto tortura l'uso di un approccio funzionale alla scrittura di programmi...

Mi piacerebbe sapere il perchè, che opinione ti sei fatto sul paradigma funzionale?

marko.fatto

09-09-2009, 17:17

Vi siete accorti che fin'ora l'autore della discussione non ha più postato e voi siete andati avanti tre pagine? :D :sofico:

Y3PP4

09-09-2009, 17:53

Dato che si parla di OOP, una espressione come:
cout << Classe.Valore() << endl;

non è OOP ?

E invece:
Classe.Show(Classe.Valore())

lo sarebbe?

cionci

09-09-2009, 18:24

Vi siete accorti che fin'ora l'autore della discussione non ha più postato e voi siete andati avanti tre pagine? :D :sofico:
Concordo, cerchiamo di rispondere al creatore della discussione ;)

Ryuzaki_Eru

10-09-2009, 19:35

Salve a tutti :)

Io non conosco C++ (e se non sarà per questione di vita o di morte continuerò ad ignorarlo :D) e di conseguenza non so come sia sviluppare giochi con questo linguaggio, che framework mette a disposizione e tutto il resto.
So però che al giorno d'oggi, studiando le basi di un linguaggio (molto spesso si trovano guide o libri che spiegano linguaggio e framework in parallelo), in poco tempo si può riuscire ad imparare a fare qualcosa di carino. Ad esempio, Python + PyGame (http://www.pygame.org/news.html) (conosco ragazzi che in meno di 3 ore fanno giochini completi tipo Space Invaders o Ball Breaker, con tanto di menu, salvataggio e simili e parlo di ragazzini dai 13 anni in su) e C# + XNA (http://msdn.microsoft.com/en-us/xna/default.aspx).
La cosa più importante per chi si dedica per la prima volta allo studio e alla creazione dei giochi è capire, e sapere, i concetti fondamentali di quello che si deve fare. Se ad esempio si deve creare un gioco in 2D allora è fondamentale sapere come vengono rappresentati i punti sugli assi, il movimento, le collisioni e cosi via.

Qua qualche link per iniziare:

http://wiki.python-it.org/PyGameTutorial
http://www.wilez.it/tutorials/XNA/

agente mm8

10-09-2009, 20:46

Io non conosco C++ (e se non sarà per questione di vita o di morte continuerò ad ignorarlo :D) e di conseguenza non so come sia sviluppare giochi con questo linguaggio, che framework mette a disposizione e tutto il resto.
So però che al giorno d'oggi, studiando le basi di un linguaggio (molto spesso si trovano guide o libri che spiegano linguaggio e framework in parallelo), in poco tempo si può riuscire ad imparare a fare qualcosa di carino. Ad esempio, Python + PyGame (http://www.pygame.org/news.html)

Sei un mito

(conosco ragazzi che in meno di 3 ore fanno giochini completi tipo Space Invaders o Ball Breaker, con tanto di menu, salvataggio e simili e parlo di ragazzini dai 13 anni in su)

Ci conosciamo? :asd:

La cosa più importante per chi si dedica per la prima volta allo studio e alla creazione dei giochi è capire, e sapere, i concetti fondamentali di quello che si deve fare. Se ad esempio si deve creare un gioco in 2D allora è fondamentale sapere come vengono rappresentati i punti sugli assi, il movimento, le collisioni e cosi via.

Quotone