🦉 Parliament 🦉
You play an owl. Consume prey and fend of predators in a third-person rogue-like based on the real-life ecosystem of an owl.
Parliament is in active production!
Follow our Dev Diary on:
Play Parliament: First Flight on Steam!
WORK IN PROGRESS
WORK IN PROGRESS
The Owl Idea
It originally started as a joke made from someone on the team accidently typing “hooting” in our design doc. I laughed at it initially, then had the “wait a minute” moment. I proposed that we build our rogue-like game around a novel idea: the real life ecosystem of an owl. During my research, I discovered so many parallels to the owl’s ecology that lined up with our design goals. It made sense and enabled us to present a unique perspective of the genre.
Prey would serve as our stat boosts and resource for stamina and health. Predators would serve to grant abilities and present the real danger of an owl to the player. Of course, we took some liberties (a bear boss that summons lightning), but kept it grounded enough that everything felt believable. Using real world research on owls kept the project grounded in reality and enabled our creativity to present a compelling product.
Systems Design
Ability System
Parliament’s ability system is based on held status from the player picking up an object. All code is run through the component attached to the player and logic is handled within functions or custom events within the component. The simple workflow is as follows:
———
Start: Player interacts with the ability egg
|-> The object assigns the type and row name for the Abilities Hud and Abilities Data Table to read
|-> The ability name is added to a modular map held within the ability component
|-> The player can then activate their ability using the appropriate button. Also, a passive ability is active so long as the ability is held.
———
All ability information is held within a data table and imported/exported through a spreadsheet. Passive abilities are intentionally designed to compliment or contrast an active ability to allow for build diversity.
Charm System
The charm system is also based on the player picking up the object, but does not contain an active/passive relationship. Instead, charms provide a positive/negative relationship so long as the object is held. Workflow is as follows:
———
Start: Player interacts with the charm object
|-> The object assigns the type and row name for the Player Stats HUD and Charm Data Table to read
|-> The charm name is added to a modular map held within the charm component
|-> The player will then notice the positive/negative relationship related to that charm and will stay active so long as it is held.
———
All charm information is held within a data table and imported/exported through a spreadsheet. Charms are designed to create a choice for the player like “move faster, but increase stamina drain”. This creates fun dynamics for the player to experiment with from run to run.
Enemy Spawn System
Spawning in Parliament is handled through a Spawn Handler object. The spawner is node based that can be modified per level to adjust for terrain. Originally, this was done through line traces for object hits, but that solution created a lot of variables that weren’t that fun for gameplay and caused some headaches. Using nodes allows for the spawner to specify locations to spawn enemies where they will not conflict with other objects, while still providing a random element in what is spawned. Workflow is as follows:
———
Start: Once a level is loaded, SpawnHandler logic is started
|-> The spawner chooses a node per enemy type (prey and predator) and spawns either a burrow or cave respectively. This “occupies” the space to prevent overlapping
|-> After the spawn points are chosen, enemies begin spawning from their appropriate point. This is done at random, but based on a rarity system set by the data table.
|-> Enemies will continue to spawn until they reach their max amount. They will respawn once the player kills an enemy. Max amounts can be set per level
———
Enemy information is held in a data table. Once spawned, the EnemyStatsAndScaling component will assign the appropriate stats based on the enemy spawned. This is all done modularly through the component.
Gachapon Machine
The Gachapon Machine allows for players to swap their currently equipped items for a randomized new one. This system allows the player to change up their builds if they end up with something they don’t like. This is also the only way to replace a charm. Workflow is as follows:
———
Start: Gachapon Machines are statically placed in levels. Upon interacting with the machine…
|-> The player can choose to give up either an ability or a charm. This is taken at random from the player.
|-> The machine will then choose a random charm/ability (matching what was picked) and spawn it in front of the machine.
|-> The player can interact with the machine so long as they have an ability or charm up to a certain number of times.
———
Limiting the interaction amount keeps the player from abusing the system and infinitely getting new items to get a perfect combo. Additionally, this plays into the fun aesthetic of the game and leans into the genre defining “build” culture.
Gameplay Trailer
Devlog #1
Devlog #2
Devlog #3
Devlog #4