Parley Game Design Document

PirAte RogueLikE Yo! is a classic-style roguelike game about pirates.

World

The world should have an abstract graph-like structure, where visitable places (islands) are nodes that store their level data, as well as what nodes the player can travel to from the given node - called neighbors.

Map generation

These islands need to have a physical location in the world space, so as to allow for a visual map to be created, as well as generating travel times between islands. Islands too far away, ones with the path blocked by something, or those where the path is too close to another island, should not become neighbors. The focus here is aesthetics first and foremost, but gameplay should not suffer. A balance should be found of a decent amount of neighbors without visual clutter, but that still permits ease of travel on the seas. In generating this graph, it is important to create a crawler or other mechanic to verify that all nodes are reachable from all other nodes, and rectify any mistakes that might have occured in world generation.

Travel

Travel is made up of two phases, the destination select phase, and the transportation phase. The destination select occurs in the world map, where the captain - or anyone else holding the helm - can see all neighbors, as well as the pathways between the current island and the neighbors, giving some impression of the travel time. It is worth considering adding extra information about weather and the like to this screen. Navigating with the arrow keys, the captain can select a destination island, and chose to embark. Playtesting should be able to tell us whether information about the neighbor node should be conveyed before embarking or not. This will yell out a command to all crew, and ready the ship for departure (skip this part in first version). Once departed, the transportation phase begins. During this phase, any number of random events can occur - most notably naval warfare. Looking at the world map during this phase will show the ship somewhere along the pathway heading towards the destination island, representing the progress. The destination as well as the start island should be highlighted. The normal view should show the character on the boat, and permit walking around like usual. This is where much of the game takes place.

Island determination

Island determination is a simple classifier determining what kind of island a specific node should be. This should take into consideration: the island’s neighbors’ types, their proximity, a randomness factor, the biome the island lies in, the territory the island lies in, and likely more to come. This step does not generate the island level, but rather just serves to tell the procedural generator what to generate.

Island types:

  • Different island sizes
  • Different island biomes
  • Ports
  • Existence of towns
  • Different settlement sizes
  • Existence of dungeons
  • Different dungeon sizes
  • Different dungeon types
  • Different dungeon difficulties

Bases belonging to different factions, also of different types and sized

Two or more nodes very close to each other merge into one, unless there are multiple ports, in which case all port nodes are preserved, but only one level is generated, with one island.

Again, the goal of this system is to take an abstract world graph and contextualize it, turning it into something generatable.

Basic character movement

Movement occurs in the standard view, and is done with the arrow keys. This is to discourage mouse usage while playing the game for a more authentic old-school feel. Holding down keys only works out of combat, and the same goes for diagonal movement. Combat changes the system slightly, to accommodate the turn-based nature of the combat system. Most notably, each character has a set amount of movement they can spend each turn by moving. Running out means the character can’t move any further that turn. Diagonal movement is disabled, and each step requires its own button press. This is done to signify the importance of every choice during combat - you don’t want to move too far, and going diagonally comes with an advantage.

AI

This card is mostly about AI as a framework, and AI will be a constant field to improve, but some rudimentary AI needs to be implemented at this stage before the next cards can be completed.

A basic AI system models goals and verbs. Goals are such things that the AI wants to achieve, and this is the hardest part of the AI. This can be done extremely advanced, or stupidly simple. We will eventually aim toward advanced AI, but KISS - keep it simple, stupid - for now. A simple AI really only needs a few goals - kill its enemies, survive, and go by their daily tasks. A crew member, for example, needs to do whatever they are on the ship to do, such as tend to the sails, man the cannons, scout from the crow’s nest, etc. They also need to participate in combat, with the basic drive to kill its enemies. Varying degrees of smartness can be put into its enemy determination (what enemy to attack), but the simplest is simply the closest enemy. The third goal, to survive, involves the pirate running away from danger they deem they can’t handle, as well as running from foes when injured. This, then, involves either simulating combat or comparing stats, or both, along with some external factors like personality and frightfulness of the enemy.

Is some sense, it’s important that the AI can work as a team. This is mostly an infrastructure problem, and you can read more about it in the TDD, but I’ve still gotbit to say about it. The system works such that the captain figures out what needs to be done in orderachieve his broader goals - such as sink an enemy ship, that goal is broken down into slightly less abstract mediary goals (tasks) that one pirate can fulfill, and those tasks are then distributed among the crew. These tasks can vary in their scope and abstractness: fire a cannon at that ship vs fire that cannon at that part of that ship until this happens - hoist the flag vs rig the sails (this would most likely further be broken down into tasks for individual pirates). Again, consult the TDD here to figure out how to implement this.

Verbs

Verbs in video games are simply stuff that *(usually the player) can do. In this context, it’s everything that an AI character can do. This isn’t hard to implement with a proper infrastructure, as an AI should be able to interact with the game world using exactly the same system as a player can. All that needs to be done here is to actually hook the AI system up to that, to let AI characters do stuff.

It’s finally here, naval warfare, the bread and butter of Parley. This is the one thing that is unique about the game, and where utmost focus should be placed. I almost want one person working full time on this area to make it the best it can possibly be, but alas. I digress.

Naval warfare takes place in a temporary “arena” level, the constituents of which are the ship, the enemy, and (some of) the sea. These arena levels are always in combat mode. During Naval Warfare, the captain can shout commands to control the AI crew, and to tell the players what they think they should do. This is done via a command menu, where modular commands can be build. This will be designed once the AI system is in place, but it’s likely to have options for different verbs, targets, subjects, and modifiers.

Combat System

Every action has an innate duration. Every action during a turn is tallied together and added to the character’s cooldown in the turn queue. In that way, how often you can act is based on what you do in a turn. Sometimes, you can begin an action and not have it finish until it’s your turn again, such as reloading a cannon.

The turn queue is represented at the top of the screen, in two rows:

  • Ascii representation of every character in the queue, in order, appearing the same way they do in the world.
  • Name of the current actor or, at the end of a turn, the character that just finished it’s turn slips down into this row, every character with a cooldown lower than it then moves one step to the left, and the character at the bottom moves into the first empty space (going sideways at the same time as the other characters, and up when they are done). Once this whole process is done, the name of the next character is shown and their turn begins. It’s worth considering putting this bar at the bottom of the screen too.

During a turn you can take any actions you normally could, as well as move around a set distance determined by your character’s speed stat. Characters can attack with both melee (pronounced mey-ley or mel-ey) and ranged weapons, most predominantly scimitars and blunderbusses, though improvised weapons are alsooption.

Hitpoints represent one’s ability to carry on, to avoid death. Dropping down to zero means death, but being on 1HP simply means inability to survive or avoid attacks. This is just a way of thinking about health that explains why having half health doesn’t impediment you in any way. In the future, it is in our interest to implementsystem much more similar to Dwarf Fortress, where every attack has a target body part, and each body part has the ability to be damaged in different ways, requiring specialized care, as well as to be dismembered, disabling use of it. In DF, this also drops the body-part on the ground, which can lead to fun.

Cannons

Like previously mentioned, reloading a cannon ends your turn, and puts the reloader on a delay until the reloading is done. The cannon is loaded the next time that person’s turn rolls around, and they can then chose to fire it. They cannot be aimed sideways in any other way than to move the ship around, but a red conical trajectory is shown symbolizing where the cannon could go as well as showing its reach. The reach can be modified with the amount of gunpowder used, as well as the vertical angling of the cannon. When the cannon is not horizontal, the trajectory is instead turned into a circle indicating where the cannonball is likely to hit.

Neither trajectory shows where the cannonball will land very accurately, but instead shows the area that the cannonball could land with high probability. It is still possible, however, that it lands outside of that area. The larger the area, the less likely the cannon is to hit any given spot in it, with the likelyhood rising towards the middle. If a shot is very likely to hit a spot, the area is small. If the shot will be unpredictable, the area will be large. About 80% of all cannonballs should land within the marked area (calculus - fun, eh?).

Ship health is much more important of a focus than character health. Each ship should consist of multiple different parts, each of which has its own health. When shooting a cannon at a ship, damage is dealt to the parts of the ship hit, calculated from the trajectory and force - how far in does the cannon penetrate? A broken part of a ship can no longer provide its function - a ship without a mast won’t ride the winds, a ship with holes in its hull will struggle staying afloat.

Chain-shots can be used to take down the rigging (mast and the like) of the enemy ship, but they are inaccurate, and as such are best used at close range. Canister-shots can be used to efficiently take down enemy crewmembers without dealing too heavy damage to the enemy ship, optimal for takeovers. Hot-shots can be used to set wooden ships on fire, a cost-efficient way of quickly sinking an enemy ship

More here: https://en.wikipedia.org/wiki/List_of_cannon_projectiles

Boarding

If the captain aims to conquer a ship, sinking it is a poor tactic. Instead, boarding the enemy ship is a better option. There are a few different options for boarding a ship out at sea, and different ships offer different opportunities in this area. The most basic one is to get real close and jump - though this can fail, and getting and staying that close can be very hard. The advantage is that nothing else is needed, which means the whole crew can jump at once and avoid being singled out. Another alternative is to use the plank, though this can easily be stopped by the enemy crew, and also requires the ships to stay right next to each other for long enough to cross - which takes a while single-file. A more optimal way of boarding is to swing over, which boasts longer range and less chance of failure than jumping. This requires masts to swing from, however, and small ships may find the throughput to be insufficient. Additionally, the landing can stun an inexperienced pirate.

A truly insane crew may decide to dive into the water, then climb onto the enemy boat. This cannot be done while the ships are still moving, and as such usually requires taking down the enemy mast.

Ship movement

ᅳ During a naval battle, the captain may move the ship if they see fit. Different motivations for this could be to aim the cannons at weak points, or to get close enough for a boarding. This is easiest done when moving forward, as the ship can simply slow down or speed up to change their y position, and turn slightly to change their x. When at a stand-still, it is very hard to move, and great care should be taken before bringing a battle to a stand-still.

Turning is done at the helm, and only requires one person to do. Changing speed requires multiple people to tend to the sails, and can take quite a while. This can be done by issuing a command as the captain, or by interacting with the sails directly to perform the task.

Proc World Gen

Once the ProgGen system is in place, we can start work on the World Generation. This comes in many parts, and the procedure is far outside of my expertise. Towns need to look realistic, dungeons need to be fun, these need to be placed logically on a realistic island. Islands need to come with different types of shoreline, docks and ports need to be generated and functional. Forests need to be placed logically, but also not be too dense as to be hard to navigate. Different biomes need to be generated, and assigned to the different islands. This requires a meeting once our ProcGen specialist has become a bit more of a specialist. ᅳ

The Pirate

The pirate loves rum. In fact, the lack of rum alone is a casus seditioni (cause for mutiny, I made that up. See: casus belli). This infatuation causes them to be aggressive, irritable, and to speak with theirr customary slurrr. Quick to jump the gun, pirates from rivalling ships or factions rarely get along for long.

In-fighting is rare, however. The pirate values their ship over their own life, and injuring other crew members is detrimental to the ships survival. Pirates often feel a kinship with their fellow crew, and injuring other crew can potentially result in the plank or desertion under some captains, which further decreases in-fighting. Fight happen regularly, but fists seldom enter the picture.

To stave off boredom out at sea, pirates often take to shanties - and rum, of course. These are likely to be public domain, but if we are interested in having them actually sung, we’ll have to record it on our own most likely.

No self-respecting pirate would pick up a rapier or a shortsword, but a cudgel is good if the job calls for some... eh... force. Ranged weapons with too much aiming required are too hard to man when drunk, and what pirate isn’t drunk? Shotguns are nice, but the barrels are a bit too long - best to leave them out of a ship-fight.