In alcuni video (non solo riguardanti il multiplayer) ho visto utilizzare le ds_map per questo scopo. Il che avrebbe moooolto senso se le mappe (o dizionari) fossero implementate nella maniera ottimale, ovvero con tempo di accesso O(1).
Tuttavia per sbaglio ho aperto la documentazione di gm ed ho trovato una frase orribile:
... momento di silenzio...Maps are not sorted in any (recognisable) way, meaning that to find a certain key you may have to iterate through the whole thing (which is very slow).
E io ero del tipo "WTF???"
Cioè sul serio, se proprio non utilizzi l'implementazione ottimale almeno usa una sorted_list così impieghi al più O(log(n))!!!
Spoiler
Immagino il sorrisetto del mio prof di algoritmi se leggesse questo post... vabbè. Adesso so cosa aggiungerò alla mia libreria "coding utilities", ovvero una "ds_at_least_decent_map()"
Comunque torniamo a noi. Vista questa porkata che da gm non mi aspettavo di vedere (o forse si) ho pensato ad un sistema di indexing alternativo. L'idea più banale è quella di fare lo stesso implementandosi una mappa decente con tempo di accesso O(1). Poi però mi sono detto che mi piace fare il precisino, e i <3 ottimizzazioni marginali, quindi perché ignorare il peso dei fattori moltiplicativi? Credo sia abbastanza intuitivo che l'accesso all'i-esimo indice di un array sia ben più rapido dell'accesso ad un valore in una mappa/dizionario.
Ecco il sistema che ho pensato: (vado con pseudo codice mezzo c++esco meticciato a gml)
NOTE:
l'id custom è indicato con _id
Spoiler
Spoiler
Spoiler
Spiegazione:
C'è un array per l'accesso alle istanze a partire dall'_id (che è esattamente l'indice nel detto array)
C'è una coda vuota che conterrà gli id già predisposti nell'array ma non utilizzati.
C'è un intero che indica il corrente valore massimo.
Quando si aggiungono istanze, finché la coda è vuota si utilizzerà il massimo come nuovo id e si incrementerà il massimo.
Quando si rimuove un'istanza il suo indice nell'array indicherà noone e l'indice stesso verrà enqueuato nella coda.
Se aggiungo un'istanza e la coda non è più vuota significa che ci sono "buchi" nell'array e quindi è più conveniente riempire quei buchi piuttosto che ingigantirlo. Prendo quindi l'indice inutilizzato e piazzo lì l'istanza.
In teoria in un ambiente dinamico con molte cose che si creano e si distruggono spesso (tipo proiettili just to say) dopo una rapida crescita iniziale dell'array, la dimensione dovrebbe rimanere sempre stabile, e non costantemente crescente.
NOTA: si funzionerebbe esattamente uguale con uno stack, ho usato una coda per sanità mentale mia. In realtà il risultato in termini di efficienza dovrebbe essere esattamente identico.
Ora, la big question è: cosa c'è che non va? Me lo sento, deve esserci un lato negativo in tutto questo cui non ho pensato