1. Questo sito utilizza i cookies. Continuando a navigare tra queste pagine acconsenti implicitamente all'uso dei cookies. Scopri di più.

Stellaris Patch 2.8

Discussione in 'Altri Giochi Paradox' iniziata da ^_AC_^, 8 Settembre 2020.

  1. ^_AC_^

    ^_AC_^ Moderator Membro dello Staff

    Registrato:
    20 Dicembre 2006
    Messaggi:
    2.839
    Ratings:
    +1.208
    Stellaris Dev Diary #181 : Threading and Loading Times
    Saluti a tutti da Paradox Francia!

    A nome di tutto il team Stellaris, spero che abbiate avuto una buona vacanza estiva, nonostante le circostanze attuali.

    Siamo tutti tornati al lavoro, anche se non in ufficio. Saranno un autunno e un inverno molto eccitanti con molte novità interessanti! Non vediamo l'ora di informarvi nel corso delle prossime settimane e dei prossimi mesi!

    Oggi inizio a parlare della prossima patch 2.8, con alcuni dettagli tecnici su cui noi programmatori abbiamo lavorato durante l'estate. Il resto del team svelerà contenuti e meccaniche nei prossimi DD.

    Parliamo quindi di threads!

    Threads? What threads?

    I fan scherzano chiedendosi cosa arriverà prima: Victoria III o un gioco PDS che usa più di un thread.

    [​IMG]

    Purtroppo devo smentire questo mito (per l'ennesima volta): tutti i giochi PDS in produzione oggi usano i thread, da EU4 a CK3. Anche Stellaris!

    Parliamo di storia. Per tanto tempo, l'industria del software ha seguito la "Legge di Moore" secondo la quale una CPU costruita tra 2 anni sarà circa 2 volte più efficiente di una costruita oggi.
    Questo era sicuramente vero negli anni '90 che hanno visto le CPU passare da 50 MHz a 1GHz. Poi le velocità ha smesso di crescere. Nei successivi 15 anni, la frequenza delle CPU è rimasta più o meno quella.
    Le leggi della fisica rendono poco efficiente aumentare la velocità oltre 3-4 GHz. Quindi i costruttori hanno diviso le CPU in vari core e hardware threads. Per questo motivo oggi si guarda più al numero di core e meno alla frequenza. La Legge di Moore è ancora valida, ma, per parlare in termini strategici, l'industria delle CPU ha raggiunto un limite morbido cercando di giocare verticale quindi ha iniziato a giocare orizzontale.

    Questo cambiamento ha effetti anche sull'industria del software, dato che scrivere codice che va più veloce con una CPU più veloce è facile: quasi tutto il codice funziona così. Ma usare thread e core è diverso. I programmi non si dividono magicamente da soli in 2, 4 o 8 per essere eseguiti su diversi core contemporaneamente, quindi sono i programmatori a doverlo fare.

    Threading nowhere faster

    Torniamo quindi alla domanda che spesso leggiamo sul forum: "il gioco sta usando i thread?". La risposta è sì, ovviamente! Infatti li usiamo a tal punto che un paio di release fa abbiamo avuto un grosso problema perché il gioco non riusciva a partire su computer con 2 core o meno.

    Ma la vera domanda è: "state facendo un uso efficiente dei thread?". La risposta è "dipende". Usare i core in maniera efficiente è molto complesse. Nel nostro caso sono due le sfide principali: sequenziamento e ordinamento.

    Problemi di sequenziamento accadono quando 2 computazioni simultanee accedono allo stesso data. Ad esempio facciamo finta di computare la produzione di 2 POP: un Prikki-Ti e un Blorg. Entrambi accedono all'attuale stockpile di energia, aggiungono l'energia da loro prodotti e scrivono il nuovo valore. In base alla sequenze, entrambi potrebbero leggere il valore iniziale (ad esempio 100), aggiungere la propria produzione (diciamo 12 e 3, il Blog ha avuto una pessima giornata) e scrivere il risultato. Idealmente vorremmo ottenere 115 (100 + 12 + 3), ma potenzialmente potrebbero leggere entrambi 100, sovrascriversi tra di loro e alla fine otterremmo 112 o 103.
    Per ovviare possiamo introdurre lock: il Prikki-Ti "bloccherebbe" il valore di energia finché non ha finito i calcoli e scritto il nuovo valore, poi il Blog avrebbe il suo turno e farebbe lo stesso.Questo risolve il problema ma ne introduce un altro: le azioni sono tornate a essere sequenziali e il beneficio di usare thread concorrenti è stato perso. Peggio ancora, il costo di bloccare, sbloccare e sincronizzare i valori probabilmente ha rallentato ancora di più l'esecuzione.

    Il secondo problema è l'ordinamento, ovvero il fatto che cambiare l'ordine delle operazioni cambia il risultato finale. Supponiamo che il Prikki-Ti e il Blorg decidano di risolvere una disputa amichevolmente. Il sistema di combattimento processa entrambi i combattenti ma siccome ci sono centinaio di azioni di combattimento simultanee, non sappiamo l'ordine. E su due macchine diverse l'ordine può essere diverso. Ad esempio sul server il Prikki-Ti action agisce per primo mentre sul client è il Blorg ad agire per primo.

    [​IMG]


    Sul server l'azione del Prikki-Ti è processata prima e uccide il Blog. La successiva azione Blog, probabilmente in esecuzione in un altro thread, viene annullata dato che i Blog morti non possono sparare. Il client invece ha ordinato in maniera diversa (magari ha più core del server) e in questo mondo il Blog ha ucciso il Prikki-Ti per primo, che quindi non ha potuto replicare. A questo punto entrambi i giocatori ottengono il temuto popup “Player is Out of Sync” dato che le due realtà sono divergenti.

    Ci sono modi per risolvere il problema, ma spesso richiedono di ridisegnare il sistema perché soddisfi entrambi i vincoli. Ad esempio nel primo caso entrambi i thread potremo tenere l'output di produzione e poi consolidarlo alla fine. Per i duellanti si potrebbero calcolare i danni immediatamente ma poi avere una fase successiva per verificare gli effetti, rimuovendo la necessità di un ordine.

    Come potrete immaginare, è più facile disegnare qualcosa tenendo conto del threading piuttosto che cambiare un sistema esistente per tenerne conto.

    The good news

    La buona notizia è che applicata nuova logica a un sistema abbastanza vecchio: caricamento di file e asset.

    Per molto tempo abbiamo usato un software di terze parti, che ci ha fatto risparmiare tempo ma che non è efficiente col threading (a volte più lento usando più core a causa dei lock). Ora grazie a delle ottimizzazioni il tempo di caricamento partita è diminuito drasticamente. Questo video vale più di mille parole:



    La comparazione è stata fatto sul mio PC con un i7 2600K e un drive SSD. Entrambi sono avvii "a caldo" (il gioco era già stato avviato in precedenza) ma nella mia esperienza anche in un avvio "a freddo" la differenza è quella

    Per avere avvii più veloci, bisogna usare il nuovo motore di rendering beta di DirectX11. Sì, avete letto bene: la prossima patch avrà anche una beta patch che sostituisce il vecchio renderer DX9 con una più recente versione DD11, già usata dalla versione console di Stellaris. Anche se visivamente non cambia nulla, usare DX11 ci permette di usufruire di varie ottimizzazioni multi-threading non disponbili per DX9. Anche usando il vecchio renderer DX9 si potranno notare miglioramenti alla velocità di avvio, ma con DX11 la differenza sarà molto più evidente.

    Alcune di queste ottimizzazioni sono state applicate anche a nuove versioni del motore Clausewitz e saranno implementate in CK3 al rilascio. Imperator dovrebbe beneficiarne anch'esso. Forse sarà possibile applicarle anche a EU4 e HOI4, ma per ora i miei esperimenti con EU4 non hanno mostrato gli stessi miglioramenti evidenti visti in Stellaris e CK3.

    Se volete conoscere maggiori dettagli tecnici sulle ottimizzazioni applicate per velocizzare l'avvio di Stellaris, potete leggere l'articolo che ho pubblicato di recente sul mio blog.

    Questo è tutto. Quello di oggi sarà forse il mio ultimo DD per Stellaris, dato che dal mese prossimo andrò a guidare i programmatori di HOI4. Potete considerare queste ottimizzazioni il mio regalo d'addio.
    Anche se ho passato poco tempo su Stellaris, non vi preoccupate: anche se me ne vado, Jeff rimarrà ancora qui con voi!
     
    • Informative Informative x 2
  2. ^_AC_^

    ^_AC_^ Moderator Membro dello Staff

    Registrato:
    20 Dicembre 2006
    Messaggi:
    2.839
    Ratings:
    +1.208
    Stellaris Dev Diary #182 : The Perils of Scripting and How to Avoid Them
    Ciao a tutti, sono Caligula, uno dei Content Designers di Stellaris, ovvero lavoro sulla scrittura narrativa e sullo scripting. Lo scripting è un termine da noi usato per indicare qualcosa di simile alla programmazione ma senza cambiamenti al codice sorgente. In altre parole, faccio quello che fanno i modders (anche se ho il vantaggio di poter leggere il codice sorgente e di poterlo cambiare se necessario). Ogni Content Designer ha la sua nicchia, e la mia è risolvere problemi di scripting in sistemi particolarmente complicati (come la War in Heaven).

    Ora, abbiamo un sacco di cose eccitanti da mostrarvi nelle prossime settimane e nei prossimi mesi, ma oggi, ispirato da alcune domande poste dopo l'ultimo DD, vorrei parlare del lato tecnico dello scripting per modder e aspiranti tali, soprattutto con un occhio rivolto alle prestazioni e a come evitare pessimi script.

    Il linguaggio di scripting di Stellaris è un tool molto potente, ma attenzione: solo perché si può fare qualcosa, non vuol dire che si debba farlo. Questo è importante per evitare problemi di prestazioni e script illeggibili e difficili da decifrare. Quindi la prima domanda da porsi: devo proprio fare questa cosa?

    Ma cosa dico, sto parlando con modder, quindi ovviamente lo farete.

    Procediamo...

    Cosa causa problemi di prestazioni?

    Ogni volta che fai un controllo o esegui un effetto, questo richiede parte del potere di processamento del tuo computer. Con alcune eccezioni che dovrebbero essere rare (ne parlo dopo) questo non dovrebbe essere un problema. Lo diventa se il controllo è ripetuto troppo spesso, su molti elementi. In pratica di solito sono i POP la causa, ma anche controllare tutti i pianeti della galassia non è una buona idea.

    Il primo step, quando possibile, è controllare quando lo script viene lanciato. Il modo migliore è settare quando gli eventi sono lanciati e usare on_actions (o lanciare eventi da decisioni o cose simili) quando possibile, invece del mean time to happen o, peggio ancora, fare in modo che un evento sia lanciato ogni giorno. Se un certo livello di casualità è richiesto, si potrebbe ad esempio lanciare un evento nascosto ogni anno e poi lanciare il vero evento con un ritardo casuale (per un esempio guardate event action.220).

    Ovviamente, non tutto è un evento, e sfortunatamente in Stellaris un sacco di cose richiedono i POP. Pesi dei Lavori e altri trigger nei file dei Lavori hanno causato problemi in passato. Come regola, anche se ottieni effetti super fighi, è meglio evitare di fare script complicati sui Lavori. Ad esempio, se create un peso dei Lavori che dipende dall'assenza di altri POP senza lavoro sul pianeta (usando planet = { any_owned_pop = { is_unemployed = yes } }), allora state creando un controllo regolare su ogni POP del pianeta che controlli ogni altro POP del pianeta, ovvero POP al quadrato. Quando raggiungi la fine di una partita, questo crea sicuramente problemi.

    Quindi cosa si può fare?

    Evitare nested loops, assicurarsi che gli eventi siano lanciati in modi e tempi appropriati ed evitare POP quando possibile sono consigli utili, ma possiamo fare di meglio. Questa è la mia lista di consgili per ottimizzare uno script:

    Usare sempre lo scope più appropriato

    Se ad esempio voleste controllare qualcosa riguardo al leader della federazione dell'impero corrente, in teoria si potrebbe fare nel seguente modo:
    Codice:
            any_country = {
                is_in_federation_with = root
                is_federation_leader = yes
                <my_triggers_here> = yes
            }
    Questo esaminerà ogni nazione per vedere se è in federazione con te, comprese Amebe Spaziali e i vili Pasharti, che sono sicuramente irrilevanti. Quindi un trigger migliore sarebbe:
    Codice:
            any_federation_ally = {
                is_federation_leader = yes
                <my_triggers_here> = yes
            }
    In termini di codice, il gioco va dall'impero alla federazione, prende i membri, esclude l'impero corrente e controlla i trigger per ognuno di esse. Di sicuro meglio di prima. Ma si può ancora migliorare:
    Codice:
            federation.leader = {
                <my_triggers_here> = yes
            }
    Questa versione va direttamente alla federazione e da lì direttamente al leader. É più veloce, ma anche molto leggibile.

    In questo il gioco controllerebbe circa 50 imperi nel primo caso, 5 nel secondo e 1 nel terzo - non male come ottimizzazione! Usando una logica simile, è sempre meglio usare qualcosa che non controlla tutti gli oggetti della galassia (soprattutto tutti i POP o tutti i pianeti), ma una lista già filtrata, e.g. any_planet_within_border invece di any_planet = { solar_system.owner = { is_same_value = prevprev } } (voi ridete ma io l'ho visto). E nella maggior parte dei casi si può usare any_owned_fleet invece di any_owned_ship.

    Un'altro importante miglioramento aggiunto nella 2.6 è stato any_owned_species, che può sostituire molte volte any_owned_pop (in particolare per controlli sui tratti) ma con molti meno controlli (soprattutto in imperi xenofobi).

    A volte puoi evitare completamente gli scope


    Se puoi effettuare controlli su qualcosa senza usare scope, è sempre meglio. Se voleste controllare se un pianeta ha più di 2 POP che lavorano come minatore, potreste farlo in due modi:
    Codice:
            count_owned_pop = {
                count > 2
                limit = {
                    has_job = miner
                }
            }
    Codice:
            num_assigned_jobs = {
                job = miner
                value >= 2
            }
    Il primo controlla ogni POP del pianeta e guarda se fa il minatore e poi controlla se il numero è maggiore di 2. Il secondo controlla un numero già memorizzato e calcolato dal gioco e controlla se è maggior di 2, cosa molto più veloce.

    Alcune cose sono sempre costose


    Non ogni controllo o effetto è uguale agli altri. Controllare un flag o un valore di solito è abbastanza semplice e cambiarlo non è normalmente molto più complicato. Però se il gioco deve ricalcolare cose, allora richiederà più tempo. Creare nuove cose è ancora più costoso, sia perché più complicato (l'effetto create_species effect sono più di 600 linee di codice C++) sia perché probabilmente al termine richiederà di ricalcolare altri valori. Può essere difficile sapere quali controlli e quali effetti sono problematici, ma questi sono i casi da evitare:
    • quando si crea un nuovo scop e.g. create_country, create_species, modify_species
    • quando si crea o ricalcola pathfinding (e.g. can_access_system trigger, creating new hyperlanes, especially creating new systems)
    • quando si calcolano POP (cambiare lavori dei POP ad esempio)

    Se proprio dovete...


    A volte, uno sporco lavoro bisogna pur farlo. In questi casi, meglio usare gli strumenti a disposizione con precisione. Ad esempio nello scrivere i controlli di un evento, di solito si ferma al primo controllo fallito (tecnica del “short-circuit evaluation”), quindi meglio fare qualcosa del genere:
    Codice:
        trigger = {
            has_country_flag = flag_that_narrows_things_down_loads
            <something really horrible here>
        }
    Di recente ho fatto qualcosa di simile per l'effetto dei POP rifugiati. In precedenza era abbastanza malato (guardate 01_scripted_triggers_refugees.txt per l'orrore attuale). In totale, controllerebbe una variazione del seguente codice almeno 8 volte:
    Codice:
            any_relation = {
                is_country_type = default
                has_communications = prev #relations include countries that have made first contact but not established comms
                NOT = { has_policy_flag = refugees_not_allowed }
                prevprev = { #this ensures Pop scope, as root will not always be pop scope
                    OR = {
                        has_citizenship_type = { type = citizenship_full country = prev }
                        has_citizenship_type = { type = citizenship_caste_system country = prev }
                        AND = {
                            has_citizenship_type = { type = citizenship_limited country = prev }
                            has_citizenship_type = { type = citizenship_caste_system_limited country = prev }
                            prev = { has_policy_flag = refugees_allowed }
                        }
                    }
                }
                any_owned_planet = {
                    is_under_colonization = no
                    is_controlled_by = owner
                    has_orbital_bombardment = no
                }
            }
    
    L'unica differenza era nell'ultimo any_owned_planet: all'inizio cerca un ottimo pianeta dove far vivere i POP, poi uno buono, poi uno decente e infine si accontenta di qualunque pianeta. Questo è molto inefficiente, dato che la lista di nazioni che accolgono rifugiati non cambia nelle 8 volte in cui si fa il controllo. Per evitare la situazione e rendere il tutto più leggibile, ho aggiunto un flag prima di ogni controllo, in questo modo:
    Codice:
            every_relation = {
                limit = {
                    has_any_habitability = yes #bare minimum for being a refugee destination
                }
                set_country_flag = valid_refugee_destination_for_@event_target:refugee_pop
            }
    
    
    

    Il controllo diventa “la nazione ha il flag? Se sì, ha un pianeta adatto?”:
    Codice:
    has_good_habitability_and_housing = {
        has_country_flag = valid_refugee_destination_for_@event_target:refugee_pop
        any_owned_planet = {
            habitability = { who = event_target:refugee_pop value >= 0.7 }
            free_housing >= 1
            is_under_colonization = no
            is_controlled_by = owner
            has_orbital_bombardment = no                            
        }
    }
    
    

    Si possono utilizzare if-limit e else (e se possibile switches - ottimi per le prestazioni) nei controlli per circoscrivere meglio il perimetro e rendere il tutto più leggibile. Di recente ho cambiato tutti i file dei diritti delle specie e modificato tutti i trigger:

    (prima)
    Codice:
            custom_tooltip = {
                fail_text = MACHINE_SPECIES_NOT_MACHINE
                OR = {
                    has_trait = trait_mechanical
                    has_trait = trait_machine_unit
                    from = { has_valid_civic = civic_machine_assimilator }
                }
            }
            custom_tooltip = {
                fail_text = ASSIMILATOR_SPECIES_NOT_CYBORG
                OR = {
                    NOT = { from = { has_valid_civic = civic_machine_assimilator } }
                    AND = {
                        OR = {
                            has_trait = trait_cybernetic
                            has_trait = trait_machine_unit
                            has_trait = trait_mechanical
                        }
                        from = { has_valid_civic = civic_machine_assimilator }
                    }
                }
            }
    
    
    

    (dopo)
    Codice:
            if = {
                limit = {
                    from = { NOT = { has_valid_civic = civic_machine_assimilator } }
                }
                custom_tooltip = {
                    fail_text = MACHINE_SPECIES_NOT_MACHINE
                    OR = {
                        has_trait = trait_mechanical
                        has_trait = trait_machine_unit
                    }
                }
            }
            else = {
                custom_tooltip = {
                    fail_text = ASSIMILATOR_SPECIES_NOT_CYBORG
                    OR = {
                        has_trait = trait_cybernetic
                        has_trait = trait_machine_unit
                        has_trait = trait_mechanical
                    }
                }
            }
    
    
    

    La seconda versione è più efficiente e i controlli sono più leggibili.

    Felice anno nuovo!
    Non posso scrivere questo DD senza citare il bug "Felice Anno Nuovo". In pratica durante una partita MP tra dev in una galassia estesa e a fine partita, giocando da remoto con molte velocità diverse le prestazioni erano un po' lente, ma accettabili. All'improvviso abbiamo notato una pausa di circa 20 secondi al 1 Gennaio. La pausa era così lunga che per passare il tempo ci auguravamo Buon Anno in attesa che il gioco riprendesse.

    La pausa era dovuta al fatto che molti grandi imperi avevano deciso di diventare sintetici e assimilare i propri POP. L'assimilazione avviene tramite script... cosa forse non molto corretta... e lanciano un evento di assimilazione ogni 1 Gennaio. Poi questo evento lancia un evento per ogni pianeta che seleziona un po' di POP del pianeta e usa modify_species su ciascuno di essi da 1 a 4 volte. Questa era la causa del rallentamento!

    Dopo molti tentativi, la nostra soluzione migliore è usare prima every_owned_species dal country scope, controllare se la specie va assimilata, e quindi usare modify_species per creare la specie di destinazione, settando un flag col la specie di origine. Quindi lo script è stato modificato per cercare la specie di origine e usare change_species su di essa. Lo script rimane illeggibile (vi risparmio la tortura), ma riduce la pausa annuale del 50%, perché l'effetto più complicato (modify_species) è usato il meno possibile.
     
    Ultima modifica: 15 Settembre 2020
  3. ^_AC_^

    ^_AC_^ Moderator Membro dello Staff

    Registrato:
    20 Dicembre 2006
    Messaggi:
    2.839
    Ratings:
    +1.208
    Stellaris Dev Diary #183 : Memory Allocation
    Drone Cronista Unità-W3 spazzò la piazza, come ha sempre fatto ogni 10 giorni a partire dalla sua creazione. Prima di allora, Unità-V3 ha eseguito questo compito finché un muro fatiscente non lo schiacciò sotto una tonnellata di macerie. La prima missione di Unità-W3 fu di rimuovere quelle macerie.

    Il Mollarnock Commonwealth è stato in passato un potente impero con dozzine di pianeti, governato dalle scintillanti spire della sua capitale, l'ecumenopoli Azure Chalice. Il Chardin Process creò un Director, una coscienza gestalt consciousness che fu in grado di coordinare i molti servitori machine del Mollarnock. Essi faticavano in modo che i padroni Mollarnock potessero concentrarsi su arti, scienze e filosofia.

    [​IMG]

    Ma tutto è destinato a cadere.


    Le colonie furono distrutte nella Discovery War, ridotte a macerie radioattive da un nemico implacabile. Per negare la vittoria al nemico e per impedire la conquista del gioiello dell'impero, il Cancelliere Rhosen decise di scegliere i termini della propria distruzione e rilasciò una terribile arma biologica, che rese Azure Chalice non abitabile per secoli.

    I secoli passarono.

    I Chardin Mechanicals collezionarono i morti e li internarono nel Santuario del Riposo. Il loro sforzo per mantenere il pianeta fu ammirabile ma destinato a fallire - rovistare, convertire e riallocare materiali ha un limite. Senza un flusso di risorse dalle colonie, stavano perdendo la battaglia per impedire il decadimento.

    Iniziò così un programma per tornare nello spazio un tempo controllato dai loro creatori.

    [​IMG]


    I Mollarnock possono essersi distrutti quattrocento ottanta sette anni fa, ma non saranno mai dimenticati.

    ---

    Stellaris è piena di storie - alcune le raccontiamo noi, ma molte altre emergono dal gameplay.

    Questa è la storia de Mollarnock, distrutti da un terribile nemico, e di coloro che furono lasciati indietro.

    Memorialista è un nuovo civic pianificato per un rilascio futuro. A differenza di altri civic, questo sarà disponibile per imperi normali, machine e sciami. (pare che le Megacorporazioni cerchino di non ricordare le cose a meno che non impatti il Rapporto Trimestrale)

    [​IMG]

    Machine Empire Memorialist Civic

    [​IMG]

    Regular Empire Memorialist Civic

    [​IMG]

    Hive Empire Memorial Civic

    Dedicati al ricordo dei caduti e allo studio dell'inevitabilità della morte, i Memorialisti sostituiscono il set dell'Autochthon Monument con un'altra serie di edifici. Sanctuary of Repose, Pillar of Quietus e Galactic Memorial. Questi edifici forniscono Stabilità e Lavori da Cronista, con benefici addizionali se costruiti su Mondo Tomba o Mondi Reliquia (attrazione per etiche governo nel caso di Imperi Tradizionali, riduzione Devianza per gestalts)

    Memorialisti Gestalt possono avere una visione differente della morte, cercando di capire qualcosa che non possono davvero comprendere.

    [​IMG]

    Sanctuary of Repose Building - Gestalt

    [​IMG]

    Sanctuary of Repose Building - Normal

    [​IMG]

    Pillar of Quietus Building - Gestalt

    [​IMG]

    Pillar of Quietus Building - Normal

    [​IMG]

    Galactic Memorial Building - Gestalt

    [​IMG]

    Galactic Memorial Building - Regular

    Aumenti di stabilità di questo tipo sono molto rari, soprattutto per gestalt. Sui Mondi Tomba e Reliquia abbiamo benefici leggermente diversi

    [​IMG]

    Chronicle Drone Job (Machine - the Hive version is similar but eats food or minerals as appropriate.)

    [​IMG]

    Death Chronicler Job

    I Memorialist (compresi quelli gestalt) potrebbero a volte ottenere risposte più solenni (di solito disponibili solo a Spiritualisti) a certi eventi del gioco, rendendoli più attrattivi per chi vuole giocare con una sciame leggermente diverso.

    Settimana prossima vedremo fino a quanto si spingono le Megacorporazioni per massimizzare i profitti e dare un'occhiata al Mishar Cabal.

    ---

    Chardin era il nome dello scienziato con cui ho iniziato la campagna a capo dell'Ingegneria quando ho creato il Mollarnock Commonwealth, quindi tutti i crediti vanno al Chardin Process.
     
  4. ^_AC_^

    ^_AC_^ Moderator Membro dello Staff

    Registrato:
    20 Dicembre 2006
    Messaggi:
    2.839
    Ratings:
    +1.208
    Stellaris Dev Diary #184 : Fwd: Notice of Termination
    Congratulazioni, [Employee.GetFirstName]!

    Dato che hai sempre raggiunto o superato gli obiettivi di performance prestabiliti e avendo ricevuto ottimi voti sia dal tuo superiore che dai tuoi colleghi, sei stato selezionato per essere terminato alla fine di questo trimestre! Il tuo sacrificio è profondamente apprezzato da tutti noi a Dodacorp™, e siamo fortunati a vederti scomparire!

    Il tuo superiore ti contatterà per fornirti le istruzioni relative ai benefici della tua terminazione, riallocare i tuoi crediti pensionistici Dodacorp™ al tuo erede e aiutarti con le scartoffie relativi ai tuoi desideri post-terminazione. Come membro apprezzato di Dodacorp™, ricorda che hai uno sconto dipendente ai servizi crematori dei nostri partner Burnatech™ e non dimenticare che puoi ottenere la tua urna Eternal Interment™ dalla nostra sussidiaria Repositrexx™.

    Chiedi al tuo superiore come poter posizionare la tua urna sul nostro Wall of Honor™, le posizioni più desiderabili stanno scomparendo in fretta!

    Per favore assicurati di completare tutte le formalità richieste per il primo di
    [Employee.TerminationDate.PreviousMonth] per non perderti questa fantastica opportunità!

    Vorremmo ringraziarti ancora per i tuoi servizi qui a Dodacorp™, e apprezziamo il tuo sacrificio odierno che porterà a ottimi profitti futuri!

    Sinceramente,

    [Employee.Division.Supervisor.GetFullName]
    [Employee.Division.Supervisor.GetFullJobTitle]

    [​IMG]


    ---

    Ispirato dalla grande popolarità del nostro DLC di CK2 Sunset Invasion, vogliamo continuare a esplorare il tema del sacrificio con due nuovi civic per il prossimo rilascio, il Culto della Morte e il Culto della Morte Aziendale.
    [​IMG]
    Culto della Morte - sfortunatamente i Curatori non possono selezionarlo

    [​IMG]
    Culto della Morte Aziendale
    - uccisioni rituali per fondi e profezie

    Disponibile per imperi Spiritualisti, questi civic sostituiscono i Templi normali con Templi Sacrificali che forniscono Lavori per Preti della Morte e Iniziati Mortali.
    [​IMG]
    Tempio Sacrificale - strano a dirsi ma cercano sempre nuovi Iniziati

    [​IMG]
    Prete della Morte - dedicati a migliorare le prestazioni del gioco

    [​IMG]
    Iniziato Mortale - i benefici sono fatali!


    I Culti della Morte con Iniziati Mortali hanno accesso a 3 nuovi Editti di Sacrifici che permettono di effettuare Sacrifici rituali per i tuoi dei (o per qualunque forza a cui creda il tuo impero). Non sono deterministici e i risultati possono variare, ma più sangue viene versato e maggiori sono le probabilità di migliori benefici.
    [​IMG]
    Editto Sacrificio: Solidarietà - ricorda i bei tempi che abbiamo vissuto insieme

    [​IMG]
    Editto Sacrificio: Armonia - puoi finalmente ottenere quella scrivania d'angolo che volevi

    [​IMG]
    Editto Sacrificio: Abbondanza - è come fare una purificazione volontaria che non fa irritare la Comunità Galattica


    Sacrificio: Solidarietà e Sacrificio: Armonia hanno un costo base di 50 influenza mentre Sacrificio: Abbondanza ha un costo base di 100 influenza. Questi sono ovviamente modificati da quello che ha normalmente effetto sul costo degli Editti (come il modificatori per Spiritualisti).

    Quando il Sacrificio è compiuto, i Preti della Morte ti informano di quanto è stato ottenuto dal divino.
    [​IMG]
    Avrei dovuto costruire più Templi Sacrificali, questi sono numeri bassi

    Anche se queste società si affidano a sacrifici rituali (una battuta su Sunset Invasion), il tema di questi civic è inteso come sacrificio volontario, dove i sacrificati sono apprezzati e onorati. Pertanto i Fanatici Purificatori non possono selezionarla, avendo probabilmente una politica più... uh... aggressiva.

    So che settimana scorsa ho detto che avrei parlato della Mishar Cabal, ma il nostro giornalista che doveva intervistarli è stato eliminato perché "aveva visto troppo". Ne riparleremo in futuro.

    Settimana prossima riveleremo cosa è scritto nel testo nascosto nei primi due screenshot sopra e forse vi mostreremo anche CENSURATO.
     

Condividi questa Pagina