Start Building a Browser-based Web3 Rhythm Game

[GENERAL] Name and surname of main applicant

[GENERAL] Are you delivering this project as an individual or as an entity (whether formally incorporated or not)

[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)

[GENERAL] Please indicate if your proposal has been auto-translated into English from another language.

[GENERAL] Summarize your solution to the problem (200-character limit including spaces)

Build an app that combines music creation with chart creation in an accessible way. Mint NFTs and let players compete for partial ownership of them. Invite contributors and the community to take part.

[GENERAL] Does your project have any dependencies on other organizations, technical or otherwise?

[GENERAL] If YES, please describe what the dependency is and why you believe it is essential for your project’s delivery. If NO, please write “No dependencies.”

No dependencies

[GENERAL] Will your project’s output/s be fully open source?

[GENERAL] Please provide here more information on the open source status of your project outputs

The code will be closed source except for that which needs to be open for verification and trust reasons.

The music and charts created in app will belong to the artists and players. They will give the game a non-exclusive right to use them.

[SOLUTION] Please describe your proposed solution.

Premise

A web-based 7-key vertical scrolling rhythm game where makers make music, players play and compete, and they both work together to create an NFT marketplace.

MVP User Experience

You have 30 seconds to make a song. You have seven keys to press. They each make a different tone. You have to play it live. You do that until you're happy with the take. But you're not done yet. Now you have to play the song you just created and get a good enough score on it to "pass". This is to ensure that people don't create impossible songs - it will still be possible to create bad songs, of course. You hit the publish button. You now have an NFT of your song, congrats. You’re guaranteed 51% ownership. And the score you just got when you passed the song is now the top score on the leaderboard. People try to beat your score. Position on the leaderboard gives you a percentage stake.

Commentary

For the given timeline and small team size I believe this is a reasonable scope. The music creation experience given above is very basic. If there were a phase two to this project, that would be the focus. I think I’d borrow ideas from apps like Incredibox, and let the musicians build charts from combining templates, like they do with the music. Personally, this project would be an amazing opportunity for me as someone who has been working on rhythm games in his spare time for over 8 years.

Technical

• General - A vanilla TypeScript/JavaScript front end with a C back end running on AWS EC2, which will run a SQLite instance and a simple HTTP server.
• UI
• General - An HTML Canvas overlaid with HTML elements. 2D.
• Scenes
• Login
• Option menu
• Song selection
• Gameplay
• Results/Score
• Leaderboard
• Song Creation
• Graphics
• Mostly drawn using primitives, maybe some sprites
• Song Creation

1. Use the WebAudio API to dynamically play sounds in response to keyboard inputs with minimal latency while recording the timestamps of the input.
2. It may be wise to do some quantization - so the sounds are corrected to be more on-beat automatically. And not every note should be a hold, probably.
3. The user iterates until they’ve created the performance they want.
4. Using the final take’s input timestamps, create an audio file, which will be a recreation of the sounds the user heard earlier.
5. Now the user will play the song, and it will be an identical experience to other people playing their song because it’s just audio playback synchronized with notes on screen.
6. Note: You want to create an audio file because otherwise players would also have to be running the dynamic audio generation code. Better to isolate those two use cases. In the future perhaps the song creation experience will be more like a DAW and not require a live performance - live is just the easier thing to do at first, I think.

• Gameplay Engine
• I’ve written a rhythm game engine multiple times before so this should go fast, but maybe I’ll write some points just to make the scope clear.
• Notes have a time position, a lane number, a type
• Two note types: normal notes and holds. Normal notes are ones you don’t have to hold.
• On player input: find the earliest note that has not been hit yet. If you’re close enough to hitting it accurately, determine the score to award and mark it as hit. Otherwise subtract score.
• Synchronizing the audio and visuals is hard, because audio playback is done on the hardware, which the browser doesn’t have direct access to. But I’ve done it before.
• Customization
• Scroll direction up or down
• Scroll speed
• Audio offset
• Visual offset
• Key bindings
• Client-Server Interface
• Client requests the list of songs available to play
• Client requests the audio and notes for the selected song to play
• Client requests the leaderboard for a selected song
• Client uploads a song and notes
• Client uploads a score
• Client requests the list of songs that that belong to them, and their fractional ownership
• Unknowns
• How to mint NFTs
• How to manage and award fractional ownership of NFTs
• How to do authentication with the server and associate it with the user’s wallet
• What specifically the audio file format should be - raw samples, mp3, etc.
• SQLite setup and usage - it’s supposed to be extremely simple and basic, and I know SQL well, but I haven’t done it before
• HTTP servers - I’ve written a WebSocket server in C from scratch, and an HTTP interface should be easier than that, but there may be hiccups
• Planning for maintenance downtime, etc… In general there will be many problems that come from actually having users, but perhaps it’s best to wait and see if the thing is fun and people want to play it first.

[IMPACT] Please define the positive impact your project will have on the wider Cardano community.

The goal is to make a gamified Web3 experience that is accessible and fun. It could also be an avenue for musicians to make their first steps into Web3. Some of the technical problems and game design problems that come out of this could be interesting to document and discuss.

[CAPABILITY & FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

In the past I made two rhythm game engines that I decided not to continue developing. They're open source.

https://github.com/Trumpet63/Rhythm-Project

https://github.com/Trumpet63/Rhythm-Project-2

Those are both just prototypes. In the years since I’ve been working on a more ambitious rhythm game, which is not open source, and much of it I can’t showcase, but a functioning early alpha demo can be seen here: https://tempotonic.rocks/edmspack/

So I’m already certain that much of the project is feasible, since I’d just be writing logic very similar to what I’ve done before. I will need to work with the community to figure out the NFT aspects of it. I’m more than happy to give status updates and document my work hours. Including the community and getting feedback is going to be an important part of the process.

As far as whether the game will be fun - I think what I’ve outlined in the MVP is at least a little fun. Like a novelty or a toy you could spend a few hours with. It’ll be good enough if I can hand it to a stranger and they figure it out, make a song, and play a chart.

The point is to get the pipeline solved and give me some hands-on experience with Cardano, after which more game design possibilities will become clear.

[Project Milestones] What are the key milestones you need to achieve in order to complete your project successfully?

Start with the hardest thing first. Write the code that mints an NFT. Figure out what the content of it will be - raw audio samples, the chart, etc. Figure out how to manage fractional ownership.

Write out the design doc. Specify the client-server interactions. Build some parts of the app as necessary to answer uncertainties.

Build music creation experience. The first musician creates their first song.

The first musician mints their first NFT. The first player earns their first fractional ownership. At this point the app’s skeleton should be complete. I’m integrating feedback as well.

Publish it somewhere if it’s not terrible, probably on itch.io. Continue integrating feedback while polishing the thing up and checking for bugs.

[RESOURCES] Who is in the project team and what are their roles?

Jeffrey Spreng - Lead dev

https://www.linkedin.com/in/jeffrey-spreng-698236114/

[BUDGET & COSTS] Please provide a cost breakdown of the proposed work and resources.

1 dev part time for 6 months

20hrs per week x 6 months = 480 hours

480 hours @~$80/hr = $38,000

$0.38 USD/1 ADA = 100,000 ADA

[VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

You’ll get someone with deep interest in rhythm games who likes to build things from scratch to start integrating with the Cardano stack and researching the potential that web3 can bring.

[IMPORTANT NOTE] The Applicant agrees to Fund Rules and also that data in the submission form and other data provided by the project team during the course of the project will be publicly available.