Parable Rhythm - An Unpredictable Crime Thriller
An interactive game powered by A.I where you solve crimes in the notorious city of Genai. Every action will have a consequence. You drive your own story.
Published Mar 8, 2024
Ever felt like being a detective and solving crime, but never got a chance?
How about playing a role-playing game where you are the detective? What if you could channel your inner sleuth, solve crimes and have (theoretically) an infinite amount of cases to solve?
Presenting,
A crime thriller set in a modern town of Genai (pronounced gun-aa-ee), where each case takes a different turn depending on how you choose to solve crimes. Every action has a consequence and will drive the case into an unpredictable pattern of events.
You play as a newly-joined detective who has been assigned a desk job at the headquarters. The Police Department assigns cases for you to solve them through their software. Having the access to the software, your task is to communicate and collaborate with the lead in-charge of cases, Inspector Neel Ray.
Most games out there have a planned out story, well you could get some dynamics when the game gives you choices and switches between multiple storylines / endings, but the point being they are all planned out. People get bored and tired playing the same story again and again, especially when the game heavily relies on the story than gameplay. After the initial iteration of the game's completion, there's no objective left for the player to replay the game if it relies on creating suspense around an aspect of the story which makes the player play the game in the first place. That objective is lost, when going for a replay because you already have that piece of the puzzle.
To make it truly a unique experience to the player every time they play the game, we need a system that could monitor, analyse and drive the story according to how the user chooses to approach particular scenarios. So how do we create a system that dynamically shape-shifts accordingly? Thanks to LLMs (Large Language Models) and Generative AI models, creating this system has never been easier.
And this is where Parable Rhythm swoops in to implement all these cool game dynamics as a prototype to how Generative AI systems could be used to make truly unpreditive and engaging experiences for the player. They now get to play the game with their own approach, not constraint to the choices traditional games give. The replay-ability of the game becomes infinite as no story is repeated, the gameplay system generating a new story from the core idea of the game, that creates a whole new experience every time the player logs on.
Having used PartyRock to create a small text-based prototype on how GenAI could be used to implement dynamic gameplay features was, well, relatively easier than creating a full production grade 2D/3D game that people would consider paying for. But the prototype is enough to spark a fire to create these production-grade AAA games with the help of GenAI. Let's quickly go through an example of how we would implement this.
This is an XYZ company based in the town of Genai. They want to make a similar game to Parable Rhythm (just not on PartyRock) but using a game engine.
- The story, after deciding on a core game theme, the GenAI LLM model could be trained and be given specific restraints to how we want the story to revolve around the core idea of the game.
- The gameplay mechanics, the core mechanics need to be developed before-hand by the developers as a real-time implementation of the current state of GenAI can prove to be unstable for developing core mechanics on the fly. However, we could enhance the power these core mechanics. eg. In an NPC dialogue system, the character bios, dialogues can be easily generated with an Artificial Intelligence interference using text generation, audio generation.
- Assets like textures for worlds, levels (procedural level building), NPC characters and their backstory/bio could be easily generated via LLMs and Image Generation models. When modeling the textures for levels, characters these image assets don't need to be created and can easily be generated through Image Gen. Here is a use-case of AI generated 3D model achieved by Luma Labs: Genie.
Although by not saving texture assets locally, we increase load on the compute resources during generation times which in-turn hamper the performance of the game. One probable solution could be by using light models trained and used only for that specific purpose and not use the same seemingly bloated model for every use-case.
Keeping the previous requirements and plans in mind, here's how we could implement this architecture on the AWS Cloud specifically using Amazon Bedrock for our Generative AI models. Before proceeding let's go through a base rundown of the requirements we would need for the game.
- Generate a random crime report with the crime scene photograph
- A chatbot that would enact Inspector Neel Ray
- Chatbots to enact Database Access Terminals
- A temporary data storage to store story elements unique to the user that don't require tampering once generated
- Store player stats for creating a leaderboard for trackers like "Most Cases Solved", etc.
For developing the user interface, we could use a web-app / mobile app / a video-game (built with a game engine) depending on how further we develop the game to enhance the immersion of the player.
- A front-end web app (for the time-being)
Now that we have some specifications to work with, let's discuss how we could build and deploy the game using the AWS cloud.
Let's try and architect the game on the cloud. Though it is to be noted, that this solution may change over time according to specific requirements, use-cases, costs, operational ease and other factors.
- Front-end web app
- Can be hosted on EC2 with Auto Scaling (requires manual provisioning) or much effectively as a serverless container app using ECS with Fargate clusters so that we won't have to handle manual operations, will be cost-effective as we only pay for the resources we use and can easily scale horizontally for burst traffic.
- To authenticate the user, we use Amazon Cognito that provides centralized and managed services for User Pools. Then, connect a Lambda function to Cognito such that whenever a user signs-up, it records the new user data to DynamoDB (as we don't require a relational database and to use serverless scaling for optimized performance and pricing).
- Leveraging Amplify libraries, we connect our frontend app to backend services for further data exchange like handling player actions in-game.
- Generating Genai Databases
- Using a Bedrock FM (Foundational Model), we could create all three databases (Resident, Car Registration and Criminal) into a central storage area in S3 or a separate DynamoDB / RDS table (easier to maintain) so our Database Access Terminals (chatbots) can reference these later.
- We could use the FM to generate output in certain database-friendly formats (CSV, JSON etc.) that we can import into the database systems we choose on the AWS Cloud.
- Creating a big static database of Genai at the start would help reduce application load and provide consistent data for all players (though we could choose to use other ways).
- Generating a crime report
- Using the Lambda and the AWS SDK, we integrate Bedrock with a suitable foundation model and evaluate it as per our use-case.
- This FM will reference data from the Genai databases we generated and store in S3 / DynamoDB / RDS.
- Whenever the user starts a new game session, this Lambda task would not only get triggered and send data generated data back to the user but also save the crime report in S3 locally under the user's directory path for other services to feed off of it. This crime report is temporary data whose scope is only under the player's current game session. We can choose to save these crime reports for further training of our AI models or delete them after the session is complete / player solves the crime / wants to restart the game.
- Crime scene photograph
- After the crime report is generated, we use one of the Stable Diffusion FMs offered by Bedrock as it's prompt and save this image in S3 to serve the user.
- Inspector Neel Ray Chatbot
- Using a light, quick and instant model from one of the FMs in Bedrock, we train it to behave and enact like the character based on the player's context and a reference to the current game session's crime report and the static Genai databases.
- Genai Database Access Terminals
- These chatbots require to be trained to behave as if they were just Access Terminals and only output matching data stored inside Genai Databases.
- Using the API Gateway with Lambda, we could connect the frontend with our Access Terminal chatbot models.
- Another way we could approach this, is through OpenSearch / Kendra (depending on where / how the Genai Databases are stored) and deploy Lambdas to interact with OpenSearch / Kendra to search in the database documents.
- Leaderboards
- We can use trackers for every game session, every case solved for that specific player and store it in a
playerDynamoDB table. - To calculate leaderboards, being a read-intensive task, we don't need to overload our main table but use DynamoDB's DAX (stores cache) for it.
Finally deploying the static assets and the frontend web app through a Cloudfront Distribution would help accelerate performance and overall better player experience. On top of this infrastructure, we would use security measures (through AWS Network Firewall, Shield, WAF, etc.), monitoring tools (CloudWatch, Cloudtrail, VPC Flow Logs), and better user management (IAM) on the cloud.
We do need to consider fine-tuning and pre-training these FMs according to the tasks they are performing so that we could achieve efficient results, reduce computational needs and increase accuracy.
Using a serverless architecture at the beginning when you have no audience projections can be beneficial as we only pay for what we use (though charged by the cloud for abstracting server management). As the application scales and we gain data to start predicting/forecasting our load, it is important to consider going the traditional manual provisioning route as this can result in a much optimized performance and cost savings.