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

Production Line GUI usability issues

Posted on September 5, 2017

I have been turning my attention recently to improving the usability and intuitiveness of the design for Production Line. I run some ads to promote the game, and have to assume a bunch of people buy it and play it without ever seeing me or anyone else play it in a video, have not read about it anywhere, and are relying purely on the in-game tutorial. Of course tutorials are all well-and-good, but ultimately the aim has to be to have a game design and GUI so intuitive that it just feel obvious to the player and they don’t get frustrated or stuck.

The next update (1.31, coming tomorrow with any luck), comes with a whole bunch of cool usability improvements. Supply stockpiles and new car designs now copy all existing options, which makes them much more useful features. there are some pricing and production hints on the sales matrix, and a host of other things. I have identified 2 small areas that I think are still confusing and want to improve upon…

The first is the interface for choosing which cars to produce. Basically the game starts with just one design, and only when you have created extra models do you need to worry about this. To edit the ‘production schedule’ you need to go the the slot at the very start of the production line (there may be several lines), click it to launch its details screen, and then notice the new button that gives you access to this feature (which is then relatively well explained).

There are several problems here:

  1. The player may not even realize they need to do this, and assume the cars are equally produced.
  2. The player may have no idea where the start of their line is, at first glance.
  3. The player may not spot the new button even if they do click on the start of the line.

There are a bunch of solutions to this. Firstly, I could stick a big fat warning on the car design window, along with a new stat showing production last hour, alerting the player to the fact that no production of this car is currently scheduled. Maybe add a tooltip on there explaining what to do to get to the production schedule screen?

Secondly, I could have a permanent icon floating above the start of the line indicating this is where the production scheduler is, and maybe double up as a button that launches the scheduler for that slot.

Thirdly maybe I need something more obvious than just a text button, something with icons, and which draws the players eye much more on that slot window? Just a button with ‘Change’ on it is kinda awful :D

Thats just the first usability issue. The second is a problem relating to missing features on cars, something that is very badly communicated to the player. The player selects which features should be applied to each of their various car designs, with some getting tons of them, and cheaper models getting few. This means that at a slot such as ‘fit wheels’ some cars will get alloy wheels, some will not. Thats fine, but sometimes the player gets out of synch, and researches the ‘alloy wheels’ tech, applies it to some designs, and then forgets to upgrade all the slots that fit wheels. (Or at least all the ones the expensive cars go through).  We currently have yellow text in the showroom for cars which have ‘missing’ features, but it makes absolutely no distinction between features missing because the cars production pre-dated this feature (old stock), and ones where there was a screw-up and a feature got missed.

Ideally the screw-up should never happen, but I’m wary of stopping the whole line when this happens. That may be confusing, and will need explanatory GUI anyway. However, it may be the best option. I could reserve that yellow text just for stuff which was really missed, and maybe leave it in white or labelled differently for stuff which is just ‘old stock’. That would at least distinguish between the two. I guess I could also have a popup on the vehicle as it goes around the factory to show a missing feature, so the player notices this before it gets as far as the showroom (by which time many poorly-configured cars have been made).

I’m still musing on the best solution to this.

A heads-up on future stuff. I will ship 1.31 this week, then I’m away for a week from Sunday, and just after that will have a booth at the EGX show in the Birmingham NEC in Birmingham UK. Please do come along if you can and say hi, or try the game (if you dont already have it). press interviews most welcome!

I guess I should point out to any new readers that Production Line is in Early Access on steam/GoG and direct from us. its $15.99 and you can grab a DRM-free copy, together with a steam key from the link below…

Academia: School simulator

Posted on August 31, 2017

Squeaky wheel, the guys who made Political Animals (which I published) have a new game coming to steam early access in a few days. here is the trailer:

And here is the store link.

http://store.steampowered.com/app/672630/Academia__School_Simulator/

Hope you like it :D. I think it will do very well indeed… if you think ‘oh itts that same style for art everyone is cloning’ then…well yeah, that’s ryan’s art. he did the artwork for Prison Architect which started all this, so he gets a free pass :D

Stressful week

Posted on August 27, 2017

So I had some bugs in stockpiles, and I tried to fix them, and it got more and more tricky, and eventually yesterday I had a bit of a code epiphany and this morning I deleted hundreds and hundreds of lines of code and wrote a few dozen new ones and now finally seem to have a stockpile ordering system that does (as far as my testing can see so far today) everything I want it to.

It was pretty stressful trying to fix it, as when i have buggy code I cant fix, it really does bring me down. So last night I was typing away in visual studio, occasionally with my head in my hands after a bottle of wine, quite late, and quite depressed/annoyed thinking…

“Why the fuck do I try and make such complex games to such a punishing schedule. Why don’t I just do some buy-to-let properties and retire like any sane person…”

Luckily I feel tons better today, but its important to note that people tend to only turn to social media to talk about game development in a good mood, and its not all roses. so there..

On a happier note, here is todays’ video blog :D

Coding post: Prop pre-draw optimizing. Thinking aloud.

Posted on August 24, 2017

Typing out my thoughts often helps.

Production Line has lots of ‘props’ (like a robot, a filing cabinet, a pallet, a car window…). They could all be anywhere on screen. They are however, all rendered in a certain tile. I know with absolute certainty if a tile is onscreen.

Before actually rendering each prop, I ‘pre-draw’ it, which basically means transform and scale it into screen space. I do this on the CPU (don’t ask). To make it fast, I split all the tiles into 16 different lists, and hand over 16 tasks to the thread manager. In an 8 thread (8 core) setup, I’m processing 8 props at once. I allocate the props sequentially, so prop 1 is in list 1, prop 2 is in list 2, and looping around so i have perfect thread balancing.

Its still too slow :(

Obviously given the tile information, I can just ‘not transform’ any prop that is in a tile that is known to be offscreen. I already reject this early:

void GUI_Prop::PreDraw()
{
if (!PTile->IsOnscreen() && FallOffset == 0)
{
return;
}

But the problem is I’ve already made the function call at this point (waste of time) and checked IsOnscreen (a simple bool…but still…). Ideally this call would never happen. A tile that is a stockpile with 16 pallets and 16 door panels on it has 32 props. Thats 32 pointless function calls. Clearly I need to re-engineer things so that I only bother with this code for props that actually are in a tile thats onscreen. That means my current system of just allocating them to 16 lists in a roundrobin fashion sucks.

One immediate idea is to allocate them not as props at all, but as tiles. That means my proplists would be a list of props (each of which can iterate their tiles) and means at draw time, I’m only checking that PTile->IsOnscreen once per tile, rather than up to 32 times. One problem here is that a LOT of tiles have no props at all, but I can fix that by only adding tiles to the list the first time a prop is added to a tile. To be really robust, I’d have to then spot when a tile was clear of props and call some ‘slow but rare’ code which purges it from the appropriate prop list. That can be done in some low priority code run during ‘free’ time anyway.

I’m going to undertake a switch to this system (its no minor 20 minute feat of engineering) and then report back :D

 

Ok…

well I *think this increased speed by about 50-80% but its really hard to be sure. I need to code some testbed environment which loads a save game, then spends X seconds at various locations and camera positions in order to have reproducible data. The speedup depends vastly on the zoom level, because its basically saving a lot of time when a LOT of the factory is offscreen, but introduces maybe some slight overhead in other circumstances, because there are now 2 layers of lists to iterate. the tiles and then props-within-a-tile. When zoomed in, thats still vastly fewer function calls.

Also it really depends on the current code bottleneck. The code is multithreaded, so potentially 16 of these lists are being run at once. If the main thread was dithering waiting for these threads to complete, this speeds things up, else nothing is gained. My threadmanager hands tasks to the main thread while its waiting so hopefully this isn’t a concern. I shall await feedback on the next builds performance with interest.

 

An indie game developer posts about introversion

Posted on August 21, 2017

Ha. Thats me just being funny in a way that will mess up Chris & Marks SEO efforts :D

But seriously…

I’m reading a cool book, called ‘Quiet‘. Here is an exciting screenshot of the cover!

I’m about 50% through the book, but feel motivated to mention how good it is. Normally I’d post stuff like this to facebook, but meh…do I really want to be monetised, scanned, aggregated and catalogued just because I like a book? Anyway. This book is pretty awesome. its basically all about introverts, what is feels like, why its not a bad thing, how you get treated by other people, and most interestingly, it raises awareness of how society treats introverts.

I’ve never really thought about it before, but there is an implicit assumption that extraversion is good. When you see someone who is loud, confident, shaking hands, smiling, hugging people and laughing, you assume they are good people, worthy people, people who are going places, high achievers, people you can trust…blah blah. Almost all politicians are extraverts, they shake tons of hands, do the proverbial kissing of babies, they speak confidently with no equivocation, they often have louder voices than normal, they never, ever shirk from public appearances…

This book makes it clear that this can be *really bad*. Some problems (like climate change) are best dealt with by people who are quiet, reflective, deep thinkers. It brings to mind the old joke that ‘we must do something! this is something! lets do this!’ which is pretty much the attitude of most politicians, and the cause of many a poorly thought out law or economic policy.

Of course, not all walks of life are as obsessive about extroverts as politics, but the entertainment industry and games is definitely one in that general area. To succeed 9we are told) one must go to games shows, shake hands, talk to everyone, be confident, be outgoing, be personable. Go to all the GDC parties, and meet new people! Walk up to journalists and pitch your game to them! Practice your elevator pitch!

Yikes.

Thankfully this good will make you feel good, happy, content to be an introvert. It will also open your eyes to the very low-key preference for extroversion in the media. In my own tiny, tiny way, I am trying to support introverts by not being stupidly LOUD AND EXCITABLE when I do my video developer blogs.  My part in the great war :D