Monthly Archives: October 2018

Lots of cool stuff in this update to Production Line, which will get further checks, tweaks and balancing before I roll it out to the main Early Access steam branch, GoG and Humble widget customers. Here is a list of all the features, and notes on the biggies:

[version 1.61]
1) [Feature] Loans can now be re-paid early, assuming you have the funds, at a penalty of 12 hours interest.

This was widely requested, and I kept putting it off because I felt that it would lead to an unbalancing in the games difficulty, but actually now I’ve tested it for a while I think I’ve got it about right and am glad its in there.

2) [GFX] Conveyors use less obtrusive graphics
3) [GUI] New screen for market analysis to show breakdown of demand, production and sales.

I find this new screen really helpful when playing the game towards the later stages when there is a lot to keep an eye on. I worry its not immediately obvious how it works, but I do think its a usability improvement for managing supply and demand.

4) [Content] New researchable upgrade & feature: large touchscreen.

To make it obvious some cars are tesla-level expensive, and some are more Ford Ka level… :D

5) [GUI] Vehicle design screen now hides categories entirely if there is only a single default option.
6) [Bug] Fixed design research queue bugs where you could adjust first and last items up and down, causing a crash.
7) [Bug] Fixed bug where the second-nearest import bay for each stockpile was sometimes calculated wrong, meaning inefficient routing. Also major route calculation speedup.
8) [Balance] Major increases in the cost and value of electric car batteries (large and small) and touchscreens.
9) [Balance] Increased the power draw and process time for making wheels.
10) [Content] New researchable feature: parking sensors. Now a pre-requisite before reversing camera. Fitted at bumpers.

Amazing we went so far without these, as they are getting so common now. Also handy to be able to add a new feature without requiring yet another resource as ‘sensor’ is already in there. Plus it gives some much needed upgrades to the bumper slots.

11) [GUI] Revamp of the ‘apply options’ screen post-research, which adds price category indicators and selective coloring, and new buttons to apply a feature to a whole category at once.

This makes things much quicker when you have 20+ designs, and you don’t really want to make a more nuanced decision other than ‘add this new widget to my expensive ranges’.

12) [GUI] Music and cruise control are now feature-categories, where the more expensive versions include the resources, value and features of the cheaper ones.
13) [Content] Self-driving! new researchable tech, new resources and feature category for high-end cars.

This is very late-game stuff and requires quite a bit of research, but then you should have expended your factory enough to have a good dozen or two dozen research facilities at this point.

14) [Balance] Boosted the impact on marketing campaigns on showroom visits by 25% to increase total market size possible with current campaigns.
15) [Bug] Fixed bug where sometimes the warning on the design screen about common or universal features missing would be skipped if the feature had a category.
16) [Bug] Fixed bug where changing the color of a car design could lead to duplicating the price slider GUI.
17) [Bug] Fixed bug where the correct price-category adjusted market value of a feature was not being displayed in a number of places.
18) [GUI] Double clicking a car in the showroom now launches the vehicle design screen for that car’s design.
19) [Content] New researchable vehicle body style -> The small van.

I’m so pleased we got this in. Its likely the last new body style,  and its a really cool one :D

Feedback on this new update is very welcome, and of course any bug reports for things I have no doubt stupidly managed to break with this patch…

 

There are no comments yet

I’ve sold games through yahoo games, Realgames, GoG, Steam, Iwin, the apple appstore, macgamestore, the humble store, and probably about a dozen minor ones I cannot even remember. Currently the ‘active’ ones, where I make literally 99% of my sales are:

Steam

GoG

Humble Store

Apple OSX store

Everything else is a rounding error. To be honest, those last two are pretty close to rounding errors already. I am about to release a few games on the new kongregate store, but after that I am doing some serious reconsidering of my strategy on this. The landscape has changed, technology and expectations have changed, developers options are definitely better, and its time to take a long hard look at the current system.

Basically any store of any consequence is trying to grab market share from steam. Steam had a VERY rocky start (younger gamers may not remember the absolute hatred and anger at the instability and clunkiness and inconvenience of steam on its initial release), but quickly rose to be the market leader. When it started accepting indie games, the premise was pretty simple: We take 30% of the retail price, and we provide a website to handle discovery, order-taking and fraud detection, demo and full-version hosting, automatic updates and some community features. Is this a good deal? And the vast majority of people thought ‘fuck yes’. It WAS a good deal, but 90% of the ‘good’ part came from exposure to such a huge audience. You could already get order taking, fraud detection and stats for about 5-10% from other companies, including getting the email addresses of your customers, depending how you haggled. Later, steam improved vastly on what it had to offer, as we got achievements, real-time sales tracking, trading cards, steamworks, a simpler (GUI-based) updating tool, better customisation of store pages, a steam-widget you could embed on your site, developer pages, and GUI tools to simplify setting discounts and participating in sales.

Debate goes on in 2018 as to whether this is worth 30%, because of the vast change in discover-ability on steam caused by the opening of the store to hobbyists and practically everyone. Thats an argument for another time, and not one that I feel is the most relevant to this blog post.

The real point of this post is to point out a pretty big discrepancy between the steam value-proposition (to devs) and that from other portals. Here is the headline:

Unless you are offering ALL of that, AND something new or better to make it worth my while, and probably throwing some swag my way, why the fucking fuck would I give you 30% of my hard earned income?

Chefs at Steam Dev Days cooking free food for devs

Chefs at Steam Dev Days cooking free food for devs

The assumption seems to be that you can set up a store, do some minimal GUI design on it, put out a press release and expect to cash in your thirty percent of every game that the developers take the time to configure for your portal. I think that time is coming to an end. The thirty percent is arguable anyway, but unless you developer experience is BETTER than steam (and lets be honest, its really not), why on earth should you take the same cut?

Hell… even steam’s offerings in some areas are extremely low quality. The steam community forums are awful, with no WYSIWYG component, no real-time preview, very limited features in comparison to software like discourse (which I have here on my forums). The stats reporting is nice, but still nowhere near as fast as it should be. There is no really usable inbuilt player-metrics component in steamworks, no way to easily upload images of work-in-progress stuff to show off early access development on the forums, there is no tech support ticket system to allow us to give proper tech support to our customers, no notification of new reviews for developers… I could go on.

Valve can ‘kind of get away with this’ for a while… because they are the market leader. But new portals cannot. Valve also do the odd cool thing like steam dev days, or send people nice gifts, even chocolate, which is definitely appreciated. they meet up with developers and give them free drinks (also appreciated). This kind of thing actually *does* matter. The Humble Bundle guys and Kongregate do get that side of it, but I’m not sure others do, and even those two have a long way to go to offer true competition for steam. Try setting sale discounts for 20 different titles on the humble store. its not fun.

So starting with next year, and my *next* game (Democracy 4), I’m going to change my view when it comes to online game stores. The game will definitely come to steam, but if anybody else wants to sell that game, my attitude will very much be… Whats it worth to me?

It doesn’t JUST have to be money (although setting your cut noticeably BELOW 30% would definitely get my attention), it can be way-better community experience, way better stats and metrics support, an awesome tech-support feature, incredibly fast and helpful developer support, an annual expo where you wine and dine us, fuck it… free chocolate or bottles of champagne sent to my house. A free fucking T-shirt? Throw us developers a fucking bone. There is no magical law that means we have to be on your store. We cover 95% of the market simply by being on steam. lets see some actual competition for a change.

 

 

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:

 

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.

 

 

 

There are no comments yet