Last weekend I took a break from working on Deluxe (which was more of a break from playing Riven, since day job stuff has me avoiding my office in the evenings/weekends) to hang out at Buffalo Game Space for BGSjam XVIII. My intent was to be around to assist with any projects that needed code or Blender assistance, but once that wasn't really much of a thing needed I made a little game.
The theme of the jam was "Passageways". There was some really great brainstorming at the start, and a lot of excellent ideas got tossed around by folks. I couldn't stay late as I had double-booked myself, but the idea of a hallway kept coming back to me. Eventually this morphed into the great base-raiding sequence Contra, and I thought it'd be fun to take a stab at remaking that in Godot.
While it's unpolished, I did end up succeeding at remaking that general concept into a game by the end of the weekend. Passageway (very original title) is a small arcade shooter in which you progress down hallway segments by destroying a big red orb at the end of the hall, all while killing/evading enemies.
The project began as all good jam games do - with a player controller. Quickly hobbling together some basic input mappings and attaching them to a KinematicBody got me most of the way there, but almost immediately afterward I decided the smart thing to do is recreate the Creature class/scene I'm (roughly) using for Deluxe. A root KinematicBody with a base collider, a Hitbox area, and a custom Health node with some signals for when it's damaged/killed got me the base scene for the player, enemies, and even the Hallway Switch. Inheriting and adding a new script that contains input parsing drives the player character, some very simple movement logic drives the enemies that move.
The biggest issue I ran into, which I'm still not sure why it was happening, was that the inherited scripts did not fire off the parent functions when the child function is called by a signal connected on the base scene. I had to use the .parent_func() approach to get them to fire, which I'm fairly certain I don't have to do in the Deluxe project.
Once the creatures were in I started adding some basic weapons, which in turn shoot bullets that are also creatures. Super easy.
Next came the hallways themselves, and this was the first "new" thing I did. The game uses a base Hallway scene that has a Position3D that indicates where the next hallway should be connected, and a script with a signal alerting a Hallway manager when it's been "completed". This was meant to be fired off in various ways (kill all the enemies in a room, defeat a boss, etc), but for the jam it ended up only being "Switch" objects - Creature scenes that, when destroyed, tell the Hallway that it's done.
When the Hallway determines that it's finished, it alerts the Hallway Manager, which in turn selects the next Hallway at random from a pool of Hallway scenes, instances it, and attaches it to the current Hallway. Then some more events fire off, triggering a door opening animation on the current Hallway, changing the current Hallway to the "completed" Hallway and the "next" Hallway to the current Hallway. I also manage animating the transition between Hallways here, and enable/disable the creature logic so the player can't move during the transition and the enemies can't move/shoot. This was a stylistic choice more than anything, as Contra does basically the same thing.
With these elements in place, I blocked out five-ish Hallways and threw them into the Hallway Manager. The end result is the game you can download now on itch.
I'm pretty happy with how this turned out. It was the first game jam I've actually participated in in a while, and it was a lot of fun. Not only that, but I think that this little project could turn into a much larger one at some point. I'd like to make it co-op multiplayer and functional on the BGS arcade cabinet. Maybe add some aiming similar to Sin & Punishment, and obviously give it some real art and music/sfx. So we'll see.
As mentioned at the start, I've fallen a bit behind on Deluxe progress. This whole month I'm dealing with a big release for my day job and I've got a bunch of non-game-dev fun things on my calendar because hell yes it's Summer and I wanna get outside. BUT, I do suspect that in the next week or so I'll start working on it again and will have another update to share following that next sprint.
Deluxe: Sprint 3
Friday, May 20, 2022
Another two weeks, another sprint report. This time round I learned a whole lot about interacting with the Physics server via GDScript, and got some very cool AI stuff implemented. Also managed a little bit of cleanup, making the creature scenes clearer.
Consolidate Hitboxes and Hurtboxes
My initial creature scene used two colliders for damage - one for causing damage to another collider, and one for taking damage. The more I worked with it the more redundant it seemed, so I decided to consolidate them into a singular collider.
This was so easy to do. Thank you Scene inheritance, Godot. All I had to do was update the Physics layers checked for the Enemy/Player Hitboxes and add an Impact_Damage exported variable to replace the Hurtbox Damage export. Removed the Hurtboxes from baseline creatures and deleted the baseline Hurtbox scenes/script, and everything just worked.
Teleportation in VR is a solved problem in most engines, and Godot is no exception. However, I like trying to implement my own version of things occasionally, when existing implementations are a bit heavy and it's not a terribly complex thing to implement on your own. So I spun up a TeleportationManager that handles calculating when and where a player can teleport around the scene. In doing so I actually learned about a lot of features that I'll be utilizing in the future.
When the user wants to teleport, the manager runs a quick and dirty simulation of throwing an object out from the controller. The manager has parameters for the distance between each step of the throw calculation and a gravity value. On each step, starting at the controller's position and using the -Basis.Z of the controller's transform, I set a start and end point that make up a step in the arc simulation. Using the PhysicsDirectSpaceState, I call intersect_ray() and check for any collisions in this step. If there aren't any, I set the next start point at the current end point, then calculate the new end point by adding normalized vector of the difference between the previous start and end positions, the gravity multiplied by the current iteration step, and the length of the step defined by the manager. If there is a collision, I use the normal to verify it's a flat surface the user can teleport to, and then set the potential teleport position to the intersection position.
Using the PhysicsDirectSpaceState is so much cleaner to me than using a RayCast node. It's similar to the way raycasts work programmatically in Unity, and much more flexible than the RayCast node IMO. There's also options for checking intersection using shapes, which I imagine I'll be able to use for things like spherecasting.
Rendering the arc utilizes the MultiMeshInstance node. I'd never tried it before, and it was shockingly easy to spin up. I set the MultiMesh up with a mesh in the editor, then programmatically set the number of instances and their positions based on the cached points of the arc created during the throw simulation described above. I initially meant to use the cached data to dynamically create an arc mesh, but I kinda like the billboarded sprite look and might keep it.
Graybox first level
Kinda wild that I've already hit a point where I need to start prototyping play spaces. The primary goal of this was to have something that a player could teleport around and enemy AI could fly about, searching for the player ship or another target of interest. CSGs were a huge help here, letting me quickly hobble together some basic geometry that's slightly more interesting than the basic meshes while still being easier and faster to hammer out than creating a small level in Blender.
Navigating Flying NPC prototype
Most of this sprint was focused on figuring out how to get the enemy AI to actually work. The initial implementation worked on a theoretical level, but was way too computationally expensive (and also overkill, as I later worked out). The followup was simpler, extensible, and what currently exists in the project.
At first I thought it'd make sense for the enemies to have a good general awareness of their immediate surrounding geometry. Not just the player, but the level as well. I started digging into raycasting as a way for the AI to "look" in various directions and navigate towards a given target. Using the PhysicsDirectSpaceState (accessible via any Spatial node), I set one raycast to see if there was any objects blocking the way to the AI's target and a subsequent pair of nested loops that would scan the surrounding space with calls to intersect_ray(). If there wasn't anything between the AI and the target, it set it's next destination to the target's position. Otherwise, the looped raycasts would search a limited distance around itself, and the point nearest the target with no collisions would be the AI's next position. Once the AI was near the position it selected, the process would repeat.
This worked in principle, but the high number of raycasts crushed the framerate (I think, more on that later). What probably would've passed as fine on desktop for a prototype was nauseating in VR, clocking in around 45 FPS on average.
So I started thinking about what I actually wanted this AI to do. After some whiteboarding, notebook doodling, and playing a bit of Descent, I came up with a state machine approach. Each enemy creature got an AIBrain node, which contains (among other things) a state the brain is currently in. Each AI tick (currently Physics ticks, because this stuff is fast) an AIService evaluates what the brain knows and makes decisions on whether or not to change state, and what state to change to. The brains have a bunch of knobs for twiddling, like vision distance, field of view (FOV), boredom, pain tolerance, and more, that should allow for some distinct behaviors. Additionally, it's up to the creature itself to determine just how it should move or act based on the state of the brain and what data it contains. Thanks to class inheritance and signals, I can create new creatures that all move, look, and shoot differently with (hopefully) minimal fuss.
I captured some video of the initial prototype of this in action, with a number of ships with the same brain parameters. They all begin in the "IDLE" state, have a FOV of 90 degrees and can see 1 meter, and get bored after a couple seconds. If the player ship comes into their view distance, in their field of view, AND isn't blocked by some other geometry, the enemy enters "CHASING" mode, moving very slowly while turning towards where it saw the player so it's eventually facing dead-on. If it loses sight of the player ship, either by the player moving out of it's FOV, view distance, or just moves behind a big blocking object, the enemy enters "SEARCHING" mode. In this instance, that means moving in the direction it last saw the player ship. While "SEARCHING", it's 'boredom' level is increasing ever second. If the boredom level hits or passes the brain's 'attention span' parameter, the enemy goes back to the "IDLE" state. However, if it sees the player before it gets too bored, it goes back to "CHASING".
There's additional logic for moving into weapons range to enter an "ATTACKING" state, and an "EVADING" state for moving out of the way of player projectiles or other threats, but that's not fully wired up yet and will tie into Sprint 4.
Enemy AI attack and evasion
While the states are there, more testing is needed for attacking. Evasion also needs the logic actually implemented on the enemy, so it can do something more than just recognize it's being attacked.
A holdover from this last sprint, it just got pushed as I felt the AI work was a higher priority.
Another VR standard, the ability to snap turn the player in increments is super handy. I've already found myself missing it while testing AI, so this'll be a relatively high priority this sprint.
Pickups/Player Weapon Changing
Items that the player can collide with to increase health or upgrade their weapon is a big one. This will probably get split into a few different tickets, one being a rough draft of how the weapon upgrade system will work.
As always, things take longer than expected. Still, progress on this has been solid IMO. Thanks for following along so far. Be sure to follow me over at mastodon.gamedev.place and diode.zone for bite-sized content updates and videos as they get posted!
Deluxe: Sprint 2
Friday, May 6, 2022
What is this?
I'm working on a game! Currently titled "Deluxe", it's a continuation of the VR Starfox-like I was working on early last year. The on-rails forward motion has been removed and replaced with a player-navigatable space, drawing inspiration from games like Bulk Slash and Geograph Seal.
I'm also trying to keep myself on track by running sprints (~two week dev cycles where I tackle small- to mid-tier tasks in an ever-growing backlog). At the conclusion of each sprint, which neatly coincides with a BGS dev meetup, I'll be presenting results at said meetup and posting a recap of what got done and a peek at what's next. These recaps are broken down by ticket, so each title is the task lifted right from my sprint tracking doc. The content is (mostly) my notes from completion of the ticket.
The Sprint 1 Recap
You might've noticed this is sprint 2, and there's no post for sprint 1 on the blog. I hadn't quite worked out how this was going to function when I started the project, so that post just got skipped. What you missed was basic project setup, some planning, and creation of the core Creature type, which I'll probably put a post together on in the future. For now all you need to know is Creatures are the main elements of the game, from the player ship and enemies to projectiles, destructable objects, item pickups, and pretty much anything else that isn't a static object like most of the game environment.
Now, on to the Sprint 2 progress!
Map out player controls
I took a peek at the Steam Hardware Survey, specifically to see what the currently popular headsets are. Combining that with the Controller mappings note in the issues section of the Godot OpenXR plugin, I came up with a shortlist of the controllers I'd like to target, and from came up with a list of actions I think I'll need for the game and menus. Drafting them up in a doc helps me keep tabs on all the things, and it made bringing it all into Godot's Input Map much easier.
This was (so far) shockingly simple. Audio's probably my weakest skillset when it comes to game dev, so I'll likely eat those words later. Anyway, creating an AudioBusLayout is incredibly easy, and appears to have a lot of flexibility. The AudioBusLayout contains AudioBuses, which you can imagine as a bunch of different channels in a mixer. Each AudioBus can get it's own levels and effects, and you can chain AudioBuses into one another to allow for grouping of mixes. In this first pass, the "parent" channels handle Music, UI, and game sound effects (SFX). Ambient sounds for the player and enemies are mixed into a general Ambient mixer, and player/enemy projectiles have their own mixers. Ambient and projectile mixers all pipe into the SFX mixer.
Audio sources on creatures, weapons
Another fairly easy one. Since I'm instancing scenes for creatures and weapons, I just needed to add an AudioStreamPlayer3D to the baseline scene others inherit from, and they all get one. Setting the appropriate AudioBus on the baseline scene means the inheriting scenes get the right channels on the mixer assigned automatically.
Placeholder sound effects
Fun fact: there is a veritable treasure trove of old-skool sample CDs floating around on the Internet Archive. Naturally none of this stuff can be used unless I purchase a license for it, but for testing stuff out and getting some killer classic sound effects/ambient audio? chef's kiss
Creatures, as they currently exist in the game, can use an optional Move_Target Spatial that they'll follow around/move towards at their given speed. I put this in originally because I needed a way for the player ship to fly towards the player's hand. Once I started working on the homing missiles (which double as a simple entry point to some dumb enemy "AI"), I decided to take advantage of the Move_Target as a way to both steer the missile creature and give it something to look at.
Missiles inherit the base creature script and export a Target spatial node path. If assigned, during _physics_process the missile's Move_Target is pushed towards the Target with a given force and moving roughly at the same speed as the missile itself. One problem with this is the missle can catch up with the Move_Target, but it's not such a big problem that the missile stops working. The end result is some simple missile creatures that can, eventually, hit something no matter where they started pointing when they entered the scene. The exported value for Homing_Force allows for easy tweaking.
Baseline destroyed creature scene
Particles baybeeeeeeee! Godot's particle system is really fun to play with, and just throwing a little explosion together with it is a breeze. Add some dynamic scaling to particles and a nice billboarded sprite material, and you've got some fun ka-booms!
Game Manager/Baseline Level scene
This is the one thing that kinda sorta didn't get "completed", because it's still too early to really know what this is. The Game Manager in particular isn't fleshed out fully because I'm undecided on whether I want to use one single Autoload for managing all game state and major functions, or if I want to break it down into several smaller Autoloads that are more focused on a given task. I'm leaning towards the latter.
Also, tracking game state ties into the Baseline Level scene. I've got a basic scene for managing a gameplay level, that can register itself to the current Game Manager implementation and provides helper functions for adding new children to the scene under the appropriate parent nodes (things like projectiles, spawned enemies, and items). In building this out, I realize that I can actually use the level scene itself as the "state" of the game, rather than some external class or enum. It can hold logic for what scene/state to transition to next, keeping things simpler and clearer for me as I add more levels and other scene types.
Consolidate Hitboxes and Hurtboxes
Right now creature damage utilizes two separate colliders, a hitbox and a hurtbox. The hurtbox defines damage done to another creature, and scans for hitbox colliders to do said damage. Even when I was first creating it it was getting confusing, so I'm going to try combining them into a singular hitbox for sanity's sake.
Player movement is an absolute must, so this has to get in. I'll need this for things like the Graybox First Level as well, so I can start playing with level scale and navigation comfort.
Given the nature of ship control in this, I'd like to be able to let the player swap hands on the fly so their arms don't get too tired too quickly.
Graybox First Level
Blocking out a simple stage that the player can teleport around and shoot at things in is basically a step away from a vertical slice. Absolute must to see if the gameplay is actually going to be as potentially fun as I think it'll be.
Navigating NPC Prototype
The homing missiles were the first test of creating AI for a Creature object. This is the next big step, giving it awareness of the environment. This comes after the graybox, so there's actually an environment for it to navigate.
If you made it this far, thanks! I'm really excited about this project, and clearly excited to write about it. Sprint 3 should wrap on 5/19, so expect a new big post then. Also, you can find me over at mastodon.gamedev.place and diode.zone posting more immediate updates and video content occasionally, so give me a follow for little bits along the way.
Kick The Tires
Monday, April 25, 2022
Just shaking the dust off here, making sure stuff's still working as expected.
OGAM - September
Tuesday, October 5, 2021
Well, September sure came and went in a hurry, didn't it? OGAM just went ahead and disappeared with it, too. The last post from mid-month here is as far as I got with the challenge this time around, attempting to create a dialog system for chatting with NPCs. It was a good opportunity for me to poke at the UI systems in Godot as well, but I just didn't get much further than that. With my day job keeping me extra busy and taking on some additional outside projects eating up my evenings and weekends, OGAM just didn't have the time/priority this past month.
So what's October looking like? If anything, small. Teeny tiny game. Minimalist. If I have an idea I'll make one (the theme is "Cycles"), but right now it's looking iffy. Though as I write this (while surfing Twitter and griping about the new Unity rebranding on a Discord server), it could be fun to do something pre-rendered using Blender's Cycles. Very 90's CD-ROM esque, perhaps.
Monday, September 6, 2021
My only dissapointment is I didn't use a The The cover for one of the profiles.
OGAM - August
Tuesday, August 31, 2021
This past month I started doing One Game A Month. I've spent the better part of the last few months buying a new house and moving, so I'd fallen off the making stuff train for a while; doing OGAM seemed like a neat way to try to get back into the swing of making content, especially now that I've got my own office. I set a couple goals for myself for the first month:
Start developing games (or game-like content) again
Get a feel for what it's like to create content in the new office, and figure out what's good, what's not, and how I can improve my new workspace
For the first month, with the theme One-Liner, I decided to try my hand at making something I've never tried developing before: an RPG combat system. I should probably note that this was something I'd already been thinking about trying to make before OGAM, so naturally I attempted to shoehorn the theme in. Rather than casting spells, the player characters would rack up Cool PointsTM as they land attacks. Once their CP meter was full, they could execute a one-liner. Rather than casting "Ice" or something, they'd say something fitting of the character, and a major attack that thematically matched the one-liner would take place. For example, a character could say "Everybody, chill!", and the result would be a large party-wide ice attack.
As is typically the case, I didn't fully grasp just how much work and planning would be required to build out a flexible RPG combat system, and I didn't quite finish. If I had to guess, I'd say it's abouy 60% there, with logic for queueing battle actions, triggering animations, and processing some of the action types. A lot of the remaining work involves connecting all the pieces together, which is also when I tend to find that I don't like the way certain systems work so I get distracted and try to rewrite it. I'd say I rewrote the whole thing probably two and a half times over the course of August.
So did I meet my goals for the month? Kinda, honestly. Even though I didn't finish the system, I am happy with the work I did on it, and I do plan on completing it at some point so I can use it with other projects. (sidenote: I don't know how it happened, but I've only just started really enjoying playing JRPGs. Something about gaining patience in my old age, I guess.) And as for what it's like making content in my new office, it's definitely nice but there's room for improvement. A proper desk would probably go a long way, for starters. Some better storage/organization for art supplies would be good too. But a good start, for sure.
If you're interested in taking a look at the project, I've posted the source over on my Github.
Devlog - Intro and Entities
Wednesday, March 31, 2021
According to the git log, I have a project I've been working on off and on since April 24th, 2020 that I haven't talked about on my blog yet. I've been working on it more and more over the last month or two, so I'd like to start writing devlogs as I go along, making this the first one I write on it.
The project is a rail shooter of sorts, heavily inspired by Starfox and Panzer Dragoon. If you're unfamiliar, the general idea is the player is control of a ship or vehicle of some kind that is always moving forward at a steady speed, firing at enemies along the way and dodging various obstacles. The key differentiator is that I'm building it as a VR game, where rather you use your hands to fly the ship and aim your weapons. It all started with a little prototype I built over the course of a week or so, just prototyping some really simple stuff like moving a little ship towards your one hand and moving a blocky environment past you, giving it a sense of flight. I thought it was cool enough to continue work on it so I kept at it for a while. Then, like with most side projects, it'd get dropped for a few weeks, I'd come back and rewrite some things, then drop it again. All very protoype-y, neat but nothing to really share.
That repeated a few times, and then finally about two months ago I started getting much more into it. I've begun creating tickets for tasks to help keep myself from feeling overwhelmed or lost. I put a good bit of time into really working out the architecture of the project, so I can more rapidly prototype concepts and put more time into content. Part of that tasking and content is writing posts about progress, so here we are.
I'd also like to take a moment here to thank the Godot team for doing some fantastic work on this engine. It's been a lot of fun learning and tinkering with it - it's nice when the tools you use to make something are nice to work with themselves. Also huge thanks to Bastiaan Olij (and all the project contributors) for the OpenVR plugin that's making my VR work with Godot possible.
Part of all the work and rework I've been doing is trying to find a way to speed up prototyping so I can make things do things faster. The less roadblocks I have to trying out a new idea, the more encouraged I'll be to try out new ideas. A big part of this is the Entity scene I've established for any element in the game I want to interact with others. I've attempted other structures like this previously, but I don't think it was until the last couple of weeks it really clicked.
In Godot, you have what are referred to as Scenes. The best way to think of a Scene is as an object in an OOP framework. You have a base class (in Godot this is a Node) that you can then extend via inheritance to create a more specific object. For a long time, my thoughts on this were to take one of the provided Node types and extend it entirely with scripting, and then inherit that new scripted Node to create other objects. While it works, I lost one major benefit of Scenes - the ability to instance and inherit from them in the editor.
Every Scene in Godot (down to the editor itself) lives inside a SceneTree. Nodes are children of parent Nodes going all the way up (down?) to the root of the tree. While each Node is a class itself in a way, you can also treat a single Node and it's children as one whole object. This parent Node and set of children can be spun off into their own scene and then instanced in other scenes over and over again, in the same way you'd write a class and create instances of it in other languages/frameworks. Now, not only can you easily instance these Scenes in Godot, you can extend them on a per-instance basis by adding new child Nodes to them. It's the same as inheriting a class and providing new functionality, except here you can do it quickly and visually with other Nodes in the engine.
If you're familiar with OOP principles this all probably sounds pretty obvious, but for whatever reason this specific approach didn't click with me until very recently. This lead to the creation of an Entity Scene, a base Scene that I can inherit from to create all sorts of interactive entities in the game that all behave nicely with one another. It's a Spatial Node, Godot's base 3D Node, with a CollisionArea Node and custom Health Node as children.
The CollisionArea is an extension of the Area Node used to define the collision layer the entity exists on and what layers it's checking for collisions on. It also includes some data that is provided to other objects when they collide with it, like how much damage a colliding object should take (if any) on impact. This is useful for ships colliding with each other or running into buildings.
The Health is a GDScript extending the base Node, and it manages the health of the object. You provide a maximum health value, a length of time the entity should be invincible for following taking damage, and a checkbox for flagging an entity as invincible. There's a take_damage() method that is used to apply damage to the entity, and two signals (Godot's built-in implementation of the observer pattern) for announcing when it's taken damage and when it's been destroyed.
The basic player projectile a good simple example of the Entity inheritance/usage. The parent node handles logic for moving the projectile, spawning a small AudioStreamPlayer3D scene that plays a brief sound effect when spawned, and the lifespan of the projectile. The Entity Scene is a child, along with a .glb placeholder model representing the projectile. The Entity is configured so it can impact anything on the Enemy, EnemyProjectile, and Obstacle layers. On impact, it takes whatever impact damage the Entity it's hitting does and applies it's own impact damage to the other Entity. For the most part, this means anything it hits "kills" the projectile while simultaneously doing 1 damage to the Entity it hit. Enemies explode, invincible obstacles don't do anything.
Here's the player's ship Scene tree. The root Spatial Node has a script managing movement of the ship and connecting the WeaponTargeting to the player's targeting hand. The Entity Scene is stock, with the Health signals connected to the HealthUI Scene, driving the progress bar representing the player's current health. ShipPlayer scene is just the .glb 3D model representing the ship. WeaponTargeting handles the aiming of the player Weapon, which is also a child of WeaponTargeting. Similarly to the PlayerBasic projectile, it can take and apply impact damage when colliding with anything on the Enemy, EnemyProjectile, and Obstacle layers. The nice thing about this is you can crash the player ship into an enemy with 1 HP, killing the enemy on impact while suffering 1 damage.
This post was supposed to cover other stuff like the audio effects I've been tinkering with, or how the levels are managed, but that Entity stuff got so long I don't think I could fit any of it in here. If you liked this writeup shoot me a line via email or Twitter and let me know. I wouldn't mind writing similar posts about other components as I create them, but I also can keep future posts a little bit more high-level and brief.
Thursday, September 3, 2020
Reasons to Vote
It gives you a say in who's gonna decide policy that affects you and your family.
This year you can even do it from home (Vote by Mail, highly recommend)
I even went out of my way to stick this handy registration form in this post (courtesy of Vote.org)
At this point in the year this is all about the Presidential election. While it's definitely a big deal, registering also means you can vote in local elections which are argueably even more important. Come next year you'll be able to help decide who gets to make decisions that directly affect the community you live in. It probably doesn't get nearly enough coverage, but with a couple of web searches and some digging around on social media platforms you can learn a lot more about your local candidates than you might think. So yeah, go register and go vote!
(I meant to post this earlier in the year, but I've been neglecting my blog as per usual. More (VR) project stuff soon.)
Tuesday, August 11, 2020
Little arranged scene spotted on the side of the road while bumming around town.