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

First minor bits of marketing GUI heading for production line

Having been away for a week to relax, coming back to work I have a desire to release an update for Production Line sooner rather than later. I hate people thinking work on the game is slowing down or stopped (ha! no chance). Because a week off means a week less features, this update which i plan to test tomorrow and deploy Sunday will not be huge, but it will have a whole host of minor bug fixes and tweaks, and also the first steps towards marketing.

Basically you will be able to research marketing facilities and place them in your factory like this:

And there is a new GUI you can launch from the main menu strip at the top of the screen which for now just shows you that same summary information. Right now, the facilities generate ‘ideas’ over time, and those are saved and loaded, but you cant use them yet until I code some basic marketing campaigns which should start to go in next week.

Also in development are some new achievements, and a new car body style (4×4 or 4 wheel drive if you prefer, or jeep-style-thing if you prefer). and eventually some proper sound effects. I’ll probably get around to some more optimisation and some proper tutorial improvements soon too. With any luck I’ll do a developer blog video tomorrow.

In unrelated news, our village has been told we will get fiber internet by 2018. Yay…but I’m not holding my breath. still waiting for a quote for ‘fiber-to-the-premises on demand’ (FTTPoD). Theoretically that’s 300Mbps down 30Mbps up, which would be amazing, but the cost is outrageous and I’m getting annoyed it takes so long to even get a quote.

Getting threads to rapidly schedule tasks in C++, Windows

very techy post…

My latest game uses the same multi-threading code I’ve used before. This is C++ code under windows, on windows 10, using Visual Studio 2013 update 5. My multithreading code basically does this:

Create 8 threads (if an 8 core system). Create 8 events which are tracked by the 8 threads. At the start of the app all of the threads are running, all of the events are unset. As I get to a point where I wwant to doi some multithreaded code, i add tasks to my thread manager, and when I add them, I see which of my threads does not have a task scheduled, and I set that event:

PCurrentTasks[t] = pitem;
SetEvent(StartEvent[t]);

Thats done inside a CriticalSection, which I initialized with a spincount of 0 (although a 2,000 spiun count makes no difference).

Each of the threads has a threadprocess thats essentially this:

WaitForSingleObject(SIM_GetThreadManager()->StartEvent[thread], INFINITE);

When I get past that, I enter the critical section, grab the task assigned to me, do the actual thread work, then I immediately check to see if there is another task (again, this happens in a critical section). if so…I process that task, if not, I’m back in my loop of WaitForSingleObject().

Everything works just fine… BUT!

If I have a big queue of things to do, my concurrency charts from vtune show stuff like this:

Seriously, WTF is happening there? Those gaps are huge, according to the scale they are maybe 0.2ms long. What the hell is taking so long? Is there some fundamental problem with how I am multithreading using events? Does SetEvent() take a billion years to actually process? If feels like my code should be way more bunched up than it is.

Deliberately frustrating fun

A lot of words have been written on the topic of flow in game design. Mentioned frequently alongside ‘mastery’, the general concept is that players enjoy a feeling of relatively stress free-calm travel through an experience where they encounter little resistance or setbacks, and preferably no ‘hard stops’.

With one aim of commercial game success being tied to keeping people playing longer (often because the highly connected gamer effectively ‘broadcasts’ their choice of entertainment to logged-in friends), creating and maintaining a sensation of ‘flow’ within the player is seen as highly desirable.

A typical game design that works well with this system is the match-3 puzzle game, or tetris. A never-ending game with a simple, but satisfying mechanic that rewards mastery yet will allow uninterrupted play in relaxed, stress-free state.  Such games can be very popular, no doubt very popular. Obviously, we have lots of them.

My latest game ‘Production Line‘ is a weird hybrid of two different design goals, to create a sense of flow, but to interrupt, pause, disturb and frustrate that flow, deliberately so as to create the endorphin rush as that frustration is fixed. Effectively what I’m doing to creating a design where the enjoyment comes not just from the state of flow, but the satisfaction and catharsis of fixing an impediment to that feeling.

Creating a ‘well-oiled machine’ creates a strong sense of satisfaction and happiness in many gamers. Its perfectly natural to look upon something you have arranged and see it work flawlessly. For some reason, this seems to appeal particularly to Germans. It also appeals strongly to me, I enjoy the sense of scale, control, to be honest- POWER that come from having built a large impressive, complex, working… *thing*.

But watching something you created do its job is only half of the pleasure. Something in our brains seems hard wired to want the next challenge, and the next, and the next. To this end, Production Line is designed as a deliberately unsolvable puzzle, an impossible balancing act. A simulation of a system so complex it has no practical perfect solution, only progress towards perfection, but no risk of attainment.

As a car-factory simulation, this feels both natural and believable. Producing something as complex as a car requires a huge number of tasks, many of which have dependencies, and none of which will take the exact same amount of time. As a result, regardless of production scale, bottlenecks are absolutely inevitable. Flow is impossible, a dream to aspire to, an unachievable goal, but one where the struggle to achieve the goal is nonetheless enjoyable.

I suspect that the general consensus of game designers is that frustration is the enemy of fun. Frustration is a negative feeling, and one to be avoided, but games balance out the good and the bad to achieve greater pleasure all the time.  The satisfaction of finally tracking down and counter-sniping someone in an FPS who shot you six times in a row is far greater than it would be without the frustration of being picked off by them again and again and again…

I’m sure some people will look at my best known game (the political strategy game Democracy 3) and my newest car-factory sim (Production Line) and think there is little in the way of a common theme, but in design terms there definitely is. Economics is a system so complex pure balance can never be achieved. Push here and the system pulls there, just like fixing a bottleneck on a car production line, or improving the effectiveness of a part of your fleet in Gratuitous Space Battles.

Positech. We make frustrating experiences fun :D. (Hopefully)

YOUR INDIE GAME WILL FLOP AND YOU WILL LOSE MONEY

At the time of writing, a quick check of stats on steamspy for player unknown:battlegrounds reveals this chart:

A very basic analysis suggests 500,000 copies this month, at $30, minus maybe 40% for refunds/taxes/steams cut gives us:  roughly $9million this month. Total sales stand at 3 million, for a total estimate of $53 million so far since release 3 months ago. Assuming a lifetime doubling of that 9conservative) that gives us about $100,000,000. income.

The developer is listed as bluehole inc, who apparently have about 90 staff: https://en.wikipedia.org/wiki/PlayerUnknown%27s_Battlegrounds

So the average income per employee there is a million dollars. original team size was 35, so assume that half the money goes to equity holders and its split equally between the 35, that gives them roughly $1.4 million each. In practice thats bollocks, because more likely 80% would be going to the equity holders and I’d guess 90% of that belongs to maybe a handful, at best 4 people? (I have ZERO idea, this is my guesswork), which means company founders are probably getting about $22 million from the game. Include sequels, potential DLC, merchandise and so on, and you can probably round it up to 25 million.

Thats a fuck-ton of cash.

But the problem is, the chances of Joe Indie game developer achieving this are close enough to zero as makes no difference.  There are 348 pages of ‘top sellers’ on indie games on steam. Taking the mid point, and looking at the top game (I wont pick on it publicly, so lets not name it). Its an RPG with Zombies in apparently (that shouldn’t narrow it much :D). Steamspy says…. *drumroll*

3,500 owners. Top price has been $9.99, been out 9 months. Maximum conceivable income is $20,979 to the developer. In practice, as its been on sale, lets multiply that by 50% and get about $10,000.

This game isn’t exactly World Of Warcraft but it has a proper 3D graphics thing going on, positive reviews and a decent capsule graphic. lets depress ourselves with the numbers:

Assume the developer is a single person with no other costs and keeps all the money: $10,000 a year, or roughly 1% of the revenue/employee as PU:BG.

Assume they are the founders/owners/creators and keep all that sweet cash, they earned roughly 0.04% of the equiv person behind PU:BG.

Yes…these figures are very very rough, but I didn’t deliberately pick something bad, in fact I picked half way through the indie top sellers. Are we really thinking they sound so out of whack? This is a WINNER TAKES ALL market. You are either in the top 0.1% of indie game developers, or you are unemployed, with an expensive hobby where you make effectively free games.

This is nobodies ‘fault’. Steam didn’t cause it, Unity didn’t cause it. games got easier to make, and more people got access to PCs, development kits, computer skills and broadband. Its really no different from waiting tables whilst pretending to be an actress, or avoiding admitting you are unemployed by claiming to be a writer. There is virtually nothing I can do about this, and nothing you can do about this, but there is something we can collectively do to at least minimize the collateral damage:

Lets admit that the default position for an indie game developer is pretty much poverty. If you want to make money, maybe one day buy a house, start a family, have a pension, why are you making indie games? You KNOW you are almost certainly screwed right? or to put it another, simpler, TL;DR way:

YOUR INDIE GAME WILL FLOP AND YOU WILL LOSE MONEY

Now, *some* people don’t flop, and do well. And that *might* be you, but I urge you, go into this job (like any other) with your eyes WIDE open. Your chances of success are incredibly, incredibly small. This is not a sensible career. This is not a wise career move. This is almost certainly personal financial suicide. You may (like me) feel compelled to make games regardless of success or failure, but ALWAYS know the odds. ALWAYS. (Han solo is wrong about his topic). I know people get inspired to make games by reading about the success of some developers (including me), and that’s great, but always know what you are doing. Do not remortgage your house to do this. Do not both quit your job and live off savings to do this when you have kids to support. Do not assume you are different or special.

Treat this as a disclaimer for my blog: You are reading the thoughts of a guy who was coding since age 11, has 36 years coding experience, has shipped over a dozen games, several of which made millions of dollars, got into indie dev VERY early, knows a lot of industry people, and has a relatively high public profile. And still almost NOBODY covered my latest game (in terms of gaming websites). Its extremely, extremely tough right now.

 

How to fix research in Production Line’s design…

Although in general I’m pretty happy with the design of Production Line, its clear that there are some issues with the way research is implemented in the game. Something I really like is the idea of a BIG tech tree, and players making decision as where to concentrate their resources in terms of competitive advantage. For example, you may focus on production efficiency, or maybe on product range, or maybe on costs, or on high-technology to making high-end cutting edge cars. Different strategies should work.

The trouble is, despite the big tech tree and different approaches, the research-choice decision (which should always be *interesting* as every decision in a decent strategy game needs to be), tends towards more of a nuisance in the late game than a joy. The reason is that research seems to get quicker and quicker, and the costs of doing it become trivial.

At the start of the game, I really need the player to be able to buy some research facilities, otherwise they cannot progress. The problem is, as we go from a tiny little factory to a big one, the cost of ‘one more facility’ becomes relatively trivial. Of course, I can make later techs more expensive in points to research, but you can’t go ‘too far’ in that direction without it automatically herding the player towards doing ‘lvl 1′ techs first and removing that initial flexibility. The flip-side is that if you *not* scale the tech costs, then later in the game, someone who has ignored a specific branch of the tree can normally just go click click click’ and research it in seconds. again: unsatisfying.

FWIW I note factorio has this problem to some extent too, although generally it works better overall because the mechanics of research there are way more involved, rendering the ‘cost’ of the facilities fairly minor compared to the manufacturing of tech ingredients.

Anyway, how do I achieve the following in my design?

  1. Make tech tree choice interesting from the start, with multiple paths accessible.
  2. Allow tech to continue to be researchable at a reasonable, but not annoying rate.
  3. Prevent tech-spamming where the research cost becomes moot.

I’ve mulled over a lot of possibilities. here are some solutions that I have considered, either together or separately:

  1. Have hard caps on the number of research facilities that can be built before some other (expensive) admin tech unlocks ‘advanced’ research, thus putting the brakes on research in the mid-game
  2. Have variable costs to run or buy research (probably let scientist wages rise as more are hired), making research spamming non-viable in the late-game.
  3. Allow research queueing, so that the player can ignore research for longer periods. (Not ideal, as each research SHOULD be a catalyst for production line and car model re-evaluation).
  4. Have different ‘types’ of research require purpose built facilities. Maybe design-related research requires dedicated design studios? Maybe super-high tech research requires very expensive dedicated and large labs?
  5. Reduce or prevent the immediate construction of any research facility, but require a construction or hiring people for staff. Maybe placing a research facility means it takes 3-4 hours before the staff can be located to fill the facility and start work?
  6. Maybe introduce licenses, or patents that act as gatekeepers for research. To research reversing cameras perhaps you need to license a patent for it ($400,000) AND then research it once you have put that money down.

The problem with 1) is it seems very ‘gamey’ and arbitrary, and not intuitive for the player to understand. 2) sounds like it would actually make sense, although I need a decent way of letting the player know about the changes. 3) seems a quality of life improvement in general, but its also treating the symptom (research-popups are annoying) rather than the true cause (research happens too quickly in the late game, and does not seem to have enough of an impact to demand attention.

4) is interesting, and certainly one I’m attracted to. I like the idea of having to place down a design-studio facility, and to effectively research car designs entirely separately. I like the idea of a purely ‘design’ based arm of research for stuff like interior styling changes, new paint colors and types, and so-on. It also seems unlikely that someone who helps design the tire-making press is also working on voice-recognition software.

5) Sounds like its acceptable because build times for facilities are quite common in games, but then how do I justify the fact that everything else in the game is placed down instantly?

6) Could be interesting, and probably plays into a wider revamp of the research system where I need research-pre-requisites not to be limited just to other research items.

I need to get this right, so I don’t want to rush into a solution. I also feel this post is way too designy, I haven’t even tried to pimp the game. QUICK! Add a steam widget!