Goal of the game: Collect all available Tamas and keep your pets alive by feeding, playing, and letting them out.
Behind the scenes, pets will lose a point of hunger and bladder every server tick of five seconds. When either of these are depleted, the next server tick will reduce their happiness by 20 points. When happiness is zero, they will lose one or two status points, depending on how far below zero their happiness meter was at server tick (it still technically stays at zero in the database). Happiness can only be increased (by ten points) by winning a game of matching or tic-tac-toe with them. Once their status points reach zero, rest in peace little Tama.
Given that it takes about 500 seconds to deplete either hunger or bladder, and another 15 seconds to fully deplete happiness, and another 25 seconds to deplete all the Tama’s life points, our little Tama pets might suffer their worst fate short of ten minutes. Ouch! Definitely some tweaking to be needed, but programming goals were met.
At today’s moment of writing, TAMAGACHA is still feeling a little incomplete but the charm and polish is almost there. There are some issues with navigation, errors dealing with duplicates, and the game is lacking a tutorial. We would also need to replace the theme characters of the game to avoid the scrutinizing eyes of Bandai lawyers..!
A bit of an introspective
The calm before the storm..
Coming out of our Pokebattler webapp looking no worse for wear, we were thrust into the fiery pits of our last project at the UC Berkeley Extension coding boot camp run by Trilogy. The only difference was that instead of the two or three days given for us to build a rickshaw of an app, we were given 3–4 weeks and an attempt to display our mastery of building and incorporating RESTful APIs and a mySQL database into a fully-fledged application.
We were also able to select our own teammates — classmates I have learned and worked with for a short twelve weeks. What started out as three, became four and then a surprising fifth. Needless to say, for many people it was to be an intense scramble to find — while accepting or rejecting! — offers to be partners in crime, and it was especially difficult considering the varied personalities and skills of students. But as the dust settled, we, five weathered individuals, raced out to brainstorm and build the most polished application one could make.
Commence the build!
With Pokebattler experience, I constantly thought of how TAMAGACHA would appear and perform. Writing client routes out, testing them, connecting them to the server controllers with
Sequelize— that was the easy part. What was challenging was the ever growing requirements of our application, whether it be adding more fields to our models, updating the seeds, testing out new libraries, unsure of some newly incorporated features would work. With all of us being new to React, it was also important to know not only how to pass data into different Components, but the origin and structure of that data.
While we did designate someone to manage our issues and keep our team up-to-date, I definitely had my fair share of leadership and delegation of certain works to be complete. And what seemed really important to me, was to write out helper, functional code that our team could use for their heavy lifting in the client. Whether for fetching Tama data or appending/removing IDs from local storage, I made sure that the base instructions were constantly utilized by our React Components. With TAMAGACHA realized in my mind’s eye, I felt it was incredibly important that, if I should be directing the goals of which our team should accomplish, that I should also give them the tools to complete their jobs. Frameworks constructed from one blueprint or modal would be far more powerful than a melting pot of functions built as needed.
Writing scheduled tasks server-side
The difference between the Pokebattler application and TAMAGACHA was the inclusion of scheduled tasks carried out server-side. In Pokebattler, the player could actively interact with their Pokémon (even though it was limited to just creation of the Pokémon and using one ability — TACKLE!!). In TAMAGACHA, the player could actively interact with their pets, but a hidden player (the server) also forced their pets to be on a time-limit. Much like in real life, time is God and we are at their beckon. And in TAMAGACHA,
node-cron is their God and whatever he does, he uses the instructions I wrote in
Honestly, what amazes me is that with a couple of libraries, something I’ve never written before in the server-side was implemented with an incredible amount of ease. Having something run constantly in the background? Easily done with
node-cron. Accessing and making changes to the database from the server side? Easily accomplished with
node-fetch. With these tools at my disposal, it made writing out the passive game mechanics really fun. It seems like the more I practice writing code, the more surprised I get when something works out the way I want it.
A final few thoughts..
This TAMAGACHA project came out to be very self-fulfilling. I think with everyone on board with the project idea and given how many days we were given to complete it, we had built something full of charm and polish. If you look hard enough, there are definitely bugs that need to be massaged out.
But what I am most thankful for is being able to work with like-minded people that 1) want to carry out a project to completion, 2) are flexible with ever-changing endpoints, and, 3) as self-supercilious as it sounds, my ability to convince them to realize an idea or feature that I want. And thanks to them for building out the logic for the mini-games, the routing to display various React Components, adding extra features that make TAMAGACHA approachable and fun, and also being patient with someone who loves to spout endless ideas and think out loud (that’s me).
Endless thanks to Maria, Eajay, Samantha, and Eddie for sticking it out.
This might be the end of TAMAGACHA, but mostly because we want to avoid copyright issues with Bandai. It is their intellectual property after all. What we have next will likely be TOMATOGACHA, an even more polished application and builds on the code of its previous iteration. Check the project board in the GitHub repo for a list of ideas and fixes that will be worked on for the next couple months while I go find a real job 😅.