MétaCan
Menu
Back to cohort
Record W2023426379 · doi:10.1145/2522968.2522977

Peer-to-peer architectures for massively multiplayer online games

2013· review· en· W2023426379 on OpenAlex

Why this work is in the frame

A frame that forgets how it found something cannot be audited. These are the routes that admitted this work.

affAt least one author lists a Canadian institution in the pinned OpenAlex snapshot.
fundA Canadian funder is recorded on the work.

Bibliographic record

VenueACM Computing Surveys · 2013
Typereview
Languageen
FieldComputer Science
TopicPeer-to-Peer Network Technologies
Canadian institutionsMcGill University
FundersNatural Sciences and Engineering Research Council of Canada
KeywordsComputer scienceScalabilityPeer-to-peerArchitectureMassively parallelRendering (computer graphics)Distributed computingCheatingMultimediaHuman–computer interactionArtificial intelligenceParallel computing

Abstract

fetched live from OpenAlex

Scalability, fast response time, and low cost are of utmost importance in designing a successful massively multiplayer online game. The underlying architecture plays an important role in meeting these conditions. Peer-to-peer architectures, due to their distributed and collaborative nature, have low infrastructure costs and can achieve high scalability. They can also achieve fast response times by creating direct connections between players. However, these architectures face many challenges. Distributing a game among peers makes maintaining control over the game more complex. Peer-to-peer architectures also tend to be vulnerable to churn and cheating. Moreover, different genres of games have different requirements that should be met by the underlying architecture, rendering the task of designing a general-purpose architecture harder. Many peer-to-peer gaming solutions have been proposed that utilize a range of techniques while using somewhat different and confusing terminologies. This article presents a comprehensive overview of current peer-to-peer solutions for massively multiplayer games using a uniform terminology.

Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.

Full frame distilled prediction

Teacher imitation

Not calibrated prevalence, not ground truth. Human validation pending. Learned from the 10,348 direct Codex labels and 10,348 direct Gemma labels. Candidate is the union of thresholded teacher heads; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels or direct frontier model labels.

metaresearch head score (Codex)0.005
metaresearch head score (Gemma)0.015
Version: codex-gemma-dda1882f352aValidation status: machine_predicted_unvalidated
Candidate categoriesMetaresearch, Meta-epidemiology (narrow), Open science
Consensus categoriesMeta-epidemiology (narrow), Open science
DomainCandidate signal: none · Consensus signal: none
Study designCandidate signal: Not applicable · Consensus signal: none
GenreCandidate signal: Methods · Consensus signal: Methods
Teacher disagreement score0.933
Threshold uncertainty score1.000

Codex and Gemma teacher scores by category

CategoryCodexGemma
Metaresearch0.0050.015
Meta-epidemiology (narrow)0.0010.001
Meta-epidemiology (broad)0.0030.001
Bibliometrics0.0010.002
Science and technology studies0.0000.000
Scholarly communication0.0010.000
Open science0.0130.008
Research integrity0.0010.001
Insufficient payload (model declined to judge)0.0000.001

Machine scores (provisional)

The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.

Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.

Opus teacher head0.097
GPT teacher head0.367
Teacher spread0.270 · how far apart the two teachers sit on this one work
Validation statusscore_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from it