エアライドマシンは一部を除いて常に数センチメートル浮いた状態で走行しており、そのほとんどが自動で走り続ける。そのため、レース中はスティックとAボタン以外は使用しないので、ゲームに慣れていない人でも簡単に操作することができる。Aボタンを押すことを「プッシュ」とよび、これによってマシンが地面に押しつけられる。プッシュ中は速度が落ちるが、マシンにパワーがたまり（チャージとよぶ）、Aボタンを押し続けて開放することで加速することができる。これを使うと、急なカーブをスムーズに、早く曲がることができる（ドリフト）。ただし、チャージをしすぎるとオーバーヒートし、余計減速してしまう（またためることは可能）。また、吸い込み、技の使用も同時に行える。なお、L、Rトリガーボタンでも同様の操作を行え、Lトリガーボタンを使えば片手操作もできる（メニュー画面もL、Rトリガーで代用可能）。スティックを左右に素早く倒すと、「クイックスピン」ができる。この状態で敵にぶつかると、ダメージを与えたり減速させることができる。また、発動した瞬間は無敵らしく、敵の攻撃を防ぐのにも使えたりする。マシンが段差を越える際に機首を上げると、飛び立つことができる。飛行性能はマシンごとに違うが、マシンによっては大幅なショートカットができることもある。ほかに、他機のすぐ後ろを走ると空気抵抗が軽減されるスリップストリームという効果がある「スタースリップ」や、細長いレールに乗ると、それに沿って加速するという特徴もある。
このゲームにはクリアチェッカーとよばれる、「エアライド」「ウエライド」「シティトライアル」にそれぞれ120個ずつ、計360個の課題があり、これをクリアすることが目標となっている。ひとつの課題をクリアすると隣接する四方のマスの課題の内容がわかるようになり、これを繰り返してマスを埋めていく。逆に、他の作品にみられるような「トロフィーやメダルを懸けてレース」といった要素はない。クリアチェッカーの課題は「○○のコースを××秒以内に1周しろ」といったありがちなものから、「ゴール時のタイムの下2ケタをゾロ目にする」という運任せのものまでさまざま。難易度もさまざまで、「特定のアイテムを10個以上取れ」など、運転テクニック以外の要素でクリアしがたい課題も存在する。また、一部の課題ではクリアすると「裏音楽」や「マシン追加」などの「ごほうび」がもらえる。課題をクリアすると、ごほうびがもらえるマスは橙に、もらえないマスは黄緑に光るようになる。どうしても課題をクリアできない場合の救済処置として、それをクリア扱いにする「紫パネル」が存在するが、数が限られる上に「ごほうび」の1種となっているので、使うにはある程度の計画性が求められる。また、パネルを使用したクリアチェッカーの条件をクリアした場合は、元々付く色に上書きされる。120個すべての課題をクリアすると、紫パネルを除いて金色に光るようになる。このシステムは後にWiiで発売された「大乱闘スマッシュブラザーズX」にも生かされている。
SOAに通じる考え方や技術は古くから存在している。オブジェクト指向やコンポーネント指向は、決められたインタフェースに従ってソフトウェアの一部分をカプセル化、部品化し、それを組み合わせて全体を構成するという考え方を基本としている。また、分散オブジェクト、メッセージング、EAI (Enterprise Application Integration) などの技術を使用し、ネットワークを介してソフトウェアを連携（疎結合）させるといったことは、大規模なシステムにおいてはすでにある程度実施されている。ただし、オブジェクト指向やコンポーネント指向においては、主にプログラム上の部品をソフトウェアの構成単位としており、業務処理の変化をシステムの変更に素早く反映させたいという視点においては単位が小さすぎる、とされている（もっとも、単位の大きさ（粒度）は元来任意であり、オブジェクト指向やコンポーネント指向における部品の粒度を業務処理のそれに合わせたものがSOAにおけるサービスであると捉えることもできる）。また、従来のシステム連携技術は、特定のソフトウェア基盤の使用を前提としている、あるいは連携させるために必要な作業や手順が煩雑である。こうしたことから、システム連携のスピードやコストにおける問題点が指摘されていた。このような問題を解決するための技術あるいは概念として、2000年頃からWebサービスが提唱されている。ただし当初のWebサービスは、現在のSOAと同様の構想がすでに提唱されてはいたものの、実装技術としてはWebを介したソフトウェアの連携自体に主眼が置かれていた。また、連携する個々のソフトウェア（サービス）をシステム全体の中でどのように位置づけるのか（サービスの粒度の目安を何に置くのか）、多数のサービスを連携させる複雑なトランザクション処理などをどのように設計、実装するのかといった事柄が、課題として残されていた。その後、Webサービスの概念や技術の拡張に伴い、2004年頃から、「Webサービス」に代わって「SOA」がキーワードとして注目されるようになった。これらの課題の対策としてポートレットフレームワークが注目されている。オブジェクト指向やコンポーネント指向は基本的ＩＴ部品の再利用を考えている場合が多い。ポートレットフレームワークの場合は、エンドユーザが直接利用するwebページ上の機能の再利用を目指している。また、オブジェクトやコンポーネントをエンドユーザが利用する場合は別にプログラムを必要としたため、ユーザと開発者の考えに差異がある場合があった。ポートレットフレームワークの場合は、ユーザが要求する機能毎をプラグインで実装する。プラグインにはWebページに配置できる複数のポートレットを含むことができる。オブジェクト及びコンポーネントと異なりプラグイン毎にアプリケーションサーバに追加／変更／削除できる。なお、インストールされているプラグインに含まれるポートレットをエンドユーザがドラッグ・アンド・ドロップ処理でWebページに配置することができる。即ち、エンドユーザが利用するビジネス機能をWebページに配置して利用することができる。なお、ポートレット毎に表示、エンティティ・インターフェース、ビジネスロジックが含まれている。そのため、技術により非依存である。例えば、JSFで作成したポートレットとSpringFrameworkで作成したポートレットを一つのWebページに配置することもできる。なお、PHPで作成されたポートレットと同様な機能をもつJavaのポートレットで置き換えることもできる。ポートレット間通信はJava API, Java RMI, Web Service, JSONなどで行うことができる。これらのプロトコル用のAPIはポートレットフレームワークが同じ機能なものを提供する。オープンソース・ポートレットフレームワークの例としてLiferayが挙げられる。