We’ve all played them. Those silly games that ask you to “find what’s wrong with this picture”. You find what looks like a discrepancy, and you touch that area with your finger , or click it with the mouse. The app recognizes you clicked the right spot, draws a little circle on it, and gives you a triumphant “DING” (ok maybe the sound is a bit cooler).
My question is: how could I implement something like this using Meteor? I’m too new to JavaScript and Blaze to come up with anything off the top of my head!
There’s a lot to answer if you don’t have JavaScript experience. In fact the answer would be the solution - and I’m not sure this is the right place to be teaching from scratch.
However …
I would start by looking at options for defining and recognising “hot spots” in images. These could range from old-school image maps, to SVG overlays, to canvas.
Once you have your chosen hot spot method defined, you can go on to the code to detect clicks - but you will have to spend some (quite a lot) of time learning fundamental JavaScript.
Then you will need to identify how to play a sound in JavaScript.
… and so it goes on …
I’m curious as to your proposed use case - why Meteor? What you have described does not in itself require Meteor’s awesome reactive stack.
I’d argue that Meteor’s isomorphic stack and rapid development speed is reason enough to use Meteor. Even if one doesn’t use reactivity or more Meteor-specific features. I build everything in Meteor now, because I simply don’t want to waste time, and I don’t want to have to build things in two languages (e.g. JS for front, PHP for back).
Javascript doesn’t seem that hard to learn. I’ve written in so many different languages, this syntax is very recognizable. I need to google image maps and SVG overlays because I’m not even sure what you are talking about here. The way I imagined it would be using the canvas. In fact, I even found something on StackOverflow that looks promising, provided I have pre-defined the hot spots in the image in the database to check against.
The code that I found has that click event listener already in it.
You bring up a good point with my choice of using Meteor for this. My answer to that is what ffxsam mentions below. The platform is just so nice, I can’t find a reason not to use it! Here are my reasons why I will:
isomorphic - I looked into Django and I’m not interested in having to write Python for server side
rapid development - javascript and blaze have almost no learning curve for me (mobile and web do , though)
future use cases - maybe I don’t use the reactivity functionality in this one specific feature, but I’m sure I will find some things along the way where I could use it, and when I do… yahtzee!!!
portability - from what I’ve read, it seems like I can create an app and port that code over to both iOS and android without too much headache… I think… right?
community - you guys are awesome! <3
HYPE!!! - so much to love about this technology and the community support. I feel like I’m at the ground level of something that is about to take off. I want to get familiar with it early!
Thanks again for the reply, I really do appreciate your thoughts!!
Cool - it’s always hard to gauge level of experience. It sounds from what you’ve said that the bulk of your experience is server-side and/or non-web?
If that’s true, then you will likely find much of the coding quite straightforward. However, if JavaScript is new, especially in the context of the browser, then I would recommend that you fully get to grips with asynchronous code. Depending on your language experience, that is probably going to be the weirdest thing to work with at first. For the most part, Meteor hides this very well in server-side code, but you will definitely need to understand it on the client.
I applaud your decision to use Meteor - your reasoning is sound.
Even if one doesn’t use reactivity or more Meteor-specific features. I build everything in Meteor now, because I simply don’t want to waste time, and I don’t want to have to build things in two languages (e.g. JS for front, PHP for back).
Cool - it’s always hard to gauge level of experience. It sounds from what you’ve said that the bulk of your experience is server-side and/or non-web?
I applaud your decision to use Meteor - your reasoning is sound.