Allora, per ogni punchout custom devi fornirgli tre file: fronte, retro e taglio, ad esempio per uno small punchout, devi avere come risultato due file png 975 x 1575 pixel, e un file svg per il taglio. Partendo dal layout inkscape che forniscono loro (che mostra solo la safe zone, dato che il taglio sarà personalizzato), la procedura standard sarebbe quella di metterci tutte le immagini che vuoi ottenere, disegnare con lo strumento linea (o linea a mano libera) tutte le linee di taglio su un diverso livello, nascondere il livello di taglio ed esportare il png, e poi cancellare tutto tranne il livello di taglio, renderlo visibile, e salvare il file.
E considera che ogni pedina dovrebbe avere tre o quattro “nick”, ovvero interruzioni nella linea di taglio, che servono per mantenere attaccata la pedina al foglio. Da quello che ho visto negli esempi, il custom punchout non è stato pensato per realizzare counter da wargame, anche perché temo che lo sfasamento che potrebbe avere la linea del taglio sia di molto superiore all’intervallo che hai tra una pedina e l’altra nel tuo file (negli esempi della TGC si vede che lasciano molto più spazio tra la linea di taglio e il disegno sulla pedina).
Il mio consiglio è quello di rinunciare ai custom punchout (quindi niente pedine rettangolari) e usare i punchout standard quadrati e circolari, che ti evitano di dovergli fornire anche i file di taglio.
Ti faccio un esempio con le pedine (chit) da un pollice di lato, la logica che utilizzano è la stessa per tutto:
Questa è un’immagine 375×375 pixel, che verrà tagliata sul contorno rosso, e il risultato sarà 300×300 pixel, esattamente un pollice a 300 dpi. Dato che il taglio non è mai perfetto, ci può essere un po’ di scostamento, per cui tutto quello che tu vuoi che appaia nel chit deve essere necessariamente all’interno del quadrato azzurro, ovvero, se metti qualcosa al di fuori del quadrato azzurro, potrebbe essere tagliato via.
Nota che nell’immagine che carichi (che deve essere rigorosamente 375×375 pixel) non devono esserci disegnati né il rettangolo rosso né quello azzurro, e lo sfondo deve estendersi fino ai bordi dell’immagine.
Mi son stampato ieri le carte e notavo che non sono esattamente simmetrici i vari set. Pensavo di trovare 5 set da 1 a 11 (in realtà uno da 1 a 10 essendo 54 carte in tutto) per ogni simbolo ma così non è, a tutti i set manca almeno un numero dall'1 all'11 e ne hanno doppi (tipo due 4 e manca il 5 e così via). E' una cosa voluta? Non che sia chissà che differenza ma sbilancia un poco il tutto.
Sì, la distribuzione non è perfetta perché non volevo set uniformi al 100%. Poi il mazzo in teoria è in continua crescita, ad ogni nuovo numero di ILSA c'è una carta in più
Mi mancavano i contest di ILSA, penso proprio che parteciperò. Immagino che per essere pronto per PLAY e considerati i tempi biblici di TheGameCrafter il mazzo sia già stato stampato, giusto? Quindi non è consentito modificare la grafica?
Esattamente, ma così avete una vera sfida (ma non è necessario usare tutti gli elementi presenti su una carta, se ideate un regolamento che ne usa solo qualcuno).
Potrebbe esserci un bug per il quale se fai built deck con il cursore alla riga 10 di 30 (perchè magari hai appena fatto una modifica) non esegue i comandi dalla riga 11 alla riga 30?
Togli la spunta dalla casella “Partial”, la causa è quella (se la togli ti fa compilare tutto, e non solo fino alla riga del cursore).
Un paio di giorni fa avevo notato lo stesso errore, e andando a fondo ho visto che era dovuto alla nuova versione di GIMP, che aggiunge i thumbnail alle immagini.
Hai Excel o LibreOffice? Di base ti conviene mettere tutti i testi delle tue carte in un foglio di calcolo, una riga per ogni carta, una colonna per ogni tipologia di testo, così diventa molto più semplice gestirli.
Secondariamente, se mi dici quali testi hai in una carta, ti posso far vedere come può essere un layout per nanDECK.
La difficoltà maggiore nel creare una pedina elettronica è che si tratta di un oggetto abbastanza complesso, prendendo come esempio i Sifteo cube, ogni singolo cubo contiene:
32-bit ARM CPU 128 x 128 color TFT LCD 3-axis accelerometer 8MB Flash Lithium Polymer rechargeable battery 2.4 GHz wireless radio Proprietary near-field object sensing technology
Siamo quasi ai livelli di complessità di uno smartphone, con notevoli costi di progettazione, più che di costruzione. E considerando l'ultimo punto, un cubo non ha la percezione di dove si trova (ma solo dei cubi con i quali è in contatto) per cui non è adatto per fare da pedina, bisogna aggiungere una tecnologia simile a quella delle tavolette grafiche per dargli questa informazione (e quindi avere qualcosa di simile a una tavoletta grafica come plancia).
Perché il progetto ora è morto? Facendo qualche ricerca avevo trovato un prezzo di $149 per tre cubi, e $50 a cubo significa poter fare solo giochi molto semplici, con pochissimi pezzi (dieci pezzi per giocatore significa un costo totale di $1000). Quando si riuscirà ad abbattere i costi a un decimo diventerà più fattibile e magari qualcuno tornerà a pensarci su.
-- //and
Autore
Post
Stai visualizzando 15 post - dal 1 a 15 (di 174 totali)