WordShip

Compete in a competitive 1v1 Wordle Shooter

Comment 1

Inspiration

Wordle is a game that's been getting some notoriety, especially after it was bought by the New York Times for over 1 million dollars. We wanted to take inspiration from this relaxing game and make it competitive. So, WordShip was born.

With a unique twist on one of gaming's oldest and most hardcore genres with society's newest and most casual addiction, we've created one of the most unexpected combinations of games.

What it does

Wordship is a competitive 1v1 "manic shooter." For reference, this is a "manic shooter":

Manic Shooter

You'll encounter this type of situation in WordShip.

WordShip is played with at least 2 players. One player, the "Player", will be navigating around the map trying to guess the "Secret Word" by destroying words that spawn. When a word is "destroyed", a Wordle-like clue is given. The player's goal is to guess the word before dying (either after guessing a certain number of times incorrectly or getting swarmed and damaged by crashing into too many words)

Words get spawned by the second player, the "Spawner." The "Spawner" knows the "Secret Word" but has to give fake words to the "Player" to guess. So, the "Player" is playing Wordle with a Manic Shooter component, while the "Spawner" is basically playing "Anti-Wordle" where clues they give should contain the least amount of detail to the "Secret Word."

After a random amount of time, the "Secret Word" spawns on the map.

Swarming the map with words could overwhelm the "Player" but at the same time, the “Spawner” could accidentally send clues that bring the "Player" significantly closer to guessing the word could be spawned in! For example, if the “Player” knows that there’s an S in the word and none of the other words spawned have an S, it’ll be easy to find the “Secret Word.” So, the "Spawner" has to play with a balance of both careful word selection and speed. They should be relatively quick in selecting words since if there are only a few words on the map, odds are that the "Player" will guess the "Secret Word".

More than 1 player can join the "Spawner" side, though they'll all have to come up with unique words together!

How we built it

The "Spawner" player uses a deployed React frontend on Google Cloud to spawn words into the game.

The "Player" uses a game built on Godot.

The main magic is the linkage between the web and the Godot game. We linked the React frontend deployed and hosted on Google Cloud to a Heroku-deployed Node.js combo Express and WebSocket server backend. The front end uses POST and GET requests (send via Axios) to API routes we built in the backend to influence the WordShip game state. Once the word is received, the validity is verified and then sent to Godot via a WebSocket, which then is spawned by the Godot game. When any word is destroyed inside the game, the word is then sent to the Express backend, where the Wordle clue is generated, then sent back to Godot to render on the "Player" side.

Challenges we ran into

It was the first time we ever worked with the Godot game engine and the GDScript. Additionally, none of us had ever used WebSockets, much less in two different languages. We originally were going to use Socket.io, but it wasn't working in Godot's C# scripts, so we had to switch to plain only WebSockets. The fewer capabilities of vanilla WebSockets implemented in Godot made it more challenging to create the functionalities we wanted, such as events, to separate out triggers. Since we couldn't trigger specific events, we had to find a system to diversify events through a single channel, so we adapted on the fly by adopting a JSON-based communication schema to parse through all the WebSocket events sent through the single packet channel by Godot as opposed to relying on the abstracted event-based functions that are in the NodeJS WebSocket package.

Besides the WebSockets, the physics and its nuances were also challenging. For example, if we didn't normalize the velocity, you'd move diagonally faster. Having a strong background in the fundamentals of physics is essential to game development.

We also encountered a giant merge conflict issue in Godot that broke the game, forced us to purge the remote, take the most fleshed out Godot game to remote, and add back in the other merged in scripts and objects again.

Godot itself has a lot of functionality and many different ways to accomplish a task, so figuring out simultaneously what to use and how to connect many complex components was a huge challenge. The larger the game, the more interactions, and the more components that need to be connected. For two Godot first-timers, this was overwhelming to do in 36 hours.

In terms of the traditional web component, our main backend developer had never worked with API routes and set up the backend. He'd never worked on the backend before so just figuring out the technicalities of backend development was a significant challenge. Also, deploying the React App on Google Cloud was difficult since the documentation wasn't too good.

Accomplishments that we're proud of

We felt that we made the game surprisingly polished for something we made in 36 hours and using a game engine we weren't familiar with. We're also pleased with how responsive the game is and how fun it actually is to play!

What we learned

The team learned all about game development using Godot, including scripting and game physics, WebSockets, deployment, and backend parts (such as API Routes, CORS, and the types of requests).

What's next for WordShip

We want to implement a room system which would be accomplished if we manage to get Socket.io in C# working. This would allow multiple instances of games to run at the same time instead of just one. Additionally, making more screens in the game itself such as a start/landing screen and a wandering AI would be good. We would also implement a scoring system for the "Player" based on how many "Secret Words" they can guess before they die too.

Built With

Share this project:

Updates