Flash - Gestione di un grande progetto

Question

Stiamo eseguendo la prototipazione utilizzando Autodesk Scaleform e creando la nostra interfaccia utente di gioco utilizzando Flash. Dovremo essere in grado di gestire un grande progetto con un team di 3-4 artisti e 10 o più programmatori. Usiamo il sistema di controllo del codice sorgente Perforce per l'archiviazione di tutto il codice e le risorse. Dobbiamo essere in grado di gestire un progetto con più risorse condivise e più persone (artisti & programmatori) che lavorano su schermi e controlli.

Il nostro problema è il seguente:

Vogliamo essere in grado di creare componenti personalizzati dalla pelle grafiche, quali pulsanti, cursori, caselle di controllo nonché controlli più complessi come le tabelle e gli elementi specifici di gioco. Vogliamo essere in grado di condividere le risorse grafiche in un'unica posizione e consentire a più artisti e programmatori di lavorare su componenti condivisi contemporaneamente. Abbiamo bisogno che tutto questo sia archiviato in un repository di controllo del codice sorgente Perforce.

Per il codice AS3 questo è tutto abbastanza semplice. Funziona come qualsiasi altro codebase e abbiamo creato progetti FlashBuilder e FlashDevelop.

Ora, le opzioni sembrano essere i seguenti:

• Creare un progetto flash o progetti. Il problema qui è che tutte le risorse sono copiate in AuthortimeSharedAssts.fla. Ciò significa che, poiché FLA è un formato binario, il nostro controllo del codice sorgente non può consentire a più di una persona di modificare qualsiasi risorsa condivisa allo stesso tempo.

• Impostare la condivisione manuale dell'autorizzazione. Ciò consentirà di lavorare su più componenti condivisi perché gli utenti possono aggiornare un piccolo file FLA discreto e questo aggiornerà automaticamente una più ampia libreria condivisa. Il problema è che questo non consente la condivisione di risorse grafiche, il che significa che, se un artista aggiorna un grafico, questo non viene filtrato su singoli file flash.

• Utilizzare il formato XFL. Ciò ci consentirebbe di unire i file al momento del check-in per il controllo del codice sorgente in quanto è un semplice testo e consente di salvare singole risorse come file separati, il che sembra perfetto. Il problema è che non riesco a vedere come realizzare un progetto, che utilizza interamente i file XFL (cioè qualcosa come AuthortimeSharedAssets.xfl).

Al momento non riesco a vedere alcun modo ovvio e ragionevole di eseguire un grande progetto in Flash. Non possiamo essere i primi a fare questo genere di cose però.

Qualcuno può aiutare o spiegare come dovremmo farlo?

Answer 1

Direi che XFL sarebbe la strada da percorrere per una squadra così grande, soprattutto quando si utilizza il controllo del codice sorgente.

Per quanto ne so, molti simboli per XFL vengono salvati come .xml nella cartella LIBRARY. Se vengono importati jpg o altri bitmap, viene salvato anche il file immagine effettivo.

Non sono stato in grado di incorporare caratteri e salvarli in questo formato, tuttavia, che può essere un grosso problema a seconda di ciò che si sta facendo. Una soluzione a questo è caricare dinamicamente i tuoi font, come discussed here. Quale può essere un piccolo inconveniente per i progettisti, ma un piccolo prezzo da pagare se si considera ciò che si ottiene utilizzando il formato XFL quando ci sono così tante persone coinvolte nel progetto.

Vorrei anche raccomandare di precompilare (creare componenti) di alcune parti del progetto.

Spero che questo aiuti.

Answer 2

Ci sono poche altre opzioni. Non sto dicendo che sono migliori, ma, a seconda del team e quanto puoi investire nello sviluppo dei tuoi strumenti di sviluppo ... OK, ecco una porta di SWFMill in HaXe: http://code.google.com/p/hxswfml/. Ciò consente di rappresentare le risorse grafiche come file di testo (XML). Forse sarebbe possibile aggiungere un plugin per Incscape per esportare la grafica in questo formato ... Quindi penso che lo these folks avesse il proprio formato e strumenti per la gestione delle immagini visive. Il compilatore Flex SDK può effettivamente tradurre in modo decente SVG in una grafica flash.

Infine, e l'opzione più probabile vorrei indagare, avrei avuto abbastanza tempo, è il formato FXG. Il compilatore Flex può compilarlo, tuttavia, richiede ancora alcune patch per rimuovere tutta la roba relativa alla struttura Flex da ciò che esce da FXG. Il vantaggio di FXG tuttavia è che programmi come Photoshop, Illustrator, Indesign ecc possono esportare in questo formato. Naturalmente, questo è per lo più non testato ... e in qualche luogo temo che FXG sia stato progettato per il prodotto Adobe che è stato sospeso di recente (Catalyst). Tuttavia, esiste la possibilità che il formato stesso rimanga il formato di interscambio per i programmi Adobe, quindi non è necessario eseguire il check-in nel FLA.

Il modo in cui lavoro con gli artisti grafici: non controlliamo mai in FLA, invece, controlliamo nel SWC e rendiamo una regola che chiunque lavori su un progetto deve controllarlo e importarlo. Questo non aiuta molto quando più di una persona ha bisogno di lavorare sullo stesso simbolo, ma, almeno, sono tutte nello stesso posto ed è possibile lavorare simultaneamente, se si stanno modificando cose diverse (cosa che accade la maggior parte tempo comunque).

Answer 3

Questo potrebbe non essere un'opzione per la tua squadra ma lo suggerirò, come è stato (nella mia esperienza) un approccio di project management di grande successo.

Quando si effettuano scelte infrastrutturali di grandi dimensioni come questa, si paga per entrare nelle erbacce e vedere i problemi che si sta tentando di eliminare. Detto questo, porta la mia spiegazione qui.

Gli ostacoli principali che si hanno sono 1) bloccare e modificare file FLA di grandi dimensioni che non possono essere uniti e 2) impedire duplicazioni/conflitti di versioni di MovieClip e classi all'interno di tali file. I conflitti possono essere autentici (i FLA hanno simboli di libreria scaduti da lib di autenticazione authortime) o quelli di runtime (file SWF compilati con versioni in conflitto delle stesse classi, causando arresti anomali del runtime).

La soluzione, secondo la mia esperienza, è 1) inserire il minor numero possibile di codici nei file binari (FLA), 2) associare il codice classe ai MovieClip nel più breve tempo possibile e 3) scrivere il proprio codice codice dell'applicazione per eseguire "l'associazione tardiva" con garbo. Ciò significa utilizzare le librerie di runtime al posto di quelle authortime. Non mi preoccuperei di provare soluzioni che trattino i binari come testo per motivi di fusione; invece, minimizza e isola il ruolo che gli FLA svolgono nel tuo codice. Tienili separati.

Se possibile mi sento di raccomandare il vostro team usa la seguente strategia:

1. Nella tua produzione (non-biblioteca) file FLA, il lavoro con i clip filmato "Visualizza". I clip "Visualizza" sono tutti arte e animazione; non hanno legami di classe e il minor numero possibile di codice. Ad esempio, se il tuo artista può aggiungere un simbolo di BouncingBall allo stage con un link a BouncingBall.as, aggiunge invece BouncingBallView senza link (nome di classe generato BouncingBallView con la classe base MovieClip).
2. Nella libreria SWF (che può essere puro AS), scrivere le classi Mediator per avvolgere queste viste. I mediatori "avvolgono" le istanze delle clip View in fase di esecuzione, esponendo le proprietà dell'oggetto vista al resto dell'applicazione e agendo efficacemente come un collegamento di classe libreria.Ad esempio, devi scrivere BouncingBallMediator.as invece di BouncingBall.as, e in quella classe Mediator hai messo tutta la logica dell'app per far rimbalzare le palle.
3. Configurare l'applicazione per caricare le librerie SWF in fase di esecuzione con tutte le classi (come BouncingBallMediator). Quindi, quando un'istanza di BouncingBallView viene visualizzata sullo stage, l'applicazione crea una nuova istanza di BouncingBallMediator e assegna l'oggetto BouncingBallView a esso. Questo disaccoppia correttamente la vista (simbolo della libreria MovieClip) dalla sua logica di controllo (nel file di classe BouncingBall.as). In tal modo viene eliminato il bagaglio esasperante delle classi di collegamento al file FLA.

Questo approccio ha molti vantaggi, ma in poche parole permette agli sviluppatori e le vostre artisti di lavorare in modo indipendente con meno preoccupazione per i conflitti di controllo di versione tra i file di classe e di arte. Gli artisti non lavorano mai con FLA che hanno codice e gli sviluppatori hanno il controllo di cui hanno bisogno per ridurre al minimo la probabilità di definizioni di classi duplicate/in conflitto tra i file SWF. Tutti si concentrano maggiormente su ciò che sanno fare meglio.

I progetti con cui ho lavorato tendono ad andare molto bene, a patto che il deviatore principale al timone non riesca a intorpidire la strategia di disaccoppiamento di cui sto parlando. Chiedo scusa per la risposta super verbose; HTH.

Answer 4

Non posso raccomandare la condivisione Authortime in quanto non sono stato in grado di utilizzare tutti i componenti dei vari swc del mio progetto. La ragione è dopo diversi giorni di investigazioni piuttosto strane.

Almeno un componente (ad esempio una finestra di dialogo) lancia sempre Errori di tipo quando utilizza componenti condivisi authortime (ad esempio un pulsante) e il componente condiviso ha un nome di instanza. Tutto funziona bene fino a quando non assegni alcun nome istanza ai componenti condivisi all'interno dei componenti che hai collegato tramite actionscript e istanziato più avanti nel tuo progetto.

L'obiettivo era quello di suddividere un enorme * fla in diversi più piccoli, condividendo le risorse in modo automatico in modo che le modifiche siano condivise tra le fiche più piccole e il compilatore (non runtime!) Non duplichi quelle classi. Funziona alla grande, anche quando si usano in massa link di actionscript e baseclass personalizzati. (disattivate automaticamente però le istanze dello stage). Il compilatore esclude con successo tutte le classi duplicate causate dalla condivisione. Puoi controllarlo facilmente guardando in ogni swc incluso.

Per riprodurre semplicemente il problema è necessario effettuare 2 fla. ognuno con un Movie Clip (ad esempio una finestra di dialogo) e uno condiviso. (ad esempio un pulsante, un fla condivide il pulsante con l'altro). Assegna tutti i componenti actionscript-linkage. Metti il ​​pulsante su ciascuna finestra di dialogo e assegna a ciascuno dei pulsanti un nome istanza. Compilare sia fla che swcs, includerli nel progetto e provare ad instanciare entrambe le finestre di dialogo. Uno di questi lancia un errore di coercizione di tipo # 1034. Rimuovere (uno dei) i nomi di pulsanti e funzionerà.

Per avere un'idea - heres a screenshot (full size):

La mia ipotesi è che finché non instancename è impostato, il flash non si preoccupa che cosa digitare il tasto è in realtà e la tratta come clip filmato, ma quando viene impostato un nome istanza, il giocatore prova a digitare il Movie Clip sul tipo specificato. Ma per qualche motivo non guarda l'intero spazio dei nomi (?) Ma solo nel swc la finestra di dialogo è stata compilata. Concludo questo perché quando il pulsante è stato compilato in swcA ma non in swcB, la finestra di swcA funziona ma non il dialogo da B e viceversa. Puoi "forzare" il pulsante per scambiare swc ricompilando il fla in cui desideri inserire il pulsante.

L'ho eseguito anche in rari casi che riguardano più di solo 2 fla/swc. Ma non ho idea del perché.Forse indago un po 'più a fondo, ma ho già perso un bel po' di tempo.

Spero che trovi una buona soluzione (e la pubblichi: P) perché abbiamo lo stesso problema di te.

---

€: L'errore (? Solo) sembra verificarsi se anche aggiornati il ​​componente condiviso una volta

€€: e solo se si esporta il file SWC mentre un altro fla con il componente condiviso è aperto (??)

Answer 5

Ho quasi gli stessi problemi ora che hai! Sto lavorando a un gioco che ha tutte le risorse grafiche in un enorme file FLA che viene esportato come libreria SWC. Il mio problema è che vogliamo suddividere questo enorme file in molti più piccoli e quindi creare un nuovo file FLA per ogni nuovo schermo.

Stiamo utilizzando RSL per condividere le risorse tra diversi file FLA. Es. fonts.fla sta avendo tre font nella libreria esportata per la condivisione in runtime. graphic_hsl.fla contiene grafica ad alto punteggio e con l'importazione di fonts.swc per la condivisione in runtime. Dovresti pensare a RSL dato che ti danno la possibilità di modificare le risorse grafiche in un file e verrà automaticamente aggiornato ovunque tu lo abbia usato in altri file FLA.

Abbiamo provato con il formato di file XFL, ma alla fine siamo passati a FLA perché il controllo della versione non è veramente utile con XFL. Ha una struttura molto complessa e il cambio di file da due computer diversi allo stesso tempo praticamente rompe le cose! Quindi niente unione con SVN, Git o qualsiasi altra cosa tu stia usando!