New World Order is the game most directly associated with this domain’s earlier life. The surviving GAMES.CZ game record identifies Termite Games as developer, Project 3 Interactive as publisher and this domain’s /new_world_order/ route as the game’s homepage. Its dated coverage places the title in the early-2000s PC multiplayer-shooter landscape.
That record is a useful starting point, not a complete production history. A catalogue entry, a preview and a review were written for different purposes. They may describe different builds or use a regional release date. A careful retrospective keeps those distinctions rather than merging every date into a single authoritative timeline.
What can be preserved here
This page restores useful context at an important historical address. It does not restore the former developer’s service, claim ownership of the game or offer downloads of uncertain origin. Old image links, forum pages and executable files are not replaced with invented equivalents.
For further research, record the date and publication type of each contemporary item. Separate announcements from evidence of release, and distinguish a reviewer’s observation from a developer’s claim. If a source describes a demo, retain that qualification when discussing its mechanics or performance.
After the Loading Screen is an independent publication. Our interest extends from this historical connection to the preservation of PC-game evidence: manuals, release notes, interfaces and accounts of play. The question is not how to make an old game sound newly available, but how to describe what survives without filling the missing parts with confident fiction.
A game history can contain a gold announcement, a first regional launch, a later boxed edition and a patch that changed what players experienced. Compressing them into one date may simplify a paragraph while making a comparison misleading.
Build a timeline with an event column as well as a date column. “Announced”, “shipped”, “review published” and “version updated” should remain distinct labels. If a source gives only a month, do not invent a day to make the table look tidy. If two sources disagree, record both and investigate their scope.
Start with the event, not the empty date cell
What happened on the date you are recording? A document has a publication date, and it may describe a separate event. Write both. “A notice published on 3 April expected a May release” is a narrower statement than “the game was released in May”. It preserves the difference between an expectation and an observed event.
The small case below is entirely invented. Its notices, dates, regions and version labels are teaching examples, not recovered evidence about New World Order or any other game. We have three documents concerning one unnamed game. The task is to write the most precise timeline those documents support, including what they leave unresolved.
A / Announcement · 3 April 2004
A short notice says a boxed edition is expected “in May”. It names no territory, day or build.
B / Shipping notice · 2 June 2004
A later notice says the boxed edition has shipped in Region North. It does not state the first day that a customer could buy it.
C / Review · 18 July 2004
The reviewer identifies the tested build as 1.1. The text does not say when that build became available or whether it was supplied on the first discs.
Our fictional three-document exercise. The open space is missing evidence, not an interval measured from a real game’s release.
Notice A belongs on 3 April as an announcement. Its expected May window can be recorded as a second, explicitly provisional item. Notice B supports a regional shipping statement by 2 June, not a worldwide launch day. Review C belongs on 18 July as a publication that describes build 1.1. The review date is not the patch date.
Keep the source’s level of precision
What should you enter when the source gives only a month? Write “May 2004, expected” in the event note. Do not substitute 1 May or 31 May. A sortable spreadsheet may tempt you to enter a day, but the display must not turn a convenience into a factual claim. A separate text field for the stated date and another for its precision can prevent that mistake.
In this case, a compact catalogue entry could have the fields document date, event described, event date as stated, territory, edition/build and qualification. For A, the event-date field is “May 2004”; the qualification is “expected; territory unspecified”. For B, it is “shipped by the notice dated 2 June”; the territory is Region North. Empty build fields stay empty or say “not stated”.
This is a proposed note-taking format, not a claim that every archive uses these labels. Its purpose is to preserve enough context for somebody else to see how the sentence was derived. Our one-source research card supplies a shorter printable starting point.
Decide whether a disagreement is really a contradiction
Does the June shipping notice disprove the expected May release? These three documents cannot answer that. A forecast might have changed; one territory might have shipped later; a small release might have preceded the notice. Those are possibilities to investigate, not facts to add. The two statements have different scope and different status.
A responsible note would say that A records a May expectation and B records shipping in Region North by 2 June. It would not silently choose May because it is earlier, or June because it looks more precise. To resolve the first-sale question, seek evidence explicitly addressing availability, edition and territory. Record whether a later source is repeating an earlier report or supplying its own observation.
Keep a disagreement log beside the timeline. One useful entry has four parts: the exact question, the two claims, the difference in their scope, and the evidence that would settle it. “What was the first retail availability date in Region North?” is answerable in a way that “Which date is right?” is not.
The version belongs in the account
Can build 1.1 in the July review describe the original release? Not on this evidence. We know what the reviewer says they used, but not when it was distributed or what changed before it. Hardware, region and edition can matter too. Keep those qualifiers beside a claim about behaviour instead of placing all uncertainty in a footnote.
For our invented case, the entry for C should read “review of build 1.1, published 18 July”. If it describes a menu or a particular response, attribute that observation to the reviewed build. Do not apply it automatically to every boxed copy. A manual’s instructions would add another kind of evidence, but would still describe intended behaviour rather than prove that every build behaved identically.
The same care applies to a correction notice. Its date may establish when an explanation was published, while the software change happened earlier. Record what the source actually dates. You can add a second event later when a source supports it; you do not need a complete chronology before the first careful note is useful.
Finish with a short account and an open question
What can we now say without filling the gaps? In the fictional example, an April notice anticipated a May release without a territory. A June notice reported regional shipping, and a July review discussed build 1.1. The first sale date and the distribution date of that build remain unestablished. That is the entire supported account.
For a real project, save each source address, publication date, relevant page or section, and a short note explaining what it establishes. Do not copy whole articles into a public archive without permission. Keep quotations separate from your paraphrase and retain the source’s qualifications.
One well-documented title is more useful than hundreds of unsupported dates. The resulting timeline may look incomplete. A visible gap invites a source; invented precision makes the next researcher undo work that should never have been asserted.
