Dyson Swarm: AWS のサービスを使用してハード SF ゲームを構築した方法

ハード SF クリッカー ゲーム: Dyson Swarm

私は情熱的な SF 愛好家で、SF 雑誌を 5 年間運営していたこともあります。 この愛情から、複雑な SF の概念を魅力的な方法で説明する一連の短編ゲームを作成するようになりました。 私の最初の作品 Dyson Swarm は、AWS Game Builder Challenge 中に登場しました。

Dyson Swarm は、プレイヤーが太陽系を解体して、太陽を取り囲む巨大構造物である Dyson Swarm を構築するインクリメンタル (クリッカー) ゲームです。 ゲーム開発者としてスタートし、徐々にリソースを蓄積し、ステージを進めていきます。

当初は開発時間を 10 ～ 20 時間と見積もっていましたが、プロジェクトは大幅に拡大し、最終的には約 70 時間かかりました (ほとんどが深夜!)。 これは、正確なソフトウェア開発見積もりの​​課題を浮き彫りにしています。

ここでゲームをプレイできます: Dyson Swarm

AWS アーキテクチャ

ゲームはクライアント側の Javascript を使用し、完全にブラウザーで実行されます。 ホスティングは S3 静的サイト バケットを使用して実現され、グローバルな高速配信のために CloudFront CDN によって強化されます。 CloudFront は TLS 終了を処理し、プロセスを簡素化します。

匿名のゲームプレイ メトリクス (プレイヤー数と進行状況) は、RDS Postgres データベースに保存されます。 データ送信にはAPI GatewayとLambdaで構築されたサーバーレスAPIを使用します。 私は既存の RDS インスタンスを使用しましたが、サーバーレス RDS も同様に適しています。

デプロイでは、S3 と CloudFront には AWS コンソールを、サーバーレス メトリクス Lambda には AWS CDK スタック (Python) を利用しました。

CDK スタック

サーバーレスメトリクス Lambda の CDK スタックは簡潔です:

<code class="language-python">from aws_cdk import (
    aws_lambda as lambda_,
    aws_apigateway as apigw,
    aws_ecr as ecr,
    aws_certificatemanager as acm,
    aws_route53 as route53,
    Duration,
    Stack)
from constructs import Construct
import os

class DysonSwarmStack(Stack):
    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        repo = ecr.Repository.from_repository_name(self, "dysonSwarmRepo", "gamesapi")

        dyson_swarm_lambda = lambda_.DockerImageFunction(self,
            "dysonSwarmLambda",
            code=lambda_.DockerImageCode.from_ecr(
                repository=repo,
                tag=os.environ["CDK_DOCKER_TAG"]
            ),
            memory_size=256,
            timeout=Duration.seconds(60),
            architecture=lambda_.Architecture.ARM_64
        )

        # do auth inside lambda
        api = apigw.LambdaRestApi(self,
            "dysonSwarm-endpoint",
            handler=dyson_swarm_lambda,
            default_cors_preflight_options=apigw.CorsOptions(allow_origins=["*"])
        )

        custom_domain = apigw.DomainName(
            self,
            "custom-domain",
            domain_name="gameapi.compellingsciencefiction.com",
            certificate=acm.Certificate.from_certificate_arn(self,'cert',"[cert ARN here]"),
            endpoint_type=apigw.EndpointType.EDGE
        )

        apigw.BasePathMapping(
            self,
            "base-path-mapping",
            domain_name=custom_domain,
            rest_api=api
        )

        hosted_zone = route53.HostedZone.from_hosted_zone_attributes(
            self,
            "hosted-zone",
            hosted_zone_id="[zone id here]",
            zone_name="compellingsciencefiction.com"
        )

        route53.CnameRecord(
            self,
            "cname",
            zone=hosted_zone,
            record_name="gameapi",
            domain_name=custom_domain.domain_name_alias_domain_name
        )</code>

既存の ECR リポジトリ (Lambda コンテナ イメージを含む) と Route 53 ホスト ゾーン (カスタム ドメイン用) を利用します。 基本的に、Lambda 関数によってサポートされる API Gateway エンドポイントを作成します。 完全なコードは、dyson_swarm_stack.py

で入手できます。

コード

完全なゲームのソース コードは GitHub にあります: Dyson Swarm GitHub Repo

dysonswarm.html にあるメイン ゲーム ループは 100 ミリ秒の間隔を使用します。 ローカル ブラウザ ストレージ (localStorage) は、ゲーム状態の永続化を処理します。 ボタン機能（全56個）はbuttonFunctions.jsで管理されます。 ゲーム アニメーションは当初 SVG でしたが、多数の要素でパフォーマンスを向上させるために Canvas に移行されました。 徹底したテストと反復的な改善により、ゲーム ロジックのさまざまなエッジケースに対処しました。

AWS Q 開発者の使用

AWS Game Builder Challenge では、AWS Q Developer の使用が推奨されました。 役に立ったと思います:

長所:

• 直感的なチャット インターフェイスで迅速な回答が可能です。
• /dev 機能はコードの差分を生成して適用し、開発を合理化します。
• コードパターンの複製に効果的です。

短所:

• /dev 機能は、複数の LLM 呼び出しにより遅くなる可能性があります。
• /dev は、インライン コードの追加ではなく、新しいファイルを作成する場合があります。 注意深く迅速なエンジニアリングが重要です。
• 改善の余地はありますが、大きな可能性を示しています。

オープンソース ゲーム

ゲームのソース コードは MIT ライセンスの下で利用可能です。 プロジェクトの基盤としてご自由にお使いください。 あなたのゲーム制作についての情報をお待ちしています!

以上がDyson Swarm: AWS のサービスを使用してハード SF ゲームを構築した方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。