FarmCraft

Inspiration

In our downtime this semester, my teammates and I have been playing on a survival Minecraft server. Naturally, we found ourselves trying to automate the production of every resource we could think of, but there is no nice centralized tool that fit our needs. So, we set out to create FarmCraft, a tool that we will continue to develop and use to Craft to our fullest potential.

What it does

FarmCraft provides a convenient user interface for our database containing resource lists, YouTube links, game type (java/bedrock), game version (i.e. 1.21.11), rate/hr, and more for many common Minecraft farms. Users can explore all the farms or search for keywords until they decide on the best farm for them. From there, users are able to access build-specific pages that clearly display all required resources (a common complaint among our server is a lack of those in YouTube tutorials), embed the tutorial video, and display all the other information as described before. We made sure to keep the aesthetics on theme for the game, keeping the experience as seamless and immersive as we could.

How we built it

We built the backend fully integrated into AWS. We stored all item images and other assets (which correspond with resource displays) into an S3 bucket. The core of our service lives in DynamodDB tables which are structured as follows:

'Blocks' contains all Minecraft blocks as of 1.21.11 including their display and official names, this table exists for verification purposes.
'Builds' contains all the farms that we are hosting as well as most of the described fields. These include an id, name, and all the info described prior minus the materials. Other fields include difficulty ratings and details about the location of the farm.
'Materials' contains resource tables for every build. They hold a build id allowing us to reference the materials list as long as we know which build we are referencing. These contain all items and their quantities required for the build. Finally, we used Lambda to interact with all of these sources. We provide convenient function apis such as get_all_builds(), get_specific_build(id), and get_image(name). These have simple logic that make calls to the DB/S3 resources and return all builds in 'Builds', a specific build and its materials given an id, and a specific image given an item name.

Our Frontend was developed using React and used Next.js to make calls to our backend. We really wanted the site to embody the aesthetics of Minecraft, so we made sure to use the signature font and references as much as possible. Despite wanting it to look nice, we still wanted it to be extremely practical and clear, which is very important when working with detailed farms, so we were careful with our designs to keep them crisp and refined. While we used server components for data fetching, we implemented client-side interactivity for the search experience. This ensures the site feels responsive, ensuring that gaming experiences stay uninterrupted. One of our core architectural decisions was to isolate high-latency API calls (like images) from the main page thread. By creating the ImagePreview sub-component, we prevented a waterfall effect where the entire page waits for a single S3 asset. We wrapped the Image API call in a try/catch block within a dedicated async function. This ensures that even if a specific Minecraft item image is missing from our S3 bucket, the rest of the build data still renders perfectly for the user. This feature did not make it to our first release, but it will be extremely helpful in the near future (outlined below). Something that was really crucial to our success was our debugging strategy. Because we are integrating multiple AWS resources with our React frontend, we built a Visual Debugging Layer into our development environment. This allows us to distinguish between a "No Data" state (the query worked but found nothing) and a genuine API failure.

Challenges we ran into

Some of our greatest challenges included lack of familiarity with tools. Three out of four of us had never touched AWS, something so core to our project. Two of us had never seen React, or ever really worked with Frontend Development at all. Despite some of our lack of experiences, we had really strong planning and organization. That, of course, did not stop us from falling into random pitfalls, such as when a git-merge gone awry almost caused us to lose all of our progress at around 2 am. We stayed calm (as calm as one can when this occurs) and felt blessed when we had discovered 'git reflog'.

We had a really slow start to the project due to the learning curve of AWS tools, or sometimes accidentally overriding our DB. We spent a lot of time trying to understand every little thing, but stepping back into the big picture and reading lots of documentation caught us up to speed quickly.

Accomplishments that we're proud of & what we learned

We are so proud of all the new tools we learned how to use and got working! We were able to follow proper software development practices, including testing, documentation, version control, and project management using Jira, as well as using industry-standard tools and libraries such as AWS and React. As described in the challenge section, we weren't experienced in these fields before, but we were still able to build something we're really proud of! The best part is that it's something my friends and we can continue to use too.

What's next for FarmCraft

FarmCraft will not end when QuackHacks concludes. We plan on adding a user log in and authentication system, where users can favorite builds, as well as upload their own farms. We plan on adding more fun UI components, such as displaying the necessary resources in a Minecraft chest format, just as they would look in game. We also, of course, plan on massively expanding our database, including a range of farms for all versions, platforms, and use cases. We also plan to add recommended roadmaps to make Minecraft automation more beginner friendly. Finally, we will actually be deploying this using Vercel; we want to first verify that our program is 100% safe and won't allow any undefined behavior (or crazy AWS bills).