Silkroads: Fundamental Map Design, and the Core Verb
Following the completion of my serialized Dictionary, explained in my previous post, it was a quick job to finally assemble all the pieces I’ve been building into something playable (in a basic sense of the word). With a decent node system supporting pathfinding, quick data editing thanks to a custom inspector, and the use of Dictionaries for convenient accessibility of data, accomplishing my key gameplay milestone was a simple case of extending my Caravan class, and creating a simple menu UI piece for trading with nodes.
In previous projects, my first step has always been proving the core gameplay. Before I sink hours into programming a game, I like to make sure it’s actually enjoyable at a fundamental level. With some brainstorming and paper-prototyping, I can investigate the qualities of the system I’m thinking of turning into a project; normally validated when I feel that a prototype has a clear core game loop – the cycle of actions that will form the base of all secondary, or peripheral, gameplay. The prototype doesn’t need to be fun, but I need to be able to sense its capacity for depth, challenge, and extension. I actually did this with Silk Roads, drawing a map of the Middle East, assembling a network of trade nodes, setting local resource supplies, and briefly trying to make a profit by moving a caravan around.
In some cases, games are so simple, or so slow, that they can be accurately simulated on paper. However, often, and in the case of this strategy game, I’m not able to create a full paper representation without significantly altering the gameplay. For this reason, the challenging aspect of the game idea – the core gameplay – isn’t implemented until at least a few days of programming. Now, many strategy games have a dominant loop of gameplay: in Europa Universalis 4 (EU4), this is starting a war that you know you can win, winning the war, and annexing land to grow in strength. However, it’s very common for strategy games to have several important loops; this way, the player has a choice in their approach to the game, allowing them to strategize. Again, in EU4, countries can be expanded by dynastic inheritance, by offering vassalship, by colonization, and even regular warfare is informed by subsystems such as alliance-building, technology, and economy. As such, I feel that strategy games cannot have a single, simple core gameplay, unlike arcade games and puzzle games. The result of this required complexity is that I’m unable to prove the core gameplay at this stage.
I can, however, prove the core verb.
Verbs are interactions available to the player: jump, shoot, build, conquer. In the case of Silk Roads, this is buying and selling resources. I can also approach the core gameplay itself, by implementing the simple dynamic (a dynamic is an element of the game’s behaviour) of buying resources where they’re cheap, travelling, and selling them where they’re expensive. Programming this kind of functionality has been my short-term milestone for the game’s preproduction. But, again, since this isn’t a challenging task, and doesn’t invoke meaningful decisions from the player, I don’t consider it to be proper gameplay, or a playable game.
Nonetheless, implementing the verb constitutes an important step, and I can use this kind of interaction as the basis of how I want my game to play. Allowing caravans to trade with markets involved writing some simple functions and basic math, where the value of a good is its base value-per-kilo multiplied by the inverse of its local abundance. Silver, with a value-per-kilo of 5, sells for full price where its supply is 0 (full demand), and half price where its demand is 0.5.
Writing a menu system has mostly been a case of creating reusable UI elements that can be easily constructed in code. These functions will serve to build other menus in the future. They currently include a menu, a text field, and a button.
Though the game’s core mechanics still need to be developed properly, I’ve already placed some thought into how I build the map itself. With the idea of exploiting local demands as the core verb, it becomes clear that local demands themselves need to be carefully defined. If, for example, two neighboring cities have completely different supplies; one with high demand for silk, the other with high demand for glass, it’d be easy – and therefore boring – for the player to ping-pong between the cities making enormous profits. A rule of thumb is as follows: the further the player sends their caravan, and the more risk they encounter, the higher the reward they should receive. As such, local supply rates should only change dramatically over long distances. If the player wants to buy a good that’s rare in their home city, they should have to travel far for it. This is basically a high-risk high-reward system. It also follows the geographical reality that, say, silk would become more common as you head closer to China, while spices would gradually grow in abundance as you approach Indonesia.
My implementation of the supply rates – visible as color-coded bar-charts above each node, follows this thinking. I’ve used my historic knowledge to define epicenters of abundance, i.e. places where a good is being produced. Then I’ve gradually had the abundance fall with distance from the city. My classic example is silk (the leftmost crimson bar) coming from China, and glass (the light blue second-left bar) from the Mediterranean.
I’ve also used geography to inform supply spread. The blue lapis lazuli, rich in Afghanistan, also spreads across the silk roads, while being slightly blocked by the mountains to the South, approaching India.
Cinammon and Nutmeg (the rightmost brown bars) spread from India and the Southeast spice islands. Transported by ships, these goods are more common in port-nodes such as Harmozia.
Ebony, a type of African wood, spreads from south Egypt and across Arabia. Silver flows from the Mediterranean. Gold, which I know was very common in West Africa, has been provisionally spread through wealthy trade centers.
When the game reaches a state that produces challenge and strategy, these distributions will have to be fine-tuned by playtesting. It’s important that I avoid the aforementioned situation – vast resource differences being too close together, resulting in a dominant strategy (trade only those resources and win the game). Meanwhile, if a player sends a caravan over a long distance, they should normally be rewarded with a large profit.
Map design also offers other opportunities for meaningful decision – classically, choice of route. There were several major trade routes, historically, some naval, some well-protected and taxed, some dangerous. While most traders might circumnavigate the Himalayas by heading north, taking the Gansu corridor and being received by Chinese officials, the more daring might pass through India and cross the Himalayas, reaching untapped markets more quickly and with less taxation. In short, routes themselves need to be balanced – there should be a reason for taking most routes, be that due to the player’s strategy, or the situation.
Finally, here’s a video of the core verb in action:
With the foundation for Silk Roads in place, I’m ready to focus on researching the design of strategy games.