Woodland Heroes is a persistent Facebook game set in tile-based isometric worlds. The game is split into two facets: a city building/resource mining mode and a turn-based projectile combat mode similar to the board game Battleship. It was released by game studio Row Sham Bow on October 2011 and won top awards in Gamasutra's Best of 2011: Top 5 Social Games.
DURATION:
While my internship at Row Sham Bow lasted two months, I focused on Woodland Heroes for about five weeks.
TEAM SIZE:
I mostly worked alone. I had assistance from a senior software engineer and a QA producer who reviewed my work and helped give me pointers on what I should next.
PRELUDE:
This is the first game I worked on in mid-development. Woodland Heroes was on Facebook for about a year once I arrived. My immediate job was to explore a large PHP and Actionscript code base and handle QA issues such as bugs and other suggestions. All of my work was done on a Mac laptop. Software included Adobe Flash Builder, Mac Terminal, SourceTree, and Splunk.
DURATION:
While my internship at Row Sham Bow lasted two months, I focused on Woodland Heroes for about five weeks.
TEAM SIZE:
I mostly worked alone. I had assistance from a senior software engineer and a QA producer who reviewed my work and helped give me pointers on what I should next.
PRELUDE:
This is the first game I worked on in mid-development. Woodland Heroes was on Facebook for about a year once I arrived. My immediate job was to explore a large PHP and Actionscript code base and handle QA issues such as bugs and other suggestions. All of my work was done on a Mac laptop. Software included Adobe Flash Builder, Mac Terminal, SourceTree, and Splunk.
PERSONAL GOALS / ACHIEVEMENTS:
* Learned plenty about Actionscript and PHP, having limited exposure to either beforehand.
* Learned how to playtest a Facebook app by running local copies on a web browser.
* Learned to debug PHP by "tailing the logs" and making unit tests.
* Reproduced and fixed quite a few bugs existing in the game before I arrived. Sometimes this involved searching for keywords "assert" or "error" in a Splunk database of user transactions to track down the cause of certain glitches. I will do my best to describe some of the fixes I have added since most likely no one reading has actually played the game:
--- Like most Facebook games, users have a limited amount of energy. If a user in battle places his shot markers and presses "Fire!" when he has no energy, the shot markers will go away. This inconvenience has been fixed and the shot markers will remain, saving the user some frustration having to place their shots more than once.
--- Also like most Facebook games, Woodland Heroes has a premium currency (crystals) that can be acquired through gameplay or microtransactions. One of its purposes is to repair user cannons in battle that have no hit points left (all its tiles have been shot). Cannons with no HP will be forever removed from the inventory so users must repair the cannons they want to save before the battles end. Cannons being repaired feature a graphic to show they are being repaired (an icon of spinning gears) and are invincible for that repair turn. If a player clicks to repair a cannon, leaves the battle and returns, the game will deceptively display "Click to Repair" even if he already repaired the cannon, wasting the user's crystals on a repair that's already happening. This was completely overhauled as the HUD state before and after leaving the battle is exactly the same.
--- Also on the subject of repaired cannons, if a cannon is destroyed in battle, it'll be replaced with a charcoal stub. If the player pays the crystals to have the cannon repaired, it'll return back to normal functionality but visibly will still remain a charcoal stub. These "zombie cannons" are fixed and will visibly return to normal once the repair is complete.
--- User image assert bugs. For the longest time, there would be "Not at root" graphical errors in Flash, some of which could derail the game and force the user to refresh the browser. The cause is because the Actionscript tends to receive the URL of "[object Object]" as opposed to a user's actual Facebook image.
--- Polished battle leaderboards. There are about 100 battles in the story mode that players can replay and try to get higher scores (i.e. destroy the enemy in fewer turns/shots). The problem was the leaderboard would not refresh every time you brought up the leaderboard so you could never tell who has the highest score at the moment without refreshing the browser. Poor user stories made this one harder to solve than usual.
--- Fixed weapons that are stuck in battles that have ended. Every item in a Woodland Heroes user's inventory has a sixteen digit ID, an item type (i.e. a "Slingshooter", a lumber mill, a flower bed, etc.), a region/battle, and a coordinate in that region/battle. Examining the user's battle and inventory data, if a battle doesn't exist (i.e. "battle_2_1") but an inventory weapon's data said it's placed in that very battle, the weapon simply disappears. Additional PHP code and unit tests were employed to validate all weapons to ensure they aren't stuck in bad battles and are returned to the user's inventory as normal.
--- Similar to the above glitch, users may pass invalid types of currency (i.e. collectible items like honeycombs, gears, moon rocks, etc.). PHP error-tracking code caught any glitchy inventory items.
--- Translucent items in the city screen. Some items sitting on the ground like rocks, tree stumps, etc. will go transparent because they overlap each other upon entering the screen (the game doesn't reset the alpha of all objects to 1). I solved this so translucent items will be opaque even if they are stacked on each other (thank the producers!).
--- Solved a rare glitch that had eluded coders for months. Before a battle, players clicked on weapons in their inventory and dropped them on the battle grid. However, on seldom occasions, some weapons would become "invalid"--they would be visible to the user but the game would treat them like they were never there. The solution lied in an old line of code that tracked all inventory item data and capped the number of weapons present in the given battle at 10. A weapon's data will list the name of the last battle it was in even if it had ended and was returned to the inventory. Therefore, if a user replayed the same battle repeatedly and had more than 10 cannons that were last used in that same battle, any weapons in the list past the 10th weapon with that battle name will turn null. I hope this story made sense but it was great to solve.
--- Here's a special glitch that I had reported on my own. If a user is placing a cannon on the grid pre-battle and clicks on a placed cannon while already holding one, he will mistakenly pick up both cannons. It's possible to pick up all the cannons and create a Katamari ball of cannons glued to the mouse cursor. Since then I have fixed this glitch. Take a look at the pictures below to see what I mean.
--- Many, many more QA glitches, unit tests, and code cleanup nonsense.
* Learned how to playtest a Facebook app by running local copies on a web browser.
* Learned to debug PHP by "tailing the logs" and making unit tests.
* Reproduced and fixed quite a few bugs existing in the game before I arrived. Sometimes this involved searching for keywords "assert" or "error" in a Splunk database of user transactions to track down the cause of certain glitches. I will do my best to describe some of the fixes I have added since most likely no one reading has actually played the game:
--- Like most Facebook games, users have a limited amount of energy. If a user in battle places his shot markers and presses "Fire!" when he has no energy, the shot markers will go away. This inconvenience has been fixed and the shot markers will remain, saving the user some frustration having to place their shots more than once.
--- Also like most Facebook games, Woodland Heroes has a premium currency (crystals) that can be acquired through gameplay or microtransactions. One of its purposes is to repair user cannons in battle that have no hit points left (all its tiles have been shot). Cannons with no HP will be forever removed from the inventory so users must repair the cannons they want to save before the battles end. Cannons being repaired feature a graphic to show they are being repaired (an icon of spinning gears) and are invincible for that repair turn. If a player clicks to repair a cannon, leaves the battle and returns, the game will deceptively display "Click to Repair" even if he already repaired the cannon, wasting the user's crystals on a repair that's already happening. This was completely overhauled as the HUD state before and after leaving the battle is exactly the same.
--- Also on the subject of repaired cannons, if a cannon is destroyed in battle, it'll be replaced with a charcoal stub. If the player pays the crystals to have the cannon repaired, it'll return back to normal functionality but visibly will still remain a charcoal stub. These "zombie cannons" are fixed and will visibly return to normal once the repair is complete.
--- User image assert bugs. For the longest time, there would be "Not at root" graphical errors in Flash, some of which could derail the game and force the user to refresh the browser. The cause is because the Actionscript tends to receive the URL of "[object Object]" as opposed to a user's actual Facebook image.
--- Polished battle leaderboards. There are about 100 battles in the story mode that players can replay and try to get higher scores (i.e. destroy the enemy in fewer turns/shots). The problem was the leaderboard would not refresh every time you brought up the leaderboard so you could never tell who has the highest score at the moment without refreshing the browser. Poor user stories made this one harder to solve than usual.
--- Fixed weapons that are stuck in battles that have ended. Every item in a Woodland Heroes user's inventory has a sixteen digit ID, an item type (i.e. a "Slingshooter", a lumber mill, a flower bed, etc.), a region/battle, and a coordinate in that region/battle. Examining the user's battle and inventory data, if a battle doesn't exist (i.e. "battle_2_1") but an inventory weapon's data said it's placed in that very battle, the weapon simply disappears. Additional PHP code and unit tests were employed to validate all weapons to ensure they aren't stuck in bad battles and are returned to the user's inventory as normal.
--- Similar to the above glitch, users may pass invalid types of currency (i.e. collectible items like honeycombs, gears, moon rocks, etc.). PHP error-tracking code caught any glitchy inventory items.
--- Translucent items in the city screen. Some items sitting on the ground like rocks, tree stumps, etc. will go transparent because they overlap each other upon entering the screen (the game doesn't reset the alpha of all objects to 1). I solved this so translucent items will be opaque even if they are stacked on each other (thank the producers!).
--- Solved a rare glitch that had eluded coders for months. Before a battle, players clicked on weapons in their inventory and dropped them on the battle grid. However, on seldom occasions, some weapons would become "invalid"--they would be visible to the user but the game would treat them like they were never there. The solution lied in an old line of code that tracked all inventory item data and capped the number of weapons present in the given battle at 10. A weapon's data will list the name of the last battle it was in even if it had ended and was returned to the inventory. Therefore, if a user replayed the same battle repeatedly and had more than 10 cannons that were last used in that same battle, any weapons in the list past the 10th weapon with that battle name will turn null. I hope this story made sense but it was great to solve.
--- Here's a special glitch that I had reported on my own. If a user is placing a cannon on the grid pre-battle and clicks on a placed cannon while already holding one, he will mistakenly pick up both cannons. It's possible to pick up all the cannons and create a Katamari ball of cannons glued to the mouse cursor. Since then I have fixed this glitch. Take a look at the pictures below to see what I mean.
--- Many, many more QA glitches, unit tests, and code cleanup nonsense.
MEDIA:
Opening Scene
Original Gameplay Footage--the "overworld" has since then been removed while the "Battleship" gameplay remains mostly the same.
LINKS:
* Woodland Heroes website
* Row Sham Bow website
Opening Scene
Original Gameplay Footage--the "overworld" has since then been removed while the "Battleship" gameplay remains mostly the same.
I was not able to take many screenshots at work. However, here's one of my desktop working on Woodland Heroes and Splunk at the same time.
Here is an example of a glitch. Here are the four cannons I placed before the battle.
I clicked on the one cannon then another...I now hold both red cannons.
Now I'm able to hold all four cannons.
The battle starts but wait--all my weapons are still glued to my cursor.
I'm still holding the cannons even after placing my shots.
Server-side, I have three cannons in place (see the green patches of grass). Yet client-side, everything is visually messed up. Game is still playable but this bug needed to be squashed.
LINKS:
* Woodland Heroes website
* Row Sham Bow website
