Showcase at Pacific Science Center

This past weekend, we had the exciting opportunity to present our game at the Pacific Science Center in Seattle! We were there with about a dozen other games created for the Seattle Indies Game Jam held two weeks ago. Since then, we and the other jammers have been polishing up our games in anticipation of the showcase.

Pacific Science Center Showcase

PacSci hosted the venue for the game jam itself as well

We were also absolutely thrilled to be recognized with the showcase’s ūüŹÜ Community Choice¬†ūüŹÜ award! During the exhibit, votes were collected from the attendees on their favorite game, and we are super grateful to everyone who voted! To be honest, I was not expecting this given the many great games on display, and I strongly encourage everyone to check out the other submissions as well.

Community Choice Award

The prizes for the game jam were… jam!

In this post, we’re sharing what we’ve been working on since the jam, what we learned from the showcase, and what we plan to do next.

UPDATES POST-JAM

In the previous devlog post, we covered 5 key points of game design, and over the past two weeks, we focused on those points we thought needed the most attention. We believe our efforts during the jam reasonably covered (Game)Play, Polish, and Progression, so we prioritized Payoff and Personality next. This involved adding:

  • A Level Summary at the end of each level, displaying a star rating on how efficiently the player solved the puzzle
  • Dialogue text between the Magician and Villagers, highlighting the humor in destroying the Village to save the Villagers

Not my trinkets and doodads, please!

The villagers show a peculiar attachment to their belongings

Beyond these, we made a variety of other improvements:

  • Three (3) brand new levels added!
  • Dynamic music that follows the player’s progression
  • Pause menu with options to Restart or Quit
  • Custom cursor changing to an open hand over adjacent buildings
  • VFX over UI counter to highlight inventory changes
  • Intro sequence at the Magician’s Tower
  • Larger models to make Magician and Villagers more visible

Intro Exposition

The intro sequence serves to set the premise

We also squashed a few bugs:

  • Prevent Magician from walking past Villager
  • Check win condition when Villager exits (in case the Magician is already at her own exit when the last Villager escapes)
  • Add missing SFX for Villager teleporting

SHOWCASE REACTIONS & OBSERVATIONS

One of the great benefits of¬†exhibiting at the Pacific Science Center is the wide range of people who show up and play your game (we’ve previously presented both Else Return Home and Good Night Rowan there). Because there are a lot of families, you get toddlers to parents playing your game. Some are experienced gamers, and others rarely play games at all. Kids especially provide some of the most honest feedback you’ll ever get! And, you get to hear fellow game developer feedback from the other exhibitors.

All Ages Exhibit

Kids really teach you how to explain things better

Seeing all these people play our game, there was both a lot of positive feedback and a variety of things we recognized we could do better.

Here’s what went well:

  • Of course, receiving the Community Choice was a major positive!
  • Even some of the youngest kids were solving the puzzles (in some cases, despite their parents’ misguidance).
  • One parent approvingly noted how our game could help kids learn critical thinking and logical problem solving skills.
  • A dad and his daughter completed all eight levels and came back later to play again!
  • Many people laughed at the silly dialogue we had scattered throughout the levels.
  • A couple jammers remarked how much the addition of the dialogue enhanced the experience.
  • Many people complimented the visuals, music, and game design.

My Auntie's Toothpick is in that house!

Folks got a good chuckle from some of the lines

Of course, the game is far from perfect after just two weeks, so we took notes on areas for improvement:

  • Our biggest concern was on how long it took many players to grasp the control scheme. We’re considering a variety of ways to make this more intuitive.
  • Some people thought an early line (“Save the windmill, not me!”) meant there was a solution that left it standing when you couldn’t. We realized this line should only come after more thoroughly establishing the Villagers’ excessive materialism, and/or use it on a level where you can avoid destroying it.
  • It was not clear to some how the star rating was determined. We’ve now edited this from “Moves Taken” to “Tiles Walked”.

Level Summary window

“Tiles Walked” is hopefully less ambiguous

WHAT’S NEXT?

Now that both the jam and the showcase are over, the first thing we’re doing is taking a rest. ūüôā Otherwise, we’re looking forward to our next opportunity to present the game to the public, which will likely be around February 2020. We’re already considering a handful of things we can do next:

  • Build development tools to create levels more quickly
  • Add improvements to better signal the game’s mechanics
  • Explore alternative control schemes that may be more intuitive
  • Detect puzzle fail state and prompt player to restart
  • Introduce new mechanic(s) to extend puzzle scenarios
  • Add dynamic villager responses to the player’s actions

In fact, we’ve already added an optional hint system

What would you like to see most? Leave a comment, or follow my itch profile to be notified of future updates. We look forward to sharing the next iteration with you in the near future!

Game Jam Post-Mortem

In this post, I’d like to share my team’s experience at the¬†Seattle Indies Game Jam 2019, where we created¬†The BridgeMaster, a tile-based puzzle game. You play as a magician who must salvage materials from the village in order to build bridges and help the villagers escape!

GOALS

Going into the jam, we had a variety of goals:

  • Above all, we wanted to choose a game design that was (relatively) simple to implement and polish the crap out of it.
  • Our two previous games (Good Night Rowan and Else¬†Return Home) were both first-person, so we wanted to switch it up with a different perspective.
  • The last two games also had relatively long gameplay loops. This time, we wanted to make a tighter gameplay loop where the primary action was exercised more often.
  • For our other games (first¬†Dog Walk, then FLY2K) we developed a generic graph library for representing nodes and edges/connections. This time, we wanted to utilize that code again but for a tile-based game.
  • We also wanted to pay attention to some core concepts of game design and let those inform our process as much as we could. The next section lays out some of those ideas.

THEORY

Before the jam, I thought about what makes a good game for a jam. Following one of our earliest jams (Odd Office), we were super grateful to be recognized by the judges for the Best Game. Something one of them said stuck with me ever since, and it was that they appreciated how it had a clear beginning, middle, and end (which can be difficult to do in only 48 hours). This insight with some other ideas evolved into a 5-Point Theory:

  • (Game)Play: The core mechanic needs to be compelling and fun to play. Ideally it is quick to repeat / can be demonstrated quickly.
  • Progression: This is where the beginning, middle, and end especially come in. There should be clear advancement, whether in terms of levels, difficulty, plot, player abilities, etc.
  • Payoff: At the micro level, this entails the audiovisual feedback when performing¬†the core mechanic. At the macro level, this¬†involves some payoff at the end of each level and at the end of the game.
  • Polish: As much as there is time for it, we should give care to the¬†audiovisual¬†aesthetics, enhancing elements where not strictly necessary but the discerning observer will notice and appreciate.
  • Personality: Finally, in the narrower sense, the game should have easily identifiable characters within it. More broadly (and perhaps more importantly), the game itself should have a clear style, and it should feel like it was made by real people.

5 Point Theory

I even made this shoddy sketch for the team at the jam

BRAINSTORMING

With these goals and aspirations in mind, we arrived at the site and discovered the theme: “Intentionally Broken”.¬† Some first thoughts had to do with “broken” games in the meta sense or goofy physics. We wanted to go further though, so we considered what it would mean if the game’s setting – the world itself – was broken. Combined with our goal to make a tile-based game, we imagined that some tiles could be walked on while others had fallen away. This soon led to¬†a magician building bridges to help villagers escape a crumbling village.¬†Finally, the piece that brought it all together was that the player’s character herself must intentionally break down the villagers’ homes to save them.

Paper Prototype

Here’s an early paper prototype of a level

WHAT WENT WELL

First of all, we had a load of fun making this game! I think that should be the top priority of any jam. We also largely achieved our initial goals by choosing this design. The (Game)Play loop was shorter, it had a top-down perspective, it was tile-based, and it used our graph code. We also finished the core mechanics with time for plenty of Polish. This included:

  • Displaying visual effects and animations for a variety of events (e.g. salvaging materials, bridge building, teleporting)
  • Interpolating rotation of the characters going around corners
  • Syncing up the audio to our intro sequence
  • Including color-coded visual feedback for the player’s input (indicating valid or invalid paths)

We also managed to develop a Progression with five full levels, along with a short intro and outro to bookend the game.

This bridging animation was not strictly necessary yet great to have

WHAT COULD BE BETTER

Nonetheless, there were many things we ran out of time for or struggled with:

  • While the intro briefly displayed the title before the first level, we did not fully establish the exposition.
  • We also planned a broader outro with its own scenes and animations, but we did not get around to this.
  • We had to leave out any¬†tutorialization dialogue for teaching the controls and mechanics.
  • While the five levels we made were intended as the tutorial, they weren’t large enough¬†to more fully demonstrate the puzzle solving potential.
  • Without the dialogue, we could not establish the Personality of the magician or the villagers and¬†highlight the humor in destroying the village to save the villagers (“Not my trinkets and doodads!” “Do you even want to be saved?”).
  • One¬†Payoff element we imagined but didn’t include was a level summary window, indicating to the player how well they did.
  • We inevitably ran into some version control issues. Merging Unity scenes amirite?

A grand plan that didn’t quite make it

WHAT WE LEARNED

Although we didn’t complete everything we wanted, we learned a lot! Some key takeaways:

  • Communication is key! With nine people on the team, it became very important to regularly sync up.
  • Whiteboards are super useful! We happened to pick a table near one, and it soon became integral to our process. We used it to¬†sketch out ideas and kept a running TODO list with status indicators and prioritization points.
  • Be prepared to cut scope early and often! We had many plans, but as the jam progressed, we periodically put features on the back-burner. By Saturday afternoon, we knew we had to switch gears and polish what we already had.
  • Clearly delineate responsibilities! Version control works best when individuals are working on separate assets, whether those are scripts, scenes, or prefabs.
  • Do variations on art assets at the end! Art must always be completed before it can be integrated, and they can’t be integrated before they are done. This means the art team could wind up finishing content at the end with no time to integrate. However, if you’ve already integrated a given asset type once, it will probably be much simpler/quicker to add or swap¬†in a variation.

We reused the same rig to add another villager type at the end

WHAT’S NEXT

Although the jam is over, we’re continuing to polish and extend on the project! A week from now, we’ll be showcasing at the Seattle Indies Show & Tell and SI Game Jam Showcase. If you happen to be in town, we hope to see you there at the Pacific Science Center! Here’s a sneak peek at some of the new features we’ve added since the jam and plan to have in time for the showcase:

  • New intro sequence starting with an establishing shot of the Magician’s home
  • Dialogue to help teach the controls and mechanics
  • Dialogue with exclamations and responses between the Villagers and Magician
  • Various bug fixes and quality of life improvements
  • Dynamic music that updates according to the player’s current progress
  • New, bigger levels added to the level progression!

While we continue to work on The BridgeMaster, we’d love to hear your feedback and suggestions! If you’d like to play the game, you can download it above. Thanks!

Introducing: The BridgeMaster

RELEASE

This past weekend, my friends and I had a blast participating in the¬†Seattle Indies Game Jam 2019! It’s the largest team I’ve been on so far (nine people), and we were thrilled to earn an Honorable Mention from the judges and top marks from the community vote! If you’d like to play it, you can follow the link below. We’d love to hear your feedback as we continue to polish and extend it!

The BridgeMaster

DESCRIPTION

In¬†The BridgeMaster, you are a magician who discovers that your neighboring village is collapsing! The townsfolk have been left stranded on the pockets of land still left standing. It’s now up to you to save them! In this tile-based puzzle game, you must salvage materials from the village, build bridges across the chasms, and give the townspeople a route out. Just be sure that you’re not blocking the path you create for them to escape!

2019 Global Game Jam: 1 Month Later

One month later and we’ve made many updates to our Global Game Jam entry,¬†Else Return Home! In that time, we’ve added all new environment models, new effects, cinematics, and all sorts of polish.¬† To see what we’ve added over the past month in more detail, take a look through our previous devlog posts and continue reading below for what we’ve done most recently.

This past week in particular, we’ve focused primarily on some features we wanted to have when we exhibit the game for¬†Seattle Unity User Group‘s¬†Show & Tell Mixer. This includes idle cinematics for the title screen and the ability to easily restart from in-game menus, both of which are super handy for exhibiting.¬†The event will be hosted at Wizards of the Coast, and if you happen to be in town, we hope to see you there!

Here are some specifics on what we’ve done this past week:

UI / UX

  • Update title screen to show City environment with the latest models
  • After game is idle for some time in title screen, display cinematic camera movements through City environment
  • Prevent accessing the Pause Menu during mini cinematic cut-scene after returning an objective items home
  • Prevent accessing the Pause Menu during ending cinematic cut-scene after returning all objective items home
  • Add option to Pause Menu to allow player to restart the game

PLAYER

  • Spawn player with consistent camera rotation in Home & City environments

ENDING CINEMATIC

  • Optimized particle effect in ending cinematic to accommodate a wider range of devices
  • Fixed a transparency / ghosting issue associated with the ending cinematic particle effects

BACKEND

  • Cleaned up a lot of scripts, eliminating unused variables, condensing code, refactoring scripts into sub-components, and allowing re-initialization of data to handle game restart
  • Imported glyph database to eventually show images representing buttons specific to the player’s connected device for input prompts

2019 Global Game Jam: 3 Weeks Later

We’re now three weeks out from the end of the 2019 Global Game Jam, and we’ve continued making regular updates to¬†Else Return Home. This past week, we focused a lot on composing and integrating a cinematic sequence for the game’s ending. We also added more 3D models to the City to offer more to explore. Here’s some of what we’ve done this past week in more detail:

ENDING CINEMATIC

  • Integrated ending cinematic to play at the end of the game once the player has returned all objective items to the home
  • Includes sequenced camera movement, particle system effects, animations, and audio
  • Designed to offer a greater impact and sense of accomplishment¬†upon beating the game

LEVEL DESIGN

  • Updated City environment with new 3D models with various debris, including bottles, bricks, cinder-blocks, and boarded up windows to give a better sense of desolation and history
  • Added and expanded areas to explore in the City with more opportunities in verticality

PLAYER INPUT

  • Added support for Pause & Quit via¬†dual stick controllers
  • Added support for running via dual stick controllers

AI

  • Added colliders and marked House as Unwalkable to prevent robot pet Dorg from running through the exterior walls of the House while in the City scene

2019 Global Game Jam: 2 Weeks Later

Exactly two weeks after submitting to the 2019 Global Game Jam, we presented the latest version of our game today at the¬†Seattle Indies Show & Tell and Global Game Jam Showcase. Despite the snow that’s kept much of Seattle home this weekend, we still had a decent number of people able to stop by, and we’re very grateful to those that did! On display we had both¬†Else Return Home¬†and our previous game¬†Good Night Rowan, for which we got both positive reception and good feedback on things we can focus on to improve. To that end, here are some of the things we’ve been working on over the past week:

LEVEL DESIGN

  • Update Home environment with new 3D models for fireplace, floor, and furniture
  • Update City environment with new 3D models for trees, fences, street signs, and various additional decorations
  • Add new landmarks in the City scene to assist with player navigation
  • Block off some more areas unintended for the player to reach
  • Replace colliders of some objects for more realistic rain drop collisions

SOUND DESIGN

  • Rebalance audio mixing, especially to make voice overs more audible
  • Sync up Door sound effects to better align with scene loading

PLAYER

  • Gradually reduce player speed when walking into park pond to give more realistic impression of wading into water
  • Prevent the player from walking all the way into the deep end of the water
  • Automatically show photo after bringing back an objective item to reiterate the game objectives and demonstrate progress
  • Fix bug to allow interaction with Dorg while holding an item

AI

  • Refactor AI of robot pet Dorg to operate on a Behavior Tree system to allow greater flexibility in adding and modifying behaviors
  • Make robot pet Dorg occasionally run ahead of player to make Dorg more dynamic and appear on screen more often
  • As the player collects more objective items, make Dorg run ahead further and more often to help the player feel increasingly more comfortable in the City and reinforce the feeling of the player gradually establishing their home
  • Prevent Dorg from running to “nearby” locations on the other side of a fence or unreachable areas that would produce either invalid or overly long paths
  • Make Dorg run around objective items but not avoid them while held by player (otherwise produces buggy behavior)

BACKEND

  • Refactor various chunks of code to enhance developers’ ease of use and facilitate new features and content
  • Add in editor visualizations to assist in debugging

2019 Global Game Jam: 7 Days Later

It’s now been one week since we submitted our game,¬†Else Return Home, as an entry to the 2019 Global Game Jam. We were thrilled to be recognized for Best Use of Color out of nearly 40 teams at our local site in Seattle, and we’ve been very pleased with the attention it’s received so far. Already, the game is outperforming the first week of release of our previous most popular game! (Good Night Rowan)

Like many game jam games however, we knew it contained some bugs, and there were a handful of features we had in mind but did not have time to get to. We decided that in the first week following the jam, we’d focus most of all on bug squashing and improving overall usability. We’ve been making daily updates since the jam, and here are some of the things we tackled:

PLAYER

  • Reduce the chance of camera clipping
  • Sync up player spawning better with asynchronous scene loading
  • In case the player manages to reach an unintended area and falls off the map, spawn the player back at the starting location
  • Keep player from¬† moving or¬†raising photo during intro sequence
  • Drain energy faster per unit distance while running (relative to walking)
  • Halt energy drain / gain while paused
  • Fix bug where player could not re-enter house empty handed after collecting first item
  • Gradually slow player movement to a halt while powering down
  • Drop held item on powering down

LEVEL DESIGN

  • Update some building models in City scene
  • Place some floating items flush with ground
  • Add colliders to buildings missing them
  • Block off areas unintended for the player to reach

UI / UX

  • Add text prompt telling player how to start game from title screen
  • Hide battery UI until after exiting title screen
  • Fix some HUD element positioning to handle different aspect ratios
  • Choreograph intro sequence better to sync up raising & lowering of photo with voice over lines
  • Add text prompt telling player how to show photo again
  • Render photo over rest of scene
  • Enhance power down glitch effect
  • Eliminate lingering frames between scene transitions
  • Add ability to Pause & Quit with an in game menu
  • Add end game text sequence with credits

AI

  • Prevent robot pet Dorg from walking through park fence
  • Have robot pet Dorg move around scene props (e.g. lamp posts, benches, debris piles, etc.)
  • Add interaction with Dorg, prompting voice over lines and barking responses

Now that we’ve squashed the majority of the existing bugs and enhanced the usability of the game, we’re turning next toward adding more content and features. This following week should include some significant updates as we prepare to exhibit the game at the¬†Seattle Indies Show & Tell and Global Game Jam Showcase. If you happen to be in Seattle, we hope to see you there!

Finding Edges from the Vertices of a Convex Quadrilateral

While working on the AI player for a real-time strategy game, I came upon a rather specific problem and discovered a nifty solution. I had been considering using the data in Unity’s pathfinding NavMesh with the aim of extracting the edges from the sets of vertices that composed it. However, when looking in Scene View, I found that the NavMesh appeared to be made up of not only triangles but also other polygons with more sides. This posed a potential problem as well as an interesting geometric question: Given only the vertices of a convex quadrilateral, how do you determine which pairs of vertices form the edges? While I ultimately did not need it for my AI implementation, I thought I’d share the solution in the article below.

Convex Quadrilaterals in Unity's NavMesh
Some parts of Unity’s NavMesh display contain convex quadrilaterals like these.

How to Find the Edges of a Convex Quadrilateral Given the Vertices?

Let’s say you’re given four points as coordinates which define the corners of a quadrilateral. You also happen to know that this quadrilateral is convex (in the context of the NavMesh display, all polygons are convex). So how can you determine which pairs of points form the outer edges of this polygon? After all, some pairs could turn out to be the interior diagonals, so we need some method to choose the correct pairs.

If you were to choose four edges at random, you could get lucky and happen to choose all the outer edges of the quadrilateral. But with six edges to choose from and four chosen, there are 15 possible combinations of which only one is correct.

Edge Combinations
The pictured formula gives us the number of possible combinations of edges when chosen at random.

However, we can significantly reduce the problem space if we imagine that we choose four vertices in order. Furthermore, we’ll consider only the three consecutive edges between them, since the fourth can be easily inferred by connecting the last vertex to the first. When we do this, we find there are essentially three resulting scenarios: one interior diagonal occurs in the sequence, two diagonals occur, or none i.e. an ordering of vertices that correctly outlines the quadrilateral. These scenarios are illustrated here:

Three scenarios
Three general arrangements of three consecutive edges

We’re now one significant step closer to our solution having better defined the problem space. But¬†how can we distinguish between these using only math? It’s easy enough to figure out using only our eyes, but we need a way to distinguish between these scenarios in code.

Consider the fact that we know the quadrilateral is convex. Consequently, we can deduce that following the outline of the quadrilateral will always result in the same turn direction from one edge to the next (i.e. clockwise or counter-clockwise). It turns out the cross product is perfect for calculating the turn direction between three points. Putting this calculation to use, we see that our target scenario of zero diagonals passes this turn direction test whereas the scenario with one diagonal does not — the angles change direction from the first half of the Z- or N-shape to the second half. Great! We’re nearly there.

But wait, using this turn direction test, our scenario with two diagonals would still pass: the angles ABC and BCD take the same turn direction (counter-clockwise in the illustration above). However, there is another feature of this case that is unlike the others: the two diagonals wind up intersecting each other. Coincidentally, we can again use the cross product to detect this intersection.

So we now have the two tests needed to determine which of the three scenarios an order of vertices results in, both of which happen to use the cross product. Depending on the scenario, we can then flip the order of the appropriate pair of vertices to get the correct sequence that outlines the quadrilateral. Our final algorithm thus looks like this:

Check the turn direction of ABC versus BCD
    If unequal flip C & D
    Else, check whether AB intersects CD
        If intersects, flip B & C
        Else, order is correct
After any flips, our edges are now AB, BC, CD, and DA

And that’s it! While perhaps a niche problem, the solution winds up being quite efficient and elegant if I do say so myself. I hope you find this helpful, either directly or indirectly, in your own geometric adventures!