Flowtris

A puzzle game where you transport people in cars or buses and fill in or avoid potholes to reach the destination.

Comment

Inspiration

I am currently working on a personal analogy. The main feature of the game is inspired by the logistics portion of the analogy.

The analogy in full is that it connects siloed information to cut through the noise and offer a holistic overview by mapping the interplay between the hearing process, parts of the ear, hearing aids, and assistive devices like directional microphones to road systems such as Germany's Autobahn, cars, trucks, buses, streetcars/trams, airplanes, warehouses, grocery shopping, and lean logistics vs bulk logistics.

What it does

The objective of the game is to transport people from start to destination on a grid representation of a city. The player must transport people through the city using cars or buses. Some roads have potholes and player can either fill them in or avoid them. Some levels have a 2-lane road system setup like Germany's Autobahn system, in which a car switches to the left lane to pass slower vehicles quickly before switching back to the right lane.

How we built it

We used Javascript to code the frontend and backend. We used React to build the grid. We used Mui Material Icons, Google Material Symbols, and Font Awesome for the icons. We used Pathfinding.js's A* implementation to find a path.

We may add SQLite DB later. It's not integrated right now.

Challenges we ran into

  1. App configuration for working together with multiple developers: Devvit is currently setup for playtesting one app per developer. Playtest is the ability to see a working version of code in the web browser.
    • Teammate was not able to playtest the app and communicated the issue 1 week in.
    • We worked with support in Discord and setup a local devvit.json file that works on my machine, only to run into a classic case of "This works on my machine but doesn't work on their machine". I could have configured this wrong or did not understand the workflow setup -- on my end, subreddit with multiple app names is supported but on teammate's end, they probably couldn't access the subreddit and so need to modify name and subreddit fields.
    • Due to all this, teammate worked on the UI without being able to playtest UI in action. We later switched responsibilities and I worked on frontend while he worked on backend.
  2. Decision paralysis: I started this project with a vague idea of the game based on my inspirations. When I started on developing paths logic, I easily implemented a simple working version involving one path. Then, I had multiple ideas on how to implement multiple paths for a grid and a 2 lane system, taking me 2 days. Later on, I decided to move on and switch back to a more simpler implementation and handed off development to my teammate. We'll revisit this feature after reviewing PR and when more work has been done on the game. Update: PR reviewed. See https://github.com/denqiu/flowtris/issues/4#issuecomment-3272882993. Multiple paths code added but kept to the side. It's not currently used. We will keep path mechanic simple for now and integrate later when my vision on the game becomes clearer. In other words, we're running out of time for this hackathon. We will not make changes until after judges finalize their decisions. Or probably set aside a separate branch or fork.
  3. Level mechanic in React: It was hard to read and connect the dots. There was a lot going on and it was overwhelming at first. It took me several days to get the hang of it, which delayed development time.
  4. Code changes: Changes tend to be submitted to a PR all at once, in one commit, rather than one issue/todo per commit. There were a lot of complexity going on rather than small simple, working changes. For example, path mechanic. There was complexity involved with multiple paths in the PR. I decided not to integrate it for now. I would prefer to work with the simple working version and build from that. But it's not bad. At least we have a very clear, working goal in code to compare against.

Accomplishments that we're proud of

This is my first time developing a game, a project, under a 2-week deadline. We worked with very short time constraints and across different time zones, USA and India. I am happy at least to move something conceptual to a product. It's ok that it is at a prototype stage.

What we learned

  • QA/PR review: Testing UI in detail and noting down issues to resolve. For example, see Issue 2.
  • Frontend: The flow of things in React when code keeps growing. It feels like spaghetti code and there's a lot of moving parts, making the experience feel complicated.
  • Communication: Better communication for app setup on teammate's side. If it was reported earlier, we would have more time to resolve this. Teammate then would be able to work on frontend code and playtest it. Teammate might create less issues for QA in Issue 2 although I consider more issues not a bad thing if it led to more scrutiny and more attention to the UI.
  • Code changes: We did not run into major issues but wanted to keep this in mind for future development. Try to keep changes to one issue or todo per git commit. Make small changes and keep things simple. Test. If all goes well, then that is the moment we can decide to expand and add more complexity. Starting out with complexity is not really the best idea in development.

What's next for Flowtris

There are more additional features to implement. This involves integrating Phaser.js into React. The game will incorporate features based on Sandtrix and Suika. See https://github.com/denqiu/flowtris/issues/3.

Built With

Share this project:

Updates

posted an update —

Agastya Khati suggested a PRD (Project Requirements Document) to start. It's a good idea.

References

PRD

Description: What is it?

A game project for Hackathon Fun and Games with Devvit Web.

Pre-Context: Germany's Autobahn road system. Has 2 lanes, fast lane and slow lane. Fast lane has no speed limit and only allows cars while slow lane only allows buses.

Problem: What problem is this solving?

Goal of the game is to transport people to the destination.

Why: How do we know this is a real problem and worth solving?

NA

Success: How do we know if we’ve solved this problem?

If the game feels fun to play.

Audience: Who are we building for?

Single-player

What: Roughly, what does this look like in the product?

A grid setup of a city and roads. Main feature is path charting mechanic.

Additional Features: ⦁ Level mechanic where there are many levels to choose from of various difficulty or game mode mechanic of easy, medium, hard difficulties. Endless mode or randomized level. Some levels have time limit or time limit depends on level/mode difficulty. ⦁ Sandtrix mechanic without requirement to color match across screen for filling in potholes. You actually want the opposite, to get as much sand as possible. ⦁ Optional: Flow-free mechanic to connect sandtrix box to potholes with pipes. Or if not enough time, automatic connection.

How: What is the experiment plan?

  1. Technologies: Javascript/Phaser.js/React
  2. Use React Grid to build simple grid of city and roads with fast and slow lanes.
  3. Setup missing squares in fast lane to represent potholes. They can have different sizes.
  4. Objective of the game is to plan routes and fill/avoid potholes in advance and transfer as many people as possible or all people in the level, which can be timed depending on difficulty. If you want to fill potholes, that will trigger sandtrix sequence which can be also timed depending on difficulty. Game will automatically take care of transporting people in cars or buses.
  5. To build sandtrix sequence, use Phaser.js.
  6. If we do have time for flow-free pipe mechanic, we can use the same React Grid component.

When: When does it ship and what are the milestones?

Ships in 2 weeks. Deadline is September 17.

Log in or sign up for Devpost to join the conversation.