Game Design, Programming and running a one-man games business…

Category: democracy 4

Improvements to the political compass / voters opinions

I’ve been trying to improve voter behavior in Democracy 4 with a bunch of goals. Firstly to maker the political compass Overton window not look so ‘forced’, and more importantly, to allow for more realistic modeling of the variety of opinion. As some players have pointed out, there is always SOMEONE in the electorate who will not ever vote for you, always some communists, always some capitalists, and so on. How to fix this?
Here is the political compass for a new game as Australia:

And here it is with my new changes I am considering:

The voters are less confined to the Overton window, and yet are still influenced it. We clearly have people far to the left of the political consensus zone, but not quite as far left as Stalin and Lenin. I think this makes sense. Even people who are claiming to be outsiders and not swayed by the mainstream media or mainstream politics are still vaguely influenced away from the extremes.

The (debug-mode-only) tooltip data for impressionability illustrates this. The game has always modelled the ‘impressionability’ of voters, but with recent changes, I’ve improved how this calculation is used to determine a final opinion. Here is the final calculation:

Final Socialism = (CurrentGlobalSocialism * Impressionability) + (InnateSocialism * (1-Impressionability))
(This is a new equation for this version, it was different before)

So every voter is born with an innate predisposition to socialism (also liberalism) or not, and this is their ‘starting’ position. They then get swayed towards the ‘consensus’ position (Global Socialism) by how impressionable they are.

Impressionability is calculated as a normal distribution but then squeezed in so its between 15% and 85%. (Its then multiplied by 0.95 which is an internal value and not important…)

Note that if the ‘Polarization’ situation is active, the value of InnateSocialism gets pushed out to the extremes by the strength of the situation.

I need to do a lot of play testing, but I think this change will make the game feel more realistic.

Democracy 4 Updated to build 1.23

Lots of changes, here is the complete list:

[1.23]
1) Fixed incorrect or broken effects & costs for EV transition, Plant Based Diets, Judicial Independence, Nuclear Fission.
2) Changed scaling for simulation values so in ‘value’ mode they show difference from the midpoint.
3) Added South Korea as a playable country!
4) Added support for country-specific minister art groups.
5) Improvements to how sensibly the icons are positioned on the main UI.
6) UK now has Tobacco Awareness Campaign enabled to reflect the warnings on packets.
7) Reforestation policy is now slower to implement, and slower to impact the environment.
8) Synthetic meat research now boosts plant based diets, and pleases instead of upsetting environmentalists.
9) Improved election analysis screen so it uses tiny people symbols rather than an ambiguous ‘dot’.
10) Slightly boosted impact of voter ‘complacency’ over time for when they start to take the governments policies for granted.
11) Fixed a bug that artificially limited how complacent voter groups could be at a lower level than it should.
12) Party analysis screen now also uses people icons instead of meaningless dots.
13) Possible fix for rare bug where alt-tabbing to and from the game can lead to ‘phantom clicks’ on items like the next turn button.
14) Fixed bug where the background fade effect disappeared when canceling an industry privatization.

And todays blog video!

How I address a tricky, user-interface layout / physics code challenge

Democracy 4 has one aspect of its GUI that still screams IMPERFECT at me, and needs fixing, but its at least 10x harder than it sounds. Its the sizing, and positioning of the icons on the main UI:

This looks like just a bunch of different sized circles on a screen. How is that tricky? Let me count the ways:

  • The icons have to be in specific zones, which are not rectangles, but could be any polygon. These change size and shape over time
  • There has to be consistency of size. A radius 10px icon in zone A has to represent the same value as a radius 10 icon in zone D
  • We could have ANY screen resolution or aspect ratio.
  • There could be ANY number of icons.
  • There is finite time, on perhaps a CPU-limited laptop to do all the calculations.
  • The icons cannot touch the center icon, or each other, or the zone boundaries.

Now it turns out…coding that is a real pain in the neck. The system that you *think* will solve it all, is to have each zone boundary and icon project a sort of repulsive force on to all the others, then step through an iterative system of applying forces and moving stuff around until an equilibrium is reached. Well kinda… but no. Look again:

Those icons with black arrows are the pain. They are kind of stuck next to corners and other icons. its the shortest distance between two icons ANYWHERE on the screen that limits the size of all of the others.

My initial solution to fix this, DID make it better, but its not good enough. What was it? Basically I do the physics-repulsing-forces thing as usual, then I ‘jiggle’ each icon in turn, randomly kicking it a few pixels in different directions, then checking to see if the overall separation of the icons got better or worse with each jiggle. I keep the jiggles that improved the situation.

Actually I improved that algorithm by first finding the icon that was the closest to the others and giving that 32 initial jiggles. This is the result, (less force is better, it means the separation is better)

Pre Jiggle. Total force:[0.39] Strongest: [0.14]
Post Jiggle. Total force:[0.03] Strongest: [0.03]
Pre Jiggle. Total force:[1.31] Strongest: [0.45]
Post Jiggle. Total force:[0.23] Strongest: [0.23]
Pre Jiggle. Total force:[1.67] Strongest: [0.32]
Post Jiggle. Total force:[0.19] Strongest: [0.19]
Pre Jiggle. Total force:[1.23] Strongest: [1.19]
Post Jiggle. Total force:[0.06] Strongest: [0.06]
Pre Jiggle. Total force:[1.14] Strongest: [0.13]
Post Jiggle. Total force:[0.17] Strongest: [0.17]
Pre Jiggle. Total force:[2.17] Strongest: [0.68]
Post Jiggle. Total force:[0.31] Strongest: [0.31]
Pre Jiggle. Total force:[0.53] Strongest: [0.40]
Post Jiggle. Total force:[0.26] Strongest: [0.26]

Which is what brings me to the current state of affairs. However, this is just one of those tasks’ that humans excel at and machines suck at. I bet you can see locations where the icons should be shuffled really easily.

Something I intend to experiment with is a more focused approach to the jiggling! I can tell now which icons (in this case two of them) seem ‘trapped’ and are causing the biggest problems, so rather than just going through all of the point containers and jiggling everything, I should now focus my attention just on the containers with the problem

Maybe I can even focus my attention just on the half-dozen icons per container that are closest to the problematic ones, but that may not actually be the solution. Check out this section in more detail:

This row of icons has basically got trapped. Moving any of them upwards and to the right is going to be tricky, unless the icons *above* them can get out of the way. The trouble is, we need some super-clever algorithm that could move an icon above them higher (thus making *that* icon worse off… so that later we can jiggle these others… and everyone will be better off.

It might be that the initial force algortihmn is too linear. A linear force would not concentrate midns enough of the dire plight of the icon in the bottom left. If the squeeze here was not seen as just *slightly* worse than the squeeze on others, but exponentailly worse… that might fix it.

…and also this icon is receiving some strong forces from its location in the corner., Unlike other icons, boundaries cannot move, so maybe we should prioritize their plight more? Surely no coincidence that both worst-case icons are in corners?

This all strikes me as something that would be easy if I’d learned more physics and maths, but hey… working it out alone from basic principles is kinda fun. I have plenty of ideas to tweak my algorithm.

Balancing Democracy 4 using stats and number crunching

I’m still working away on improving the balance for my political strategy game ‘Democracy 4‘ which is in Early Access, and likely the hardest game to balance in the history of humankind, due to the insane number of interconnecting variables.

Something I was working on today was the likelihood of each dilemma popping up. These are occasional ‘situations’ that are urgent and need the player to make a choice one way or the other. Basically the choices are always hard, because they mean upsetting someone, or causing an effect that may be undesirable given your goals.

For example, if a company is about to collapse, you could bail it out (pleasing the workers, but setting a bad example for other companies, maybe upsetting capitalists, who prefer a free market), or not, and your decision depends on who you can afford to (or choose to) upset at that moment.

Some of the dilemmas are totally random, but most are influenced by some variables so that they seem fairly ‘relevant’ to the way you are playing the game. So they all have inputs based on certain variables, and thus as the game designer I don’t know in advance when they will happen (they are not timed or scripted in a conventional way).

This is all very easy to design and code, but the problem is you can end up with the inputs being unbalanced, and thus maybe everybody is sick of seeing dilemma A, regardless what they do or how they play, whereas interesting and exciting dilemma B hardly ever gets triggered. For a small studio with a limited budget, having any game content that is rarely seen by the player is an efficiency disaster.

Luckily I (anonymously) keep track of every trigger of a dilemma by version number, so I can guild up big databases of such events. The events database is currently about 4GB in size, and is testing the limits of my MySQL optimization abilities. Thus I copy the last 2 versions events into a much smaller (600MB) database for me to query. That lets me get cool charts like this:

Which lets me visualize the extent to which some dilemmas (the ones with long red bars) are triggering WAY more than they would if their distribution was completely random. I’ve been using this data for the last few versions, but I still have the unbalanced issue despite a lot of manual revisions, so I’m working on code today to visualize this better.

I actually found this easier in excel, once I had data that showed me every dilemma, and what percentage of dilemmas each one represented, over the previous 2 versions:

I can then work out what percentage they *should* be, thus the error in terms of over or under representation. Luckily I’m analyzing 100 dilemmas, so its a simple 1%. I calculate an error in percentage terms, for each version, then calculate the change. A positive value is movement towards better balance, a negative one is movement away, (worsening the balance). This can then be conditionally formatted in excel:

Which is a cool trick, but also depressing to see the extent to which I often am having a trivial effect towards balance, or even making things worse (negatives).

However, at least having a nice process to visualize this stuff makes it more obvious to spot where I am being too timid in my corrections. In an ideal world, this would all be integrated into a single web query, and in an ideal, ideal world, some sort of cool machine-learning AI would be making these adjustments instead of me…

But hey, its a big step up from just ‘setting some numbers and then playing it a lot before release’ which is what I did ten years ago :D I’ll gradually get this stuff more and more optimized.

An indie strategy game translation business case. lets do the Math(s)

(My wife is triggered when I say ‘math’ because its American. we say maths here in the land of Monty python)

I have a bit of a rule that I try to follow, that when I am trying to make a business decision, I always calculate forwards not backwards. What I mean by that, is I try not to think ‘I’d like a Polish translation of Democracy 4. is it justified?’. That already sets you on the foot of WANTING it to be. The best way to do this is to set out the number that justifies a greenlight, then to work out the equations as best you can, then unemotionally go with the result.

Democracy 4 is currently in English, French, Italian, German, Spanish and Brazilian Portuguese. The classic strategy game translation pattern is EFIGS. I have added Brazilian Portuguese because it was done by someone who got in contact with me direct, so was affordable.

Anyway. Lets look at Russian, Japanese and Polish.

If I look at Democracy 3, which was translated into Russian and Polish but not Japanese, I get the following full-history revenue breakdown. Note that the game did not *ship* initially with those, the languages were added later.

  • Russian revenue $91k gross
  • Japanese revenue $45k gross
  • Polish revenue $89k

Democracy 3 sold super well, over 6 years with 4 expansion packs, so the total revenue is really good, and obviously Democracy 4 revenue right now is WAY lower, but I’m trying to plan ahead.

Steam take 30%, and there are refunds, chargebacks, and sales tax, so we actually get about 60% which gives me:

  • Russian net income $54,600
  • Japanese net income $27,000
  • Polish net income $53,400

The cost of a translation for the game is roughly $7-9k. It can go higher with more interesting languages like Japanese, so lets say the high end and assume $9k. We are likely to add a fair bit of extra policies etc. over time, and need to keep everything up to date so lets budget for a final $10k per language. I also have to implement it, play test it, and deal with any problems that might come up that have not been seen before in earlier languages. This generally isn’t taking me more than a few days each time, but lets push the complete implementation cost for each one to $12k.

This currently assumes that Democracy 4 sells the same as Democracy 3. This may not be true due to the following negatives:

  • People might be sick of politics due to real world events
  • Much more competition in the games market in general
  • Players of democracy 3 may have ‘had their fill’ of politics and decide not to upgrade

However there are also positives:

  • Young people seem much more engaged in the Bernie sanders / alt-right / Jeremy Corbyn / AOC era than they were during the relatively bland time when D3 came out.
  • Steam is bigger, with a larger addressable audience now
  • D3 was a hit, and some people will be easy to persuade to get D4 if they enjoyed the previous game.

I’m not super risk-taking, so lets be pessimistic and assume that the balance of these factors means that the long term income of Democracy 4 (which I should have mentioned is a MUCH better game btw) is likely to be about 66% of that of Democracy 3. That gives us these values:

  • D4 projected Russian net income: $36,036
  • D4 projected Japanese net income: $17,820
  • D4 projected Polish net income: $35,244

There is a big assumption here, and that is that people playing Democracy 3 in country X…were playing it in the local language, and would NOT have bought an English-language version. The way to check this is to look at the percentage of sales in the first year of release that were Chinese for D3, and compare it with the percentage in the most recent year (where Chinese was translated). This is not perfect, and china specific but we get this:

  • Percentage of D3 sales to China year 1: 0.16%
  • Percentage of D3 sales to China last year: 4.33%

Same for Polish:

  • Percentage of D3 sales to Poland year 1: 0.53%
  • Percentage of D3 sales to Poland last year: 2.7%

So we can see that the effect of a native language version boosted Chinese sales and Polish sales, and the relative native-language-applicable revenue was 96% and 80% respectively, so lets split the difference and assign a value of 88% to the revenue:

  • D4 projected income from native Russian: $31,711
  • D4 projected income from native Japanese: $15,681
  • D4 projected income from native Polish: $31,014

This all makes a super-convincing case to do Russian and Polish, and a slim, but arguable case for justifying Japanese. There are of course other factors, and huge margins for error. One factor is the multiplier-flywheel effect. If I could sell an extra 10,000 copies of Democracy 4 tomorrow and get no money at all for it…its kind of in my interests, because then it climbs up the ‘top sellers’ lists and gets more visibility. Also, I may already be selling copies of D4 to english-speaking players in Polad/Japan who cannot recomend it to their non-english speaking gaming friends yet. Thus, the word-of-mouth of the game is currently not at full capacity.

PLUS! Democracy 4 is not just sold on steam, but direct from us (via humble widget), through GoG, Humble Store and the Epic store. Epics royalty rate is famously higher, and that then changes the figures slightly again in my favor…

I shall mull this over, because no indie dev suddenly commissions $30k more contract work without being 100% sure and sleeping on it, but I thought people may be interested in seeing the thought process.

I know that crowd-sourced translations are a thing, we even started it with D4, but progress is too slow, and also too unpredictable. It also runs the risk of multiple contributors having different translations for the same word in various places throughout the game. I think professional translations are a better system. YMMV.