Da(ta) Bus

Connect the circuits to route Buster to his destination elsewhere on the motherboard. Careful where you place your tiles, you may end up blocking Buster's path! Help Buster to get a new high score!

Comment 2

Inspiration

With so little time to develop a project, and even littler time than we are used to for a hackathon (most of us have only done 48+ hour jams), we knew that our focus would be on creating a simple, but functional experience. The game concept is unique, but takes inspiration from a variety of existing games, including Tetris, Flow, and Circuits Logic Puzzles. Sound and visuals also took inspiration from Balatro. With the theme of connection, we were originally planning on theming the game to connected telephone polls to allow people to communicate, but when we started creating the tilemap, it looked a lot like a circuit board. We decided to lean into this and theme the game around a motherboard bus. We imagined that those who know what a motherboard bus is would appreciate the reference, and those who don't know what it is would find it silly.

What it does

The game's rules are simple:

  • Click and drag tiles and place them on the board to form a path between Buster and the target location.
  • When a path is formed, those tiles are removed from the board and scored, and Buster gets a new location to travel to.
  • Straight and corner tiles are worth 2 points, T tiles are worth 1 point, and cross tiles are worth 0 points.
  • The score for each path is equal to the point total of all the tiles used in the path, multiplied by the number of tiles used in the path.
  • When you are no longer able to complete a path, that's game over.

How we built it

We used Unity Engine with C# to build the game, Piskel for the art, and FL studio for the music and sound. For the sake of our own well-being both physically and mentally, we decided to start on Saturday morning instead of Friday night. Saturday morning started with a quick brainstorming session. One of our team members already had a game concept that everyone was on board with, so after some ideating and clarifying, we began figuring out what needed to be done. Our programmers split off to discuss software design and assign tasks, our sound designer began searching for inspiration and started composing, and our designer started creating a temporary tilemap. A few hours later most of the class structures were in place, the final tilemap and Buster animation were completed, and the background track intro was completed. Development from this point on was routine and largely went to plan, minus some algorithmic challenges, and we were able to submit on time.

Challenges we ran into

The game concept is very simple, but we all overlooked some crucial aspects of implementation that provided some difficulty several hours into development. The main issue revolved around algorithmically determining if a path had been created, and which nodes were a part of that path. The problem in itself is not too difficult, and can be represented using an undirected graph; however, utilizing depth-first search became significantly more complicated once we realized that the graph could include cycles of many difference varieties. Our designer discussed the issue with the programmer working on the issue, and they collaborated to create an algorithm that could account for the cycles, although it was more complicated than they had anticipated. In fact, we discovered through research that the problem is well-documented and classified as NP-hard. There were several bugs in implementing our solution, but we ultimately were able to solve it. One problem we wish we would have been able to solve but were ultimately unable to was the selection of the next location for the Buster to travel to. Finding a location with a guaranteed solution was difficult, and we managed to create an algorithm to do it, but it was ultimately too computationally expensive and hurt run-time too much to be included.

Accomplishments that we're proud of

Solving the NP-hard problem and completing the project in about 12 hours was a major accomplishment for us. Also, half of our team had never done a hackathon or game jam before, and so our success is definitely notable for us. Our ability to scope properly from the beginning and identify features that we would classify as stretch goals rather than necessary has improved the more we work together. This project was a good example of our ability to scope properly and collaborate efficiently.

What we learned

"Don't do graph theory" - Sean

On a more serious note, our main lesson (or really reminder) was that not everything is as simple as it seems. Despite our project's simple gameplay, a small oversight led to a significantly more difficult problem than we had anticipated.

What's next for Da(ta) Bus

We plan to polish Da(ta) Bus for a more refined release.

Built With

Share this project:

Updates