Category Archives: production line

Production Line Updated to 1.68

February 28, 2019 | Filed under: production line

This is the last feature-update before we come out of Early Access. The next week is likely to just be bug fixing and usability/UI tweaks and fixes. Here is the list of new stuff:

1) [GUI] Changed vehicle renaming so it doesn’t annoyingly add (1) to a duplicate name until you leave that screen, to prevent driving people MAD.
2) [GUI] Component prices on the finance screen can now be sorted up or down by either name or price.
3) [GUI] Added remappable shortcut key (B) to toggle blueprint mode.
4) [GUI] Redesigned layout of car design screen to accommodate longer languages.
5) [Feature] Added Swedish translation and improved others.

6) [Bug] Fixed bug when adding items to a supply stockpile where some categories would occasionally not be shown.
7) [GUI] Smart junctions now retain their list of designs when switching in/out of design mode, and also add new designs to the default list.
8) [Bug] Fixed crash bug when moving existing paint drying slots.
9) [Feature] You can now move supply stockpiles, and they keep their configuration when moved.
10) [Bug] Fixed bug where if you changed floor textures under office space, then moved existing office facilities, the default office floor texture was not re-set.
11) [Feature] Added researchable make electric motor and make electric powertrain slots.
12) [GUI] Canceling a slot or facility movement action snaps the item back to its old location.
13) [Feature] You now get a brand awareness boost of up to 20% automatically if you have high number of sales over the last four hours.
14) [Bug] Moved slots now remember their import preferences.
15) [Feature] Telling a supply stockpile to copy a specific task’s requirements now links it, and it auto-updates to account for new research. Any manual change to the slot breaks the link.

16) [GUI] You can now place down conveyor belts as blueprints.

17) [GUI] The production schedules at the start of each line are now saved if you move that slot.
18) [GUI] Slight gradients on the vehicle design price slider now mark out the different price ranges.
19) [Content] Some new items have been added to various slots, to show gantrys, dashboards, shock absorbers, speedometers,automated platforms & scisssor lifts.

Hope you like the new stuff. feedback most welcome, as are bug reports, we really want a bug-free emergence from Early Access. Many thanks to all your support while the game was in EA. Suggestions for future updates also welcome. if you like the game, bought it from steam and have not yet left a steam review, it is much appreciated!

Only part of the ‘true cost’ of producing a game is the narrowly defined ‘development cost’, as it should also theoretically include an allowance for ongoing studio costs over the lifetime of making the game. The cost of heating my home office, the accountant, the webhosting for all my sites (including this blog) and depreciation of my PC should all play a part in calculating the *true* cost of producing Production Line. (My car factory strategy game for the PC).

With this in mind I thought I’d briefly add up some estimates of the paper-cost, the estimated cost if I was paid a regular salary, and also the true, true cost.

So the basic cost, if I break it out into categories gets me a breakdown like this:

If I assume as lead programmer I should be earning £60,000 (first result I found. Note that I’m the only coder and have 20+ years coding experience), then things change a lot to look like this:

Then I need to add in the office costs. Firstly I’d get a pension as an employee, so I should add that in over the dev period (3 years of contributions), 3 years of accountancy, 3 years of webhosting, and as I replace my PC probably every 4 years, I need to allow for 3/4 of a new desktop PC. I also have 3 years of office internet and phone bill to include. There is stationary, heating and other bullshit, but lets just call that $200 a year. New chart:

So is anything learned from this short little exercise? Well there are many ways to interpret it. Firstly, It really looks like I may be undervaluing music and SFX in my game. Surely combined they should be more than 5% of my dev budget right? And translation, although the costs scare the fuck out of me, actually seems relatively small in terms of the big picture.

It also brings home just how important personal productivity and time management is. If I messed around on twitter less, got distracted less, and maybe got up a bit earlier each day, a 10% increase in my productivity would have a massive impact on overall costs, probably saving me enough to make a huge boost to the art budget.

It also shows me that trimming the art budget if the game is not doing well is absolutely the wrong target. Its all about the code.

And finally its worth keeping an eye on the external dev costs such as webhosting etc. Each item is small, but together they are virtually the same as the art budget. Also worth noting: I deserve an absolute monster PC every 4 years, thats for sure. Even if I doubled the price I pay for a PC, the faster compile times would probably pay for themselves.

I updated the version of the game today to build 1.66, on Steam, GoG and the humble store / direct. The latest update is 1.66, a build whose major feature is the introduction of the late-game ‘world events’ feature. That was THE feature that I was determined to get in before I could describe the game as feature complete. it may need some tweaking and balancing, but now its in, i’m calling the game ‘beta’. You can read the full list of changes in this version on the forum here.

There will still be a good few weeks of tweaking, adjusting, balancing and checking before we actually take the game out of Early Access and declare it ‘released’. And even when that is done, its very likely that I will continue to spend a decent amount of time of improving and balancing the game. I don’t have any firm plans for expansions yet, but I’ll have time to think about it, and to ask people what they might like to see.

Production Line is the first game I’ve every released in early access on steam, although I’ve done low-key betas before (Big Pharma was one). I definitely have enjoyed the EA experience, but I think it could possibly be facilitated better within the steam platform…

I used my own system to gather data from players within the game to find out what the player-base thought my dev-priorities should be. I also had to use the ‘artwork’ upload part of steam a lot to share screenshots of stuff that was a work-in-progress or ideas for improvement. TBH it felt clunky, and not fleshed out.

There is also no way to tell (without collecting your own data) how many people have played a beta build on steam, making it a bit tricky to know that the ‘unstable’ branch had got enough testing before rolling out changes to everyone else.

Anyway… Its been great fun, and a lot of effort (and time!) has gone in. I even got into the habit of doing almost-every-week video blogs to document work on the game, here is the latest one:

I’ve really enjoyed doing those too, and will probably do a few more to highlight any post-release tweaks and ideas for expansions that might crop up after the game leaves early access. After that, it would theoretically be time to think about what game I would work on next (or consider ports of PL to other platforms). The thing is, we already have Democracy 4 in production, and as that gets closer to its initial Early Access (or even pre-EA), I’ll need to devote more time to producing that.

Finally its worth mentioning that the price of Production Line will go UP before release from its current $19.95 to $24.95. I’ve pencilled that in for 12th February, so if you were considering buying the game at some point, don’t wait too long :D And yup, we get the biggest cut of the money when you buy direct:

There are no comments yet

For the last year or so I’ve been employing a pretty ‘passive’ approach to promoting my current game Production Line. By this I mean that I have primarily concentrated on posting on my own forums and the steam forums, posting weekly video blogs, and cross posting those to the forums, reddit and my production line facebook page.

In a sense, all of that is basically preaching to the converted, as if you follow me on youtube, are subscribed to the reddit, or a fan of the facebook page… well you already know about the game and very likely already bought it.

The only way in which I am actively reaching beyond the current audience is by some facebook ads, but obviously the cannot reach everyone (loads of gamers don’t even have facebook accounts). We don’t have any more game shows coming up for me to meet youtubers and press, so apart from facebook, to the outside world I’m pretty silent about the game.

I should probably get used to changing that as the game eventually shuffles towards release (probably January next year?). With that in mind, I think I’m going to set aside some time next week to build up a proper list of youtubers to get in touch with, and put together a proper updated press release with new screenshots and information. The game is now on Kartridge and the Humble Store, so that definitely needs updating.

 

Of course the trouble with any *active* promotion is that it involves my time. The blog posts, video blog, tweets and facebook posts already take up a big chunk of time, and I’m busy coding the game as it is! Unfortunately I don’t have any *easy* way to outsource any of this work. It is *me* in the videos after all, and even if I could record the video, then pay someone else magically to disassemble my green screen, render out the video (only 2 mins editing normally needed), upload it, cross-post it and so-on… its only likely saving me 30mins-1 hour a week anyway. Thats also the fantasy scenario where someone beams star-trek style to my house to assist me, then beams out immediately.

SO I remain, after all these years both the code AND the marketing/PR/Biz bottleneck for my company. I have a horrible feeling that if I *did* ever expand further, code would be easier for me to outsource the rest of it. I’ve tried outsourcing PR a lot of times and never made a decent ROI (or even a positive one).

Food for thought.

There are no comments yet

So my recent adventures in the land of code have taken me to port Production Line to 64 bit. The current 32bit build only allows me to access 2 GB of RAM and although even super large factories can fit in 800MB now, when you really pack things in and put the hours in, it *is* possible to hit 2 GB. With modding & any possible post-release expansion possibilities, there is arguable a need to remove that limit and so here we are.

I’ve basically done 2 days(ish) work on it, and have a release build and debug build 64 bit version of the game that seems to run just fine. It was relatively painless. The 3rd party stuff I use is mostly, Steam, some sound middle ware, Directx and an intel profiler, and all of this has 64 bit support, so the majority of the work has been going through the config for the game and changing include folders and paths to point to 64 bit DLLs and Lib files.

This has been complicated a bit by the mess that the Visual Studio (2013) software makes out of configurations. I can have a debug64 project config that then has the platform set to 32bit, and then god-knows where the exe gets put or which files get compiled and oh-my-god how messy. I think I have finally got close to getting it straight in my head, although I have ended up hard coding exe names and paths and may have to even rename my engines lib file to engine_64.lib to make ABSOLUTELY sure that it is not using the wrong lib file and thus mix-and matching.

I can totally see why people do not want to support both 32 bit and 64 bit versions of the same game, especially given the fact that, unbeknown to me, the mere *existence* of a 32 bit dll in the exe folder will seemingly stop my 64bit .exe launching. I guess you end up with separate folders? What a pain.

In terms of code, it was almost entirely painless. As I suspected, my one pain point was my GUI code for buttons. I have a base button type that takes a function pointer called BUTTONFUNC to execute when clicked. I cannot remember far enough back to work out why, but generally I end up passing an objects ‘this’ pointer as an (int) to the constructor for a button, if I want the button function to access it as data. So I end up writing code like this:

PCheckFree = new GUI_CheckButton(TRANSLATE(“CHOOSE_MISSION_FREEPLAY”), Freeplay, (int)this);

And then in the code that receives it I’d do this:

void GUI_Scenario::Freeplay(int data)
{
GUI_Scenario* pwin = (GUI_Scenario*)data;
pwin->SetType(SIM_Scenario::FREEPLAY);
}

Which is perfectly fine and lovely, assuming pointers are 32 bit and an int is 32bit. However, it turns out that porting to 64 bit is as simple as just replacing both users of (int) with (size_t) which varies based on platform, and voila! problem sorted. I expected this to be the first step in a whole world of nightmares,, but although I have not done serious testing yet, it appears to launch, run and allow me to load in massive save games, so I reckon I’m 95% of the way there. All I need to do know is investigate how all the various stores (Humble, Kartridge, Steam, Gog) handle multiple versions (64 bit versus 32 bit), to ensure I’m not leaving the tiny 32bit minority behind. I guess eventually that will not be an issue.

I’m definitely happy that this seems to have gone smoothly, as it amounts to days of coding and admin and investigation which are essential, but doesn’t make the game noticeably better for players, which is always a worry when the game is still in Early Access. Fun fun fun…