Approximately Up’s demo route is no longer the current game. The paid release went live on August 6, 2026, the former Demo AppID no longer resolves in Steam appdetails, and Approximately Games says the full game contains redesigned missions, changed content, and new features. If you are playing the paid AppID 3904850, do not use this page as a full-release walkthrough.
This guide is for an old installed copy of the retired demo. It applies only while your objectives still lead from the Earth shipment jobs to the powered ice-cream delivery at Moonstep and then Fred’s Star on Oldara. If those names, controls, or objective prompts are absent, stop here and follow the current client instead.
Check the build before following a single step
Look at the title screen and the objective list before changing a ship. A compatible demo save should still expose the old Earth retrieval work, Moonstep, and the Fred finale. The guide also assumes the demo-era controls documented by the community reference: G for garage editing, holding R to enter a flight test, and O for objectives. Use the bindings shown by your own client if they differ.
Three mismatches mean the route has ended for you:
- You own the paid release: the developer explicitly says its missions and content were redesigned. Similar parts or planet names do not make the old order reliable.
- The next objective has a different name or destination: do not force the old Moonstep or Oldara sequence onto a current mission.
- A part behaves differently: keep the engineering idea—separate power, readable controls, early braking—but let the live tooltip and objective override every demo-specific instruction.
That version check is the most important step in the article. The rest is a reconstruction of the retired demo’s progression, not a claim that the full release kept it.
Give the ship one readable electrical spine
Start with a low, rigid hull and place lifting thrusters around its footprint. The useful feature is symmetry: when one corner rises first, you can compare it with the opposite corner instead of guessing across the whole vehicle. Do not hide the first test under automation, decorative wiring, or extra mass.
The demo references describe power and data as separate jobs. Build them so you can inspect them separately:
- Power: battery or generator to a power router, then visible branches to the lifting thrusters.
- Control data: throttle or vertical lever to a data router, then matching signals to the same lift group.
- Protected consumers: reserve independent power branches for radar, displays, RCS control, and mission cargo. A main-engine switch must not silence the instruments or freezer with it.
In the garage, trace one thruster from source to socket before copying that pattern. Then enter flight mode and add lift slowly. A useful first result is a short, level rise followed by a deliberate descent. If the ship does not move, determine which of three observations is true: the thruster has no power, it has power but receives no control value, or every thruster responds but the hull is too heavy. Those are different failures, and adding another logic block does not solve all three.
If one corner jumps, inspect that corner against its partner. If a lever remains at full input, return the focused control to neutral; the demo-era controls page documents middle mouse for resetting a focused lever or joystick. If every lift unit works but the ship still sinks, reduce mass or add lift rather than rewiring a valid signal.
Teach the hull to turn before giving it a destination
The community RCS reference uses a six-thruster beginner arrangement: one opposing pair for pitch, one for yaw, and one for roll, connected through an RCS controller. Six is not a universal placement diagram. It is a way to ensure that each requested rotation has an opposite response and that the pair produces rotation around the hull rather than only pushing it sideways.
Mount the pairs around the center of the ship, assign opposite directions within each pair, power the controller, and connect pitch, yaw, and roll from the 3D joystick. Test close to the ground. Move only pitch, return the stick to neutral, then repeat for yaw and roll. A continuous spin means the two sides are not opposing correctly. A dead direction means either that side is unassigned, the controller never receives the axis, or the relevant unit is unavailable. Fix the observed axis before testing another one.
Save this manually controllable hull as its own blueprint. Do not add hover correction yet. An automatic loop can counter a bad RCS pair just enough to disguise the defect, then fail when cargo shifts the center or a long approach demands sustained control.
Let the Earth shipments expose cargo and radar defects
Open the old demo objective list and take the local lost-shipment work before the Moonstep run. These jobs are valuable because they test the cargo opening, radar display, landing visibility, and return procedure without a long transfer.
The demo mission reference gives the early package as about 1.2 × 1.2 × 1.2. Treat that as a planning clue, not permission to build a hole with zero tolerance. Walk the route from the outer gate to the secured position and look for frame corners, seats, doors, or cable runs that can catch the crate. Make sure a crew member can still reach the controls after cargo is aboard.
Power the radar and place its output where the pilot can actually read it. Launch only far enough to confirm that a target appears. Follow the live marker, land beside the shipment instead of covering it with the hull, load it through the tested opening, and return to the pad named by the objective. If the job does not advance, read the current wording and check the crate’s final position before rebuilding the sensor network.
The snowy-mountain retrieval changes the approach rather than the cargo. Arrive with enough height to see the terrain, remove sideways speed before the last descent, and leave room to climb away. Reaching the marker at high speed proves navigation, not landing control. After both retrievals, the ship should have a usable bay, a readable radar target, and manual control on all three rotational axes.
Moonstep is a power-continuity mission
The retired demo’s ice-cream delivery is not ordinary cargo. The mission reference says the freezer must remain powered for the Earth-to-Moon trip and stay connected until the objective completes. Give it a direct, dedicated branch from the battery side. A switch used to cut travel thrust must not remove freezer power.
Prove the branch on the ground
Load the freezer, then operate every switch you expect to touch during ascent, coasting, radar checks, and landing. Watch the cargo branch through the whole drill. If any routine action cuts it, change the topology before launch. Retest lift and all RCS axes with the added mass; the empty-hull result no longer proves the loaded ship.
Travel by observations, not by a memorized burn
Leave Earth under manual control, build travel speed only after the hull is stable, and return the controls to neutral before a long coast. Keep both radar and its monitor powered. The demo navigation references describe a target handoff as the ship enters the Moon’s region, so do not keep chasing an old Earth-relative blip. Wait until Moonstep appears in the active display and confirm the new direction before changing course.
Begin braking while there is still distance to spend. If Moonstep is correctly selected but the ship keeps drifting past it, the problem is speed, not the radar. Rotate early and remove horizontal motion before the pad moves beneath the hull. The community Moon page describes build-dependent thrust behavior near the lunar surface, but it does not establish one safe altitude that applies to every ship. Compare the response of the thrust groups fitted to your build and switch while there is still room to recover.
Close the delivery before touching the wiring
After landing, leave the freezer connected until the objective changes. A safe landing cannot repair a power interruption that happened during the transfer. If the ship arrives but the mission remains open, inspect the live objective, the freezer connection, and its position in that order. If the cargo failed earlier, return to the garage and isolate that branch; do not repeat the whole flight with the same cutoff path.
Prepare for Fred’s Star without pretending there is one fixed route
Official Steam news identifies Fred’s Star as the June 6 demo finale and the last major demo update before release. The readable community outline places the action on Oldara and mentions long-range flight, scanner or tower work, and a star event. It does not supply an independently verified, button-by-button objective sequence. This section therefore covers the ship state and the visible signals you can verify, not a hidden code or universal tower order.
Duplicate the proven Moonstep ship and make the copy the finale build. Put radar, scanner equipment, and their displays on a power branch that remains live when travel engines are cut. Retest pitch, yaw, and roll after adding the equipment. Preserve a low-speed control mode: arriving fast is useless if the ship cannot hold a scanner or charger near a target.
On Oldara, keep the objective screen open at each transition and let the current wording decide the next action. The community outline says the mission uses planetary towers and scanner work. If a tower or next marker does not appear, first confirm that the radar/scanner branch is powered and readable, then change position around the planet before assuming a fixed sequence is missing. Stay with an interaction until the objective text changes; leaving on the first visual effect can force an unnecessary return.
Do not publish a number that the evidence does not stabilize. No reviewed source establishes a universal charger output, timer, tower order, or safe distance for every build. When the current objective and the old outline disagree, the objective wins. When the ship cannot hold position or keep the scanner alive, end the run and repair the finale blueprint rather than searching for a nonexistent code.
Steam lists online co-op for up to four players. During the Moonstep and Oldara legs, give each player one observable state: the pilot owns attitude and abort decisions, the navigator owns target changes, the systems player watches cargo or scanner power, and the builder records the exact branch that failed. A useful callout combines a state with an action—”Moonstep acquired; brake” or “scanner branch off; abort”—instead of offering several theories at once.
Where this retired route ends
The demo task is closed when the Earth shipments are complete, the powered freezer objective advances at Moonstep, and Fred’s Star reaches its final in-game transition on the old build. Keep separate blueprints for the clean manual hull, the loaded Moonstep ship, and the Oldara variant. A blueprint preserves construction; it does not prove that mission progress, cargo state, or demo data transfers to another application.
Do not carry this sequence into the full release merely because a familiar planet or part appears. Approximately Games says the paid game changed the missions and content enough that the demo no longer represents its current state. The shortest correct next step for a full-release player is to stop using this page and read the live objective in AppID 3904850.
Sources and version check
The August 7, 2026 version check used the official Approximately Up Steam page, Steam appdetails, and the developer’s news feed for release state, four-player co-op support, demo retirement, and Fred’s Star timing. Demo actions are bounded to readable, unofficial community pages and are not presented as full-release instructions. The English-filtered Steam Guides list for AppID 3904850 contained no guide items when checked. Article images remain original Steam store JPGs for AppID 3904850.