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

Democracy 3: Extremism Released

I don’t know what the US situation is right now, but Europe sure is going all extreme in it’s politics, from the National Front in France to the delights of UK politicians who blame flooding on gay marriage (oh yes…). We have a big test of extremist (kinda) politics in the UK coming up with the European elections. Should be an interesting spectacle. On that front, how about I release a NEW EXPANSION PACK!

I have to admit, I really like this trailer. Live action FTW. If you want to grab the expansion and get all extremist on yo voters asses, then you can grab it from my site here or from steam here or GoG here. Also Mac Game Store soon. Let me know what you think of it!

Now back to polishing Democracy 3 for the ipad…

Strategic risks and opportunities

I’m sat in an airport lounge sipping tea and typing business strategy on a laptop. I am a walking cliche. Having said that… it might be helpful to share my brain dump on the future risks and opportunities I see for my company. First the risks (I am, after all a pessimistic brit).

Risk 1. Price war and collapse for PC games.

This would change things dramatically, not only because I might just earn a lot less, but because many of my strategies are price-point-dependent. You cannot break even advertising a one-time $5 purchase. Probably not a $10 one either. I have to make games that command a $20+ full price tag. I actually am not too worried about this happening. Not for original, interesting, polished high quality games with marketing. For shovelware sure, but that’s not me. Risk: 5%

Risk 2. Royalty collapse / publishers go evil.

Steam could demand 80% royalties, and everyone could copy them. That would be pretty crushing. I find this incredibly unlikely. Steams market share is big, but there are enough other players ready to take over the minute something like this happened. Plus, the more people at steam I meet, the less likely this seems. Risk 5%

Risk 3. Everything shifts to Mac / Linux / Tablets / VR.

This seems much more likely. It’s mitigated by Microsoft getting a new boss, so maybe they will stop fucking up. On the other hand the rise of the tablet/phone seems unstoppable. I now know that VR is awesome and not far off. The upside here is that I can cope if this happened. Learning OpenGL wouldn’t kill me. I reckon I could make games that are designed for tablet first if I needed to. Risk 20%

Risk 4. I am out-competed.

There are a lot of smart young developers in India / Russia / Brazil / China who are going to kick our asses. I live in one of the priciest countries in the world. I am 45 years old and need sleep now and then. The only thing I have that lets me compete with a 17 year old kid in Vietnam is my experience, but as they age, and senility kicks in for me, plus I’m stuck in a C++ era, that will be less effective. I can compensate by actually hiring people from these countries, but that still leaves a big risk of competition. Risk 25%

Risk 5. Critical employee.

If I get hit by a bus Positech is dead. I pretty much *am* the company at a strategic sense. My eyesight could fail, I could have health problems etc. This is obviously a different kind of risk. I can at least mitigate this with a healthy diet and exercise. Theoretically. Risk 1%

So there is the doom and gloom. How about exciting future stuff?

Opportunity 1.  New countries.

For the first time I have a game where I actually own 100% of the translated versions (Democracy 3 in German and French). I think they have made money, and also more importantly acted as a first step to understanding how to do this right, as I did EVERYTHING wrong. In an ideal world, every future game of mine has built in language support and unicode. This is unlikely but I’m heading there. Is piracy rife in some of the biggest markets out there? Yup, but the numbers are huge. Opportunity: 35%

Opportunity 2. Expansion.

I find this so difficult, but my current system is to expand by publishing games. I tried this with redshirt, and for a first attempt at this idea, if worked pretty well. Enough that I’m doing another one (details to come…). This is a very simple way for me to expand. I may eventually get an actual employee, and if I didn’t have such a nice home working environment I’d likely already have done this and had an office. Opportunity: 30%

Opportunity 3. Investment/ Diversification.

I don’t have to expand in games. I thought long and hard about starting a solar farm business. Positech even SOUNDS like an energy company. I lack expertise here, so at the moment I’m just content to have invested in existing solar farms. Maybe eventually I’ll make the leap to setting one up. Opportunity: 20%

Opportunity 4. Education / Biz software.

I think the education market is under-served. Democracy 3 is a great teaching tool, and there is vast potential here. I sometimes toy with the idea of hiring someone full time to push Democracy 3 into schools and to further develop it as a proper teaching tool, or also as a business tool. I can make a very convincing argument here. The problem is I’m not massively into spending my time talking to school district managers and big business committees. Plus there is the problem of getting people to take a games company seriously. Opportunity: 20%

=======

If I was 25 years old, I’d probably be hiring a bunch of people to expand on all those fronts right now. I’d have some trendy office in some trendy part of a big city and be high-fiving fellow entrepreneurs over lunch in whatever sushi bar has the best wifi. I’d actually know how to use uber. I’d have google glass.

As it happens, I find myself to be a relatively quiet tea-sipping forty-something, keen to get back home to his cats and the English countryside, and to shave. (One thing I learned this trip is that security people confiscate shaving foam.) I balance this out knowing I’m happy, have a good life and really love what I’m working on. Ultimately that surely is the goal.

 

 

The future of steam, VR and other seattle stuff

So here I am, sleepless in seattle. Actually its more like sleeping well, but with a nosebleed in seattle, but that isn’t as catchy.

I’m here for a meeting with valve and some other indies, so I have lots to talk about. I am no expert at knowing exactly what I am and am not allowed to say, so here are vague impressions rather than a news-dump on steams plans. For a while, a lot of indies have been panicking about steam. There are more and more indie games being released though greenlight and people are worrying that the ‘average’ indie game on steam is making less money. The phrases you hear are ‘floodgates are opening’ and ‘race to the bottom’.

I’ve seen what valve have planned and I really do not think anyone has to worry. Actually I do. If your plan is to dump your first unity hobby game on steam and then retire rich, and that game is a clone or unpolished, or incredibly unoriginal, then yeah, you are so fucked, but frankly I don’t care.

Valve are approaching the ‘floodgates’ problem in exactly the right way. The steam experience for everyone is going to get so much better. I can’t fault their plans in any way. I’d love to attract loads of web traffic with a clickbait ‘valve are about to wreck steam’ blog post, but that would be complete bullshit.

My advice to indies uncertain about steam’s future is just to make a really cool game and don’t worry. That sounds like PR bullshit but it’s actually true for once.

While I was at valve I got their VR demo. I fail AGAIN here in any attempt to be contrary or scandalous, because I’m just going to echo what other have said. Fuck yeah. This is so cool. I never thought it would even work on a stereoblind person, but it is amazing. It isn’t perfect, it isn’t suitable for everything, but it *is* amazing. A whole new experience. I never thought we would be this close to a proper star trek holodeck so quickly.

I met some really nice people here. It’s always awkward mentioning anyone specific because then you feel like you might not mention everyone and my Englishness thinks I am probably offending someone, but hey, I’m not intending to. Anna & Augusta from valve were very cool to meet, I suspect Alden now sleeps safer knowing that I’ll safeguard his job when I own valve, and it was amazing how much in common I seem to have with the amazingly cool Tommy refenes, including a love of l33t electric cars. Also always good to bump into chet again. Whenever a bunch of games geeks get together, we always end up talking about cats. I also got to meet Jamie Cheng, another real friendly and cool guy.

I should also pay respects to the legendary Ichiro lambe, who has proven that Americans can actually be just as deadpan and sarcastic as English people.

 

 

 

My big slowdown function

Well I feared as much when I wrote this: https://positech.co.uk/cliffsblog/2014/04/14/reading-back-from-gpu-memory-in-directx9 but it turns out that, yup, that function is the slowest in the entire engine, at least until battle is joined. I really need to fix it.

Essentially what I’m doing there is maintaining a depth buffer for objects in the game. I then do some fancy processing on that buffer (all taking place in video card memory. I then really badly need to know the values of the depth buffer for about 100 different points, and based on the outcome of that, I either don’t draw, draw some stuff quite small, or draw it really big. In short, I’m scaling an object based on specific values of the depth buffer.

Right now, my engine does not use vertex shaders at all. I just use pixel shaders, and have vertex shaders as NULL. I’m pretty sure the solution to my problem is easy if I go to draw all of these objects, then write a vertex shader that can scale the object accordingly. the thing is, I’m using directx9 and therefore I really do have separate vertex and pixel; shaders. This is going to involve me reading up on the most undocumented stuff ever, which how vertex shaders and pixel shaders can be used in a 2D game under directx9.

Bah.

Optimizing GSB2 rendering, the day fighters went in…

So today I added the first few new fighters to my GSB 2 engine. As a result, for the very first time I noticed the release mode build looking like it wasn’t running at a full 60 FPS at 1920×1200. My target is a healthy 60 FPS at 2560×1440, so this will mean some proper optimizing. I thought I’d keep a diary here of my investigations. First step is to do a ‘releasesymbol’ build (release build with debug symbols) and run aqtime pro, my optimizer of choice, to look for CPU slowdowns. This is an instrumenting profiler so it will be slooow…..

My initial invesdtigation shows that 50.68% of the time is drawing the battle,  31.62% is processing the frame. I decide to concentrate on the frame processing first, as this is easier to potentially multithread…

f1

So pretty clear I need to work on the debris processing. This is already being multithreaded though… digging deeper it seems that a sorting function takes up 99.95% of that time, and 99.73% of *that* time is spent in GUI_DebrisCloud::Clear() ouch. It’s immediately obvious that per-frame sorting is mega overkill anyway, but why is clear so slow? Aha, because it involves removing the object from another, less optimised list. Ouch… Some digging shows I only add it back to that list later in the frame anyway, so this is entirely redundant, so thats a very easy win! Next lets look at the GUI_3DManager::PreDraw().

f2

Yikes. Looks like STL is not being my friend at all here. A bit of investigation is called for… Again, this is an STL sort algorithm. I suspect I may have an unusually long list of items to sort there, and some digging suggests that this list has about 400 items in it. Not a lot, maybe the actual sort comparison is slow? No it’s a simple float comparison. what can be going on? is the STL list sort() really that inefficient for so small a list? apparently so. My options are to replace it with a vector (which makes removes/inserts a bit slower) or sort less often, or find a way to reduce the list size. The sorting is already being done why other threads are busy. I’ll experiment with a switch to vectors. While I’m at it, lets take a look at the slowest stuff inside the battle drawing…

f3Looks pretty clear that my post processing is slow, but as I recall, thats actually where most of the real drawing takes place… Some digging shows me that the main culprits are my lighting compositing and my lens flare streaks. This is the dreaded code where I read back from the rendertarget, which I knew would be hellishly slow. I *could* do it every other frame, and ‘lag’ very slightly. I *could* reduce the amount of the data I need to read-back, but I suspect this isn’t the problem. A tricky problem, whereas looking into the lightmap stuff I find a whole bunch of STL list iteration going on. I have mused before about using some fixed size (but big) arrays instead in this area… I also think I’m simply doing *too many* single sprite draw calls here, multiple ones for each fighter (don’t ask!). I’m pretty sure I can make some safe assumptions that compress those fighter layers into one, meaning an instant 50% less ship draw calls, so I’ll try that too… In fact some of them had THREE layers. ouch. Right thats three changes so lets go through the old sloooow profiling again. (results not 100% same as I’m not doing a scripted playback…)

Right then, first thing is that DrawFighting() is now taking 58ms vs 74ms, so already a nice phat boost. (is this microseconds? I think so, it doesn’t matter :D). ProcessFrame takes 10.61 vs 46.19. Oh yeah! The new frame processing looks like this:

f4Weirdly my reduced layers have made no difference. previously the ‘drawunlit’ function took 4.48,s, the new version takes 4.53.  I’m now making 360 draw calls per frame, previously it was 442, but thats had zero impact. Maybe the draw call count is harmless at this point? Interesting. (I make many other draw calls per frame, this is just a certain function). The 3DManager sort time went from 10.5ms to 1.628, so a massive win. So far I am 2 victories, 1 damp squib. I can see some asteroid related slowdowns, but they aren’t in all maps and I’m looking for broad wins here… I just spotted 484 calls per frame to ship::IsOnScreen(). This is possibly an inefficient function, as it cycles through layers and checks for each layer being onscreen, without any ‘quick win’ bounding box clauses… I’ll add a sanity check fast ‘if ship center offscreen by twice our hull size, then quit’. That *must* be faster… I can check this fast without a whole long profiling battle so…

Cool, that function is now 10x faster. yay! 3 out fo 4.

In my browsing I now spot this beast:

f5

What the hell? I was only flying along, there were no distortion waves, let alone roughly 1,000 new ones per frame. This sounds like a complete balls-up! Actually this looks like the profiler getting confused, possibly by some release build optimisation. It does draw my attention to a list I fill each frame… There are 3 slowdown in this,. the creating a new object for the list (tiny struct), the function call to add it, and the actual list push_back. This is all slow. it looks like I am already caching the objects, but clearly it’s not enough. Luckily AQTime lets me profile line-by line…

c1Hmm, so as suspected lists just suck for this purpose. I need to sort out my caching (I actually suspect the max cached objects is just too low…) but I’m going to have to switch to vectors or ideally just an array for this stuff. Less convenient, but it clearly will boost performance.

Anyway… I’ll keep plugging away. I love this stuff. I fully expect the game frame rate to double by tomorrow. This is early days easy win stuff.