Pusher Contest Idea: JavaScript Game (3)

K - May 5 '18 - - Dev Community

In my last post I lined out my idea and had a small discussion with Mikk about it.

I re-evaluated the game design and while it is far from perfect, I have to start or I won't meet the deadline.

Ha, doing stuff is the worst!

Game Design

A mix of the clicker and the battle royal genre.

I'd give it the code name Startup Clix

The rough out-line:

  • a game consist of multiple rounds
    • a round take about 10 seconds
  • there are about 20 players per game
  • every player has a startup
    • every startup starts with some money
  • there is a burn-rate
  • at the end of every round the burn-rate reduces the capital
  • every round every player needs to build a product
    • a product is build with clicks
  • at the end of every round the products are valued and sold
  • every startup gets the money value of their product
  • if the money of one startup is gone, its player loses the game
  • the last player left wins the game

An example game could look like this:

So you basically join a game, when it's full, the game starts.

You start clicking for 10 seconds to build your product and can submit it when you think it's good enough.

The faster you submit and the more clicks you put in, the more money you get at the end of the round.

After the round is done, you get your product money and lose money according to the burn rate.

If you got money left you can play the next round, if not you are out.

If you are the last player with money, you win.

Technical Considerations

Pushers Presence Channels to keep track of the online players, every game will be a new channel.

AWS Lambda & API Gateway to join a game and to submit a finished product.

Pushers Webhooks can call Lambda functions via API Gateway to keep the user count up to date on the AWS side of things.

AWS Step Functions to model games with state-machines. A state-machine is a definition of possible game states. Every game is an execution of a state-machine. Step Functions can pipe data from state to state (-> channel name, active players, money, etc.) , it can transition states with timeouts (-> rounds) and external events (-> player joins/leaves) and last but not least it can execute Lambda functions that can call the Pusher API to update all players.

Pusher and Step Functions are the core of the application, without Pusher there wouldn't be a way to get state-updates back to the clients.

I'll probably build the back-end with AWS SAM, to get the infrastructure as code benefit. I guess the Pusher side will be a few clicks to setup and can be controlled entirely via AWS Lambda.

For the front-end I'd use either React or Preact, because I don't know any better and I don't have much time to waste. GitHub pages is probably the fastest way to get it deployed just put an index.html in the repo root. I could version the whole thing in one repo.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .