Re: Sviluppo programmi/giochi

#21
MasterHalo 117 ha scritto:
02/03/2018, 17:29
No Repez davvero, deve scomparire nell'etere :m1a1:
Buttarmi subito sulle cose difficili mi ha effettivamente fatto capire la complessità dietro al game development ho contemporaneamente scoperto la sacra regola KISS (Keep It Simple, Stupid) che salva la vita, veramente.
Infatti mettersi a fare progetti complessi ti permette di porti e risolvere problemi più difficili rispetto a progetti più semplici.
Ovviamente non significa che bisogna puntare al livello di produzione di un gioco AAA :m1a1:, avere un progetto complesso e capirne i limiti fa parte appunto dei problemi del progetto complesso.
MasterHalo 117 ha scritto:
02/03/2018, 17:29
(per quanto odi il concetto di game design document vero e proprio, mi sa di design AAA fallace ).
Il nostro è un file dove buttiamo giù tutto: dal personaggio principale, all'ambientazione e il gameplay cercando di interlacciare tutto. Alla fine non esiste una maniera vera e propria per fare un GDD

Re: Sviluppo programmi/giochi

#22
Fefifox ha scritto:
02/03/2018, 21:19
MasterHalo 117 ha scritto:
02/03/2018, 17:29
No Repez davvero, deve scomparire nell'etere :m1a1:
Buttarmi subito sulle cose difficili mi ha effettivamente fatto capire la complessità dietro al game development ho contemporaneamente scoperto la sacra regola KISS (Keep It Simple, Stupid) che salva la vita, veramente.
Infatti mettersi a fare progetti complessi ti permette di porti e risolvere problemi più difficili rispetto a progetti più semplici.
Ovviamente non significa che bisogna puntare al livello di produzione di un gioco AAA :m1a1:, avere un progetto complesso e capirne i limiti fa parte appunto dei problemi del progetto complesso.
Vero, ma parlando per esperienza personale, vedere tutti quei problemi assieme può minare l’intero sviluppo e la voglia degli sviluppatori.

Poi parlo per me, non tutti siamo uguali :sisi:
Immagine

DOWNLOAD -> Halo: The RPG Episodio 0 | 1 | 2

Vietato rispondere ai messaggi di moderazione in verde e grassetto.
Per chiarimenti contattare lo staff in privato.

Re: Sviluppo programmi/giochi

#23
Scrivere un soggetto pare facile ma non lo è. Io avrei già tutto in testa,m seppur molto vago. Infatti ti frega il dover andare sui particolari, perché comunque un minimo di plot devi darglielo per dare un contesto al gioco.

E avrò lo stesso problema anche creando il level design probabilmente.
Immagine

Re: Sviluppo programmi/giochi

#25
Vi racconto di un problema logistico della nostra società (ormai possiamo considerarla una società quella mia e di Fefifox anche se non è registrata alla camera di commercio) coi file del progetto.
Ci troviamo nell'impossibilità di poter lavorare assieme a livello di file proprio fisici perchè io sto a Vicenza e lui sta al polo sud nella terra del fuoco in mezzo ai pinguini, perciò ho pensato di introdurre una organizzazione del lavoro per task il più indipendenti possibili in modo che ognuno possa lavorarci senza che i propri task siano bloccati in attesa che un altro debba finire i suoi perchè ne dipendono (tipo una catena di montaggio), ma ci si scontra con la necessità che prima o dopo dovremo fare delle build alpha di sviluppo per fare un punto generale del progetto e per valutare i progressi.
A questo punto, anche per via di AWS Glacier e Snowball (si, Amazon fa anche questo oltre che l'e-commerce) che ho conosciuto parlando con altri sviluppatori e project manager è venuta l'idea di fare delle finestre di merge. Ma c'è un ma:

- Glacier è utile per fare deposito di file senza limitazioni in quanto si paga solo al momento in cui si fa prelievo dei file ad un prezzo irrisorio (2 cent per GB nel prelievo più lento) e se non ricordo male perchè ho letto velocemente più tieni i file meno paghi, cioè se non li prendi spesso paghi meno. Utile per depositare sorgenti che restano li per anni nel caso serva rebuildare il progetto perchè devi correggere bug o re-pacchettizzi o fai remake

- Snowball permette di trasferire dati fisici su hard disk e Amazon ti manda un corriere con un NAS che ha spazio per CENTINAIA DI TERABYTE MINIMO fin o QUALCHE PETABYTE. Decisamente overkill e con un costo minimo che si aggira sui 200€, che è fuori portata per il nostro budget (0€). Dopodichè il corriere torna per ritirare il NAS e lo manda al datacenter di Parigi (ma si può mandarlo anche oltreoceano via aereo), un sistemista travasa i dati sul server solo nel momento in cui sblocchi il trasferimento con chiave che ti viene assegnata.

Vista la limitazione di budget, ho ideato un sistema di finestre di merge dove impostato un punto in cui si deve fare una build alpha si crea una finestra che si apre se e solo se ogni task, assegnato ai vari membri del team, a cui dipende questa finestra è stato
completato. Con una chiavetta USB molto capiente, uno inserisce i dati richiesti dentro un file zip criptato con AES 256, li mette su una busta imbottita col pluriball e li spedisce con posta internazionale (Poste Italiane / Correo Argentino con un costo di 3€ e 25 giorni lavorativi di tempo), avvisa dell'invio tramite email criptata con PGP il destinatario dove includerà anche la chiave di apertura del file 7z e quando arrivato da conferma di ricevimento cosi che il mittente cancella i suoi file. Dopodiché se necessario il destinatario invia la chiavetta vuota ad un altro membro del team che farà la stessa cosa.

Quando i file necessari previsti dalla finestra di merge sono arrivati tutti, creerà la build e aggiorna il progetto che sarà caricato sul cloud perchè venga usata da tutti i membri del team.

A parte una questione di tempo, per cui sono previste infatti poche finestre di merge e solo se indispensabili, ha un costo veramente basso.
Immagine

Re: Sviluppo programmi/giochi

#27
Va avanti ma a rilento, per il momento sto portando avanti il task della sceneggiatura e poi procederò a quello del level design del livello demo. Fefifox con l'università ancora non ha avuto possibilità di fare qualcosa perchè quello fatto finora era stato fatto con Unity e ora noi abbiamo deciso di usare UE4
Immagine

Re: Sviluppo programmi/giochi

#28
Copia un messaggio di Fefifox giusto che ha scritto nella chat admin:

A meno che non vogliate fare giochini per Android o giochi 2D
Unreal Engine > Unity
Tutto ciò che vedete è fatto in BSP con texture e material stock, persino lo skylight è default
Tra l'altro è impagabile non avere il "Made with Unity Personal Edition" all'avvio del gioco
Per quanto riguarda la programmazione visuale è utile solo per fare cose di piccole dimensioni (tipo trigger che attivano oggetti\luci\altri trigger), il giocatore lo sto sviluppando in C++ partendo da quello incorporato con il motore (non devo reinventare la ruota per alcune cose)
Immagine
Immagine

Re: Sviluppo programmi/giochi

#30
Prima o poi inizierò a passarvi qualcosa ma per ora è tutto molto basico e manca persino di un menù.
Parlando di gameplay in questo periodo, quando ho tempo, mi sto occupando di fare una base e imparare l'API ma a breve termine punto a inserire:

1) La possibilità di raccogliere gli oggetti e manipolarli in base al loro peso e grandezza
Su Unity già muovevo tutto via codice e la logica di fondo non cambia

2) Un sistema per aprire e chiudere le porte che sia il più comodo, preciso e fluido possibile
In realtà è anche un'approccio che avrò per tutto lo sviluppo perché non voglio interrompere il gameplay ma allo stesso modo non voglio che il gioco faccia tutto al posto del giocatore.

Più avanti voglio fare in modo che le porte e certi oggetti si possano rompere e/o bruciare, qua lascio nuovamente la filosofia di game design su cui mi appoggio ampiamente
Fefifox ha scritto:
02/03/2018, 0:05
Il progetto che stiamo portando avanti è sulla linea degli Immersive Sim, questa pagina lo spiega perfettamente:
https://www.giantbomb.com/immersive-sim/3015-5700/
La cosa più sicura che posso anticiparvi è che il gioco supporterà il controller perché il motore è già provvisto di Xinput e non so se persino DirectInput.

Ora mi manca solo capire quante volte dovrò rifattorizzare il codice :m1a1:
cron