Hello, this is Matsubara from the Coding Factory Club.
My main job is to act as a "project/technical consultation desk," where I am in charge of calculating the amount of work required to estimate and schedule projects that customers inquire about. However, I am a former coder in the Coding Factory Department, and I still occasionally code on my days off.
This time, I'm in charge of the January 2019 coder's blog, so I thought I'd make a New Year-themed game using HTML5 as a part of my winter break research project.
*"HTML5" is used not only to refer to HTML format files, but also as a general term for various technologies that have become possible with the creation of HTML5.
That's when the idea of "Tosenkyo" came to mind. I've seen it on TV and at sake events a few times, but some of you may be hearing about it for the first time.
To explain the rules in a very simple way, the game involves throwing a fan at a target (butterfly) on a pedestal (pillow) a few meters away, and competing for points based on the shape (mei = throwing fan role) that the butterfly, pillow, and fan make. Seeing is believing, so please watch the video.
It is said to have originated in the Edo period, but it is still popular as a pastime in the family home today. Some people also play it seriously as a sport.
By the way, does this movement look similar to something? That's right, it's the flick of a smartphone!
We thought that if we recorded the state of the smartphone when it was flicked and used that result to determine the name, we could create a simple game that captured the unique characteristics of Tosenkyo.
Visualize your tasks and create a schedule
This is my first time making a game, so I don't really know what to do, but I've listed the tasks that will likely be necessary and made a rough schedule like this:
- Throwing a fan = Obtaining the flick state using JavaScript (1st week)
- Coding the game screen and creating screen transitions (Week 2)
- Formulate judgment rules and display judgment results (3rd week)
I imagine I'd work on each for about 4-5 hours over the weekend.
As we continue working, it's likely that various additional requirements will emerge, but for now our first goal is to get it into shape as a game, and we plan to leave further refinements such as making it look better or improving the game's judgment as our future tasks.
Week 1: Getting the flick state using JavaScript
When I came up with the idea for the Tosenkyo smartphone game, I thought that the outcome should be determined simply by the speed of the flick, but with HTML5 it is also easy to obtain values related to the smartphone's tilt.
I decided to use the tilt as a factor in judging the game because I thought "this is probably an essential element of Tosenkyo." By the way, I have never actually experienced Tosenkyo! So, it's all based on my imagination, but looking at it positively, I have a feeling that something new and unconventional might come out of this.
First, the coordinates (X,Y) of the start position of the flick are obtained using the touch event "touchstart" and the coordinates of the end position are obtained using "touchend", and the length (distance) between the two points is calculated using Pythagoras' theorem.
When I want to know the specific information that can be obtained from an event, like the coordinates in this case, I can write the code below and open the Console from the browser's developer tools to check it.
Actual source code and Google Chrome's console screen. Information obtained at touchstart (when the user touches the screen) is displayed on the console screen.
Next, we get the start and end times using "new Date" and calculate how many seconds (time) the flick took, and then we can find out distance / time = speed.
The other factor to determine the angle is the tilt, which is obtained from the deviceorientation event. It shows the direction (alpha), vertical tilt (beta), and horizontal tilt (gamma), but since the direction is not relevant this time, we only obtained beta and gamma. Since deviceorientation cannot obtain the angle on a PC and returns "undefined," I verified it by displaying each value in an alert on my smartphone (iPhone).
I'm flicking my smartphone at different angles to verify that the values are being obtained correctly.
The task for the first week is to get the values using JavaScript, so that's all for now.
Week 2: Coding game screens and screen transitions
The game screens required were the "Top Page (1)" where the main visual and start button are displayed. The "Game Screen (2)" appears when the start button is pressed. When you flick on the game screen, the "Flying Fan Animation (3)" appears, followed by the "Result Screen (4)". We envisioned a total of four screens in this order.
This time, the images used in (1) to (3) are from "Irasutoya". Still, I can't believe they even have images of Tosenkyo! Irasutoya has such a wide range of content, it's amazing. Also, the photos of the inscriptions displayed on the results screen in (4) are from Wikipedia.
First, write four <section> in index.html and set them to "width: 100vw; height: 100vh;" in CSS. These four <section> are displayed full screen, and you can use JavaScript to toggle their visibility as you play the game.
The coding went smoothly because there were only a few elements, but I fell into a trap of spending more than two hours struggling with which font to use... When I was looking at the Google Fonts API page, I found a lot of interesting font effects, so I tried them out and time passed by in the blink of an eye. By the way, when I applied the effects, for some reason (this may be a problem with the development environment), they no longer displayed on the iPhone, so I did not use them this time. I chose a Japanese font from Google called "M PLUS Rounded 1c" to match the image of the illustration.
The " Google Fonts + Japanese " site. As you scroll down, samples of Japanese fonts are displayed one after another. It's easy to get an idea of the fonts, and it's stylish.
So, I completely misallocated my time, and it was certain that I would not be able to achieve this week's target task by the time the static coding was finished. In such a case, I prioritized the implementation of functions that are essential to the game and omitted optional elements! I decided to put the creation of animation aside for the time being and proceed with the implementation of screen transitions.
The specific mechanism for the screen transition is as follows: first, JavaScript is used to hide everything except the <section> of the top page, and then when a button is clicked (click event) or after a flick (touchend event), the display is switched on and off to transition between (1) to (4) in that order.
Furthermore, since this game is for smartphones only, if you access it from a PC (i.e. if deviceorientation is "undefined"), an alert will be displayed.
From the left, these are the "Top Page," "Game Screen," and "Result Screen" that we created this time.
I couldn't make an animation, but I think I can continue with next week's tasks as planned. The time for the second week is up here.
Week 3: Formulate judgment rules and display judgment results
There are several schools of Tosenkyo, each with their own unique meijyo (definition of hands and their points). The meijyo used in the game this time are those of the "Nihon Tosenkyo Renmei." There are 31 types of meijyo, each named after a Hyakunin Isshu poem. The task for the third week is to use JavaScript to determine the rules for judging the meijyo and display the results.
First, the "Photo (and alt)", "Name", "Score", and "Explanation" displayed on the result screen are dynamically changed, so we will make them variables and make them outputtable using JavaScript. At this point, we just want to be able to check the display, so we will output appropriate values.
For now, I've set it up so that what was previously written directly in HTML can be output using JavaScript.
Next, we call the judgment function and change it so that the results are displayed according to the judgment rules. The judgment rules are created by branching each of the flick's numerical values (distance, width, speed, vertical angle, horizontal angle) with if statements, so that if this happens, then this inscription will be displayed. It would take a lot of time to set up 31 patterns, so for now we've created only three. We used a two-dimensional array for the inscription list that is displayed according to the judgment results.
At this point the code was getting quite long, so I separated the judgment function and inscription list into separate files, judgment.js and data.js, respectively.
After this, you just need to carefully think up 31 different judgment rules and branch them using if statements to complete the process.
A spreadsheet to manage the judgment rules. It is not linked to JavaScript, but I made this because there are too many inscriptions and it would be difficult to understand them without putting them in a table.
However, I feel like the game is already complete even with just three possible outcomes. With that feeling, I'll end the third week here.
It was finally finished! Or so it should have been, but...
I was pretty satisfied with the results from last week, so I was thinking about slowly increasing the number of patterns, when suddenly I remembered something. "Oh, I haven't done any animation yet." That's right, I had completely forgotten about it. (I thought I didn't need it anymore) It doesn't take that much time, so I'll do it.
The animation is done using CSS3 transition, which simply moves the fan from the front to the back, reducing its size to create a sense of perspective. The screen transition is done using JavaScript's "transitionend" function, which switches the screen when the animation ends.
I was able to do this series of movements quickly, but when I went back to the top page with the home button and started the game again, for some reason the animation didn't appear from the second time onwards (sigh). After testing, I found that the start of the animation and the screen change process were running at the same time, and from the second time onwards, the animation had ended by the time the screen changed, probably due to caching (because it was a short animation). By adjusting the playback timing, the animation was successfully displayed from the second time onwards. That's right, in other words...
Finished!!!
Yay, thank you.
The completed game looks like this:
Results will vary depending on the distance (length), width, speed, and accuracy of your smartphone when flicking within the flick area (within the border).
You can actually play the game by accessing this page . (Please access it from your smartphone.)
Conclusion
When I first decided to make the game, I thought it would not take much time as the specifications were quite simple. However, it required more detailed adjustments than I had imagined, and because it was a smartphone game, it took quite a bit of time to prepare the testing environment (at first I displayed localhost on the smartphone, but it was a hassle to set it up every time and I had problems loading web fonts, so I ended up switching to GitHub Pages).
In addition, I'm actually still working on creating the 31 patterns... I hope to have them all ready by the time this article is published. When making a game like this, I'm also wondering if there are any other good ways to branch the game other than using if statements.
This time it was a New Year's edition, but I would like to try it again if I have the opportunity.
MATSUBARA Megumi