Category Archives: production line

Battering the RAM

February 03, 2018 | Filed under: production line | programming

I had a bug in Production Line recently that made me think. Large factories under certain circumstances (and by large I mean HUGE) would occasionally crash, seemingly randomly. I suspected (as you usually do if you have a large player-base) that this must be the players machines. If code works fine of 99.5% of PCs, and breaks on the remainder…that seems suspicious. Once I managed to get the same save games to crash on mine, again in seemingly weird places, but always near some memory allocation…the cause became obvious.

I had run out of memory.

This might seem crazy to most programmers because memory, as in RAM is effectively unlimited right? 16GB is common, 8GB practically ubiquitous, and in any case windows supports virtual memory, so really we are talking hundreds of gigs potentially. Sure, paging to disk is a performance nightmare…but it shouldn’t just…crash?

Actually it WILL, if you are running a 32 bit program (as opposed to 64 bit) and you exceed 2 GB of RAM for your process.  This has always been the case, I’ve just never coded a game that used anything LIKE that. Cue angry rant from unhinged ‘customer’ who thinks it is something akin to being a Neanderthal that my game is 32 bit. Take a look at your program files folders people…the (x86) is all the 32 bit programs. I bet yours is not empty… 64bit is all well and good, but the majority of code you run on a day-to-day basis is still 32 bit. For the vast majority of programs it really wont matter. For some BIG games, it really does. Clearly a lot of FPS games easily need that RAM.

So the ‘obvious’ solution is just to port my engine and game to 64 bit right?

No.

Not for any backwards compatibility reasons, or any porting problems reasons (although it WOULD be a pain tbh…) but because asking how to raise that 2 GB RAM limit is, to me, completely the wrong question. The correct question is “Why the fuck are we needing over 2GB  of RAM for an indie isometric biz sim anyway?” And it turns out that if you DO ask that question, you solve the problem very quickly, very easily, and with a great deal of pride and satisfaction.

So what was the cause? and how was it fixed? Its actually quite surprising. Every ‘vehicle’ in the game code has a GUI representation. Because the cars are built from a number of layers, they are not simple sprites, but actually an array of sprites. The current limit is 34 layers (some layers have 2 sub-layers, for colored and non-colored), from axles to drive shafts to front and rear doors, windows, wing mirrors, headlights, exhausts and so on. Every car in the game may be drawn at any time, so they all need a GUI representation. The game supports 4 directions (isometric), so it turns out we need 34 layers X 2 sub-layers X 4 directions = 272 sprites per car. Each sprite needs 4 verts and a texture pointer (and some other management fluff). Call it 184 bytes per sprite, that means the memory requirements for any car amount to 50k per car. If the player has been over-producing and has 6,000 cars in the showroom then this suddenly amounts to 300MB just of car layer data.

So that explains where a lot of the memory comes from…but what can I do about it? I’m not stupid enough to DRAW all these all the time BTW, I cache them into a sprite sheet and when zoomed out I use that for single-draw-call splats of a whole car, but for when zoomed in, or when the sprite sheet is full, I still need them, and I need them to be there to fill the sprite sheet mid-game anyway. How did I reduce the memory requirements so much?

Basically I realized that although SOME vehicle components (car doors etc) had 2 layers, the vast majority did not. I was allocating memory for secondary layers that would never be rendered. I simply reorganized the code so that the second layer was just a NULL pointer which was allocated only if needed, saving myself the majority of that RAM. With my optimizing hat on, I also found a fair few other places in the code where I have been using ints instead of shorts (like the hour member of a sales record) and wasting a bunch more RAM. Eventually I ended up knocking something like 700MB of RAM in the largest, worst cases.

Now my point is… if I had just taken the attitude of many *modern* coders and thought ‘ha! what a dick! lets allow for > 2GB memory’ rather than thinking about exactly how the amount had crept up so much, I would never have discovered my own silliness, or made the clearly sensible optimization. Lower memory use is always good, as long as there isn’t a major CPU impact. More vehicle components can now fit into the cache, and be processed quicker. I’ve sped up the games performance as well as reducing its RAM hunger.

Constraints are good. If you have never, ever given any thought to how much RAM your game is using, you really should. It can be eye-opening.

 

 

Thats paraphrasing the great Ron Burgundy, in case its not clear… Anyway…

One of the main areas of game that is ‘missing’ from the current alpha build of my car-factory sim game ‘Production Line‘, is all of the high-end stuff that goes into real luxury cars. (By luxury I am meaning $100,000+) Right now it is very hard to actually make a car that you can sell for $100k without a huge markup, and although it can be argued that cars at that price range *do* have a huge markup, its not quite *that* crazy. Some of the things that spring to mind are probably high-performance engines (turbo etc, lots of cylinders, or multiple motors for electric cars), fancy bodywork such as gull-wing or falcon wing doors, and plush interiors. I’m currently thinking about the design of the ‘plush interiors’ stuff.

Although its probably declining in fashion, there is definitely a market in luxury cars for real-wood in the dashboard and other internal parts of the car, such as the area around the gear-stick (thats stick-shift for you Americans?). I am guessing that the price differential between a simple plastic dashboard like you find in most cars to a smooth polished and multi-layered varnished wooden dashboard is probably pretty massive. FWIW I used to varnish mahogany for a living. its harder than it looks, especially if you want that smooth-as-glass finish without a single blemish. Its all about removing all the dust. I digress…

A quick glance at the BMW configurator (UK) for the 740e saloon (about the right price range) shows me such options as ‘fineline wood high gloss’ for ‘included in price’ to ‘Eucalyptus smoke brown’ for an extra £995 ($1,373). Thats a nice handy nudge towards luxury pricing in my game! Wooden dashboards here we come.

Dashboards are just one thing, what about all that shiny chrome stuff you get in cars, surely that costs a bit too? Indeed it can. A pair of chrome wing-mirror covers for the Jaguar XJR (A stupidly slow and overpriced low-tech car for the money…but again…I am getting distracted) will cost you… £198 ($273). Even Aluminium gearshift paddles cost £389. its hilarious how peoples sense of perspective implodes the minute they buy a luxury car. Anyway, its amazing how many bits of a car you can cover in chrome, if you want to give it a ‘luxury’ feel, and I certainly don’t want to bore the player (and complicate the GUI) with a bazillion options, so I was thinking of just including a single ‘chrome fixtures’ upgrade for luxury cars in the game. I’m guessing $1,000 should cover it? I’m amused to discover both that Aston martin calls this stuff  ‘jewellery pack’ and that it doesn’t price it separately! haha. Its configurator is hilariously gratuitous.

The third option that I plan to add soon is that of interior lighting. The Ford ‘edge’ talks about ‘enhanced ambient lighting’. This is the stuff you dont notice until its gone, but it includes subtle lights in the foot-well by the pedals, the lights by the door handles on the inside, and those cool lights that gently fade in and out when activated rather than snapping on. Looking at the difference between models, I think some companies are charging up to $700 for a ‘premium ambient lighting package’.

So that gives us an extra $3,000 of new features to push up the price of our car. To summarize:

  • Premium ambient lighting package
  • Wooden Dashboard
  • Chrome fixtures

Thats the easy bit, where do we add these in the production line? Right now we have ‘fit dashboard’ which is part of the larger ‘fit accessories’ task. At the moment it takes 2.0 seconds of player time, but it has a number of additional options, such as ‘driver and passenger airbags, a heater, and touchscreen. This already can cause a bit of a bottleneck, so how about this as a solution:

  • Split the existing ‘fit dashboard into two tasks: ‘fit controls’ and ‘fit cabin options’. I can rename the original ‘fit dashboard to ‘fit interior’.
  • Set the wooden dashboard, chrome fixtures and premium lighting to be options under ‘fit cabin options’
  • Set the airbags, heater and touchscreen to be options under ‘fit controls’

The only problem with this would be that if I have the fit interior needing research to be split into two, that means you need to do this research AND expand the line slightly before fit heater & airbags and touchscreen become an option. What I *could* do here is to allow them to also be options under the parent, which should work AFAIK, but is something I have not done before. Would that be confusing? Hmmm.

So question one is does this work for everyone as a system to incorporate these new features in the production line. Wooden dashboard would require the new wood resource, chrome requires chrome, and ambient lighting would need sensors and light bulbs (also a new resource).

My second question on this is where these items should be researched. Wooden dashboards isn’t really a ‘technology’ so might it be something we can add to the design studio instead? That facility does become redundant once all the current body types are done. Or… is that going to lead to confusion? Also surely getting the right production processes to build a wooden dashboard surely *is* a sort of technology? Hmmm.

As always, thoughts and opinions are very welcome.

 

 

 

There are no comments yet

…So I ended up concluding that rolling those two bits of GUI together was not unanimously a good idea, but I think changing the car design one so those horizontal tabs became left hand side list items is a bit of a no-brainer so I did that:

I’m currently working on supporting toggling slot upgrades to be on or off, to allow more player control. I’m in a bit of a ‘usability’ mode where I’m making the game easier to use, and more welcoming, because its easy to get caught up into an Early-Access vortex where all you think about is expanding the game for people who already know how to play it.

However, that doesn’t mean that I am *not* planning a lot of expansion. I have some more music on order (yay!) and am getting all those untranslated strings sorted so that its a smooth translated experience in French, German and Spanish. I’ve also got some more artwork coming probably in the new year, for stuff like making your own air bags, some new machinery to make slots more distinctive, new animations, and some components like chrome and wood to make plush luxury interiors (plus cabin lighting!).

Basically Production line seems to be going quite well, which is just as well as I have lots of other stuff making demands on my time, mostly Shadowhand and Democracy 3 unicode. We have some teething problems with the windows build of Democracy 3 unicode, in that some fonts are not displaying right. We are aware of this and desperately trying to fix it ASAP, although the earlier build is now available as a steam beta option. We already have some thumbs up reviews in Chinese, which I take as a good sign, and hope to have an official press-release about Chinese Democracy soon :D

Shadowhand has been announced to the world recently, and will ship on the 7th December on Steam, GoG and the Humble store (oops…must set that up…) We have been promoting the game a bit on youtube, reddit and facebook, and our wishlists are thundering higher and higher. The more I play the game, and read peoples comments on it, the more confident I am that its going to do well. If you are wondering what I’m on about, you should go check out the game from the link below…

There are no comments yet

My car factory game currently has two separate dialog boxes launched by these two icons on the top interface strip in the game world:

The one on the left is the ‘car showroom’ dialog and it looks like this:

…and the one on the right is the car design dialog and it looks like this:

I have some design issues with the way this works, in terms of it being a nice logical and intuitive user-interface. Firstly, those two icons are not really distinctive enough to show that one means ‘the car market as it currently is, plus your showroom’ while the other means ‘design of your cars’. Secondly its not immediately clear why they are separate dialog boxes at all. There is some justification for having 3 buttons and 3 windows (market, showroom and designs) or a single one with 3 tabs called ‘cars’, but very little justification for the current layout. In addition, the car designs window is currently different dimensions to the showroom, which feels weird when switching between the two, and to further complicate the issue, clicking a design in the showroom dialog launches the car design window to show that model…

My gut instinct is that this is just poor design, resulting not surprisingly from the design evolving during the games development. Initially the showroom was a single window, then it got the market added as a new tab, and the overall design of this stuff has not been revisited with fresh eyes since it got added.

The problem with just changing it, is that existing players of the game are going to initially wonder what happened. I can put a note in the change-list, and mention it in my next blog video, maybe even have a first-run popup, but there is always the possibility that some players may prefer it the way it was. Of course the game is still in Early Access, so really players should be expecting that the design would evolve, and I think the majority would welcome the change, but its still something I hesitate to do without canvassing some players opinions.

For existing (or for that matter new or potential…) players, what do you think about changing this?  Would a single window (and thus button) make more sense?