Inspiration

I realized that my addiction to the Minesweeper app on my phone had become truly apparent. I decided to take action, and make a clone of my own!

What it does

You text coordinates. The app lets you know if you got blown up. Hard reload, and you're back in action

How I built it

I started by looking for the right front end. I wanted something that could integrate with Flask, and using a react component felt like a bit overkill for my needs (though a React remix could be a great exercise for a future hack!). So, I poked around a bit with Plot.ly and MatPlotLib, but neither seemed to be grokking the way that I wanted. I had originally visualized doing a data viz dashboard, but p5 came out on top, due to its sheer simplicity. I wanted to build an app from concept to deployment, and I knew that higher power frameworks might leave me side-tracked, or trying to implement gimmicks for gimmick's sake.

So, I built the p5 game engine for the front end, and then started wiring up the Flask back end. Once I got it to a browser-clicky-game place, I went to work integrating Twilio to handle the actions. After a bit of fussing about with delivering data from immutable multi-dicts to (x, y) coordinates in p5, the app was nearly done. The style is minimal, but it gets the job done, and it's clean. I left axes off of the graph for increased difficulty ;)

I toyed with various mine concentrations to see how it effected the gameplay, and settled for about a 30% distribution. A future feature could be an adjustable board, with a variable number of mines.

After the app was functioning to my liking locally, I started building out the containerized elements that were necessary for a Google Cloud deployment.

Challenges I ran into

The p5.js library is not designed for event-driven programming. Navigating how the front end talked to the back end was challenging. Fortunately, p5 supports a loadJSON callback, but to implement a home-brew 'event loop', it is constantly making requests. Furthermore, delivering a payload from Twilio took a bit of figuring and experimentation.

And then, there was the deployment fiasco. I come from an AWS background, but I figured I'd give GCloud a shot (cheaper, plus why not??). Implicitly, the GCloud AppEngine containerizes the service, and it was tricky to get the app.yaml to speak the right language with GCloud. However, I emerged victorious over the gunicorns, and managed to get the app booted into the cloud.

As previously mentioned, the standard p5 library is extremely user-friendly, but also a bit limited when it comes to event handling. Figuring out how to program a minesweeper game without ridiculously repetitive code was a bit of a challenge, and fine tuning the details was, as always, a bit challenging.

Accomplishments that I'm proud of

This was my first real foray into building a web application, and I'm super proud that I actually finished it! Flask was delightful to work with, and I'm eager to use it for building more microservices in the future.

What I learned

I learned a ton. I explored Flask and p5 and the Twilio API. I learned how to manage my ideas and develop a workflow. I met interesting, fun, and intelligent people, and had a great time.!

What's next for MineTexter?

A reload button, or better, an automatic canvas reset after game over. I would also like to build up a Battleships version of the application, as it is a similar game with similar mechanics, and could integrate pretty smoothly with my existing code. A leaderboard would be handy, but better than that, perhaps a full refactor using additional event-driven modules available from the p5 community.

I am unsure how the mechanics of the game will break down or change with multiple users, or when more than one text is received simultaneously. I think that a simple queue implementation could reconcile this issue.

Another useful feature would be a response mechanism, whereby the server would send a message back to the user after they've sent a message, with the updated game status. If this were sophisticated enough, it could omit the need for a UI altogether, though I think that the visual board is a nice touch.

Share this project:

Updates