Gameplay: Difference between revisions
From Rise: The Vieneo Province
No edit summary |
(Integrate arrival and service-sequence brainstorm: optional guidance, clear prerequisites, vehicle readiness, existing skills and rental rules; retain demo boundaries and source archive) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
'''Gameplay''' brings together Rise's earlier design discussions, Bill's player feedback and newcomer proposals, the supplied ''Gameplay1.doc'' and ''brainstorming the Order.doc'' notes and prospecting scenario, and the October 2026 review of player attraction and retention. It is a development reference: it explains the experience these sources point toward and identifies what still needs a decision or testing. | |||
The proposed guiding promise is: '''Become a capable operator whose work helps a living province grow.''' Flying is central, alongside driving, trading, building, planning, and belonging to a community. The satisfaction comes from learning to do something well, seeing why it matters, and making a place in the world. This wording is the 2026 synthesis, rather than a quotation or a previously adopted slogan. ([[#Source-G|G]], [[#Source-B|B]], [[#Source-R|R]]) | |||
'''Reading this article:''' ''Documented'' describes what the linked help pages say; it is not a fresh audit of every live system. ''Recorded direction'' identifies a dated development statement. ''Historical proposal'' records an idea without assuming it was implemented. ''Recommendation'' identifies the October 2026 synthesis for consideration and testing. Consolidating these materials does not approve every proposal as a roadmap commitment. The demo restrictions are a settled constraint for this design work, reaffirmed by Jason on 24 October 2026; [[Demo Limits]] is their authoritative reference. ([[#Source-P|P]]) | |||
== | == What players are here for == | ||
The original audience discussion included simulation, spaceflight, science fiction, business building, an MMO community, and advancement from modest beginnings. Bill's answers give that list a practical meaning: he enjoyed flying, solving construction and supply problems, completing colonies, arriving safely, and helping other players. The earlier discussion with c00p similarly connected flying with contributing to a world and feeling part of it. ([[#Source-G|G]], [[#Source-B|B]]) | |||
'''Skill does not require constant manual control.''' Bill described extensive use of AutoFlyte, punctuated by monitoring, adjustments, and manual landing. His account supports an experience built around judgment and responsibility: choosing the operation, preparing the vehicle, understanding the instruments, managing automation, and intervening appropriately. It does not establish that unattended flight is safe, and its historical flight profiles should not be used as current operating instructions. Today's [[Orbit|orbital guidance documentation]] also makes automation part of Rise's flight experience, with specific capabilities and limits. ([[#Source-B|B]], [[#Source-D|D]]) | |||
The likely audience therefore extends beyond players seeking manual flight challenges. It includes people who enjoy transport operations, logistics, colony development, economic planning, exploration with a practical purpose, and familiar places and people. These are audience hypotheses to test, not measured market segments. | |||
=== | === Core values to strengthen === | ||
The following principles are recommendations drawn from the sources, rather than a claim that Rise has previously adopted a formal values charter. | |||
{| class="wikitable" | |||
! Value | |||
! What it should mean in play | |||
! Basis | |||
|- | |||
| '''Earned competence''' | |||
| Players learn to plan and complete increasingly demanding operations. Training, understandable feedback, and trustworthy automation help them develop that competence. | |||
| Bill's flying and problem-solving; the existing simulators and orbital guidance. ([[#Source-G|G]], [[#Source-B|B]], [[#Source-D|D]]) | |||
|- | |||
| '''A coherent world''' | |||
| Distance, weather, vehicle capability, supplies, and operating constraints affect decisions. The interface makes those relationships understandable. | |||
| The flight and colony accounts, with current orbital and weather-radar documentation. ([[#Source-G|G]], [[#Source-D|D]]) | |||
|- | |||
| '''Useful work and visible consequences''' | |||
| A delivery, survey, or construction project has an intelligible beneficiary and result. Players can see what their work enabled. | |||
| Bill's colony-building account and proposed transport economy. ([[#Source-G|G]], [[#Source-B|B]]) | |||
|- | |||
| '''Lasting attachment and autonomy''' | |||
| Players choose goals and develop a history with vehicles, routes, settlements, and collaborators. Several kinds of achievement can matter. | |||
| Pride in completed colonies, the earlier world-belonging discussion, and the sandbox audience. ([[#Source-G|G]]) | |||
|- | |||
| '''A welcoming, dependable community''' | |||
| Mentoring and cooperation are valuable, while the essential first steps remain understandable when no experienced player is available. | |||
| Bill's help with rentals and loans, his difficulty reaching newcomers through chat, and the guided-start discussion. ([[#Source-B|B]], [[#Source-G|G]]) | |||
|} | |||
== Reconciling the earlier discussions == | |||
=== Apartment arrival and early access to flight === | |||
Bill's newcomer proposal used immigration, an arrival sequence, an apartment hub, transport to services, training, and city-owned vehicles for jobs. The October 2018 Gameplay notes also discussed retaining Bradbury, company vehicles, and making flight visible during arrival. These were related proposals, not a completed specification. ([[#Source-N|N]], [[#Source-G|G]]) | |||
There is a later recorded direction: in February 2020, Jason wrote in ticket 616 that the apartment had been upgraded, the tutorial included it, and the intention was to retain the apartment start while guiding players to the simulators promptly. The ticket was subsequently closed as ''won't fix''. Its title, "Need to start new players in simulator," should therefore not be read as an outstanding decision to replace the apartment spawn. ([[#Source-T|T]]) | |||
'''Recommendation:''' keep that sense of arriving and belonging, but make the route to a first flight clear and short. The current [[Tutorial]] promotes flying and then recommends taxi work and earning credits; [[Flight Simulators]] documents free practice without aircraft ownership or rental. Bring those two messages together. A newcomer attracted by flying should readily discover the free simulator, while taxi driving remains a worthwhile route for someone who wants it. The early design observation that tutorials are normally developed last should not govern this improvement: test the first playable learning loop alongside the systems it teaches. ([[#Source-D|D]], [[#Source-G|G]], [[#Source-R|R]]) | |||
The later-supplied ''brainstorming the Order.doc'' describes a busy arrival terminal, a briefing, a personal objective list, and a sequence through training, banking, vehicle purchase, and outfitting. It is another historical proposal, not a later decision superseding the apartment start. Its welcome, social contact, and sense of a functioning province can inform the existing arrival experience without requiring the terminal layout, a walkable cafeteria, or an extra chain of errands before trying flight. The file's 2004 timestamp predates the recorded apartment direction, although it does not establish when every idea was written. ([[#Source-O|O]], [[#Source-T|T]]) | |||
=== Help players find and complete the next action === | |||
The arrival brainstorm's useful addition is guidance that connects an intention to an actual service and a ready-to-use vehicle. It proposes an optional PDA objective list, short "How do I?" help, recognizable buildings, navigation to the entrance, explanations of facility services, and vehicle comparisons. This reinforces the contextual-help ideas in ''Gameplay1.doc''; it does not require a new PDA or a second interface system. ([[#Source-O|O]], [[#Source-H|H]]) | |||
'''Recommendations to test against the existing interface:''' | |||
* '''Offer a small, optional next-step list.''' Explain the current objective, its purpose, where to go, and what remains to be done. Let players dismiss it, choose another goal, and resume later. Reveal detail as it becomes relevant rather than making every service a compulsory onboarding stop. | |||
* '''Make the final approach to a service understandable.''' A building name or distant waypoint may not explain which entrance, parking position, or menu action is needed. Guide the player to the interaction point and show why an action is unavailable. [[Waypoint Management]] already supports storing, activating, and sharing locations. Improve the path through those facilities before adding another navigation system; do not adopt the old proposal to withhold essential destinations until the player has visited them. | |||
* '''Explain the choice before commitment.''' Service descriptions should state purpose, prerequisites, eligibility, cost, and result. Keep basic help easy to reach. The existing [[Skills Assessment Office]] assesses skills; it is not evidence that the proposed paid neural-training school exists. Account eligibility, including [[Demo Limits]], must remain visible at the point of choice. | |||
* '''Make essential instrument information easy to read.''' The document's proposed overlay stands in for information a person would notice in a real cockpit. Test readable values, units, warnings, and control modes, with detailed instruments available when needed. The aim is better awareness of the simulated vehicle and its constraints, with no assumption that a new overlay, input scheme, or hidden handling bonus is required. | |||
* '''Help the player become ready to operate.''' Choosing a vehicle should include its suitability for the intended task, relevant condition and capacity, required compatible equipment, price or rental terms, and the next service or activity. Explain what happens to a previously rented vehicle, where equipment is fitted, and any applicable fuel or storage obligations. [[Rusty's Rentals]] already documents rentals, accessory installation with the target vehicle present, and return at Rusty's lot with a fuel surcharge if not refilled. The brainstorm's return-to-any-official-facility rule must not replace those instructions. [[VBay]] is an existing reference for vehicle sales. | |||
These are usability recommendations grounded in the document and checked help pages, not a finding that every proposed aid is currently missing. Observe a newcomer following the actual route and fix the points of uncertainty first. Keep training and an eligible first contribution reachable without requiring vehicle purchase, paid schooling, a bank visit, or private land ownership as newly invented prerequisites. ([[#Source-O|O]], [[#Source-U|U]], [[#Source-P|P]]) | |||
=== Progression, assistance, and ownership === | |||
The original Gameplay notes considered restricting transfers to prevent wealthy players from bypassing progression or enabling real-money trading. Bill, meanwhile, described giving newcomers enough money to try a rental and lending returning players a ship. His newcomer design explicitly offered city-owned vehicles before ownership. These expose a real design choice: assistance can undermine a particular progression model, but it can also let a player discover the activity that makes progression worthwhile. ([[#Source-G|G]], [[#Source-B|B]], [[#Source-N|N]]) | |||
'''Recommendation:''' separate learning, permission to operate, and ownership. Let training and any required qualification establish readiness; let employment, rental, or a controlled loan provide access; let ownership expand autonomy, capacity, and responsibility. Design any transfer restrictions around specific abuse, with explicit rules for legitimate mentoring and loans. The historical ramp-check idea remains a possible means of checking authorization, not a confirmed current requirement. This reconciliation needs a product decision before new restrictions are introduced. ([[#Source-G|G]], [[#Source-R|R]]) | |||
The arrival brainstorm adds certificates, paid instant learning, purchased experience memories, and handling that improves with character training. Current [[:Category:Skills|skill documentation]] already describes improvement through use; that must be distinguished from the human player's understanding of flight and from vehicle operating permission. Paid memory injection, black-market training, and hidden aircraft-handling changes remain historical proposals. This synthesis neither adds them nor removes the documented character-skill system. ([[#Source-O|O]], [[#Source-U|U]]) | |||
The | |||
=== | === Wealth, circulation, and a viable economy === | ||
# [[ | |||
# | Bill's original account described a shortage of circulating money and proposed off-world fuel sales, transport work, rare-element exports, and NPC support. That account is evidence of his experience and design concerns at the time; it is not proof that today's economy has the same shortage. ([[#Source-B|B]]) | ||
## to | |||
Ticket 655 records subsequent economic work: a 2017 audit of money movements, a 2018 note about minting money when Deois funds fell below a threshold, and a February 2019 fix for dock pricing after DIHV fuel purchases. The ticket is closed as ''fixed''. It supports those recorded interventions, but does not establish implementation of Bill's entire rare-element, contract, or NPC proposal, nor verify the current configuration of each intervention. ([[#Source-E|E]]) | |||
# | |||
'''Recommendation:''' audit present money sources, sinks, circulation, and available work before prescribing another cash injection or export system. A successful transport economy should offer useful work to newcomers while supporting producers, operators, customers, and public services. Personal wealth is a valid goal, alongside reliable operations, completed colonies, a productive fleet, and community contribution. Bill's illustrative mineral quantities, prices, and export percentages remain historical design examples, not adopted balance values. ([[#Source-G|G]], [[#Source-B|B]], [[#Source-R|R]]) | |||
=== Time, difficulty, and fair consequences === | |||
The earlier "Trey's Triangle" discussion asked how ability, time, and knowledge determine success. Bill's substantial flying time shows that long operations can be enjoyable; his wish for colonies to become self-sufficient also shows that repeated maintenance is not necessarily the desired end state. His frustration with connection failures must be distinguished from the satisfaction of mastering a difficult landing. ([[#Source-G|G]], [[#Source-B|B]]) | |||
'''Recommendation:''' preserve demanding decisions and meaningful consequences, while reducing unexplained waiting, repetitive administration, and losses caused by defects. Improve automation feedback and interruption handling without treating every flight as safely unattended. [[Logbooks]] already distinguishes connected playtime from operational experience; use similarly careful distinctions when evaluating engagement. Logged-in hours alone cannot tell whether a player is learning, working, socializing, waiting, or frustrated. ([[#Source-D|D]], [[#Source-R|R]]) | |||
The original griefing examples identify potential abuse involving involuntary movement, vehicles, runways, and colonies. They are risk cases to investigate, not recommended gameplay. Permissions, consent, obstruction handling, and recovery from verified faults should be considered explicitly. Combat, theft, colony interference, and offline vulnerability need their own scope and protection decisions; this consolidation does not approve expanding them. ([[#Source-G|G]], [[#Source-R|R]]) | |||
== Firm demo boundary == | |||
On '''24 October 2026''', Jason confirmed that the existing [[Demo Limits]] are firm. Design the entry experience within them; changing demo eligibility is not an open onboarding decision in this article. The downloads are identical, with the distinction enforced by the server. The policy page dates the restrictions to 27 June 2020. ([[#Source-P|P]]) | |||
As documented there, demo players cannot: | |||
* Create an alliance. | |||
* Customize vehicle trim color, hull registry, or vanity plates. | |||
* Buy land, and therefore cannot construct colonies. | |||
* Earn bank interest or trade commodity futures. | |||
* Accept portal contracts; the restriction also covers posting them if that facility is introduced. | |||
Use the current [[Demo Limits]] page if this summary and the policy ever diverge. Absence from its list does not by itself prove that another activity is available to a demo account. | |||
'''Design consequence:''' use documented practice and account-eligible activities to demonstrate the pleasure of operating in Rise. The [[Flight Simulators|free simulators]] and the [[Tutorial|tutorial's taxi-work route]] provide existing starting points to check in an observed demo session. A proposed starter operation must have a verified, permitted access path; it must not silently depend on a portal contract or bypass the restriction under another name. If no eligible paid flight exists, offer the practice and ground-work route while the flight remains a proposal. Land ownership, colony construction, futures, and interest-bearing savings belong to the full-version career. Show these as later possibilities with clear requirements, rather than promising them as demo rewards. ([[#Source-D|D]], [[#Source-N|N]], [[#Source-P|P]]) | |||
== A proposed first-session experience == | |||
This sequence combines the recorded apartment direction with Bill's training and employer-vehicle proposals. The free simulator is documented; the guided progression, paid starter flight, and employment arrangements below are recommendations, not an announcement of available missions. ([[#Source-T|T]], [[#Source-N|N]], [[#Source-D|D]], [[#Source-R|R]]) | |||
# '''Arrive and understand the opportunity.''' Use the apartment as a useful home and service hub. Explain how to reach practice, paid ground work, and other services. Make the immediate objective and controls readable, with optional next-step help and guidance to the actual service interaction point. ([[#Source-O|O]]) | |||
# '''Try the activity that brought the player here.''' Offer a clear route to a free simulator, with one manageable exercise in one aircraft. Teach the essential controls and relevant automation, then let the player perform a departure, approach, or landing. | |||
# '''Explain the result.''' Give a short debrief: what succeeded, what caused difficulty, and what to practise next. Use the simulator's documented pause and reposition functions to make repetition convenient. | |||
# '''Complete useful work.''' Offer an existing, eligible activity and test the proposal for a modest paid flight in an employer-owned vehicle. Establish its permitted access path, responsibility, duration, and recovery rules before offering it. A demo player must not be sent to accept a portal contract. The proposed first flight contribution should be achievable without buying an aircraft; it is not yet an available mission promised here. | |||
# '''Show a next goal.''' Connect the result to another job, a qualification or practice goal, a rental, or a longer-term ownership and colony ambition. Let the player choose rather than opening every system at once. | |||
Bill's job list communicated a valuable principle: access to real work before vehicle ownership. Its particular payouts, 24-hour copilot takeover, pay multipliers, cash-card fees, and loan terms were sample rules. They require separate design and balance decisions. Likewise, show attainable work prominently and explain prerequisites for other jobs, rather than making the first impression a screen full of unavailable tasks. ([[#Source-N|N]], [[#Source-R|R]]) | |||
Apply the [[#Firm demo boundary|firm demo boundary]] at every step, including job discovery, vehicle access, rewards, and the next goal. Separate an available action from a preview of a full-version career, and explain the requirement before the player invests time in it. ([[#Source-P|P]]) | |||
== Sustaining a career == | |||
=== Make work legible and consequential === | |||
The recommended progression is '''learn → complete useful work → see its effect → gain capability → choose greater responsibility'''. It does not require every player to become a colony owner. A dedicated pilot, ground operator, trader, builder, or organizer should be able to understand a viable place in the economy. ([[#Source-G|G]], [[#Source-B|B]], [[#Source-R|R]]) | |||
For a delivery, communicate the real need, destination, cargo, constraints, likely time, and payment before acceptance. Afterward, show a truthful consequence when the system can establish one: materials delivered to a construction project, a stock shortage reduced, or passengers brought to their destination. Avoid claiming that a shipment saved a settlement unless the simulation supports it. | |||
Bill's proposed survey teams, field camps, vehicle deliveries, collection runs, and city-to-airport trucking provide a pool of mission ideas. Their common strength is connecting different vehicles and settlements through useful movement. Evaluate them against actual supply and demand; new commodities or elaborate NPC systems are not prerequisites for testing that principle. ([[#Source-B|B]], [[#Source-R|R]]) | |||
The arrival brainstorm also imagines player-owned dealerships competing on price, distance, vehicle information, and transport to the seller, followed by fitting and storage services. It adds a useful question to work discovery: can the buyer understand the complete cost and practical steps of becoming ready to operate, and can another player provide a worthwhile service along the way? Existing rental and auction facilities provide places to examine that experience first. Player dealerships, wholesale supply, courtesy shuttles, universal rental returns, and the example insurance subscription are not established by this document as current features. Its gravity-driven shuttle is also a speculative technology, not a reason to bypass Rise's operational constraints. Private property is a full-version possibility, not a required demo parking solution. ([[#Source-O|O]], [[#Source-U|U]], [[#Source-P|P]]) | |||
=== Let success create freedom === | |||
Bill looked forward to completing a colony group that would no longer require constant food and material runs. Preserve that ambition: better organization and investment should be able to reduce routine servicing and free the player to expand, specialize, help others, or pursue a different challenge. Current colony requirements remain those in the [[:Category:Colonies|colony documentation]]; this is a proposed direction for evaluating future changes. ([[#Source-G|G]], [[#Source-D|D]], [[#Source-R|R]]) | |||
NPC transport and automation could fill gaps and keep essential services viable, as Bill proposed. Their scope needs testing so that they support the world without removing the work players want to do. Consider unmet needs, predictable service boundaries, and opportunities for players to provide a better service before designing a fully automated economy. ([[#Source-B|B]], [[#Source-R|R]]) | |||
=== Offer operations that fit different sessions === | |||
Keep long regional and orbital journeys meaningful, and also offer useful shorter activities. Practice, a local ground task, a nearby flight, and a longer supply operation can serve different available amounts of time. Give honest duration estimates and identify natural stopping points. Where technically feasible, support safe handover or resumption at those points without changing the shared world's clock or promising a universal pause. The simulator's pause remains a training feature. ([[#Source-B|B]], [[#Source-N|N]], [[#Source-D|D]], [[#Source-R|R]]) | |||
Automation should clearly distinguish what is active, what is armed or waiting, and what still requires the operator. Explain why an action is unavailable and how to make it possible. A returning-player reminder of the current vehicle, destination, task, and next action would reduce the effort of resuming a career. These are proposed usability improvements, not reductions in the underlying flight or economic model. | |||
=== Earlier design notes in current terms === | |||
The supplied ''Gameplay1.doc'' is an early design document, preserved in the [[Gameplay/Archive/Gameplay1 design notes|source archive]]. Its local file timestamp is in 2007; that is not proof of authorship or the date every passage was written. It ranges from interface and trading ideas to a proposed backstory and detailed vehicle progression. Its useful contribution here is the relationship between learning, equipment, services, and an expanding career, rather than its old names or exact rules. ([[#Source-H|H]]) | |||
{| class="wikitable" | |||
! Idea in the notes | |||
! Relationship to current documentation | |||
! Recommendation carried forward | |||
|- | |||
| New vehicles open more activities without closing earlier ones; hints arrive at a new stage or on request. | |||
| [[Tutorial]] and [[Flight Simulators]] already provide routes into driving and flight. Neither establishes the document's proposed experience-point ladder. | |||
| Offer branching careers and optional, contextual help. Preserve useful ground and local work as capability grows; do not require everyone to climb the same vehicle ladder. | |||
|- | |||
| A consistent personal/vehicle interface, contextual instructions, a reference guide, and notes for ongoing work. | |||
| The [[Intermedia]], [[Manifest]], and [[Player Portal]] already expose related controls and information. | |||
| Check what these interfaces already provide, then improve continuity, prerequisite explanations, and return-to-task information. Do not replace them with a new MIDAS system solely because the old document proposed one. | |||
|- | |||
| Visible inventory, capacity checks, physical delivery, and separate knowledge of goods from possession of them. | |||
| [[Manifest]] and [[ARJ]] document cargo and vehicle handling. Portal settings include reserves, buying and selling prices, and desired quantities. | |||
| Make location, quantity, ownership or access, capacity, price, and delivery obligations understandable before committing to a transaction. A remote inventory view must not imply instant physical transfer. | |||
|- | |||
| Classifieds for goods and services; conversations and asynchronous negotiation; credentials showing what an operator can do. | |||
| [[Player Portal]] and [[VBay]] provide existing, specific facilities. They do not establish the proposed universal trade floor, ratings system, or escrow service. | |||
| Improve discovery of real demand and qualified help before designing another marketplace. Distinguish a price agreement, payment, permission to collect, and completed delivery. Preserve the demo contract restriction. | |||
|- | |||
| Survey data and better equipment help people discover opportunities; information itself could be valuable. | |||
| [[Assay]] already describes uncertain surface estimates and skill, while [[Remote Assay]] documents airborne scanning. Land and colony systems already exist. | |||
| Improve the connection between evidence, confidence, terrain, transport costs, and a viable project. Sale of survey data remains a separate historical proposal, not a documented feature. | |||
|- | |||
| A home and a modest safety net let a struggling player try again. | |||
| The apartment direction and free practice are already recorded. The document's support payments, hunger, rest, and character-stat rules are separate ideas. | |||
| Preserve a comprehensible recovery path and the ability to practise after a setback. Review economic effects before adding grants; avoid turning routine survival administration into a prerequisite for enjoying flight. | |||
|} | |||
'''Terminology and scope:''' use '''[[ARJ|ARJs]]''' for the current containers where old notes say ''PODS'', and '''[[T-19 Stratomaster|T-19]]''' for the present aircraft reference where Bill's examples use the retired ''T-1''. Jason supplied those corrections on 24 October 2026. This is not a claim that the replacements have identical capacities, compatibility, procedures, or economics: follow the current vehicle and ARJ documentation. In particular, the old MuVER/PODS conversions, container locks, and transfer mechanics are not specifications for today's ARJs. The archive retains the original terminology. ([[#Source-H|H]], [[#Source-P|P]], [[#Source-U|U]]) | |||
The Re-HAB origin story, detailed avatar and health systems, apartment walking sequence, hidden character-stat changes to aircraft handling, and proposed vehicle technology remain historical concepts. They are not newly adopted canon or implementation requirements. The recommended direction here is understandable operational skill and consistent vehicle behavior; the old suggestion that hidden agility makes a ship turn faster should not be imported into that direction without an explicit, justified design decision. Existing character skills such as assay are a separate documented system. ([[#Source-H|H]], [[#Source-U|U]]) | |||
=== Example career: Carbon Hole and Irish Luck === | |||
Jason also supplied a [[Gameplay/Archive/John's prospecting scenario|story about John developing two mineral claims]]. John surveys a site, buys cheaper used equipment, returns to collect output, sells it, and considers a richer second project. He seeks an investor because the second project exceeds his means. He also steals from Steve, loses a later raid against a defended claim, and ultimately loses his financed project to the investor after failing to repay. The reveal that Steve is the investor connects their stories through the economy. This is historical design fiction, not an account of current gameplay. ([[#Source-J|J]]) | |||
Its strongest loop is '''investigate → judge the opportunity → acquire access and equipment → produce → transport and sell → meet obligations → reinvest'''. It can create useful roles for surveyors, producers, pilots, equipment suppliers, traders, and financiers. The player need not do every job personally, and advancement need not mean buying the next ship. The claim names, return visits, accumulated output, and relationships also illustrate the atmosphere–persistence–colony appeal identified by the streamer. ([[#Source-J|J]], [[#Source-S|S]]) | |||
Translate the example through present systems before proposing features: | |||
* '''Survey and acquisition:''' current [[Assay]] uses surface estimates, resource grades, and terrain suitability; [[Remote Assay]] is an airborne instrument. [[Assessor's Parcel Number|APNs]], [[Vieneo Land Management]], and the [[Player Portal]] are the documented land references. Do not promise a five-to-ten-minute drone test yielding the story's carbon/iron/gold percentages, or turn its imagined claim-registration visit into a current walkthrough. | |||
* '''Production and logistics:''' the [[:Category:Colonies|colony documentation]] connects construction, materials, people, labor allocation, and production. The story's unattended digger is not a substitute for those requirements. Use current [[ARJ]] and vehicle capacities for the transport leg. The useful design question is whether the player can see what will be produced, what limits it, and when a collection trip is worthwhile. | |||
* '''Equipment and finance:''' the used-digger example makes the tradeoff between entry cost and productive capability understandable. [[VBay]], [[Veridian Bank]], and [[Repossession]] document existing vehicle sale and credit systems, but they do not establish the story's player-to-player investment contract or automatic transfer of an entire mineral claim. Such a proposal would need explicit collateral, repayment amount and date, permissions, notices, default handling, and a transaction record. The story calls its offer a "200% payout" and later gives 10,000 CR advanced and 20,000 CR due; retain that as an illustration, not a priced or approved product. | |||
* '''Risk and return visits:''' make progress, costs, access rights, and upcoming obligations visible when the player returns. The theft, automatic attacks based on IVR, thirty-second gun reset, and exposure while offline remain unresolved combat and property-policy proposals. They must not become the default cost of participating in a peaceful colony career merely because they appear in this story. | |||
All percentages, prices, production rates, weapon counts, and deadlines in the story are illustrative. There is no new commitment here to used mining machinery, player lending, collateral seizure, raiding, or defensive weapons. The documented systems are references to build from, not a fresh audit proving that every related detail works today. ([[#Source-J|J]], [[#Source-U|U]]) | |||
'''Demo distinction:''' John's land purchase and colony-development career is a full-version example. A demo introduction may explain that future possibility, but cannot offer ownership, construction, or portal contracts as its first-session loop. A possible earlier contribution as a pilot or supplier still requires a verified, permitted activity; it cannot be assumed from the story. ([[#Source-P|P]]) | |||
'''Smallest useful test:''' follow one eligible operation from a visible colony need through preparation, transport, and a recorded result, then show an understandable next goal. Before adding a new investment or combat system, establish that players can discover the opportunity, understand the costs, complete the work, and recognize its persistent effect. This extends the existing first-contribution priority without making the whole story a development prerequisite. ([[#Source-R|R]], [[#Source-J|J]]) | |||
== Attracting players who will feel at home == | |||
The [[:Category:Comparisons|comparison articles]] describe different experiences offered by [[Star Citizen]], [[Elite Dangerous]], [[EVE Online]], and [[No Man's Sky]]. They help identify Rise's appeal; they do not establish why another game has more players, measure demand for Rise, or justify assuming that all players of those games want the same thing. ([[#Source-C|C]]) | |||
Rise's proposed positioning is the combination of '''operating vehicles, understanding a physical world, and contributing to its development'''. Show a complete operation: a need, preparation, the journey, an arrival, and the result. The old progression-video idea already linked ground work, aircraft, ascent, docking, and ATC. Develop that into an understandable story of a player's contribution, with honest examples of pace and complexity. Reach people interested in flight, transport, and management simulations as well as space games. ([[#Source-G|G]], [[#Source-R|R]]) | |||
Visual presentation still matters. Weather, clouds, lighting, sound, clear instruments, and reliable performance can strengthen the experience Rise already offers. The older suggestion to disregard players who care about graphics should not be treated as a settled constraint. Prioritize presentation that helps people read the world, appreciate it, and understand their decisions. Weather radar is a documented example of the connection between environment and operation. ([[#Source-G|G]], [[#Source-D|D]], [[#Source-R|R]]) | |||
=== Player feedback: atmosphere, persistence, and colonies === | |||
On 22 October 2026, Jason relayed the following comment from the streamer identified earlier as Peli-Rami. The wording is reproduced as supplied: | |||
<blockquote>Yeah, Star Citizen tries to combine everything to one game seamlessly transferring between flying and FPS. The thing that Rise is doing better is atmospheric simulation, presistency and colony gameplay.</blockquote> | |||
This identifies '''atmospheric simulation, persistence, and colony gameplay''' as strengths this player values. The comparison with Star Citizen is his assessment, as relayed by Jason; it is not an independently established technical ranking. It gives a firmer basis for discussing his preferences than the earlier inference from video titles. It does not, by itself, explain every reason he returns or establish how representative those preferences are. ([[#Source-S|S]]) | |||
'''Recommended implications:''' make these three strengths work together in the player experience: | |||
* '''Atmospheric simulation:''' help players understand and enjoy the relationship between conditions, aircraft behavior, instruments, and flight decisions. Build confidence in controlled training before introducing more demanding conditions outside the simulator. | |||
* '''Persistence:''' make accumulated work and its continuing effects visible and dependable. Help returning players understand what has changed, what they achieved, and what they can do next. | |||
* '''Colony gameplay:''' introduce a meaningful relationship with a settlement early, such as a useful delivery with an observable result. A player can contribute to a colony before being ready to own one; a demo-facing example must first establish an eligible activity under [[Demo Limits]]. | |||
This reinforces Bill's accounts of flying, building, solving supply problems, and taking pride in completed colonies. It also sharpens the onboarding recommendation: the first flight should lead toward an understandable contribution to the persistent world. A proposed starter delivery tied to an actual colony need would test that connection; it should retain manageable conditions and respect demo eligibility. These are design recommendations drawn from the feedback, not additional requests attributed to the streamer. ([[#Source-G|G]], [[#Source-B|B]], [[#Source-D|D]], [[#Source-S|S]], [[#Source-R|R]]) | |||
Public Peli-Rami video titles concerning learning to fly, cargo business, an E-10, and the clouds update remain supporting context. The earlier review used titles and descriptions, not complete streams. One enthusiastic creator is a useful case to investigate, not a substitute for observing new, returning, and departing players. ([[#Source-V|V]]) | |||
== Recommended priorities and validation == | |||
These are proposed priorities from the October 2026 review. Order should be revised when observation or implementation constraints supply better evidence. | |||
{| class="wikitable" | |||
! Priority | |||
! Smallest useful improvement to test | |||
! What to learn | |||
|- | |||
| '''1. First flight and understanding''' | |||
| A clear apartment-to-simulator path, one guided exercise, a short debrief, and readable control and automation states. Fix failures that stop this path. | |||
| Can a newcomer reach and complete a satisfying flight exercise without an experienced player taking over? | |||
|- | |||
| '''2. First contribution and next goal''' | |||
| One eligible paid starter operation, access to a suitable vehicle, clear completion feedback, and an attainable next opportunity. Test a real colony supply need as the purpose of the operation. ([[#Source-S|S]], [[#Source-R|R]]) | |||
| Does the player understand why the work matters, see its contribution to the persistent world, and want to do another operation? | |||
|- | |||
| '''3. A sustainable career''' | |||
| Better work discovery, visible supply needs, session-length choices, return reminders, and targeted improvements to economic circulation and routine servicing. | |||
| Can players build increasingly capable careers without depending on repetitive chores or constant personal assistance? | |||
|} | |||
Start with an observed group of roughly five to eight newcomers to find usability problems. This is a proposed research exercise, not a statistically representative sample. Record where they stop, what they misunderstand, assistance received, time to active flight, exercise and job completion, and whether they return after a week and a month. Record independent and mentor-assisted experiences separately; at small numbers, report counts and explanations rather than impressive-looking percentages. Interview returning and departing players as well as enthusiasts. ([[#Source-R|R]]) | |||
An initial hypothesis could be that a player choosing the flight route reaches active simulator flight within approximately 10–15 minutes of entering the game. That is a test target, not an observed result, universal promise, or reason to rush the lesson. Success means the player understands an accomplishment and sees a reason to return. The appropriate timing must come from observation. | |||
Before accepting a larger feature, ask whether it strengthens a core activity, improves the player's understanding or choices, creates worthwhile work, and can be evaluated against a concrete player outcome. A larger feature list alone does not resolve a weak first experience or an unclear career. ([[#Source-R|R]]) | |||
=== Decisions still required === | |||
* Which first exercise and paid operation to support within the firm [[Demo Limits]], including a verified permitted access path, vehicle access, qualification, liability, and recovery rules. | |||
* How to protect legitimate gifts, mentoring, and loans while addressing specific progression and real-money-trading concerns. | |||
* What current economic evidence warrants changes to money creation, exports, contracts, or NPC services. | |||
* Which interruptions can safely support handover or resumption, and how verified faults are distinguished from ordinary operational mistakes. | |||
* The intended role of combat, theft, consent, and offline vulnerability. Historical combat missions and John's claim-raiding story do not settle this scope. | |||
* Whether demand justifies new trading, survey-data, or player-finance systems beyond documented facilities; if so, their delivery, permission, collateral, notice, and default rules. | |||
== Sources, attribution, and decision history == | |||
This consolidation was prepared on '''22 October 2026''' and expanded on '''24 October 2026''' by Codex at Jason Reskin's request. The later revision incorporates ''Gameplay1.doc'', John's scenario, current-system references, and Jason's confirmation of the demo boundary. A further addition that day reconciles ''brainstorming the Order.doc'' with the apartment direction, existing navigation and vehicle services, and the same demo boundary. Permanent revisions and archives preserve disagreements and proposals not adopted here. The dates below distinguish the origin of a source from a later edit or its archival date. | |||
Bill's two source pages have been moved to '''[[Gameplay/Archive/Bill's Answers]]''' and '''[[Gameplay/Archive/Bill's New Player Experience]]''', retaining their revision histories. Their former titles redirect to this consolidated article; the wiki account does not have deletion permission. Original revisions 4421 and 3943 remain the source evidence. The archive notices and removal of the active Development category do not revise Bill's original proposals. Exact source snapshots are also retained with the local consolidation archive. | |||
'''Coverage of Bill's material:''' his flying and supervision accounts inform ''What players are here for'' and ''Time, difficulty, and fair consequences''; economy and export ideas inform ''Wealth, circulation, and a viable economy''; his daily play, testing, mentoring, and loans inform community, assistance, and session design; field work, trucking, and NPC ideas inform ''Sustaining a career''. His newcomer sequence, vehicle access, and example financial rules inform the arrival and first-session sections. His detailed flight profiles, numeric examples, and personal daily schedule remain historical source material rather than current instructions. The sources remain available in full for questions this synthesis does not settle. | |||
* <span id="Source-G"></span>'''G — Earlier Gameplay discussions.''' [https://www.risetvp.com/index.php?title=Gameplay&oldid=4425 Gameplay before this consolidation], revision 4425. The page originated on 10 May 2018; this snapshot was last edited on 31 March 2025. It contains the audience and progression discussion, Trey's questions to Bill, the 2 October 2018 meeting notes, the 9 October simulator-audience annotation, the video storyboard, and the discussion with c00p. Attribution to those participants follows the source's labels; not every undated note can be assigned a precise meeting date. The old copied directory listing and its obsolete development-status claim are historical material, not current product information. | |||
* <span id="Source-B"></span>'''B — Bill's player testimony and economy proposals.''' [https://www.risetvp.com/index.php?oldid=4421 Bill's Answers, original revision] (now [[Gameplay/Archive/Bill's Answers|archived]]), revision 4421. The page originated on 27 June 2018; this snapshot was last edited on 31 March 2025. Bill supplied the flight, economy, social, assistance, and trucking accounts. A later wiki edit date should not be interpreted as the date every observation was made. | |||
* <span id="Source-N"></span>'''N — Bill's proposed newcomer experience.''' [https://www.risetvp.com/index.php?oldid=3943 Bill's New Player Experience, original revision] (now [[Gameplay/Archive/Bill's New Player Experience|archived]]), revision 3943. The page originated on 27 June 2018; this snapshot was last edited on 13 October 2021. It proposes arrival, apartment services, training prerequisites, city-owned mission vehicles, and example financial rules; part of it explicitly refers to ticket 616. | |||
* <span id="Source-T"></span>'''T — Recorded onboarding direction.''' [https://jira.risetvp.com/view.php?id=616 Ticket 616: Need to start new players in simulator], particularly Jason's note 3478 of 17 February 2020. The note favors the apartment start with prompt guidance to simulators. Ticket status checked on 22 October 2026: closed, ''won't fix''; last updated 4 April 2020. This is evidence of the recorded direction, not a verification of every proposed onboarding feature. | |||
* <span id="Source-E"></span>'''E — Economic changes following earlier concerns.''' [https://jira.risetvp.com/view.php?id=655 Ticket 655: Deois is destitute], particularly Jason's notes 1148 (7 June 2017, money-flow audit), 1623 (9 May 2018, conditional minting), and 2610 (17 February 2019, dock-pricing fix and separate follow-up scope). Status checked on 22 October 2026: closed, ''fixed'', version 2.2; last updated 18 February 2019. These records do not establish current economy-wide conditions or implementation of all Bill's associated proposals. | |||
* <span id="Source-D"></span>'''D — Documented systems used for the reconciliation.''' [https://www.risetvp.com/index.php?title=Tutorial&oldid=4560 Tutorial (4560)], [https://www.risetvp.com/index.php?title=Flight_Simulators&oldid=4795 Flight Simulators (4795)], [https://www.risetvp.com/index.php?title=Logbooks&oldid=4783 Logbooks (4783)], [https://www.risetvp.com/index.php?title=Demo_Limits&oldid=4650 Demo Limits (4650)], [https://www.risetvp.com/index.php?title=Category:Colonies&oldid=4656 Colonies (4656)], [https://www.risetvp.com/index.php?title=Orbit&oldid=4976 Orbit (4976)], and [https://www.risetvp.com/index.php?title=Weather_Radar&oldid=4951 Weather Radar (4951)], read for this review on 22 October 2026. Consult the current versions for operating procedures and compatibility limits. | |||
* <span id="Source-C"></span>'''C — October 2026 comparisons.''' [https://www.risetvp.com/index.php?title=Star_Citizen&oldid=4978 Star Citizen (4978)], [https://www.risetvp.com/index.php?title=Elite_Dangerous&oldid=4979 Elite Dangerous (4979)], [https://www.risetvp.com/index.php?title=EVE_Online&oldid=4981 EVE Online (4981)], and [https://www.risetvp.com/index.php?title=No_Man%27s_Sky&oldid=4983 No Man's Sky (4983)], prepared at Jason's request. These provide sourced design comparisons, not comparative audience or retention measurements. | |||
* <span id="Source-V"></span>'''V — Limited public creator example.''' Public Peli-Rami videos concerning [https://www.youtube.com/watch?v=CGA8HUaQd30 learning to fly], [https://www.youtube.com/watch?v=RTL-BCw43T4 cargo business], [https://www.youtube.com/watch?v=X993j895R7Q an E-10], and [https://www.youtube.com/watch?v=GCSwaELnU-s the clouds update]. The review used public titles and descriptions, not full-stream analysis. No endorsement of this article's recommendations is implied. | |||
* <span id="Source-S"></span>'''S — Streamer feedback relayed by Jason, 22 October 2026.''' Jason supplied the quoted comment in the follow-up to this Gameplay consolidation and attributed it to the streamer previously identified as Peli-Rami. No original public message URL or recording was supplied. The quotation is preserved as provided, including its spelling; the article uses the standard spelling ''persistence'' in its discussion. This source records the player's assessment as relayed by Jason, separately from the public video evidence in V and the recommendations derived from it. | |||
* <span id="Source-R"></span>'''R — 22 October 2026 growth and retention review.''' Jason asked how Rise could attract and retain more players while preserving or strengthening its core values, then requested reconciliation with the three historical wiki articles. Codex proposed the guiding promise, principles, priorities, first-session sequence, and validation approach consolidated here, and refined the recommendations after Jason relayed the streamer feedback recorded in S. They are recommendations derived from the cited evidence; the request to publish this synthesis is not blanket approval to implement them. Future adopted decisions should add a date and a link to the relevant decision or implementation record. | |||
* <span id="Source-H"></span>'''H — Supplied early design document.''' [[Gameplay/Archive/Gameplay1 design notes|Gameplay1 design notes]] ([https://www.risetvp.com/index.php?oldid=5039 archived source revision 5039]), transcribed from ''Gameplay1.doc'' supplied by Jason on 24 October 2026. The supplied .doc contains RTF text. An unchanged local copy and the extracted text are retained; the file's last-modified timestamp is 14 February 2007, not a verified composition date. Authorship is not established from the file. Its interface, trade, progression, support, and worldbuilding concepts are historical proposals. Original-file SHA-256: <code>1D7ED0B381933B62CC8A5DBF37A84A5FB1B7AF2819058361830157A7F6AB3AEB</code>. | |||
* <span id="Source-J"></span>'''J — John's prospecting and investment scenario.''' [[Gameplay/Archive/John's prospecting scenario|Complete supplied scenario]] ([https://www.risetvp.com/index.php?oldid=5040 archived source revision 5040]), provided by Jason on 24 October 2026 in the request to expand Gameplay. The original writing date was not supplied. The archive preserves its wording; the discussion above separates its economic and persistence ideas from unverified mechanics and balance examples. | |||
* <span id="Source-P"></span>'''P — Jason's consolidation directions, 24 October 2026.''' In the request supplying H and J, Jason confirmed that [[Demo Limits]] are firm, identified PODS/ARJs and T-1/T-19 as obsolete/current references, requested reconciliation with current systems, and authorized retirement of Bill's two source articles after citations and archives were preserved. [https://www.risetvp.com/index.php?oldid=4650 Demo Limits, revision 4650] was read again on 24 October. This is a decision about the boundary for the synthesis, not approval of every proposed feature in H or J. | |||
* <span id="Source-U"></span>'''U — Current documentation checked on 24 October 2026.''' [https://www.risetvp.com/index.php?oldid=4993 ARJ (4993)], [https://www.risetvp.com/index.php?oldid=4844 T-19 Stratomaster (4844)], [https://www.risetvp.com/index.php?oldid=4457 Assay (4457)], [https://www.risetvp.com/index.php?oldid=4536 Remote Assay (4536)], [https://www.risetvp.com/index.php?oldid=4674 Assessor's Parcel Number (4674)], [https://www.risetvp.com/index.php?oldid=3554 Vieneo Land Management (3554)], [https://www.risetvp.com/index.php?oldid=4656 Colonies (4656)], [https://www.risetvp.com/index.php?oldid=3614 Manifest (3614)], [https://www.risetvp.com/index.php?oldid=4662 Player Portal (4662)], [https://www.risetvp.com/index.php?oldid=3938 VBay (3938)], [https://www.risetvp.com/index.php?oldid=4563 Veridian Bank (4563)], and [https://www.risetvp.com/index.php?oldid=4591 Repossession (4591)]. Tutorial (4560) and Flight Simulators (4795), listed in D, were also rechecked. The arrival-brainstorm review additionally checked [https://www.risetvp.com/index.php?oldid=3029 Waypoint Management (3029)], [https://www.risetvp.com/index.php?oldid=4992 Rusty's Rentals (4992)], [https://www.risetvp.com/index.php?oldid=4138 Skills Assessment Office (4138)], [https://www.risetvp.com/index.php?oldid=3919 Skills (3919)], and [https://www.risetvp.com/index.php?oldid=4439 Character (4439)]. These establish what the documentation describes; live behavior, compatibility, and proposed gaps still require verification before implementation work is scheduled. | |||
* <span id="Source-O"></span>'''O — Arrival and service-sequence brainstorm.''' [[Gameplay/Archive/Brainstorming the Order|Brainstorming the Order]] ([https://www.risetvp.com/index.php?oldid=5050 archived source revision 5050]), extracted from ''brainstorming the Order.doc'', supplied by Jason on 24 October 2026 as a further gameplay brainstorm. The original Word binary file is retained unchanged; its last-modified timestamp is 28 December 2004, not a verified date for each passage or an authorship claim. The archive preserves its complete main text, with paragraph line endings normalized and Word formatting omitted. It supplies the terminal, optional objectives, service guidance, awareness overlay, training, vehicle-shopping, outfitting, and storage concepts discussed here. Adoption of those features is not implied by their inclusion. Original-file SHA-256: <code>B101057CCA401C34770F03F1DFDEA60E22D79717A681347410DB3008E61D5BA3</code>. | |||
[[Category:Development]] | [[Category:Development]] | ||
Latest revision as of 16:53, 24 October 2026
Gameplay brings together Rise's earlier design discussions, Bill's player feedback and newcomer proposals, the supplied Gameplay1.doc and brainstorming the Order.doc notes and prospecting scenario, and the October 2026 review of player attraction and retention. It is a development reference: it explains the experience these sources point toward and identifies what still needs a decision or testing.
The proposed guiding promise is: Become a capable operator whose work helps a living province grow. Flying is central, alongside driving, trading, building, planning, and belonging to a community. The satisfaction comes from learning to do something well, seeing why it matters, and making a place in the world. This wording is the 2026 synthesis, rather than a quotation or a previously adopted slogan. (G, B, R)
Reading this article: Documented describes what the linked help pages say; it is not a fresh audit of every live system. Recorded direction identifies a dated development statement. Historical proposal records an idea without assuming it was implemented. Recommendation identifies the October 2026 synthesis for consideration and testing. Consolidating these materials does not approve every proposal as a roadmap commitment. The demo restrictions are a settled constraint for this design work, reaffirmed by Jason on 24 October 2026; Demo Limits is their authoritative reference. (P)
What players are here for
The original audience discussion included simulation, spaceflight, science fiction, business building, an MMO community, and advancement from modest beginnings. Bill's answers give that list a practical meaning: he enjoyed flying, solving construction and supply problems, completing colonies, arriving safely, and helping other players. The earlier discussion with c00p similarly connected flying with contributing to a world and feeling part of it. (G, B)
Skill does not require constant manual control. Bill described extensive use of AutoFlyte, punctuated by monitoring, adjustments, and manual landing. His account supports an experience built around judgment and responsibility: choosing the operation, preparing the vehicle, understanding the instruments, managing automation, and intervening appropriately. It does not establish that unattended flight is safe, and its historical flight profiles should not be used as current operating instructions. Today's orbital guidance documentation also makes automation part of Rise's flight experience, with specific capabilities and limits. (B, D)
The likely audience therefore extends beyond players seeking manual flight challenges. It includes people who enjoy transport operations, logistics, colony development, economic planning, exploration with a practical purpose, and familiar places and people. These are audience hypotheses to test, not measured market segments.
Core values to strengthen
The following principles are recommendations drawn from the sources, rather than a claim that Rise has previously adopted a formal values charter.
| Value | What it should mean in play | Basis |
|---|---|---|
| Earned competence | Players learn to plan and complete increasingly demanding operations. Training, understandable feedback, and trustworthy automation help them develop that competence. | Bill's flying and problem-solving; the existing simulators and orbital guidance. (G, B, D) |
| A coherent world | Distance, weather, vehicle capability, supplies, and operating constraints affect decisions. The interface makes those relationships understandable. | The flight and colony accounts, with current orbital and weather-radar documentation. (G, D) |
| Useful work and visible consequences | A delivery, survey, or construction project has an intelligible beneficiary and result. Players can see what their work enabled. | Bill's colony-building account and proposed transport economy. (G, B) |
| Lasting attachment and autonomy | Players choose goals and develop a history with vehicles, routes, settlements, and collaborators. Several kinds of achievement can matter. | Pride in completed colonies, the earlier world-belonging discussion, and the sandbox audience. (G) |
| A welcoming, dependable community | Mentoring and cooperation are valuable, while the essential first steps remain understandable when no experienced player is available. | Bill's help with rentals and loans, his difficulty reaching newcomers through chat, and the guided-start discussion. (B, G) |
Reconciling the earlier discussions
Apartment arrival and early access to flight
Bill's newcomer proposal used immigration, an arrival sequence, an apartment hub, transport to services, training, and city-owned vehicles for jobs. The October 2018 Gameplay notes also discussed retaining Bradbury, company vehicles, and making flight visible during arrival. These were related proposals, not a completed specification. (N, G)
There is a later recorded direction: in February 2020, Jason wrote in ticket 616 that the apartment had been upgraded, the tutorial included it, and the intention was to retain the apartment start while guiding players to the simulators promptly. The ticket was subsequently closed as won't fix. Its title, "Need to start new players in simulator," should therefore not be read as an outstanding decision to replace the apartment spawn. (T)
Recommendation: keep that sense of arriving and belonging, but make the route to a first flight clear and short. The current Tutorial promotes flying and then recommends taxi work and earning credits; Flight Simulators documents free practice without aircraft ownership or rental. Bring those two messages together. A newcomer attracted by flying should readily discover the free simulator, while taxi driving remains a worthwhile route for someone who wants it. The early design observation that tutorials are normally developed last should not govern this improvement: test the first playable learning loop alongside the systems it teaches. (D, G, R)
The later-supplied brainstorming the Order.doc describes a busy arrival terminal, a briefing, a personal objective list, and a sequence through training, banking, vehicle purchase, and outfitting. It is another historical proposal, not a later decision superseding the apartment start. Its welcome, social contact, and sense of a functioning province can inform the existing arrival experience without requiring the terminal layout, a walkable cafeteria, or an extra chain of errands before trying flight. The file's 2004 timestamp predates the recorded apartment direction, although it does not establish when every idea was written. (O, T)
Help players find and complete the next action
The arrival brainstorm's useful addition is guidance that connects an intention to an actual service and a ready-to-use vehicle. It proposes an optional PDA objective list, short "How do I?" help, recognizable buildings, navigation to the entrance, explanations of facility services, and vehicle comparisons. This reinforces the contextual-help ideas in Gameplay1.doc; it does not require a new PDA or a second interface system. (O, H)
Recommendations to test against the existing interface:
- Offer a small, optional next-step list. Explain the current objective, its purpose, where to go, and what remains to be done. Let players dismiss it, choose another goal, and resume later. Reveal detail as it becomes relevant rather than making every service a compulsory onboarding stop.
- Make the final approach to a service understandable. A building name or distant waypoint may not explain which entrance, parking position, or menu action is needed. Guide the player to the interaction point and show why an action is unavailable. Waypoint Management already supports storing, activating, and sharing locations. Improve the path through those facilities before adding another navigation system; do not adopt the old proposal to withhold essential destinations until the player has visited them.
- Explain the choice before commitment. Service descriptions should state purpose, prerequisites, eligibility, cost, and result. Keep basic help easy to reach. The existing Skills Assessment Office assesses skills; it is not evidence that the proposed paid neural-training school exists. Account eligibility, including Demo Limits, must remain visible at the point of choice.
- Make essential instrument information easy to read. The document's proposed overlay stands in for information a person would notice in a real cockpit. Test readable values, units, warnings, and control modes, with detailed instruments available when needed. The aim is better awareness of the simulated vehicle and its constraints, with no assumption that a new overlay, input scheme, or hidden handling bonus is required.
- Help the player become ready to operate. Choosing a vehicle should include its suitability for the intended task, relevant condition and capacity, required compatible equipment, price or rental terms, and the next service or activity. Explain what happens to a previously rented vehicle, where equipment is fitted, and any applicable fuel or storage obligations. Rusty's Rentals already documents rentals, accessory installation with the target vehicle present, and return at Rusty's lot with a fuel surcharge if not refilled. The brainstorm's return-to-any-official-facility rule must not replace those instructions. VBay is an existing reference for vehicle sales.
These are usability recommendations grounded in the document and checked help pages, not a finding that every proposed aid is currently missing. Observe a newcomer following the actual route and fix the points of uncertainty first. Keep training and an eligible first contribution reachable without requiring vehicle purchase, paid schooling, a bank visit, or private land ownership as newly invented prerequisites. (O, U, P)
Progression, assistance, and ownership
The original Gameplay notes considered restricting transfers to prevent wealthy players from bypassing progression or enabling real-money trading. Bill, meanwhile, described giving newcomers enough money to try a rental and lending returning players a ship. His newcomer design explicitly offered city-owned vehicles before ownership. These expose a real design choice: assistance can undermine a particular progression model, but it can also let a player discover the activity that makes progression worthwhile. (G, B, N)
Recommendation: separate learning, permission to operate, and ownership. Let training and any required qualification establish readiness; let employment, rental, or a controlled loan provide access; let ownership expand autonomy, capacity, and responsibility. Design any transfer restrictions around specific abuse, with explicit rules for legitimate mentoring and loans. The historical ramp-check idea remains a possible means of checking authorization, not a confirmed current requirement. This reconciliation needs a product decision before new restrictions are introduced. (G, R)
The arrival brainstorm adds certificates, paid instant learning, purchased experience memories, and handling that improves with character training. Current skill documentation already describes improvement through use; that must be distinguished from the human player's understanding of flight and from vehicle operating permission. Paid memory injection, black-market training, and hidden aircraft-handling changes remain historical proposals. This synthesis neither adds them nor removes the documented character-skill system. (O, U)
Wealth, circulation, and a viable economy
Bill's original account described a shortage of circulating money and proposed off-world fuel sales, transport work, rare-element exports, and NPC support. That account is evidence of his experience and design concerns at the time; it is not proof that today's economy has the same shortage. (B)
Ticket 655 records subsequent economic work: a 2017 audit of money movements, a 2018 note about minting money when Deois funds fell below a threshold, and a February 2019 fix for dock pricing after DIHV fuel purchases. The ticket is closed as fixed. It supports those recorded interventions, but does not establish implementation of Bill's entire rare-element, contract, or NPC proposal, nor verify the current configuration of each intervention. (E)
Recommendation: audit present money sources, sinks, circulation, and available work before prescribing another cash injection or export system. A successful transport economy should offer useful work to newcomers while supporting producers, operators, customers, and public services. Personal wealth is a valid goal, alongside reliable operations, completed colonies, a productive fleet, and community contribution. Bill's illustrative mineral quantities, prices, and export percentages remain historical design examples, not adopted balance values. (G, B, R)
Time, difficulty, and fair consequences
The earlier "Trey's Triangle" discussion asked how ability, time, and knowledge determine success. Bill's substantial flying time shows that long operations can be enjoyable; his wish for colonies to become self-sufficient also shows that repeated maintenance is not necessarily the desired end state. His frustration with connection failures must be distinguished from the satisfaction of mastering a difficult landing. (G, B)
Recommendation: preserve demanding decisions and meaningful consequences, while reducing unexplained waiting, repetitive administration, and losses caused by defects. Improve automation feedback and interruption handling without treating every flight as safely unattended. Logbooks already distinguishes connected playtime from operational experience; use similarly careful distinctions when evaluating engagement. Logged-in hours alone cannot tell whether a player is learning, working, socializing, waiting, or frustrated. (D, R)
The original griefing examples identify potential abuse involving involuntary movement, vehicles, runways, and colonies. They are risk cases to investigate, not recommended gameplay. Permissions, consent, obstruction handling, and recovery from verified faults should be considered explicitly. Combat, theft, colony interference, and offline vulnerability need their own scope and protection decisions; this consolidation does not approve expanding them. (G, R)
Firm demo boundary
On 24 October 2026, Jason confirmed that the existing Demo Limits are firm. Design the entry experience within them; changing demo eligibility is not an open onboarding decision in this article. The downloads are identical, with the distinction enforced by the server. The policy page dates the restrictions to 27 June 2020. (P)
As documented there, demo players cannot:
- Create an alliance.
- Customize vehicle trim color, hull registry, or vanity plates.
- Buy land, and therefore cannot construct colonies.
- Earn bank interest or trade commodity futures.
- Accept portal contracts; the restriction also covers posting them if that facility is introduced.
Use the current Demo Limits page if this summary and the policy ever diverge. Absence from its list does not by itself prove that another activity is available to a demo account.
Design consequence: use documented practice and account-eligible activities to demonstrate the pleasure of operating in Rise. The free simulators and the tutorial's taxi-work route provide existing starting points to check in an observed demo session. A proposed starter operation must have a verified, permitted access path; it must not silently depend on a portal contract or bypass the restriction under another name. If no eligible paid flight exists, offer the practice and ground-work route while the flight remains a proposal. Land ownership, colony construction, futures, and interest-bearing savings belong to the full-version career. Show these as later possibilities with clear requirements, rather than promising them as demo rewards. (D, N, P)
A proposed first-session experience
This sequence combines the recorded apartment direction with Bill's training and employer-vehicle proposals. The free simulator is documented; the guided progression, paid starter flight, and employment arrangements below are recommendations, not an announcement of available missions. (T, N, D, R)
- Arrive and understand the opportunity. Use the apartment as a useful home and service hub. Explain how to reach practice, paid ground work, and other services. Make the immediate objective and controls readable, with optional next-step help and guidance to the actual service interaction point. (O)
- Try the activity that brought the player here. Offer a clear route to a free simulator, with one manageable exercise in one aircraft. Teach the essential controls and relevant automation, then let the player perform a departure, approach, or landing.
- Explain the result. Give a short debrief: what succeeded, what caused difficulty, and what to practise next. Use the simulator's documented pause and reposition functions to make repetition convenient.
- Complete useful work. Offer an existing, eligible activity and test the proposal for a modest paid flight in an employer-owned vehicle. Establish its permitted access path, responsibility, duration, and recovery rules before offering it. A demo player must not be sent to accept a portal contract. The proposed first flight contribution should be achievable without buying an aircraft; it is not yet an available mission promised here.
- Show a next goal. Connect the result to another job, a qualification or practice goal, a rental, or a longer-term ownership and colony ambition. Let the player choose rather than opening every system at once.
Bill's job list communicated a valuable principle: access to real work before vehicle ownership. Its particular payouts, 24-hour copilot takeover, pay multipliers, cash-card fees, and loan terms were sample rules. They require separate design and balance decisions. Likewise, show attainable work prominently and explain prerequisites for other jobs, rather than making the first impression a screen full of unavailable tasks. (N, R)
Apply the firm demo boundary at every step, including job discovery, vehicle access, rewards, and the next goal. Separate an available action from a preview of a full-version career, and explain the requirement before the player invests time in it. (P)
Sustaining a career
Make work legible and consequential
The recommended progression is learn → complete useful work → see its effect → gain capability → choose greater responsibility. It does not require every player to become a colony owner. A dedicated pilot, ground operator, trader, builder, or organizer should be able to understand a viable place in the economy. (G, B, R)
For a delivery, communicate the real need, destination, cargo, constraints, likely time, and payment before acceptance. Afterward, show a truthful consequence when the system can establish one: materials delivered to a construction project, a stock shortage reduced, or passengers brought to their destination. Avoid claiming that a shipment saved a settlement unless the simulation supports it.
Bill's proposed survey teams, field camps, vehicle deliveries, collection runs, and city-to-airport trucking provide a pool of mission ideas. Their common strength is connecting different vehicles and settlements through useful movement. Evaluate them against actual supply and demand; new commodities or elaborate NPC systems are not prerequisites for testing that principle. (B, R)
The arrival brainstorm also imagines player-owned dealerships competing on price, distance, vehicle information, and transport to the seller, followed by fitting and storage services. It adds a useful question to work discovery: can the buyer understand the complete cost and practical steps of becoming ready to operate, and can another player provide a worthwhile service along the way? Existing rental and auction facilities provide places to examine that experience first. Player dealerships, wholesale supply, courtesy shuttles, universal rental returns, and the example insurance subscription are not established by this document as current features. Its gravity-driven shuttle is also a speculative technology, not a reason to bypass Rise's operational constraints. Private property is a full-version possibility, not a required demo parking solution. (O, U, P)
Let success create freedom
Bill looked forward to completing a colony group that would no longer require constant food and material runs. Preserve that ambition: better organization and investment should be able to reduce routine servicing and free the player to expand, specialize, help others, or pursue a different challenge. Current colony requirements remain those in the colony documentation; this is a proposed direction for evaluating future changes. (G, D, R)
NPC transport and automation could fill gaps and keep essential services viable, as Bill proposed. Their scope needs testing so that they support the world without removing the work players want to do. Consider unmet needs, predictable service boundaries, and opportunities for players to provide a better service before designing a fully automated economy. (B, R)
Offer operations that fit different sessions
Keep long regional and orbital journeys meaningful, and also offer useful shorter activities. Practice, a local ground task, a nearby flight, and a longer supply operation can serve different available amounts of time. Give honest duration estimates and identify natural stopping points. Where technically feasible, support safe handover or resumption at those points without changing the shared world's clock or promising a universal pause. The simulator's pause remains a training feature. (B, N, D, R)
Automation should clearly distinguish what is active, what is armed or waiting, and what still requires the operator. Explain why an action is unavailable and how to make it possible. A returning-player reminder of the current vehicle, destination, task, and next action would reduce the effort of resuming a career. These are proposed usability improvements, not reductions in the underlying flight or economic model.
Earlier design notes in current terms
The supplied Gameplay1.doc is an early design document, preserved in the source archive. Its local file timestamp is in 2007; that is not proof of authorship or the date every passage was written. It ranges from interface and trading ideas to a proposed backstory and detailed vehicle progression. Its useful contribution here is the relationship between learning, equipment, services, and an expanding career, rather than its old names or exact rules. (H)
| Idea in the notes | Relationship to current documentation | Recommendation carried forward |
|---|---|---|
| New vehicles open more activities without closing earlier ones; hints arrive at a new stage or on request. | Tutorial and Flight Simulators already provide routes into driving and flight. Neither establishes the document's proposed experience-point ladder. | Offer branching careers and optional, contextual help. Preserve useful ground and local work as capability grows; do not require everyone to climb the same vehicle ladder. |
| A consistent personal/vehicle interface, contextual instructions, a reference guide, and notes for ongoing work. | The Intermedia, Manifest, and Player Portal already expose related controls and information. | Check what these interfaces already provide, then improve continuity, prerequisite explanations, and return-to-task information. Do not replace them with a new MIDAS system solely because the old document proposed one. |
| Visible inventory, capacity checks, physical delivery, and separate knowledge of goods from possession of them. | Manifest and ARJ document cargo and vehicle handling. Portal settings include reserves, buying and selling prices, and desired quantities. | Make location, quantity, ownership or access, capacity, price, and delivery obligations understandable before committing to a transaction. A remote inventory view must not imply instant physical transfer. |
| Classifieds for goods and services; conversations and asynchronous negotiation; credentials showing what an operator can do. | Player Portal and VBay provide existing, specific facilities. They do not establish the proposed universal trade floor, ratings system, or escrow service. | Improve discovery of real demand and qualified help before designing another marketplace. Distinguish a price agreement, payment, permission to collect, and completed delivery. Preserve the demo contract restriction. |
| Survey data and better equipment help people discover opportunities; information itself could be valuable. | Assay already describes uncertain surface estimates and skill, while Remote Assay documents airborne scanning. Land and colony systems already exist. | Improve the connection between evidence, confidence, terrain, transport costs, and a viable project. Sale of survey data remains a separate historical proposal, not a documented feature. |
| A home and a modest safety net let a struggling player try again. | The apartment direction and free practice are already recorded. The document's support payments, hunger, rest, and character-stat rules are separate ideas. | Preserve a comprehensible recovery path and the ability to practise after a setback. Review economic effects before adding grants; avoid turning routine survival administration into a prerequisite for enjoying flight. |
Terminology and scope: use ARJs for the current containers where old notes say PODS, and T-19 for the present aircraft reference where Bill's examples use the retired T-1. Jason supplied those corrections on 24 October 2026. This is not a claim that the replacements have identical capacities, compatibility, procedures, or economics: follow the current vehicle and ARJ documentation. In particular, the old MuVER/PODS conversions, container locks, and transfer mechanics are not specifications for today's ARJs. The archive retains the original terminology. (H, P, U)
The Re-HAB origin story, detailed avatar and health systems, apartment walking sequence, hidden character-stat changes to aircraft handling, and proposed vehicle technology remain historical concepts. They are not newly adopted canon or implementation requirements. The recommended direction here is understandable operational skill and consistent vehicle behavior; the old suggestion that hidden agility makes a ship turn faster should not be imported into that direction without an explicit, justified design decision. Existing character skills such as assay are a separate documented system. (H, U)
Example career: Carbon Hole and Irish Luck
Jason also supplied a story about John developing two mineral claims. John surveys a site, buys cheaper used equipment, returns to collect output, sells it, and considers a richer second project. He seeks an investor because the second project exceeds his means. He also steals from Steve, loses a later raid against a defended claim, and ultimately loses his financed project to the investor after failing to repay. The reveal that Steve is the investor connects their stories through the economy. This is historical design fiction, not an account of current gameplay. (J)
Its strongest loop is investigate → judge the opportunity → acquire access and equipment → produce → transport and sell → meet obligations → reinvest. It can create useful roles for surveyors, producers, pilots, equipment suppliers, traders, and financiers. The player need not do every job personally, and advancement need not mean buying the next ship. The claim names, return visits, accumulated output, and relationships also illustrate the atmosphere–persistence–colony appeal identified by the streamer. (J, S)
Translate the example through present systems before proposing features:
- Survey and acquisition: current Assay uses surface estimates, resource grades, and terrain suitability; Remote Assay is an airborne instrument. APNs, Vieneo Land Management, and the Player Portal are the documented land references. Do not promise a five-to-ten-minute drone test yielding the story's carbon/iron/gold percentages, or turn its imagined claim-registration visit into a current walkthrough.
- Production and logistics: the colony documentation connects construction, materials, people, labor allocation, and production. The story's unattended digger is not a substitute for those requirements. Use current ARJ and vehicle capacities for the transport leg. The useful design question is whether the player can see what will be produced, what limits it, and when a collection trip is worthwhile.
- Equipment and finance: the used-digger example makes the tradeoff between entry cost and productive capability understandable. VBay, Veridian Bank, and Repossession document existing vehicle sale and credit systems, but they do not establish the story's player-to-player investment contract or automatic transfer of an entire mineral claim. Such a proposal would need explicit collateral, repayment amount and date, permissions, notices, default handling, and a transaction record. The story calls its offer a "200% payout" and later gives 10,000 CR advanced and 20,000 CR due; retain that as an illustration, not a priced or approved product.
- Risk and return visits: make progress, costs, access rights, and upcoming obligations visible when the player returns. The theft, automatic attacks based on IVR, thirty-second gun reset, and exposure while offline remain unresolved combat and property-policy proposals. They must not become the default cost of participating in a peaceful colony career merely because they appear in this story.
All percentages, prices, production rates, weapon counts, and deadlines in the story are illustrative. There is no new commitment here to used mining machinery, player lending, collateral seizure, raiding, or defensive weapons. The documented systems are references to build from, not a fresh audit proving that every related detail works today. (J, U)
Demo distinction: John's land purchase and colony-development career is a full-version example. A demo introduction may explain that future possibility, but cannot offer ownership, construction, or portal contracts as its first-session loop. A possible earlier contribution as a pilot or supplier still requires a verified, permitted activity; it cannot be assumed from the story. (P)
Smallest useful test: follow one eligible operation from a visible colony need through preparation, transport, and a recorded result, then show an understandable next goal. Before adding a new investment or combat system, establish that players can discover the opportunity, understand the costs, complete the work, and recognize its persistent effect. This extends the existing first-contribution priority without making the whole story a development prerequisite. (R, J)
Attracting players who will feel at home
The comparison articles describe different experiences offered by Star Citizen, Elite Dangerous, EVE Online, and No Man's Sky. They help identify Rise's appeal; they do not establish why another game has more players, measure demand for Rise, or justify assuming that all players of those games want the same thing. (C)
Rise's proposed positioning is the combination of operating vehicles, understanding a physical world, and contributing to its development. Show a complete operation: a need, preparation, the journey, an arrival, and the result. The old progression-video idea already linked ground work, aircraft, ascent, docking, and ATC. Develop that into an understandable story of a player's contribution, with honest examples of pace and complexity. Reach people interested in flight, transport, and management simulations as well as space games. (G, R)
Visual presentation still matters. Weather, clouds, lighting, sound, clear instruments, and reliable performance can strengthen the experience Rise already offers. The older suggestion to disregard players who care about graphics should not be treated as a settled constraint. Prioritize presentation that helps people read the world, appreciate it, and understand their decisions. Weather radar is a documented example of the connection between environment and operation. (G, D, R)
Player feedback: atmosphere, persistence, and colonies
On 22 October 2026, Jason relayed the following comment from the streamer identified earlier as Peli-Rami. The wording is reproduced as supplied:
Yeah, Star Citizen tries to combine everything to one game seamlessly transferring between flying and FPS. The thing that Rise is doing better is atmospheric simulation, presistency and colony gameplay.
This identifies atmospheric simulation, persistence, and colony gameplay as strengths this player values. The comparison with Star Citizen is his assessment, as relayed by Jason; it is not an independently established technical ranking. It gives a firmer basis for discussing his preferences than the earlier inference from video titles. It does not, by itself, explain every reason he returns or establish how representative those preferences are. (S)
Recommended implications: make these three strengths work together in the player experience:
- Atmospheric simulation: help players understand and enjoy the relationship between conditions, aircraft behavior, instruments, and flight decisions. Build confidence in controlled training before introducing more demanding conditions outside the simulator.
- Persistence: make accumulated work and its continuing effects visible and dependable. Help returning players understand what has changed, what they achieved, and what they can do next.
- Colony gameplay: introduce a meaningful relationship with a settlement early, such as a useful delivery with an observable result. A player can contribute to a colony before being ready to own one; a demo-facing example must first establish an eligible activity under Demo Limits.
This reinforces Bill's accounts of flying, building, solving supply problems, and taking pride in completed colonies. It also sharpens the onboarding recommendation: the first flight should lead toward an understandable contribution to the persistent world. A proposed starter delivery tied to an actual colony need would test that connection; it should retain manageable conditions and respect demo eligibility. These are design recommendations drawn from the feedback, not additional requests attributed to the streamer. (G, B, D, S, R)
Public Peli-Rami video titles concerning learning to fly, cargo business, an E-10, and the clouds update remain supporting context. The earlier review used titles and descriptions, not complete streams. One enthusiastic creator is a useful case to investigate, not a substitute for observing new, returning, and departing players. (V)
Recommended priorities and validation
These are proposed priorities from the October 2026 review. Order should be revised when observation or implementation constraints supply better evidence.
| Priority | Smallest useful improvement to test | What to learn |
|---|---|---|
| 1. First flight and understanding | A clear apartment-to-simulator path, one guided exercise, a short debrief, and readable control and automation states. Fix failures that stop this path. | Can a newcomer reach and complete a satisfying flight exercise without an experienced player taking over? |
| 2. First contribution and next goal | One eligible paid starter operation, access to a suitable vehicle, clear completion feedback, and an attainable next opportunity. Test a real colony supply need as the purpose of the operation. (S, R) | Does the player understand why the work matters, see its contribution to the persistent world, and want to do another operation? |
| 3. A sustainable career | Better work discovery, visible supply needs, session-length choices, return reminders, and targeted improvements to economic circulation and routine servicing. | Can players build increasingly capable careers without depending on repetitive chores or constant personal assistance? |
Start with an observed group of roughly five to eight newcomers to find usability problems. This is a proposed research exercise, not a statistically representative sample. Record where they stop, what they misunderstand, assistance received, time to active flight, exercise and job completion, and whether they return after a week and a month. Record independent and mentor-assisted experiences separately; at small numbers, report counts and explanations rather than impressive-looking percentages. Interview returning and departing players as well as enthusiasts. (R)
An initial hypothesis could be that a player choosing the flight route reaches active simulator flight within approximately 10–15 minutes of entering the game. That is a test target, not an observed result, universal promise, or reason to rush the lesson. Success means the player understands an accomplishment and sees a reason to return. The appropriate timing must come from observation.
Before accepting a larger feature, ask whether it strengthens a core activity, improves the player's understanding or choices, creates worthwhile work, and can be evaluated against a concrete player outcome. A larger feature list alone does not resolve a weak first experience or an unclear career. (R)
Decisions still required
- Which first exercise and paid operation to support within the firm Demo Limits, including a verified permitted access path, vehicle access, qualification, liability, and recovery rules.
- How to protect legitimate gifts, mentoring, and loans while addressing specific progression and real-money-trading concerns.
- What current economic evidence warrants changes to money creation, exports, contracts, or NPC services.
- Which interruptions can safely support handover or resumption, and how verified faults are distinguished from ordinary operational mistakes.
- The intended role of combat, theft, consent, and offline vulnerability. Historical combat missions and John's claim-raiding story do not settle this scope.
- Whether demand justifies new trading, survey-data, or player-finance systems beyond documented facilities; if so, their delivery, permission, collateral, notice, and default rules.
Sources, attribution, and decision history
This consolidation was prepared on 22 October 2026 and expanded on 24 October 2026 by Codex at Jason Reskin's request. The later revision incorporates Gameplay1.doc, John's scenario, current-system references, and Jason's confirmation of the demo boundary. A further addition that day reconciles brainstorming the Order.doc with the apartment direction, existing navigation and vehicle services, and the same demo boundary. Permanent revisions and archives preserve disagreements and proposals not adopted here. The dates below distinguish the origin of a source from a later edit or its archival date.
Bill's two source pages have been moved to Gameplay/Archive/Bill's Answers and Gameplay/Archive/Bill's New Player Experience, retaining their revision histories. Their former titles redirect to this consolidated article; the wiki account does not have deletion permission. Original revisions 4421 and 3943 remain the source evidence. The archive notices and removal of the active Development category do not revise Bill's original proposals. Exact source snapshots are also retained with the local consolidation archive.
Coverage of Bill's material: his flying and supervision accounts inform What players are here for and Time, difficulty, and fair consequences; economy and export ideas inform Wealth, circulation, and a viable economy; his daily play, testing, mentoring, and loans inform community, assistance, and session design; field work, trucking, and NPC ideas inform Sustaining a career. His newcomer sequence, vehicle access, and example financial rules inform the arrival and first-session sections. His detailed flight profiles, numeric examples, and personal daily schedule remain historical source material rather than current instructions. The sources remain available in full for questions this synthesis does not settle.
- G — Earlier Gameplay discussions. Gameplay before this consolidation, revision 4425. The page originated on 10 May 2018; this snapshot was last edited on 31 March 2025. It contains the audience and progression discussion, Trey's questions to Bill, the 2 October 2018 meeting notes, the 9 October simulator-audience annotation, the video storyboard, and the discussion with c00p. Attribution to those participants follows the source's labels; not every undated note can be assigned a precise meeting date. The old copied directory listing and its obsolete development-status claim are historical material, not current product information.
- B — Bill's player testimony and economy proposals. Bill's Answers, original revision (now archived), revision 4421. The page originated on 27 June 2018; this snapshot was last edited on 31 March 2025. Bill supplied the flight, economy, social, assistance, and trucking accounts. A later wiki edit date should not be interpreted as the date every observation was made.
- N — Bill's proposed newcomer experience. Bill's New Player Experience, original revision (now archived), revision 3943. The page originated on 27 June 2018; this snapshot was last edited on 13 October 2021. It proposes arrival, apartment services, training prerequisites, city-owned mission vehicles, and example financial rules; part of it explicitly refers to ticket 616.
- T — Recorded onboarding direction. Ticket 616: Need to start new players in simulator, particularly Jason's note 3478 of 17 February 2020. The note favors the apartment start with prompt guidance to simulators. Ticket status checked on 22 October 2026: closed, won't fix; last updated 4 April 2020. This is evidence of the recorded direction, not a verification of every proposed onboarding feature.
- E — Economic changes following earlier concerns. Ticket 655: Deois is destitute, particularly Jason's notes 1148 (7 June 2017, money-flow audit), 1623 (9 May 2018, conditional minting), and 2610 (17 February 2019, dock-pricing fix and separate follow-up scope). Status checked on 22 October 2026: closed, fixed, version 2.2; last updated 18 February 2019. These records do not establish current economy-wide conditions or implementation of all Bill's associated proposals.
- D — Documented systems used for the reconciliation. Tutorial (4560), Flight Simulators (4795), Logbooks (4783), Demo Limits (4650), Colonies (4656), Orbit (4976), and Weather Radar (4951), read for this review on 22 October 2026. Consult the current versions for operating procedures and compatibility limits.
- C — October 2026 comparisons. Star Citizen (4978), Elite Dangerous (4979), EVE Online (4981), and No Man's Sky (4983), prepared at Jason's request. These provide sourced design comparisons, not comparative audience or retention measurements.
- V — Limited public creator example. Public Peli-Rami videos concerning learning to fly, cargo business, an E-10, and the clouds update. The review used public titles and descriptions, not full-stream analysis. No endorsement of this article's recommendations is implied.
- S — Streamer feedback relayed by Jason, 22 October 2026. Jason supplied the quoted comment in the follow-up to this Gameplay consolidation and attributed it to the streamer previously identified as Peli-Rami. No original public message URL or recording was supplied. The quotation is preserved as provided, including its spelling; the article uses the standard spelling persistence in its discussion. This source records the player's assessment as relayed by Jason, separately from the public video evidence in V and the recommendations derived from it.
- R — 22 October 2026 growth and retention review. Jason asked how Rise could attract and retain more players while preserving or strengthening its core values, then requested reconciliation with the three historical wiki articles. Codex proposed the guiding promise, principles, priorities, first-session sequence, and validation approach consolidated here, and refined the recommendations after Jason relayed the streamer feedback recorded in S. They are recommendations derived from the cited evidence; the request to publish this synthesis is not blanket approval to implement them. Future adopted decisions should add a date and a link to the relevant decision or implementation record.
- H — Supplied early design document. Gameplay1 design notes (archived source revision 5039), transcribed from Gameplay1.doc supplied by Jason on 24 October 2026. The supplied .doc contains RTF text. An unchanged local copy and the extracted text are retained; the file's last-modified timestamp is 14 February 2007, not a verified composition date. Authorship is not established from the file. Its interface, trade, progression, support, and worldbuilding concepts are historical proposals. Original-file SHA-256:
1D7ED0B381933B62CC8A5DBF37A84A5FB1B7AF2819058361830157A7F6AB3AEB. - J — John's prospecting and investment scenario. Complete supplied scenario (archived source revision 5040), provided by Jason on 24 October 2026 in the request to expand Gameplay. The original writing date was not supplied. The archive preserves its wording; the discussion above separates its economic and persistence ideas from unverified mechanics and balance examples.
- P — Jason's consolidation directions, 24 October 2026. In the request supplying H and J, Jason confirmed that Demo Limits are firm, identified PODS/ARJs and T-1/T-19 as obsolete/current references, requested reconciliation with current systems, and authorized retirement of Bill's two source articles after citations and archives were preserved. Demo Limits, revision 4650 was read again on 24 October. This is a decision about the boundary for the synthesis, not approval of every proposed feature in H or J.
- U — Current documentation checked on 24 October 2026. ARJ (4993), T-19 Stratomaster (4844), Assay (4457), Remote Assay (4536), Assessor's Parcel Number (4674), Vieneo Land Management (3554), Colonies (4656), Manifest (3614), Player Portal (4662), VBay (3938), Veridian Bank (4563), and Repossession (4591). Tutorial (4560) and Flight Simulators (4795), listed in D, were also rechecked. The arrival-brainstorm review additionally checked Waypoint Management (3029), Rusty's Rentals (4992), Skills Assessment Office (4138), Skills (3919), and Character (4439). These establish what the documentation describes; live behavior, compatibility, and proposed gaps still require verification before implementation work is scheduled.
- O — Arrival and service-sequence brainstorm. Brainstorming the Order (archived source revision 5050), extracted from brainstorming the Order.doc, supplied by Jason on 24 October 2026 as a further gameplay brainstorm. The original Word binary file is retained unchanged; its last-modified timestamp is 28 December 2004, not a verified date for each passage or an authorship claim. The archive preserves its complete main text, with paragraph line endings normalized and Word formatting omitted. It supplies the terminal, optional objectives, service guidance, awareness overlay, training, vehicle-shopping, outfitting, and storage concepts discussed here. Adoption of those features is not implied by their inclusion. Original-file SHA-256:
B101057CCA401C34770F03F1DFDEA60E22D79717A681347410DB3008E61D5BA3.