Vigilante

[Klear]

Version -0.90 is live! It’s not spectacular, but I’ve done some good work behind the scenes.

New stuff

• Three tiers of housing: Hovel, Appartments and Penthouse.

  • The peeps will look for the best tier they can afford with their income for at least 30 days and they perfer houses close to their place of work, if they have one.
  • Rent was meant to be collected weekly, but I chickened out at the last minute so it’s paid every day for now. If a peep fails to pay it, they get evicted.
  • Rent is based on the budget of peeps who were looking for a home the day before (more on the log system later). So if there is one peep who would be willing to pay 30 and five peeps who could pay only 10, the price is set to 10, since 60 > 30.

• Restaurants are a better quality alternative to Food Dispensers

  • They are more expensive to build and maintain, require to be staffed (which means they are only open for 8 hours a day) and have a limited capacity, but peeps will prefer them IF they can afford it.
  • Unlike production facilities where wage determined the amout of work done, here the employees are simply paid half of minimum wage. I was going to let them eat there for free as a perk, but forgot to implement it, so the waiting staff is seriously underpaid right now and there are no tips. Tough for them.
  • Working hours are determined by demand, unlike working hours of production facilities, which as as of now randomly to a random early hour.
    • The restaurant can’t change its opening hours once they are set, because the why, how and when of that is a bit too nebulous for me at this point.
  • The location where a restaurant is built also depends on where the most demand is (together with when). The same goes for Dispensers and Sleeping Pods.

• Peeps now have the first vestiges of memory - when looking for a place to eat or sleep, they’ll remember places they already checked and decided that the queue is too long so they no longer ping-pong between two dispensers waiting for the queue to go away. They forget this whenever they go to sleep. (I’ll come up with a better memory disposal system later, but for now this works well enough).

• Added a new graph screen (switch from map view in the top right corner). I’ll be adding more graphs as I think of interesting data to display there.

• Workplaces which have working hours now have separate graphics for when they are closed. Except for the Power Plant (I was tired) it looks pretty good!

• Workplaces can now go bankrupt, or rather, if a place has negative profit over the past 7 days and there was no profit yesterday, the building will get shut down. For now I let the buildings exists on the map so I could give the owners the option to reopen them if they think they will be able to make money again, but for now that’s not implemented, as the economic situation is unlikely to improve over time.

• Added a log system with three uses:

  1. Reports on the state of the world (such as a new building being built)
  2. Reports used to guide some decisions (such as peeps wishing for a new service)
  3. Error messages
  • This replaces all the various “print” lines I used to track all kinds of stuff. Now I can easily switch specific reports on or off depending on what I want to see.
  • Early on the hungry and broke peeps kept reporting their lack of sustenance every damn minute of game time which obviously filled GBs of memory with junk, but now it’s working reasonably well. Of course, in the future I’ll come up with a system that would delete old useless logs.
  • There is a tiny display showing the latest five logs below the map. For now it only shows buildings being built or shut down. In the future it should be expandable and allow filtering and stuff like that, but this is all you’re getting for now.
    • The question mark next to it is supposed to take you to a help screen in the future, but since I hate designing UI, for now it only covers the screen with a nasty gray rectangle and… huh. Seems like that’s it. You can’t even get rid of it in any way. Yeah, you don’t want to click the question mark.

Background fixes and stuff

• Buildings are split into four classes:

  1. “Dispensers” are automated places where a peep pays and gets food or a place to sleep
  2. “Housing” can be rented and the room then belongs to the renter until they can no longer pay or they move to a better place
  3. “Production” have employees and produce something based on their wages
  4. Employees of “Services” are paid a flat wage no matter the production. As long as they are staffed, they work the same as dispensers.
  • I rewrote the functions finding out demand, setting prices and determining if a building is worth the investment. Previously I tried to fit every building type into a single function, but it just ended up extremely convoluted and hard to read. Splitting them like this made the whole thing a lot more smooth and readable, and allows me to make adjustments much easier.
  • Demand is no longer estimated by guessing wildly (huh, there are 150 peeps? Better prepare 150 meals, economy be damned!) but by evaluating the demand from the previous day, in the case of housing including the purchase power of the peeps. It mostly works just fine, and when it doesn’t, it’s usually a problem with the economy rather than my programming.
  • Whichever building of a certain type has the most production gets to determine the price. That means that a dispenser that’s used by a hundred peeps sets the price accordingly and another one that only gets ten customers per day has to survive with that (or get shut down).
    • This is an interesting effect - a less popular place that is otherwise identical to a very popular one should, in theory, have higher prices to offset the lesser demand, as long as the higher price doesn’t drive all the customers away. I will be solving these cases way later, since for now there is a single universal price for each good and service.

• I finally put all functions into local modules. Didn’t seem to have any impact, but it’s nice to know my code is a tiny bit more in line with what’s considered reasonable.

• Magical free money for the homeless! That is to say, to make sure the economy doesn’t crash immediately after the jobless peeps run out of their starting money (which is presently set to 20 - 500 for most peeps, 1000 - 50000 for 20 lucky ones to make sure something actually gets built), once a peep gets hungry and can’t afford a dispenser meal, they gain 3x that much money out of nowhere so they can continue being good customers.

• Made the loading bar a bit smoother

• Scrolling the list of peeps is now a bit faster and thus more convenient. Still didn’t find the time to add buttons to skip by pages because I hate making UI.

Since the html5 version is starting to become unreasonably slow, here’s a bundled windows version:

Vigilante.zip (2.5 MB)

I’ve also noticed that in the html5 version no Hovels get built (their price remains inf) which is kinda strange and probably bears investigating. The way the numbers are set, the question whether Hovels will be profitable is on the knife’s edge, though, so it’s probably just because a different set of numbers are generated from the default seed. Changing the seed sometimes results in profitable Hovels (and sometimes locks the game up sometime during the first week… oops!

What’s next

There’s a couple of things I’m kinda looking forward to implementing:

• Entertainment! The peeps do have a (hidden) boredom stat which only ever goes up. Time to give them something to do. Unlike fatigue and hunger which cause peeps to try to satisfy them once they reach a set threshold, I think boredom will have an upper limit and the value will determine just how much of their budget they want to blow on entertainment - meaning that rich peeps will be able to party until they drop while to poor ones will only seek entertainment once in a blue moon, or possibly never.
• Liking and disliking stuff, namely other peeps and different rooms.
• Begging and petty crime! There are still tons of unemployed homeless peeps. Let them annoy the rest of the peeps by begging and steal from dispensers if they get really desperate. I think that there won’t be any possible repercussions at this point, but it will lay some groundwork for security guards, law enforcement and repair services later.
• More detailed information in the jobs display and implement sorting, by type at the very least. It’s getting quite crowded.
• Speaking of crowded, the map gets filled up pretty fast and if you set the number of peeps much higher than the default 150 (or making the map smaller) will cause problems as there’s no more room to build. I’m going to come up with a completely new design for the map. This one was really only meant to help me this far. It’s high time to come up with something more compact and space-station-like.
• You can notice that aside from housing (which is set to inf), there are some default prices. And yes - setting them to anything else does cause problems. I should probably fix that.

[Klear]

So I’m starting to implement entertainment and it got me thinking about the way I check needs overall, so I decided to put it all in writing here to make more sense of it.

Basic needs

Peeps have a “hunger”, “fatigue” and “boredom” stats which increase by one every minute (or rather, increase in bulk once the peep’s current action finished or if the simulation is stopped). Once they reach a pre-determined value (1000 right now), the action “hungry” or “tired” gets added to that peep’s action queue and once they get around to it, they will go an solve it.

Now that I think of it, adding these actions is a bit useless and it has been causing problems in the past, so I’ll change it to simply check the hunger/fatigue levels when peeps are deciding what to do, which will also allow these decisions to be more fluid.

Entertainment

Entertainment is different. If you can’t afford food, you’ll die (or get magical charity money if you live on my station), if you can’t afford a place to sleep, you can sleep on “the street”, but if you can’t afford entertainment, you life will suck but it’s not a matter of life and death, at least in the short term. Boredom just doesn’t quite work like that. I don’t think it can be reduced to some physical process that builds up and then lets itself known much like hunger or tiredness does. After all, people are quite capable of having fun all the time if they have the time and money. So instead of having a clearly defined threshold, I’ll let the boredom stat decide just how much of their budget are the peeps prepared to pay to have some fun (and then do it if there’s a venue which they can afford for that).

Budgeting

I can get a peep’s budget from a function which adds up all sources of a peep’s income, optionally subtracts housing and/or food expenses and adds the peep’s current money divided by the number of days he’s budgeting for (30 by default). All wages and other income and currently work on a per day basis (this is why I eventually decided not to implement weekly rent) so this gives me exactly how much money peeps have to spend in a day. Note - when peeps are looking for food and their daily budget is less than the price of dispenser meal, but they do have enough money, the result gets overridden so that they always buy food if they can.

There isn’t much the peeps can spend their money on so they are mostly programmed to go all in - they rent the most expensive housing they can and eat the best food with no regard for saving money for the future (that will come at a later time though). The biggest expenses are buildings being built, but that doesn’t concern anyone beyond those who already own a workplace or two and as such have enough income to realistically save enough money for investment. I don’t want them to blow all their money on entertainment and then get hungry and evicted. I mean, I kinda do, but not everyone and not every day.

So - what I’m going to do is have the “boredom” stat represent the willingness to pay for some entertainment. Time to create another neat curve. It should be low (but not zero) at 0 boredom, so let’s say 5%, rounded down. A peep whose daily budget is less than 20 won’t even consider paying anything for entertainment if he’s not bored at all. Someone richer with a budget of 200 would be willing to pay 10 for some thrills even though he probably just left such an establishment (otherwise his boredom would have been higher).

As boredom goes up, so does the acceptable price. Let’s make the nice round 1500 (which is 25 hours worth of boredom) the level at which the peeps is bored enough that he’d pay his whole daily budget for some entertainment - which sounds good to me. The poorer peeps will thus only spend the entertainment money when they are really bored, that is, close to once a day, depending on the prices.

The question remains - what if the boredom goes up even more? My first instinct is to let the peeps spend even greater percentage of daily budget, double, triple, if they’re really desperate (and the budget is very small), but I have a bad feeling that this is going to peeps being evicted for not paying rent regularly. At any rate, the increases in percentage spent is going to have to increase way slower than in the 0-1500 range. Just how many days, weeks, months without any entertainment would make you forgo food and a warm bed just so you could have a peek in a VR kiosk? I don’t know! But I happen to have just the simulation to answer these questions for me.

[Pawel]

Regarding needs, did you consider applying some more math, and I mean here fuzzy logic for this? The Sims are designed basing on this and it works pretty cool and kind of realistic. Fuzzy logic allows you to implement complex and yet logical solutions to the queue of needs

[Klear]

Well I’m considering it now! Just read up on it and it looks kinda neat. For now the decisions the peeps face are few and simple enough, so I have a simple hierarchy to decide their next action. While stuff like going to work has an obvious precedence before anything else, a tired AND hungry peep will eat first and sleep after that (I think, it might be the other way around).

I knew I will have to set something up so they’d decide more intelligently and this looks like the perfect way to do it! Thanks!

As I’ll be rerwiting most of the code that has something to do with needs anyway, I might as well use this. I especially want to add a proper scheduling system - right now their alarm goes off 30 minutes before work and they (mostly) drop everything and go there, but I don’t want them to, say, pay for an hour in the VR Lounge only to leave after five minutes…

[Pawel]

It made me think if I schedule my time basing on my needs in that way, because of the fact, that usually indeed I’m giving on everything and going to work but wait, all the basic needs are fulfilled before so the queue is scheduled somehow by some logic I think, in a field of fuzzy logic, the need to go to work should rise drastically just before the job starts, like in the Sims - when the car arrives, a Sim immediately adds ‘going to work’ to the queue your game is a very interesting point of view

[Klear]

Yeah. I tend to view my everyday life through the game’s logic now. It’s interesting (and potentially insanity inducing).

Going to work will have to have an utmost importance until I can figure out penalties for being late. Plus less work done might in theory lead to problems in the demand/supply chain as it is currently set up, though I haven’t noticed any detrimental effect just yet. Since I don’t want to deal with that, I’ll rather make sure they are all on time for now.

Redoing the map so that it doesn’t take forever to get anywhere will help too.

[Klear]

Going to work will have to have an utmost importance until I can figure out penalties for being late.

Fun fact - the very next day I overslept and arrived to work an hour late. Luckily nobody cares.

[Klear]

I have some trouble sleeping, so I decided to share a problem that keeps coming back one way or another. It’s not a programming problem, rather an “economic” one, but I think it’s interesting.

Let me describe a simplified example: there is demand for 100 units of Stuff. Stuff is not a luxury. It will get sold if there’s the money for it. So someone builds a Stuff factory which produces 100 units every day and based on his expenses etc. charges a reasonable price say 10 credits.
So far so good.

Say the demand is 200 units per day instead. Not a problem! Two Stuff factories get built and the price remains the same.

What if there’s demand for 150 units, though? A single factory can produce only 100 units, but that still leaves 50 demand. A second factory planning to satisfy this demand would have to run at a lower efficiency (since running costs and wages don’t scale perfectly) and to maintain the same profitability it would have to sell the Stuff for a higher price. Alternatively, the two factories would end up producing 75 units each and charge, say 15 credits.

That’s a problem. Prices should change with the total supply and demand, not just the remainder after subtracting a number of maximally efficient providers. Under extreme circumstances (demand at 101) the price would grow much larger as a whole factory would have to be built and cover its running costs just by the sale of that single unit. Even if the production were to be split evenly, the expenses per units would rise, leading to an increase in prices.

Right now the “solution” is that the (global) price is set by the largest producer, but that usually means that a second factory covering the remainder will not be profitable and thus simply isn’t built - which leads to unsatisfied demand and other problems down the line, as you can imagine.

Another solution is to set up the values just right so that the issue doesn’t materialize, though that takes a bit of work.

I would love to be able to “force” demand to be met, but it just doesn’t work too well. Why produce enough to meet the demand when there’s more total profit in meeting just a part of it?

I wonder if there’s a real-world equivalent to this. I suspect the whole issue is caused by the limited scale on which my game world operates at this point - if there were dozens of Stuff factories producing thousands of units, it would probably smooth itself a bit better. That is the theory I’m going with anyway and I will ignore the problem for now, but whenever the economy starts to crash down on me, this is the thing I end up thinking about the most.

[britzl]

No one in their right mind would build a 100 unit factory to cover a need of one unit, unless the forecast is that demand would rapidly increase. It would be more realistic if the factory at max capacity would find ways to increase output through optimization or adding more shifts. Or maybe it is fine that there’s higher demand than can be satisfied? Take pre orders and have a long queue like Tesla is doing.

[Klear]

No one in their right mind would build a 100 unit factory to cover a need of one unit, unless the forecast is that demand would rapidly increase.

It’s one unit per day, so it’s not that unreasonable as long as they are sure they can sell it. But it’s still not the way to go.

Production capacity is also not the problem, as the production stops at the amount that makes the most money and won’t produce more because it wouldn’t be worth it. There are some constant running costs (including the initial investment), some expenses that scale linearly (resources needed for production of a single unit) and then there are wages that influence productivity based on a hyperbole. Plus there’s the number of workers hired. All this together creates a couple of peaks with max profits for the given output and the factory is set to whichever of these peaks is less than or equal to the demand. Setting the output any higher (by hiring more workers or paying them better) would ultimately lead to less profits.

Take pre orders and have a long queue like Tesla is doing.

This is a great suggestion. In the scenario with 101 demand per day, the sensible thing is not to produce one unit a day, but to produce a hundred and then close shop until they are sold. Or rather have the original factory produce more than the current demand once in a while and then underproduce while the supplies last.

This will mean that the workers will get higher wages for a day once in a while, or some extras will be hired and fired the next day (which may or may not lead to the wages being slightly lowered for that day). In either case it will likely wreak havoc with their budgets, but that’s something I can fix later when I tackle jobs without fixed schedule.

[sergey.lerg]

I would sell the Stuff at a higher price to make up the capital for the second factory with perspective that it won’t be underproducing much (say at least 75%). So the price is calculated accordingly to cover expansion expenses, 12.5 or 15.

[Klear]

But that’s just it - that would mean the price of Stuff would be lower if demand is exactly equal to the most efficient output of the factories but higher if there’s a remainder:

Demand 50 - price 15
Demand 100 - price 10
Demand 150 - price 15
Demand 200 - price 10

If the demand is very low, production is low and Stuff is scarce, so higher price makes sense. But if the demand exceeds the optimal production of a factory and that production is subtracted from the demand, that artificially creates the scarcity situation again.

However, I believe taking the current stockpile into account when planning production and aiming to have some reserves at all times will solve it.

[NeZvers]

I am speechless! You probably are masochist . That massive game scope is huge workload for developer team already. I can’t imagine how to manage all that code.

[Klear]

It’s not that bad. I imagine that what I have now after more than a year of development could be written in less than a week by an experienced programmer, but that’s the whole point - to become one.

And there is a precedent - Dwarf Fortress has a scope that… err… dwarfs mine and it’s also written by one guy, though from what I hear he’s crazy focused on that game. I treat this only as a hobby.

[Jerakin]

But that’s just it - that would mean the price of Stuff would be lower if demand is exactly equal to the most efficient output of the factories but higher if there’s a remainder:

From a economical point of view you have two slighty different scenarios.

Demand is higher than supply

If you can only produce 10 Stuff but there is a 100 people that want Stuff, then the price will increase until Person 89 is not willing (or able) to pay what person 90 is. The likely outcome is that the people’s demand of Stuff will increase the prices.

A new factory would only be opened if it can recoup the cost of selling Stuff at the current (or lower) market price. The interesting factor here is it depends on who opens the factory. If it is a new factory owner that are selling Stuff, then it is likely (almost guaranteed) he will undercut the already established Stuff seller (even if that means making a loss at the beginning) to get market shares.

But an already established factory seller of Stuff would most likely not increase his price to “recoup” starting a new factory.

Supply is higher than demand

If you can produce 100 Stuff but only 10 people want Stuff, then you can lower your output (and cost of outputting). The likely outcome is that the seller of Stuff will decrease the prices to sell more.

---

---

It is very common to create more supply than there is demand. The fast fashion industry is notorious for this, they create tons and tons of extra clothes every seasons that ends up being burned or in landfills. The same can be said for sellers of produce - your local stores probably throws out hundreds of kilo worth of food every week. In short, in the current market economy you assume that you will not be able to sell all of your Stuff and will budget accordingly. A factor of Stuff wouldn’t operate on such thin margins that it would need to sell 100% of its output.

[Klear]

If it is a new factory owner that are selling Stuff, then it is likely (almost guaranteed) he will undercut the already established Stuff seller (even if that means making a loss at the beginning) to get market shares.

Got this covered. Competition, monopolies and all that stuff will require some complex decision making from the owners in the future, but for now I simplified it - every new business is aiming for a profit margin that will make it pay for itself within a certain time period (I think I have ti currently set on 21 days). Since nobody will open the same business with smaller profits, if the price is set at the lowest value that satisfies this profit margin, it is impossible for a new player to undercut it.

This fulfils the first scenario - with supply lower than demand, the price is set as high as possible while still not allowing a smaller new producer to enter the market. But the economy is crashing right now because this causes obvious problems for the ones that want to buy Stuff (to turn it into Other Stuff) but can’t.

As it is now, they have an option to buy unlimited amounts from “the dock” for a much higher (and fixed) price, but that just runs them out of business because the price is way too high. I set up this option up in order to avoid the chicken/egg situation at the beginning (no demand for Stuff means no factories will produce it, no supply of Stuff means no demand is created) but once businesses start using it excessively, it’s a good sign that something is wrong in the supply/demand chain.

If they didn’t buy extra Stuff from the Dock, they’d have to lower their production, which will ripple downwards and rather than reaching an equilibrium, it currently just makes everything close down over time and the economy simply disappearing, because the Stuff producers stubbornly set their output below the expected demand.

I’ll have to make sure the second scenario happens, at least for Stuff that’s really important. Luckily goods don’t decay and storage is free at this point, so burning the extras won’t be necessary.

[Klear]

Since I took a longer break than usual due to some other obligations in real life and then UDGJ2, I figured I should make a small “I’m still not dead” update. I won’t upload a new version at this time, though, as it’s still rather messy and there isn’t much to show off at this point. That said:

• I’ve half-implemented VR Lounges as the first entertainment building. Adding a new building type went surprisingly smoothly, but to make the peeps actually used them lead me to…
• Complete overhaul of decision-making and action queues:
  • There’s only one action stored for each peep instead of a queue. Further plans (such as walking several tiles and buying a meal) are stored using a newly written scheduler
    • This allowed me to get rid of the “hungry” and “tired” pseudoactions.
    • There’s also no longer a need to cycle through all peeps to find those without a current action, speeding up each turn
  • Peeps can check their schedule in advance to see if they have enough time for an action and, say, plan to wake up just in time to get to work on time based on the distance from their workplace.

There are still some issues with this system and some peeps often tend to arrive at work late (usually they oversleep), so I took the opportunity to make sure everything works if they do. While I want them to be on time most of the times, late arrivals for various reasons should defintiely be a thing at some point.

• Simplified possession of resources and thus trade
• Made production evaluation a bit faster and a bit more clever
  • Product stockpile is taken into account when calculating supply
  • Factories will now aim to produce more than the current demand and shut down temporarily if their supply can cover it
  • Future demand is calculated based on average production from the past three days (weighted towards yesterday) if possible
  • When forced to buy from the dock, a business can only buy bare minimum rather than blow a lot of money on expensive goods

These changes mostly fixed (as far as I can tell) the issues I’ve talked about in the last few posts. The economy can even deal with lesser production as some peeps oversleep, though the problem gets bigger and bigger as the peeps struggle to fulfill their basic needs and eventually some businesses go under because not enough workers show up for long enough. Eventually I’ll implement docked pay, overtime work and sacking to respond to this, but right now improved scheduling and making basic actions take a bit less time (especially walking) should be enough.

What’s next:

• I think it’s time to overhaul the map and replace the current placeholder system with a more advanced placeholder. The current map tends to get crowded too fast and the distances are way too long, especially for a space station. Instead of tiles each holding either a building or a corridor, I’d like to make a bunch of blocks, each with a corridor and a bunch of rooms at the sides. I might even implement a detailed view showing the exact peeps standing in the right place in the selected block, paving the road for eventual exploration by the player from the POV of the peeps.
• I’m seriously considering biting the bullet and implementing long-term planning and budgeting. Right now, everything is daily - rent, wages, production. I’ve been keeping things intentionally simple for now, but I’ve reached a point where doing this might actually solve some problems in business management (I mean, in addition to creating some completely new ones).
• There’s still quite a few “simple” things I’ve been wanting to implement for some time: beggars, thiefs, perferences (towards buildings and peeps), GUI improvements (especially help and log screens) and I’ve been toying with the idea of dumping all presets to an external file so that other people could mess around with them as easily as I can, though that last one has a pretty low priority.

Aaaand I’m moving the version number to -0.87. Done. That’s it.