Supermarket SimulatorSupermarket Simulatorwiki
In-game picture of the storefront of the shop on the first day from Supermarket Simulator, used to illustrate How a vehicle drives and answers the controls.
Picture taken from the game to identify this item; it remains the property of the developer or the person who uploaded it, and is credited in the picture sources.

Vehicles · Supermarket Simulator · read from a local copy

How a vehicle drives and answers the controls

A vehicle has a controller of its own, with a separate one for the car kind.

A Supermarket Simulator vehicle is not one object: the game gives it a controller of its own, a drive type and an engine setting, wheels, lights with a controller behind them, sound and effects, a readout, a state for losing control and a manager for its collisions.

What the game establishes

In play

A vehicle has a controller of its own. There is a controller for the vehicle layer and a separate one for the car, and the game knows which kind of vehicle it is dealing with, which is how two vehicles can answer the same input differently.

How it drives is a setting rather than something fixed in the body. There is a drive type and an engine configuration, so the same controls can be tuned for a different vehicle without the controls being rewritten.

The wheels are objects of their own rather than part of the body, which is what lets a vehicle be given different wheels without being a different vehicle.

The lights are a system, not a switch. There is a lighting component, a kind of light and a controller that drives them, which is why headlights, brake lights and whatever else a vehicle shows are not all one thing.

It has sound and effects of its own, at both levels: for the car and for the vehicle underneath it. That is why a vehicle can sound heavy and still use the same base machinery as a light one.

It has a readout of its own as well: a state display for the car and a controller for what the vehicle shows, so the vehicle can tell you something about itself rather than only moving.

Losing control is modelled. There is a state for being out of control and a duration for the body coming to rest, which is why a bad landing or a spin is something the game can name rather than only show.

Collisions are handled by a manager of their own rather than by every vehicle separately, and the game keeps a manager over the vehicles as a whole with an interaction of its own for getting into one.

The controls are a thing of their own. A vehicle exposes an interface for being controlled and carries its own car input, which is why the same controls can drive a car and be reworked without the vehicle being rewritten.

There are controllers for the awkward moments too. The build keeps one for a crash and one for a trailer, which is why hitting something and towing something are handled apart from the ordinary driving loop.

The engine is watched as well. The build keeps a state for engine revolutions and a pair for vehicle actions, one describing what can be asked of a vehicle and one carrying it out, which is why the answers to the controls can be reworked without changing the controls themselves.

What you feel while driving is managed as well. Nitrous, the pedals, skidding and the ragdoll each have a manager of their own, which is why a boost, a slide and being thrown off are separate states of the vehicle rather than one effect.

The picture beside this entry is the game's own: the body texture it ships for one of its scooters, one of the vehicle textures in the build.

What this entry does not tell you: how fast any vehicle goes, how much fuel it uses, or how each one handles. We have not verified those numbers, so we do not print them.

Related

Version and sources

A local copy of the game, read only. The grounding for each fact is listed on the technical reference pages; nothing here is estimated. Documented build: 1.6.0 (223).