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
Spawn player with consistent camera rotation in Home & City environments
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
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
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:
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
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
Added support for Pause & Quit via dual stick controllers
Added support for running via dual stick controllers
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
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:
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
Rebalance audio mixing, especially to make voice overs more audible
Sync up Door sound effects to better align with scene loading
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
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)
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
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:
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
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
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!
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.
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.
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:
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!