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

The myths perpetuated by startups about themselves.

Posted on March 18, 2017

This blog post was partly inspired by this story, where a business decided someone did not fit their corporate culture because she asked how much she would earn. Yup, let that sink in for a minute, and lets talk about the myths that a lot of tech startups perpetuate, that are complete and utter nonsense.

Myth #1: Forget your salary, its all about the exit strategy!

There is a myth that every ‘startup’ is the next facebook, or twitter, or snapchat. As a result, you should not give a damn how hard you have to work or what you earn. Living on peanuts and sleeping under your desk is frankly an honour, and you will get to write a book about it one day on your yacht, after the company IPOs and you get your share of ten billion dollars. Thats the myth. The likelihood is that you will either burn out long before then and have to quit, that your significant other will leave you and you will have a meltdown and get fired, or far, far more likely: it turns out that making a toaster that connects to the internet isn’t actually a billion dollar idea after all, the company burns through cash, crashes and burns and everyone gets a tweet informing them they are unemployed.  In the idea is really good, it will raise some money, if it raises money, it can pay its workers.

Myth #2: We are the brightest and best in the world!

No you aren’t. You are probably a bunch of relatively well off middle class white guys from California who read a lot of books about steve jobs and now think you are a genius because you understand a bit of java. Whoopy do. Unless the company is Deep Mind, and a bunch of you have phds in artificial intelligence, or maybe quantum physics, and unless you have a few people with nobel prizes and fields medals, you are NOT the brightest and best. And frankly, that would be deeply embarrassing. if your startup does contain ten of the cleverest people on earth and you use those collective skills to develop a bluetooth enabled cat feeder…then what a terrible, insulting waste of your vast abilities. Get some fucking perspective.

Myth #3: Get users now, revenue will follow!

Really? Ask twitter how that went, or maybe myspace. Having a lot of users just means a lot of server costs and admin. The point of a business (and I feel it sad that anyone has to type this) is to make profit. Note that the word is profit, not revenue, which is totally different. Its amazing how many people think that a big userbase automatically generates revenue ‘somehow at some point’. Ask ANYONE in the games business if you can just bolt on Free-To-Play to an existing game, and they will laugh you out of the room. NO is the answer, you need to build that business model in right from the start. This is common sense, but companies like twitter and snapchat ignore it. Building a vast network of people who love your service because your service has no ads….yeah thats not going to be easy to monetize is it?

Myth #4: Our company is just like amazon. We will get big fast.

Well done, you have learned a buzz-phrase, and totally failed to understand the underlying business model. Amazons get big fast worked because they had an actual business model that they knew made a profit AT SCALE. Selling over the internet is highly profitable, and the economies of scale are vast. This does not apply to snapchat or instagram or twitter etc Amazons system had to be big because ‘every book in the world’ was compelling, and because books sold for MONEY. You can waffle all you like about how your business model has network effects, but unless there is a statement at the end of the company business model explaining where the profit comes from, its just a fortune cookie. The only thing that will get big fast is your debt.

Myth #5: We are making the world a better place.

Fuck you. Fuck you and the horse you rode in on. Do you know how a business can make the world a better place? by creating quality long term jobs that pay decent salaries and benefits. By contributing to the local community. By building things and solving problems that make society better. By paying their god-damn taxes. By setting an example of fair treatment to their employees, and ensuring a welcoming business environment for all races and genders and backgrounds. If your idea of making the world a better place is making billions of dollars so you can become another internet cliche with your bright orange Lamborghini and a swimming pool, then do us all a favour and just give up now.

Wow, that was angrier than I thought it would be. :D

I’m still shorting snapchat. YMMV.  Pics are from the televisual genius of HBOs Silicon valley.

 

New Production Line car design interface

Posted on March 14, 2017

When I initially designed the Production Line ‘car design’ system it sounded like it made so much sense. Cars were a list of ‘features’ such as ‘electric windows’ etc, and whenever a car came to be sold, we would see if we had sold a car with that list of features before or not, and if not, we popped up a dialog box asking the player what to call this design and how much to charge with it, along with information on the market value (fair price) for that combination of features. This seemed perfectly reasonable.

The problem is that a) there are about 999,999,999 permutations of features and b)actual cars arent really sold that way anyway.

If you buy a car, you decide to buy (for example) a Vauxhall Astra, and then you decide which options you want, effectively from a price-list of add-ons. Usually car companies bundle a set of features together as certain ‘models’ such as ‘deluxe’ or ‘GT’ or whatever, but essentially there is a base body design and a price list of features to go on top. In order to reduce the amount of pointless GUI and busywork in Production Line I decided to switch to a similar model for patch 1.13.

Now we have a new button in the GUI, which launches the ‘design browser’ in the game which shows you all of the actual properly different body types of cars you currently produce. (for now its hacked showing designs from an earlier version, so they all have the same body type, but for new games you will only have one here for now). That window lets you select which car design you want to view or edit.

That then brings up this new window, which will also pop-up when you produce a car for the first time, or when you ship a car with a feature that was not previously available in this design. (That should happen only when you have researched a new upgrade and then shipped an upgraded car).

This is where the GUI gets a bit confusing. Essentially any design is just a shopping list of features with the base feature being ‘basic car’. For each feature you can see the market value of that feature (the consensus in the market place for the fair value for one of those), the price you are currently charging, and the markup over the market value in both percentage and dollar terms (with buttons to adjust this).

You can price cars at a premium to earn higher profits, or a discount to shift them quicker. This is where the confusion will come..

This does not represent a hard profit or loss for that car.

because there are so many fixed costs, its very very hard to work out how much each feature really costs you to add, so you have to separately keep an eye on what that feature is costing you. The premium/discounts here are only a guide as to how competitive you are with your rivals, who may be more or less efficient than you. My big dilemma here is how confusing is this? and is there a better way to explain/present it? Obviously there will eventually be a tutorial.

I also think that probably what I need here is some option to copy a single premium/discount to all features, so you are not adjusting each one manually. I’m not sure of the best way to present that from a GUI POV. In terms of ‘why would you ever not want to do that?’ consider this: You rush ahead in the early stages of the game to research cruise control before anybody else. As a result, you have the ONLY cars with cruise control. You can therefore charge a whacking great premium for that feature, way above the premium you would charge for other car features.

Does that make sense? Is this an improvement on the old model? Feedback most welcome. This is hopefully going into the 1.13 patch coming this week. maybe even Wednesday! (more likely Thursday).

BTW don’t forget the price goes to $12 from Sunday. If you know you are going to get it anyway, order it below :D

New Production Line Blog Video

Posted on March 12, 2017

I missed two weekends of doing these due to GDC but worry ye not, I am back working on the game with a vengeance:

I currently have a minor routing issue with the new sped-up code, but I’m getting closer to squashing it. The next big change to the game will be design pricing, and after than its likely to be some new components, machines and slots. New cars hopefully next month.

 

Major code speedup. Big factories ahoy!

Posted on March 11, 2017

I recently got sent a HUGE factory in a savegame for Production Line. It has over 600 production slots and 24 resource importers, and its MASSIVE. Here are some screenshots:

Despite its awesomeness it was MASSIVELY slow. Not only did loading it take forever, but whenever you changed any of the resource conveyors the game would hang for about 20 seconds. hardly ideal, especially given that I have an 8core i7 PC. So I set to work trying to optimize the code. I did some fairly small optimisations first, which boosted processing by 12% but I needed more fundamental re-design.  After chatting to a fellow indie coder, I agreed that my currents system of always calculating the optimum route to everywhere, for everyone, when something changed, was clearly not viable. I switched over to a new system of ‘lazy’ computation. Basically when I change a route somewhere, it now sets a flag on every production slot saying ‘you should recalculate your nearest slot soon’. That flag gets checked every frame, and sometime in the next 120 frames 92 seconds) each slot will calculate the route from its location to all the importers, and store the nearest two. It needs this so slots seem to import from a sensible location, as opposed to an importer that is miles away.

This was good, and sped things up a LOT. Now instead of hanging, the game would stutter for about 10 seconds. better but nowhere near good enough. I then realised I was doing something seriously dumb. I was going through all those routes I calculated, and picking the nearest, THEN doing it again, to pick the second nearest. doh! This sped things up, but in retrospect, it was trivial, it just alerted me (alongside my profiler) to the fact that when I tried to get (for example0 15,000 routes, I actually calculated 30,000. How come?

It turns out that the code that multithreaded all of the ‘calc the routes’ code, was not storing any of the results, so the code that came after it which then went through the (not saved) routes to pick the nearest ones was having to recalculate them anyway. I was essentially doing everything twice.l Worse…this second bit of code was single threaded, meaning all my multithreaded time was wasted and all the work happened in a single thread. What a dork.

A nice simple change to the code to make sure those multithreaded route calcs are actually stored *doh* means that not only did the processing time half, it now gets split over potentially 8 cores instead of 1, so on my PC its now running 16x faster. Combine that with the earlier speed-ups and its likely 18x faster, and because of the frame-spanning over 120 frames, it *feels* fluid as hell, even on insane maps.

Here is the concurrency visualiser showing the loading of the insanely big map.

And here it is zoomed in showing the multithreaded bits.

Those gaps are because each slot makes a single-threaded call to evaluate all of the import bays (each colored block is the code to get a route from one import bay to one production slot), and that call (in the main thread), then spreads it over the worker threads. Ideally I’d find time to eliminate that single thread blocking. Also I have some gaps in there because the end of each threads Calc() has to use a critical section lock to deposit its new routes safely in the main thread. Ideally I’d bunch them up inside a thread structure and dump them at the end.

Anyway, enough tech bollocks, the upshot is that massive factories will now be uber-fast :D.