挨拶
フリュー(株)で、プリントシール機(以下、プリ)のソフト開発をしている永吉です。
この記事では、ユーザーがどのタイミングでプリを遊んでも、快適に遊んでもらえるための仕組みについて紹介したいと思います！
プリの性質について
プリでは、アミューズメント機器では珍しい、「ある性質」があります。
何だと思いますか？
それは、「１つの筐体を複数のユーザーでシェアしてプレイしている」という性質です。
プリのことをよく知らない読者のために、軽くプリの説明をします。
プリは基本的に以下の4つのブースで構成されています。
- 受付ブース(コイン投入ブース)
- 撮影ブース
- 落書きブース(左)
- 落書きブース(右)
ユーザーは 受付ブース → 撮影ブース → 落書きブース の順番でブースを移動しながらプリで遊びます。
この流れでは、受付ブース から 撮影ブース にユーザーが移動すると、即座に次のユーザーの受付を行えます。
撮影ブース → 落書きブースに移動する場合も同様で、撮影ブースからユーザーが移動すると、即座に次のユーザーは撮影をすることができます。
言葉では想像し辛いと思いますので、図を用意しました。こちらをご覧ください。
この図を見ると、最大4組のユーザーが同時にプレイしていることが分かると思います。
この状況で全てのユーザーに快適に遊んでもらうためには
PCの要求スペックも高くなるというものです。
このことから、「複数台のPCを使っているか、高スペックなPCを使っているんだな」と思われる方もいるかもしれません。
しかし残念。弊社では1台のPCで全てのユーザーの処理を行っています。 *1
しかも、部材コストの観点からスペックもそこまで高くないです。
1台のPCで全ての制御を行うデメリット
1台のPCで全ての処理を行うということは、複数のユーザーが同時にプレイすると、重くなるというデメリットがあります。*2
このデメリットがあることでどういった問題が発生するでしょうか？
- プレイ中の画面がガクガクになる
- 内部で動いている画像処理の速度が低下し、プレイ中にユーザーが待たされる
- 画像送信を担当しているプロセスの速度が低下し、スマホに画像が全然届かなくなる
などなど、主にユーザー体験の低下に繋がる問題が発生します。
ユーザー体験を低下させないための仕組み
アミューズメント機器に限らず、プロダクトを作っている者として、全てのユーザーに素敵な体験をさせてあげたいと思うのは、当然のことですよね。
では、それを実現するために何を行っているのか？
それは、徹底したCPUリソースの制御です。
弊社では、以下の項目を調整することでCPUリソースの奪い合いを防ぎ、システムが安定して動作するようにしています。
- 各プロセスの優先度の指定
- 各プロセスが使用できるCPUコアの指定
- 画像処理の並列に処理できるプロセス数の指定
- 画像処理で使用できるCPUパワーの制限
具体的になにをしているのか？
「CPUリソースの制御が必要な理由は分かった。具体的には何をしているの？」
ということで、説明します。
説明するにあたり、以下のようなスペックの仮想的なプリを想定します。
文字だと分かりにくい！という方は、下のほうに図示しているので、そちらをご覧ください。
仮想的なプリのスペック
ブース構成
| ブース名 | 数 |
|---|---|
| 受付ブース | 1つ |
| 撮影ブース | 1つ |
| 落書きブース | 2つ |
各ブースにユーザーが滞在する時間
| ブース名 | 時間 |
|---|---|
| 受付ブース | 180秒 |
| 撮影ブース | 180秒 |
| 落書きブース | 360秒 |
各種ユーザーのイベントの時間
| イベント名 | 時間 |
|---|---|
| 撮影ブース入場～撮影開始 | 40秒 |
| 撮影開始～撮影終了 | 120秒 |
| 落書きブース入場～落書き開始 | 100秒 |
| 落書き開始～落書き終了 | 180秒 |
画像処理にかかる時間
| 処理名 | 時間 | 処理内容 |
|---|---|---|
| 撮影処理 | 撮影中は常に行う | 撮影中にユーザーに見せる画像を作る処理 |
| 落書き処理 | 20秒/1枚 | ユーザーが落書きをするときに表示される画像 |
| 印刷処理 | 20秒/1枚 | シールに印刷するための画像を作成する処理 |
| 携帯処理 | 20秒/1枚 | ユーザーのスマホに送信する用の画像を作成する処理 |
その他の条件
| 条件名 | 条件 |
|---|---|
| CPUコア数 | 6つ |
| 撮影枚数 | 6枚 |
1プレイの流れを図で表すと、以下のようになります。
矢印の長さの縮尺が合っていないような気がしますが、そこは置いておくとして…
ここまではOKでしょうか？
CPUのリソースを調整してみる
このようなプリがあったとして、どのように調整すると4組同時にプレイしてもリソースの奪い合いが発生しないようにできるでしょうか？
基本的には、CPUリソースの大半を使用している、画像処理のCPUリソースを調整することで実現します。
そのためまず初めに行うことは、画像処理の使用するCPUコアと、それ以外のプロセスが使用するCPUコアを分けることです。
そこで、今回は以下の表のようにCPUコアの割り当てを行います。
| 条件名 | 条件 |
|---|---|
| コア番号 | 使用プロセス |
| 1 | 画像処理 |
| 2 | 画像処理 |
| 3 | 画像処理 |
| 4 | 画像処理以外 |
| 5 | 画像処理以外 |
| 6 | 画像処理以外 |
そのため、画像処理が使用できるCPUコアは3コアということになります。
画像処理以外が使用するCPUコアを絞ると、画面がガクガクになってしまうかもしれないのでとりあえず半分にすることが多いです。
画像処理の流れを図示したものが下図になります。
矢印が2本書いてあるところは、並列で動いているところです。(並列にしないと処理の完了が間に合わない)
処理の部分だけを抜き出した図が、下図になります。
1マス10秒で、色でユーザーを分けています。
この図から、どのタイミングでも画像処理の最大3つしか被っていないことが分かると思います。
画像処理に割り当てたコアは3つなので、これならリソースを奪い合うことなく動作することができます。
このように、理想的に設計できると、4組のユーザーが同時にプレイしてもお互いに影響を与えずにプレイすることができます。
今回の場合はきれいに調整することができましたが、開発中には以下のような問題が発生します。
- 撮影枚数が12枚など、大量の画像を処理するために並列で処理しないと間に合わず、処理が被ってリソースの奪い合いが発生する。
- プリによっては、撮影のタイミングをユーザーが決めることができる場合があり、その場合は画像処理のタイミングがずれる。
- プリは基本的に2人で撮ることを想定されているが、10人などの大人数で撮影された場合、画像処理の時間が延びる。
このような問題が発生しても柔軟に対応できるように、様々なCPUリソースの制御手段が用意されています。
まとめ
いかがだったでしょうか？
ユーザーに快適に遊んでもらえるように、プリ内部には様々な仕組みが存在します。
本記事ではその一部について説明を行いました。
ユーザーに素敵な体験を提供するために、私たちが頑張っていることが伝わると、とても嬉しいです！
