-
Unity, space shooter, programmazione for dummiesprendiamo Unity, qualche tempo fa ho fatto alcuni tutorial ed arrivai a finire lo space shooer.
io non sono affatto un programmatore, sono solo un curiosone, quel progetto è stato fantastico per me, pensavo a quanto sostenuto qui:
elaborare algoritmi o pattern è una cosa che fa parte del programmare, ma che viene a cadere quanto il lavoro del programmatore più che programmare diventa configurare.
Per esempio se tu programmi un videogioco devi implementare la fisica ecc ecc... ma se utilizzi un'applicazione per fare giochi magari il tutto si riduce a fare drag and drop di blocchi, metterci su delle texture e configurare solidità=true.
Concordo sul fatto che quando programmi ci sono righe di codice da scrivere che sono noiose, come la creazione di vari getter/setter o di metodi vari per clonare oggetti.
Indubbiamente automatizzando queste cose il programmatore passa meno tempo a scrivere codice noioso.
Se però gli togli anche la parte divertente, come implementare il motore fisico, allora non c'è più gusto.
Ok.
all'interno di unity tutto il sistema di coordinate di riferimento e motore fisico sono già fatte ed uno non fa altro che utilizzarle in un ambiente di sviluppo semigrafico, esattamente quello che critica il trollone qui sopra.
il giochino è a scorrimento verticale, ad un certo punto vengono generati i nemici, è stato dato un sistema di coordinate che determinano l'area di gioco visibile ed un sistema di movimento degli elelemti del gioco (gli asteroidi e la navicella del tizio) attraverso script che fanno uso delle funzioni di base del motore di unity ed oggetti 3d organizzati nell'editor grafico ("configurazione" se ho capito bene cosa intende il trollone qui sopra), gli asteroidi vengono generati subito fuori l'area visibile con movimento verso l'area visibile e così appaiono le ondate di nemici.
Gli asteroidi vengono generati in questo loop utilizzando un semplice sistema di coordinate tridimensionali in cui z è inutile (la proiezione del gioco è ortografica e non c'è nessuna profondità, è tutto allo stesso livello)
nel tutorial te lo fanno fare cosìIEnumerator SpawnWaves () { yield return new WaitForSeconds (startWait); while (true) { for (int i = 0; i < hazardCount; i++) { Vector3 spawnPosition = new Vector3 (Random.Range (-spawnValues.x, spawnValues.x), spawnValues.y, spawnValues.z); Quaternion spawnRotation = Quaternion.identity; Instantiate (hazard, spawnPosition, spawnRotation); yield return new WaitForSeconds (spawnWait); } yield return new WaitForSeconds (waveWait); }
spawnValues viene dichiarata in precedenza come variabile pubblica, e questo in unity vuol dire che una volta compilato lo script quei valori sono editabili nell'editor grafico (è di tipo Vector3 quindi l'editor visualizza una maschera dove scrivere 3 valori per x, y e z).
ti fanno impostare x alla metà della larghezza dello schermo, y fuori dallo schermo (in alto al di fuori della parte renderizzata dalla game camera) e z è sempre uguale.
A questo punto
Random.Range (-spawnValues.x, spawnValues.x)
genera una serie di coordinate casuali comprese tra i valori che le porranno all'interno dell'area di gioco. generando ondate di nemici con posizioni casuali ma sempre all'interno dell'area di gioco.
ed io mi sono ritenuto soddisfatto ed ho imparato un sacco di cose e mi divertii qualche ora.
A questo punto però, quando avrò defintivamente finito di lavorare e se mai riprenderò Unity in mano per divertirmi un altro po mi metterò a modificare quella funzione per generare ondate di nemici con le forme ed i pattern che desidero, così com'erano nei primi giochi del genere che giocai da bambino sul commodore, e questo sarà invece un problema del genere che secondo me il trollone considerava interessante e divertente.
concordo sul fatto che quella sia la vera parte interessante dello sviluppo, tutto il resto del tutorial era la configurazione di un semplice meccanismo di gioco fondametalmente già fatto all'interno del motore di Unity.
Però Unity altro non ha fatto che esporre a me, neofita completo, un problema di generazione di algoritmi e pattern che in altri modi non avrei mai potuto divertirmi a svolgere.
O forse il trollone intendeva ancora qualcos'altro come parte "divertente" che voi informatici ci tenete nascosto?
**Modificato dall'autore il 24.02.2017 15:25**Please consider the environment before printing this message, 50% of the above is useless!-
Re: Unity, space shooter, programmazione for dummiesScritto daNon Autenticatoil 2017-02-24 15:50:58.0 alle 2017-02-24 15:50:58.0Scritto da: dada216
> prendiamo Unity, qualche tempo fa ho fatto alcuni tutorial ed arrivai a finire lo space shooer.
>
>
>
> io non sono affatto un programmatore, sono solo un curiosone, quel progetto è stato fantastico per me, pensavo a quanto sostenuto qui:
>
>
>
> elaborare algoritmi o pattern è una cosa che fa parte del programmare, ma che viene a cadere quanto il lavoro del programmatore più che programmare diventa configurare.
>
> Per esempio se tu programmi un videogioco devi implementare la fisica ecc ecc... ma se utilizzi un'applicazione per fare giochi magari il tutto si riduce a fare drag and drop di blocchi, metterci su delle texture e configurare solidità=true.
>
> Concordo sul fatto che quando programmi ci sono righe di codice da scrivere che sono noiose, come la creazione di vari getter/setter o di metodi vari per clonare oggetti.
> Indubbiamente automatizzando queste cose il programmatore passa meno tempo a scrivere codice noioso.
> Se però gli togli anche la parte divertente, come implementare il motore fisico, allora non c'è più gusto.
>
>
>
>
>
> Ok.
>
> all'interno di unity tutto il sistema di coordinate di riferimento e motore fisico sono già fatte ed uno non fa altro che utilizzarle in un ambiente di sviluppo semigrafico, esattamente quello che critica il trollone qui sopra.
>
> il giochino è a scorrimento verticale, ad un certo punto vengono generati i nemici, è stato dato un sistema di coordinate che determinano l'area di gioco visibile ed un sistema di movimento degli elelemti del gioco (gli asteroidi e la navicella del tizio) attraverso script che fanno uso delle funzioni di base del motore di unity ed oggetti 3d organizzati nell'editor grafico ("configurazione" se ho capito bene cosa intende il trollone qui sopra), gli asteroidi vengono generati subito fuori l'area visibile con movimento verso l'area visibile e così appaiono le ondate di nemici.
>
> Gli asteroidi vengono generati in questo loop utilizzando un semplice sistema di coordinate tridimensionali in cui z è inutile (la proiezione del gioco è ortografica e non c'è nessuna profondità, è tutto allo stesso livello)
>
> nel tutorial te lo fanno fare così
>
>> IEnumerator SpawnWaves () > { > yield return new WaitForSeconds (startWait); > while (true) > { > for (int i = 0; i < hazardCount; i++) > { > Vector3 spawnPosition = new Vector3 (Random.Range (-spawnValues.x, spawnValues.x), spawnValues.y, spawnValues.z); > Quaternion spawnRotation = Quaternion.identity; > Instantiate (hazard, spawnPosition, spawnRotation); > yield return new WaitForSeconds (spawnWait); > } > yield return new WaitForSeconds (waveWait); > } >
>
> spawnValues viene dichiarata in precedenza come variabile pubblica, e questo in unity vuol dire che una volta compilato lo script quei valori sono editabili nell'editor grafico (è di tipo Vector3 quindi l'editor visualizza una maschera dove scrivere 3 valori per x, y e z).
>
> ti fanno impostare x alla metà della larghezza dello schermo, y fuori dallo schermo (in alto al di fuori della parte renderizzata dalla game camera) e z è sempre uguale.
>
> A questo punto
>
> Random.Range (-spawnValues.x, spawnValues.x)
>
> genera una serie di coordinate casuali comprese tra i valori che le porranno all'interno dell'area di gioco. generando ondate di nemici con posizioni casuali ma sempre all'interno dell'area di gioco.
>
> ed io mi sono ritenuto soddisfatto ed ho imparato un sacco di cose e mi divertii qualche ora.
>
> A questo punto però, quando avrò defintivamente finito di lavorare e se mai riprenderò Unity in mano per divertirmi un altro po mi metterò a modificare quella funzione per generare ondate di nemici con le forme ed i pattern che desidero, così com'erano nei primi giochi del genere che giocai da bambino sul commodore, e questo sarà invece un problema del genere che secondo me il trollone considerava interessante e divertente.
>
> concordo sul fatto che quella sia la vera parte interessante dello sviluppo, tutto il resto del tutorial era la configurazione di un semplice meccanismo di gioco fondametalmente già fatto all'interno del motore di Unity.
> Però Unity altro non ha fatto che esporre a me, neofita completo, un problema di generazione di algoritmi e pattern che in altri modi non avrei mai potuto divertirmi a svolgere.
>
> O forse il trollone intendeva ancora qualcos'altro come parte "divertente" che voi informatici ci tenete nascosto?
Avendo in passato programmato (senza concludere alcunché) intervengo pure io. Gli ambienti di sviluppo sostituiscono lo scripting ad alto livello alla programmazione a basso livello, ma al Vero Hacker piace la conoscenza a basso livello (e penso alla fisica, dove ogni descrizione ad alto livello è inutile per fare fisica) cui però può applicarsi per cultura personale.
L'ideale sarebbe lavorare per soldi e investigare per cultura personale, ma reputo la cosistenza di queste due cose improbabile. Quando lavori il lavoro non ti dà un attiomo di tregua, ti prosciuga fino a lasciarti esanime a sera. Allora da vero selvatico non lavori per preservare il tuo intelletto, che però senza soldi per alimentare i progetti farà ben poco. Inoltre, quello che ho più volte dichiarato di temere è un futuro in cui a lavorare e avere i soldi siano pochi, gli altri dovranno accontentarsi di espedienti.
Infine sollevo la questione: il codice generato dagli ambienti di sviluppo sarà senz'altro migliore di quello che può scrivere un normale programmatore, ma come sarà rispetto a ciò che può fare un alex.tg? Che infatti ha scelto la strada dell'investigare più che lavorare.
-
Re: Unity, space shooter, programmazione for dummiesScritto daNon Autenticatoil 2017-02-24 18:02:43.0 alle 2017-02-24 18:02:43.0Scritto da: dada216
> O forse il trollone intendeva ancora qualcos'altro come parte "divertente" che voi informatici ci tenete nascosto?
Lasciamo stare i videogiochi, parliamo di cose più terre a terre.
In un gestionale una cosa che si fa di sovente è utilizzare delle grid.
Implementare un framework per generare delle grid customizzabili può essere una cosa divertente, ma oggi in azienda si usano spesso cose già pronte che bisogna solo configurare.
http://demos.telerik.com/kendo-ui/grid/index
Poi però i clienti vogliono sempre delle robe custom, quindi passi il tuo tempo a imparare a configurare le grid per ottenere una grid fatta come la vuole il cliente. E a volte per ottenere il risultato devi scrivere del codice piuttosto contorto.
Questi framework di alto livello portano a un modo di programmare molto dichiarativo (quello che io chiamo configurazione), in cui non hai molto spazio per usare il cervello. Il tutto si riduce a cercare in google "come cazzo si disattiva la selezione di una riga" ecc ecc...
Comunque al momento ci sono ancora lavori abbastanza interessanti in giro, ma penso che più si andrà avanti e più si passerà dal programmare al configurare.
Il problema è che nella business informatic essere bravi a programmare non è una cosa che viene molto premiata. Hanno più successo magari quei programmatori mediocri che non riescano a sviluppare un cazzo per conto loro e quindi passano il loro tempo a cercare cose già fatte, facendo copia-incolla qua e là di codice che non capiscono.
Questi quindi diventano molto bravi a fare copia-incolla e in poco tempo arrivano ad avere un'applicazione funzionante (che poi è quello che interessa al cliente). I classici "spara gestionali".
I programmatori validi, che riescono a sviluppare cose per conto loro e che lo fanno, non riescono a stare al passo con gli spara gestionali, quindi si devono adattare al mercato e diventare anche loro spara gestionali, oppure cambiare settore lavorativo e trovare uno di quei lavori in cui saper davvero programmare è ancora importante. Ho idea però che di questi posti non ce ne siano molti e ce ne saranno sempre meno, perché fare le app diventerà sempre più semplice.
-
Re: Unity, space shooter, programmazione for dummiesScritto da:
> Scritto da: dada216
> > O forse il trollone intendeva ancora qualcos'altro come parte "divertente" che voi informatici ci tenete nascosto?
>
> Lasciamo stare i videogiochi, parliamo di cose più terre a terre.
>
> In un gestionale una cosa che si fa di sovente è utilizzare delle grid.
>
> Implementare un framework per generare delle grid customizzabili può essere una cosa divertente, ma oggi in azienda si usano spesso cose già pronte che bisogna solo configurare.
>
> http://demos.telerik.com/kendo-ui/grid/index
>
> Poi però i clienti vogliono sempre delle robe custom, quindi passi il tuo tempo a imparare a configurare le grid per ottenere una grid fatta come la vuole il cliente. E a volte per ottenere il risultato devi scrivere del codice piuttosto contorto.
> Questi framework di alto livello portano a un modo di programmare molto dichiarativo (quello che io chiamo configurazione), in cui non hai molto spazio per usare il cervello. Il tutto si riduce a cercare in google "come cazzo si disattiva la selezione di una riga" ecc ecc...
>
> Comunque al momento ci sono ancora lavori abbastanza interessanti in giro, ma penso che più si andrà avanti e più si passerà dal programmare al configurare.
>
> Il problema è che nella business informatic essere bravi a programmare non è una cosa che viene molto premiata. Hanno più successo magari quei programmatori mediocri che non riescano a sviluppare un cazzo per conto loro e quindi passano il loro tempo a cercare cose già fatte, facendo copia-incolla qua e là di codice che non capiscono.
> Questi quindi diventano molto bravi a fare copia-incolla e in poco tempo arrivano ad avere un'applicazione funzionante (che poi è quello che interessa al cliente). I classici "spara gestionali".
> I programmatori validi, che riescono a sviluppare cose per conto loro e che lo fanno, non riescono a stare al passo con gli spara gestionali, quindi si devono adattare al mercato e diventare anche loro spara gestionali, oppure cambiare settore lavorativo e trovare uno di quei lavori in cui saper davvero programmare è ancora importante. Ho idea però che di questi posti non ce ne siano molti e ce ne saranno sempre meno, perché fare le app diventerà sempre più semplice.
>
>
>
e tu scrivi i tools ai programmatori mediocri!Please consider the environment before printing this message, 50% of the above is useless!
-
-