Devlog #006

Hello capitalists!

It’s devlog time! I've got a fresh batch of updates and improvements to reveal, so let’s jump into the details!

A significant portion of development time has been dedicated to implementing a new core gameplay system: Bonds.

This mechanic allows players to issue bonds, hold them, or sell them in the market as a way to raise capital for their companies. The system includes a simulation of market participants who evaluate your company’s creditworthiness. Their decisions are based on the interest rate you offer and their assessment of the default risk associated with your business.

The bond market functions similarly to the items market, with prices fluctuating according to how simulated participants perceive the risk of lending to your company. The goal is to provide a detailed and realistic economic model that adds depth to financial decision-making.

Here’s the interface for creating bonds:

On the left-hand side of the interface, you can either create a new bond or select an existing one if you want to issue additional bonds.

On the right-hand side, you’ll find a breakdown of your company stats, including how the market evaluates your bond, along with the resulting debt and the estimated price at which the bond will likely sell. The price is calculated based on the current default risk rating, but this is only an approximation. After issuing bonds, the price may shift as your company’s debt load and interest obligations increase, affecting cash flow and overall risk.

At this stage, the functionality for player-created bonds is fully implemented, but the balancing is still a work in progress. It’s already clear that tuning this system will be a challenge 😅. My goal is to make it predictable, fair, and grounded in realism while maintaining gameplay depth.
Also I'd like to extend this down the road to have the cities and other companies also create bonds which the player can buy and sell.

For players who prefer a simpler approach, I’ve also added a "simple loans" option. This feature allows you to borrow money at an interest rate tied to the lead interest rate, bypassing the complexities of the bond system. You can toggle this option in the gameplay settings.

The addition of a simpler loan system makes the game more accessible for casual players while still offering experienced players an option for a more relaxed and straightforward playthrough.

Incorporating a way to lend money has proven to be a valuable enhancement to the game. It adds flexibility for players to take on higher-risk ventures and creates interesting dynamics as the in-game world and markets evolve. The tension between managing debt and capitalizing on opportunities should provide an engaging challenge, regardless of playstyle.

I've started reworking the user interface, as it feels like one of the game's biggest pain points right now. This sentiment has been echoed by testers, so it's clear that improvements are necessary.

For some background: the game currently uses Dear ImGui, an excellent UI library by ocornut. While the author designed it primarily for creating tools for game developers rather than in-game UIs, it initially seemed like the right choice for several reasons:

• It's easy to implement, with existing C# bindings.
• It was more than sufficient during the prototyping phase (and served well in that context!).
• It's free and perfectly suited my engine's need for internal tool development.

At the time, it felt like a no-brainer. However, as the game mechanics have grown more complex, the limitations of Dear ImGui have become apparent. It lacks the level of customizability I now need to present the game's complex systems in a way that is both clear and intuitive for players.

As much as I've enjoyed working with Dear ImGui, it's time to move on.

That said, before diving into a full UI revamp, I'm focusing on preparing the game for another internal testing round to gather more player feedback. Once that's done, I'll begin work on a custom UI system tailored specifically for Capitalist Empire and future projects.

I haven't thought too much about the new system yet, but I'm excited about the challenge - and you can count on reading about the process here once it's complete. It's going to be a fun (and probably lengthy) project!

Alongside bonds, there’s another new feature making its way into the game: Incidents. While smaller in scope and impact, this addition adds variability, and creates additional layers of risk for players.

Incidents occur randomly and are categorized as negative, neutral, or positive. To keep things fair, the game balances these events to avoid overwhelming players with consecutive negative effects (finding the right balance here was an interesting challenge). Each incident lasts for a fixed duration, determined randomly when it occurs.

Here’s a bunch of some currently implemented incidents and their effects:

Negative Incidents

• Labor Dispute: Reduces productivity across all buildings.
• Construction Crisis: Increases construction costs.
• Savings Trend: Population reduces spending, impacting sales.

Neutral

• Market Volatility: Increased price fluctuations in a specific item market.
• Excess Supply: Oversupply in an item market drives prices down.
• Excess Demand: A sudden spike in demand raises prices for a specific item.

Positive

• Motivated Workers: Boosts productivity across all buildings.
• Subsidy Grant: Reduces upkeep costs for workers and buildings.
• Global Boom: Increases consumer spending as the global economy thrives.

The incident system works by assigning an impact value to each event and limiting the total impact over a set period. This allows fine-tuning of difficulty while ensuring the incidents fit the desired gameplay experience.
I might add more incidents in the future but these seem to work well enough for now.

Another interesting topic worth discussing is how time and the calendar work in the game. Originally, I used the standard C# structs for managing time—DateTime, DateOnly, and TimeOnly. While they worked fine initially, I didn’t give much thought to the complexities they would introduce. It turns out, realistic calendars are incredibly complicated to manage in a game context.

The main issue stems from real-world quirks: months with a non-uniform number of days and the occasional leap year adding an extra day. These details make handling time for game mechanics far more cumbersome than necessary. It's also less transparent and more complex for the player.

To address this, I implemented custom DateTime, DateOnly, and TimeOnly structs with some simplified assumptions:

• Every month has exactly 30 days.
• Every year has 12 months, making a total of 360 days per year.

These simplifications make time calculations in the game significantly easier and they replace all of the C# date handling api I did use so far.
For example, determining the annually paid interest for bonds is now just a straightforward multiplication, without worrying about varying month lengths or leap years.

While this approach isn’t realistic, it's far simpler to work with for programmers and players.

That's it for this devlog.

Thanks for reading!