Database Table Tags
Our tooling is just a bit smarter this week (but much more usable). Take a look–
Only database tables with “gameplay_physical” tag shows up in the spawn-here menus.
The developer’s options for spawning something into the physical game world are now “Props”, “Items”, and “units”– three database tables (spreadsheet sheets) that have been marked with the “gameplay_physical” tag–
A sheet itself can have metadata associated with it now via “tags”, which is a comma-separated list of strings in cell B2, near the table / sheet title.
The new API for grabbing these tags is ultra simple–
Simply specify what sheet you want, and you’ll get all of the unique tags for that sheet. The immediate use-case, as described above, is to eliminate certain classes entities (or rows of tables) from consideration in things like menus.
Within different tables of our database (units table, items table, towers table, etc), there is often quite a bit of overlap and simularity between the entities in each table. For instance, the “units” table has a column / property for “display_name”, but so to does the “items” table–
This was not the case this time last week. Standardizing our table columns (every table should have an “id” column, “display_name” column, “description” column, etc) should allow us to write more general code, as currently each table is handled by a unique class in our codebase. If we can guarantee that each table has an “id” column, for instance, we can simplify our logic, thus reducing the possibility for bugs. In other words, in areas where our entities are similar, the same pieces of logic should process them.
A potential use case is in debug menus. If we can guarantee that every row across several tables will contain a “description” and “display_name” (and maybe even “icon”), we can create very generic and re-usable menus that display the icon and display name of each entity across theset tables (and put the description into a tooltip).
Instead of using an external tool, or even launching a separate scene, the Gameplay Testbed and Editor mode is now integrated into the game from its mode select–
Our debug / content creation modes may now be accessed from the mode select
…But only in development builds. There is reason to be nervous about this “improvement”, as it isn’t very hard to imagine a member of the team accidently pushing a development build out to the world (at which point this special functionality would be freely accessible), but fortunately our automated build system does not allow dev builds to be uploaded. Automating the upload process takes human error out of it (well, to an extent. It increases the amount of effort and investment needed for a human to mess things up).
As seen in the above gif, some menus will now allow us to click-around to different locations, allowing us to repidly place unique units at different places.
Standardized Website Icons (Partial)
Making the website more playful and interactive
Three of the six top-bar icons (that represent Arbor Interactive games) have been standardized. One of our freelance artists, Nastya Stepanova, has taken the main characters and redrawn their faces in her own cartoony, clean, and expressive style while keeping elements of the original game’s art style. She has also create a special “hover frame” for each character, allowing the character to change their expression when hovered over with a mouse. Three more icons are on the way.
The website is nothing short of hideous on mobile, so we will eventually need to shift some investment in that direction. While it may be worth hiring out, I’ve learned so much about how Jekyll, CSS, HTML, JS, etc work through my experiments on the desktop version of this site, that I’m tempted to tackle the issue myself, if for no other reason than to give me mobile-website-design abilities. Should my company ever shift into website production, it will come in handy.
The narrative of Life’s a Beach hasn’t received all that much thought– something that should be clear within about 10 minutes of playing the game. While its characters are charming (thanks largely to Sam Olson’s artwork and some playful voice acting), their motivations and backgrounds are at best dead-simple, and at worst non-existant. Improving the characters is a necessity, as meeting fun new people and learning their story is one of the great joys of existence (as scary as it may be for some of us).
Where to begin? If we look at the game right now, looking at its enemies, its playable characters, the intro cutscene, and general gameplay, there are a few things that cannot change–
- Sandy and Drift are building castles (proven through cutscene).
- Shadia doesn’t like it (proven through cutscene).
These two things cannot change because we don’t want to throw out solid (expensive) 1920x1080 artwork. We will use it to the death.
Here are a few more observation of things that can change–
- The player has an antagonistic relationship with wildlife, being fought by crabs, etc (proven through battles and enemy waves).
It occurs to me that we can adjust this latter item to give much-needed context to the two “things we can’t change” above. We should…
- Flip the relationship between Sandy and the crabs. They should be allied strongly (proven through 1-2 new cutscene slides showing crabs entering the new castle, and showing affinity for Sandy and Drift).
- Adjust gameplay enemy waves such that crabs no longer appear in them as enemy units.
- Create an automatic, guaranteed player unit posse of 2-4 crabs per-stage that will fight for you.
- Adjust marketing to no longer reference “pesky crabs”, as this no longer makes sense.
These changes allows us to (a) Motivate Sandy in building these castles. She doesn’t just love architecture (as referenced by her hat)– she also loves wildlife and wants to create a grand home for the local crabs. (b) Motivate Shadia’s short-term antagonism towards Sandy and her castles, as crabs are considered an invasive species in Michigan, could be seen to be annoying for beach goers, and Sandy’s rising popularity is a threat to Shadia’s power.
From a gameplay perspective, we gain the ability to spawn in 2-4 allies per stage (crabs) and have it make total sense. Positioning allied units to help defend chokepoints and support towers is a neat (and unique) part of gameplay, so it may help gameplay out a bit too.
This change, and specifically the fact that crabs are considered invasive in Michigan’s freshwater great lakes, gives us an avenue to push a more poigant idea as well– the idea of belonging and “otherness”. The poor crabs. Perhaps they really are upsetting local habitats, rebalancing local food chains, and causing some havok, but is it their fault? They’re just trying to survive, right? I wonder if my environmentalist friends will talk to me after this game launches.
A serious improvement to gameplay will require a serious improvement to testing and iteration. Waiting through an entire game load, menu navigation, stage select navigation, then intro cutscene won’t cut it. We need the ability to spawn in any enemy at any time. We need the ability to buff certain units with cheats such as infinite health so we can study how our AI, attacks, etc are working over a long fight. We need the ability to adjust (and persist changes to) testbeds such that we can test our technologies in diverse environments (and create unit tests out of them to prevent regression). The last few weeks of improvements to our landing page and load times were spurred by an improvement in our measurements and analytics in those areas. Our first step in improving gameplay should be to establish a more formal and rigorous measurement, analysis, and verification approach for gameplay-related problem areas.
In the current iteration of Life’s a Beach, a system called the GameplayManager takes responsibility for spawning enemies in the waves defined in the cloud config spreadsheet, running the stage intro cutscene, spawning the player’s posse, spawning initial currency, monitoring victory and defeat conditions, etc.
Note that none of these things are technically required for testing games. While we do need to eventually spawn units to test combat, we certainly don’t need to spawn them in a spreadsheet-defined way. Why can’t we just click a block and say “spawn 5 of unit type X on team “enemy” at this location?
- Upgrade : An affordance should be created simply titled “AffSpawn”. This affordance should be a right-click-only affordance, and be attached to any tile in the map. It should launch a window that displays a list of categories of “things” to spawn. Clicking a category should produce a window of all of those “things”. Clicking a thing should cause it to spawn at the initial location.
Subscribe to Future Devblogs!
Subscribe here to be notified when we publish future devblogs, tutorials, etc.