The gameplay of Megalo Polis has a few layers on top of each other, and the most basic one is the interaction with citizens. The objective of each mission is to get elected, which you do by getting more votes than your opponents. And you do that by converting more citizens than them.

It's a little bit more complex, as the default rules states that what matters is the number of citizens you total, in the districts that you control. A kind of winner-takes-all rule. So you could only have one citizen of your color in all districts, and still win. Or conversely, you could control almost all citizens, but not a single district, and your score would be a whooping 0%. But in general, your level of control of districts is equivalent to the number of citizens you have convinced.

So the most basic layer of gameplay is moving around, and converting citizens. This is done very simply, as you have to stand near a citizen for a few seconds to convert it. The time varies depending on your character, on the social class of the citizen, and a few other parameters.

We spent a few weeks, at the start of the project, to get this working right - and we are still tweaking it at this stage. Clément, our main developer, was hired for the project, and was in charge of putting the first bricks together. Starting from nothing, on a completely new concept, is a real challenge. The overall idea was laid down, as explained previously, still, it had to be tested and proven, before moving to the next step of the full game production.

What Clément did, was setup a test map, place a few districts, a few citizens each, and have a bogus character move around. As we had no 3D objects done yet, it was looking weird of course.

The next step was to code the rules, and have as many parameters accessible live while testing, as possible. Half of the screen was covered with buttons, control bars, dropdown lists, etc. It soon had to be organized into tabs just to remain manageable. That's the image at the top.

Clément remembers this phase of the project :
"The important thing at this state is to build a fast and easyly manageable system. There's a great chance that you will have to throw away important parts of it, so forget all complexity and beauty of code. Go straight to the needs and provide interfaces to the game designer, so he can easily try different values and get immediate results. Ugly & Fast is a good way to prototype until you've found what your core gameplay will look like."

Once this got into place, we needed a few weeks to balance all these parameters, and make sure that the foundations of the project were correct : player and citizens speed, conversion delays, attraction efficiency, social class distance, and so on. These values remained more or less the same up to now. One notable change was an increase in the player speed right before the first release.

We also added a few more rules into the mix later on, like the neighbour bonus. It gives a bonus on conversion, when you already control citizens in the district. This parameter, among other, then got promoted to a level design factor, and changes from mission to mission, from a very low 0% (no bonus whatsoever), to around 25% (meaning you convert twice as fast when you already have 4 citizens on your side). We could even put negative values, now that I think of it.

It's a shared task between code and design, to identify which parameters must be exposed, how to balance them, and what level of complexity is acceptable in the calculations. Too many parameters is harder and harder to balance AND to code without bugs or even side effects, but in a strategy game, you need to have quite a few levers, to create choices and hence strategy.