Skip to content
Varun Singh edited this page Oct 3, 2024 · 12 revisions

Welcome to the Streamlines wiki!

Always make sure all software tests pass before merging PR.

Sanity Testing

  • Are all methods and classes emulated by GWT?

  • Does creating and editing a path work? Test bidding system, top dog, inventory system.

  • Does multiplayer work? (i.e. do routes and planes appear live when another player joins and interacts with the game)

Internal Testing

Initial Game State

Failing to Meet a Quota

  • Complaint system - choose between board confidence going down and losing terminal
  • Merge, don't split paths. Path splitting caused ConcurrentModification (requiring hiding during the frames that it gets done), players have to put planes back, which leads to edge case: we need to deal with the passengers on the flight of the airplane that is getting returned to inventory. OR we keep the planes automatically but then what if there's a plane loading on a terminal that gets lost? We wouldn't have these problems with merging. The planes stay in their current state without extra logic and the mechanic is a simpler one.

UI

  • Side action bar
  • Move everything out of map instead of drawing on top of map using UI manager

Player Disposal

  • Should we revert all bids to previous player (and store the previous bidder in memory as Optional<Player>)? Prevents cheating by joining on a separate device, bidding, and then leaving. But players might not want those terminals back and would rather just place a separate bid. The important part is alerting the player every time a terminal of theirs is affected: "someone placed a bid over your terminal", "the bidder left the game", etc.

Closed Testing

Logistics

  • Gather emails (personal preferred) in group chats and DMs
  • Google Sheets extension for email list and personalized messages
  • Google Form for gauging experience with gaming, experience with RTS, and desired time commitment (more time commitment = earlier prototypes, smaller time commitment = later prototypes)
  • Testers who commit early are expected/requested to continue through later rounds of prototypes
  • 3 full games per tester per prototype
  • Discord server for people to find others that can play with them at a convenient time
  • Google Form to log feedback, time played, who played
  • Non-UMD students will need to separately request to us for a specific time so we can start the fly.io server
  • Web and desktop are very different purposes/audiences/experiences
  • Fix as many bugs as we can find, finish end game state, polish all transparency and communication before rolling out to testers
  • Roles for levels of experience and rounds
  • Automate everything through Discord bots, Google Sheets extensions, ChatGPT scripts?

Mechanics

  • Increase quota as player keeps surpassing double the quota
  • Challenging a player to get their terminal (with odds in favor of current owner) to meet a quota

Clone this wiki locally