My First General Assembly Project
My first two posts were in 2018? What the heck happened since then? Yeah I wondered about that myself. Life I guess. But what’s important is that I’m back — kinda — and I’m going to tell you about something new that’s been going on.
Just over a month ago I left my pretty comfortable job at an energy company to go down a path some have described as “brave”, “inspiring”, “the right choice”. Others as “foolish”, “a waste”, “a mistake”, you get the idea. As with most things you can get pretty polarising opinions depending on who you ask. But that’s not what I want to talk about today, because I have something else I’m really excited to share with you instead: My first General Assembly project — Data Crunch (NOT mobile-optimised, VISIT ON DESKTOP), a small game based on jQuery! Let’s get right into it.
What is jQuery?
I’m writing this with an assumption that you’re equipped with a basic understanding of what jQuery is. But just to remind myself as well, jQuery is a Javascript-based library that was created to help significantly speed up DOM (Document Object Model) tree manipulation and various other tasks like event handling, and AJAX (Asynchronous Javascript and XML) calls. You could conceivably do everything jQuery does with vanilla JS for sure, but you’d probably need a lot more time. Think of it this way. Your task: Get a screw into the wall. Vanilla JS is your tried and tested screwdriver. jQuery is your Black & Decker power tool. Same job, twice(?) as fast. jQuery was first released in 2006, so it’s been around for almost 15 years, an eternity. Its continued popularity speaks to its resilience and relatively gentler learning curve.
What is Data Crunch based on?
Language: The underlying language is JavaScript, using the still-popular jQuery library. Why? Simply because this was what I learnt in my first 2 weeks of the software engineering course in GA! And what better way to put your skills to the test than to try your hand at a small project? The most important thing you have to know about jQuery is the dollar sign. Money, money, money. It gives you power to manipulate everything… in the DOM.
document.querySelector("h1"); // vanilla JS$("h1"); // jQuery function that returns a jQuery object
Game Mechanics: As a beginner, I decided on something inspired by Candy Crush. Most of us are familiar with the mechanics. Basically, you match candies in rows/columns. The longer the match, the higher the score. I came across this wonderful tutorial by Ania Kubow (thank you Ania!) who broke it down pretty nicely.
How does Data Crunch function?
Data Crunch works very similarly to its inspiration. Checking for matching tiles, clearing them, and cascading new ones underpins the entire game. There are a multitude of methods out there, but I settled on CSS Grid to adjust the layout of the body, and flexbox to create the tile grid. (I’ll address why throwing everything together like this without being familiar with how they worked had downsides).
Game Board:
— The game board was created using flexbox. Each tile’s height was 10% of the parent container to allow for margin spacing between the tiles. This also ensured 8 tiles could fit nicely. Why 8? Because 8 huat lor. Here’s a preview of how jQuery helps by allowing short and chainable methods that would look crazy long in vanilla JS. This is because jQuery objects are returned by jQuery methods.
$(“body”).append($divRound).append($divScore).append($divMoves).append($divGrid).append($buttonDiv);Tile:
— Each tile has two event listeners attached, a hover and a click. This is different from the tutorial and Candy Crush, which implements a drag-drop/swipe functionality. I prefer a click-swap functionality as 1. It’s my own implementation. 2. I don’t like holding down my mouse button. Each tile gets a random color and its own id from 0–63 as they are created using a loop.
Hover Event Listener:
— The hover event listener captures the id and the colour of each tile as the cursor passes over.
Click Event Listener:
— Super important. So many things happen here. Upon user click:
- Checks if a tile has been clicked before using variables that hold tile information. If NO, store the information!
- If YES, and THAT tile is different from the current tile that the cursor is hovering over, swap can take place!
- Check if there is a match made. If there isn’t a match made after swapping, means it’s an invalid move and the colours will swap back.
- Give a tile a halo to indicate the current selection. If another tile has been selected before, switch the halo over. If a valid swap has been made, remove halo.
Check and Clear:
— A function that runs every 500 ms to check for matches, clears them, generates new tiles, and cascades them down.
And there you have it, a quick summary of the key functionality of Data Crunch!
What’s unique about Data Crunch?
While the basic mechanics of Data Crunch is the standard tile-matching logic, which itself is quite fun and addictive, I wanted something more. Games and user attention are inextricably tied to privacy these days, so I decided I wanted to include that aspect in my project.
USP 1:
You start the game with only 10 moves, and every valid move consumes a turn. Once you’re out of moves, you’re given the choice of continuing with 3 more moves, or ending the game. All you have to do to continue is to indicate your consent to a random series of questions, each asking for some personal information. (Disclaimer: Data Crunch doesn’t actually collect ANY information other than your name which gets discarded upon page reload)
The Catch: In the background, as you’re matching tiles and gaining explicit points, there is a hidden ‘cost’. As more matches are made, points are taken away from a hidden privacy score. Both are revealed at the end. No game is ‘free’!
USP 2:
You can increase the difficulty if 5 different icons are too easy. More types of icons means a smaller chance of matches and less possible points. And of course the additional icons are from our favourite social media companies!
This aspect was meant to be an ‘educational’ bit, inspired by Data Defenders. Having fun and learning at the same time is really underrated.
Challenges Faced
- Tile matching logic — Initially I had one function created per unique match, so the matching function wasn’t reusable nor extendable. Managed to refactor into two functions, one checking for row matches and another for columns. Each accepting the number of matches as an argument.
- Building independent functions — As the code got longer, functions got nested and started depending on other functions. I ended up in a situation where I had no time to untangle some functionality from others.
- Building logic for tile halo highlight — On the surface a seemingly easy functionality to build, but boy was I wrong. Spent a quarter of a day on this. With this I cannot stress how important writing out logic flow on paper was for me to visualise what if/else statements I needed.
Areas for Improvement
Lots of things actually so this list isn’t exhaustive. But I have picked a few I either want to try to incorporate in my next project, or think it’s important to take note of as a general concept or best practice.
- Functional thinking — I tried to encapsulate functionality into functions, but as things started expanding and more logic got built I started nesting functions within functions. Ended up tangling the matching and clearing functionality with the cascading functionality. Remember not to do too many things in one function!
- Responsive design — As mentioned, the improper mixing of flexbox and grid meant my game performs decently on a desktop, but as I realised to my horror, is absolutely terrible on mobile. PLEASE PLAY ON YOUR DESKTOP. To be fair, responsiveness wasn’t a priority here, even though I incorporated simple components of Bootstrap.
- Reducing the use of global variables. — This was a relatively simple game, so globals are still fine. However, when the code starts getting really long and complicated with more functionality, I imagine globals can start interfering by clogging up namespace, among other problems.
- Single source of truth — What underpins the game is the “colors” of the tiles, which ideally should reside in a store such an array. Any reference or updates to that information is then made to the array in order to maintain consistency. My logic made constant references to the DOM in order to get that information which makes the code more fragile.
Conclusion
There’s no going about it, I didn’t think this was particularly easy. I’m honestly surprised and quite satisfied at how it turned out in the end. There were some major challenges, especially with programming thinking, responsiveness, and good code design. While I managed to go back and improve some bits, other parts unfortunately had grown beyond what I could change.
Overall this was a really fun project! There are certainly many areas for improvement, but if you are a Candy Crush fan, I hope this was a decent attempt at replicating the game. Additionally, I believe you’d be slightly better informed about your propensity to give up personal information when asked as well.
Let me know what you thought about this project through a comment or message. Will you be more alert the next time your personal information is at stake?
