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

Improving the charts in Production Line

Although obviously a tycoon/sim game like Production Line *does* need some fancy graphics, a decent overall design idea (‘Run your own car factory!) and a fair amount of content, in the long term, to get players to really put in the hours, the quality of the game can come down to two basic things:

  1. Is the simulation nicely balanced to provide an ongoing challenge
  2. Does the player easily have simple, clear access to all the information they need?

These are the things that I struggle with, because I know how vital they are, and yet other than measuring the games retention, they are very very hard to measure to see if you are making improvements on a day to day basis. I can easily add another car body or some more achievements or some more maps, and quantify the change, but if I redesign one of the stats screen, do I *know* that made things better?

So this results in a lot of chin-stroking and thinking, and reading books on user interface design, and of course a lot of playing the game. The screen that I have recently agonized over is this one:

Thats actually the ‘simplified version, that takes it for granted you can tell what those little $ symbols mean (price range) and recognize the car body styles enough to tell sedan from compact, from SUV etc. That frees us some space so its not impossibly text heavy, but frankly its still a mess. The red areas are ones where we are not currently selling a car to that segment, and each block is a combination of a car body style and a price bracket. All the data in each block is self explanatory (I hope), but although all the *data* is there, being able to rapidly draw conclusions from it is really hard. I guess the spread of green to red gives you a very rough approximation of how much of the market you have ‘covered’, but is that really accurate given that compacts and sedans vastly outsell offroad vehicles, and in this layout, all car body styles have equal prominence?

This is my current attempt at a solution:

This ‘pie chart within a pie chart’ shows the breakdown of total customers visits to your store (not the wider market, which is accessed through more marketing…) and shows the extent to which you produced enough cars to satisfy all those customers in each price bracket. The different body styles have been assigned colors, and those colors are split into light/dark gradients to show the four price brackets within each body style. To ensure that is apparent, icons at the edges of each segment show the price range symbols for that segment. Because the segments are correctly sized for the number of customers, its much easier to see where the majority of the market is, and no longer do you confuse the relative sizes of the off-road and sedan market (for example). It also makes it clearer that in general the expensive and luxury markets are smaller than the others. Unresearched body styles are greyed out entirely.

Here is an example with all body styles researched:

The inner chunks that are more darkly coloured are used to show the percentage of that market segment you have produced cars for. So if you get 8 customers per hour for a certain body style / p[rice combo, and you produce 4 cars of that type (of whatever designs), then that segment will be drawn ‘half full’.

So far that sounds good, but there are three problems I am yet to resolve.

  1. When you produce too many cars (produce 9 when there are only 8 customers) that information is not shown.
  2. This shows car production but not sales. maybe I produce a car for each customer, but they are too expensive to sell to them?
  3. The player may confuse the relative shaded AREA rather than the radius of the inner chunk as being the relevant metric.

Almost all of this is clarified by the mouseover tooltip which explains everything, but thats a clunky fix. I’m thinking of adding an extra red ‘bleed’ segment at the circumference to illustrate any cases where there is overproduction. I’m also considering having selectable buttons at the top to toggle between this chart showing production and then sales, as they are obviously different stats.

Still… I think its certainly a helpful addition. If you want to see the current version of this chart in action, I just uploaded a new blog video with it in today:

 

Optimizing Production Line app startup

Yeah I know its not long anyway…but its 2018 and on a CPU this speed, why is it not virtually instant?

I just multithreaded the steam app_init so that stuff is effectively ‘free’ now, and its time to see where the rest of the startup time is going. My current measurements from AQTime:

Drilling into this it looks like the easy wins will be inside the Main Menu constructor, as the init3d stuff probably cannot be multithreaded, and involves a lot of disk-bound stuff while I load textures, which is really tough to speed up (I could turn on my pak file code, but I’ll probably only do that just before final release).

Sadly almost all of the main menu constructor code looks like its the loading in of a big png file for my menu background. This is a 2560×1440 png file that is 7.5MB on disk. This is big, but I load in WAY more graphics than that when I do the pre-load textures on all the cars, which are in dds format. I’ll experiment with shifting it to a DDS file. This *should* be way faster, as a png has to be converted whereas a DDS file effectively *is* in the memory format used internally by directx, so its just a straight dump into memory…

That *dopes* actually drop it down to 17.2% (from 21.73%). I suspect there is a further optimisation in that this is currently not a power of two texture, so changing it to be one (as a test) yields…

OMG. its now 1.54%. Resizing that texture seems to take insane amounts of time, and this change knocks 0.5 seconds off my startup time. The next candidate is my sound engine. Multithreading its startup code completely takes it out of the picture too.

MainMenu initialise goes from 116ms to 4ms just by converting a non pow-2 png to a pow2 dds file, and now things look like this:

Total startup time has shrunk from 2.5 seconds to 1.9 seconds. Nothing anybody will consciously notice, but it makes me happier :D. Plus I *do* think that subconsciously people do feel the difference. Snappy start-up times are great for games when you want to have a quick blast, and the perceived responsiveness is bound to make people feel happier about their experience with the game. Plus it means less CPU draw and less battery drain on laptops.

This is for my car factory simulation game Production Line, currently in early access.

 

 

 

The state of indie dev and why it will not get easier

I recently showed off my latest game production Line at a big UK games show (EGX), and not long after than, I took a trip (my first ever) to Boston to meet up with some Boston devs and talk to some nice people from valve. I also had a look around the local Boston indie games festival event while I was there, and talked to a bunch of indies about various stuff. In-between this I visited the Boston tea party museum, which you kind of have to do if you are very English and in Boston right?

Now I am finally recovered from jet lag, and back working on cool new stuff for Production Line, I have time to reflect on the indie scene as I see it now in September 2018.

I think this is a good time to do this, as a number of people are talking about this article about the reality of indie game dev, and there has also been debate about this article, about the experience of some fellow indies (who also happened to be next to us last year at EGX). Its probably also worth mentioning that Limit theory’s developer seems to have quit the project.

Anyway…

yeah its not getting any easier, and I don’t see any immediate reason to believe it will. In theory, eventually enough indie developers go bankrupt in a saturated market so that the self-correcting methods of capitalism kick-in, people realize that its no different to writing a novel (in terms of success chances), and the people who are currently ‘chasing the indie dream’ get jobs in banking or business app development. In practice it seems that indie development is still seen as attractive enough that there is another decade or so of new entrants coming in to replace every developer who drops out when their finances run dry. I really cannot see the ‘number of games released on steam this week’ metric dropping a lot in the medium term.

Another potential solution or equilibrium would be a more even and less hit-driven distribution of revenue from stores could make indie devs more sustainable at the margins. Every RimWorld or Prison Architect, of for that matter every PubG is making so many bazillions of dollars of pure profit, that if it could be distributed over 100x as many games, there would be a lot more solvent developers and maybe a handful fewer multi-multi-millionaires on steam. Arguably that would be a good thing, but not something I think you can really force.

Ultimately there a few forces that are naturally causing the current state of affairs to persist, and I dont think any of them are evil, or corrupt, or bad per-se, they are just the reality.

Force #1: people want this lifestyle so much they are prepared to take unnecessary risks. That means the price is driven down. Its simple supply and demand, and because many people are as happy to live on noodles as a game developer than they would be to apply the same skills to biz-app development at a $90,000 salary… then the average developer is going to see their wage driven down. Thats simple supply/demand economics and that is not going to change.

Force #2: Barriers to entry have dropped hugely. We can argue the pros and cons of the $100 steam fee, but the simple fact is unity and similar engines & asset stores mean its easier to make a game than ever before. That vastly increases the pool of people able to compete in the market.

Force #3: There is a massive skill disparity in the range of ‘indie’ game developers. This is the one that requires more explanation:

A really AWESOME bricklayer may be able to lay bricks at double the rate of a bricklayer who learned the trade last week. Maybe even three times as fast. Thats awesome. But a really AWESOME programmer is likely 40-50 or even 100x as productive as a newcomer to programming. It sounds like bullshit but its true, and the sad thing is, you really need to HAVE that much experience before you truly appreciate this reality. The same is likely true for artists.

If you are a newcomer to programming, think of all the time you spend debugging, the time you spend googling the answer to something, the time you spend refactoring, the time you spend on skype or discord asking people for help, and then remove ALL of it, and thats how it is when you have coded *that kind of thing* 10 or 20 times already. Once you know what you are doing at a certain level, programming is just typing. I can create new user interface code for Production Line pretty much at the speed I can type this blog post, and to be frank, using whole tomatoes improved intellisense, its actually quicker for me than typing English.

In many ways I am the *WORST CASE* scenario as a competing indie developer. I have 37 years coding experience, and 20 years indie dev experience. I learned to type before home computers even existed, and used to get a book and type out the text from the book on a manual typewriter *for fun* as a child. I’m married, and have no kids so I’m not constantly socializing or dating, and have zero distractions. I work from home in the countryside in a 100% distraction-free environment. I can afford the most comfortable chair imaginable, the fastest PC imaginable, I am healthy, I love my job, I have no boss, and no financial worries. Add to this… I have no major hobbies, I hate most TV, the majority of books I read for fun are about programming or business or marketing.

If you imagine designing a robot to take human form and churn out as much productivity as possible as an indie dev… its not *that* much better than me. The only things working against me are the fact that I guess I’m older than average so theoretically less energised? (I made a a developer blog video on Boxing day, so I cant see the lack of energy myself…)

Anyway my point is… I am your competition as an indie dev. You may not like to think like that, and I certainly like to be helpful to other indies, and encourage people, but the fact is, I exist and I’m making games 60 hours a week and I love it. I am not the only one. You are also trying out-code Chris Delay from introversion, Jonathan Blow, Jamie Cheng, Ryan Clark, and a bunch of other indies who have WAY more experience and WAY more technical ability than you (probably), simply because of age and time.

(This sounds horribly arrogant, but I’m not claiming to be any ‘better’ a person and certainly not innately any cleverer than anybody else. I’ve just done it a LONG time, and I am unusually single minded and focused. Essentially I’m tough competition due to time, age, and genes.)

..so what am i getting at here?

The excellent Lake Ridden post mortem includes this:

“35h work week. We measured the SCRUM points completed and was able to get the same amount of things done in 35h instead of the usual 40h. All while the stress number was staying the same or dropping. Everybody was actively encouraged to use this extra free time to see family or do exercise.”

Which sounds GREAT and I wish the whole world was like that, but unfortunately it is not. They are indie devs, and competing in the free market with the rest of us. I’m not working 35 or even 40 hours, and never will ( I am too obsessed with my games), and by mere fact of being much older and more experienced than that team, I have a huge advantage. You cannot legislate that advantage away, nobody can make a solo indie dev who owns the company work less hard. The playing field is NOT level, and its not going to be.

So whats my answer to this problem?

I absolutely accept that I do not have one. It is, simply put, really fucking hard right now, and probably always will be. Music, Writing, Acting, game-dev, they all suffer from this problem. Too many people want to do it for everyone to end up with a great lifestyle, working conditions and standard of living. I absolutely understand why people would like indie game dev to pay (on average) like a normal 9-5 job with normal 9-5 hours, but this is not about to happen, sorry. If you expect gamers to ‘pay more’ to subsidize better working conditions for indie game devs, ask yourself when you demanded the option to pay an extra amount to spotify to support indie musicians.

HUGE disclaimer: If you work for someone else in a big company like EA/Ubisoft/Whoever else, then absolutely you should NOT be working > 40 hour weeks. I ROUTINELY went home dead on 6PM from my jobs in AAA and never got fired for it. Similarly, if you are a super-experienced developer in those same companies then you should FIGHT LIKE HELL to get the pay you deserve. Absolutely some coders should earn 10x what other coders earn, and if they wont pay you that, leave.

TL;DR: Indie dev is really hard. The experienced devs have an advantage. This sucks if you are new. This will not change.

 

 

Chrome paint effect: Production Line

I now have a new shader in Production Line that gives a pure-metal chrome-style effect to cars in the game. Here is a car in the factory:

And here is one in the car design screen:

I like the look of these cars, and definitely will be including this in the game. Because the shader is different, it cannot combine with the ‘polished paintwork’ feature (or rather… the feature has no further visual effect), and for various reasons it simplifies things if this becomes an all-or-nothing option (so you can have a car model entirely in chrome, but not red or yellow or chrome at random). I am currently musing on the best way to slot this into the game./

Right now we have car colors as a purely aesthetic choice. they make no impact on the car price or attractiveness, or the time to paint, or anything like that. In practice, car colors can be set per-model (if the player chooses to), in order to make it clearer which are which on the production line. This is very helpful. Because I like this feature, I don’t think I want to start introducing different prices or demands for colors.

The only exception to this system is ‘polished paintwork’, which sticks the car through an extra slot, makes the car more attractive to buyers, and also changes the rendering effect so the cars paint looks much brighter, which is pretty cool.  To add to everyone’s confusion, I also have a mechanic where certain car colors are LOCKED and unselect-able until the relevant achievement is beaten and unlocked, which I thought was a nice way to incentivise aiming to beat the achievements in the game.

So now I suddenly have a new thing: Chrome color! How best to incorporate this into the game? I can see a number of options:

1) Leave it as shown above. it has a special button which enables Chrome, and selecting any other color will disable it. Selecting chrome means all other colors get removed, and now your car is chrome. Yay! Simple(ish) to understand surely?

2) Make chrome paint a feature, that has to be researched (yay! more design research!) in the design studio. Its then something that gets selected like ‘Polished Paintwork’ (probably make a new paint category for this), and can be a premium feature. I could have a new upgrade for the paint shops that does this, making those cars take longer.

3) Make it just another color (like 1) but also require an achievement to unlock it anyway. We already have a UI to show color options as locked/unlocked so I can re-use that.

As I type this out I am aware that I am leaning towards 2). I want more reasons to keep the design studios around, and to be honest this would be a good point to move that ‘polished paintwork’ stuff into the design studio anyway? I can see a new design category on the design screen like I have for wheels, and power-train, that has ‘Standard paint / Polished paint / chrome’ as 3 different options. This keeps things working within existing game mechanics and should be easy to understand right?

I’m still recovering from showing the game at EGX. It was fun, and beneficial but also pretty hard on my elderly aching feet…