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

Show me the long term

It was a long time ago that I set up www.showmethegames. It was done out of exasperation with a conversation I’d seen 100 times in private lists and forums and email conversations that goes like this:

indie #1: we should set up a site that encourages people to visit each others indie websites
indie#2: thats a cool idea. It should have forums and a blog
indie3: ...yeah! and it should have regularly updated content...
indie4:..not only that, there should be embedded video, and also devlogs, and listings for all our games
indie1: Excellent, who is going to set up the site?
....sound of tumbleweed....

So I thought ‘fuck it’ and set one up myself. I got a lot of indie games listed on there, paid a web designer to do a logo and initial site design, and spent some time talking to other indies, even recording video from conferences to post content…

And it did ok. We ran a sale once, and that got very good traffic. But then I got busy. VERY busy, and getting anyone to write content for it was like pulling teeth. I should know better, because I was fighting against…

THE TRAGEDY OF THE COMMONS

Which is basically why nobody had ever done this before. So about three months ago I changed my strategy. I’d left the site neglected for a while, but now I had a new outlook, and it was this…

“I am going to invest in building up SMTG as a decent traffic generator for indie game developers. It doesn’t matter that I do it alone, or that others are benefiting from my work and financial investment. In the long term I’m building up an asset. It’s not worth much yet, but it will be, and in two years time I’ll be glad I did it.”

So I hired a proper game journalist to write cool articles each week for the site which are now online. I also re-engineered the back-end a little bit to support me updating it more often without a lot of legwork by me. I also have other plans, to be revealed soon. I’m spending a few thousand dollars here and there. Not a lot, but not totally insignificant. Many indie games sites die through lack of traffic and interest. I’m prepared to do what it takes to keep this site running.

To that end…it needs more games. It needs recent games. HIGH QUALITY indie games that sell direct (through humble widget is fine), and that are finished (not early access). Do you know any? If so email em at cliff AT positech…. etc.

Speeding up loading times

So I released a video yesterday of GSB2 running on multiple monitors, and in that video, a large space battle loads. It takes about 5 seconds. I find those 5 seconds agonizing. I recently spent half a day speeding up the games startup time because launching the game to test 100+ times a day was starting to buy me. Granted, 100×10 seconds is not very long, but I am incredibly impatient. I sometimes launch 2 apps on 2 different monitors and start typing on app 1 whilst windows finishes creating the window for app 2. I often encounter problems where clicking the google homepage and entering a search term means I miss the first few characters as the intel i7 catches up. I’m VERY impatient.

So how did I speed it up? and what tips are there for coding faster loads?

In this case, it was dumbness on my part. Some code that pre-loads ship designs was checking for whether or not lightmaps existed for each ship texture. Some have them, some don’t. It checked by creating the file and loading it in, failing if not found. HAHAHAHA. Very slow, and not needed. Those ships may well not be accessed this game…

So obviously it was tons quicker to not load the file in then, but just to check for the existence of the file on disk (or arguably to do this even later). Cue big speedup. Another speedup was possible because every instance of that item checked for the files existence, so I cached the result in the ship type and only checked for each file once. Much Much Faster.

That’s fine with a game that has few files on disk, but if you need to do this for 2,000 files, it can be real slow just to do those 2,000 file checks. Accessing actual hard drive data as opposed to RAM is painfully slow. With non SSD drives actual physical platters might need to spin. File access is the killer of load times. File access, and decompression.

Ideally you have data on disk that is pretty much in the format it will take in memory, then there is no decompression, just a straight ‘blap’ into RAM. There is a tradeoff here against debuggability, editability and modability. Some games have 2 file formats, a binary version, used when shipped, and a text version that overrides the binary and is only used during development. That can be kinda buggy, and prevents modders accessing the raw assets which might be a bad thing.

Another trick is to use ‘pak’ or resource files. In principle, and often in practice, these are just big zip files. The file access for the entire games resources becomes a single file read, and you effectively load the whole file-access-table for the game in on startup, vastly minimizing file-access slowdowns in cases where there are thousands of tiny files.

In general the golden rule of load times is to only do what you have to. If you can pre-process assets (into binary formats, for example) then do it. If you can defer some actions until that content is really needed, then do it. There is a natural tendency for programmers to have a ‘initapp()’ function and stick everything in there, but you really don’t need to. The player may well not launch the stats screen in this run-through, so don’t load any assets for it, or indeed, any data for it, and don’t waste CPU time initializing systems that might not even be used.

The best advice I could give anyone for speeding up load times would be to just get a profiler. Some are free, most IDEs come with a built-in one (they often suck), and LEARN how to use it. If you never put any time into fixing it, the chances are your load times are laughably inefficient. Most games are.

Gratuitous Space Battles 2 in multi-monitor mode!

At last a shaky-cam (well not shaky, but you know what I mean) video of GSB 2! I wanted to do this to show off multiple monitor mode with a lemon for scale. The video shows my dev PC with the game running. My PC is a i7 3770 quad-core 8gig RAM, windows 7 and a GeForce GTX670 video card, powering two 27″ monitors for a total GSB2 fun ratio of 5120×1440, or other 7 million pixels of lasers and explosions. Here is the video:

I’ll be doing more videos over the next few months to keep you all updated, plus other things are in the pipeline :D. In future I’ll capture normal in-game footage I just wanted to do a multi-monitor one :D Help me spread the word about 7 million pixels of explosions with ‘likes’ and ‘shares’. I reckon I’ll be more popular than these youtube kids by tomorrow!

BTW the games current website is at www.gratuitousspacebattles2.com (it will get a makeover eventually), I blog about the game here, occasionally tweet about it (@cliffski) and there are forum discussions here.

 

Something I learned today about STL and Z-sorting…

So here is a thing, you might be interested in if you use STL, if you don’t…well sorry :D

if use use the sort()n function thats built into an STL list, it guarantees to preserve the order of identical objects in the list. if you use the vector version, all bets are off.

Bloody hell.

So if you have a bunch of asteroids with these Z values

5,9,3,0,0,0,-2,-5

And you use a list to sort them, all is good in the world. if you use a vector, those 3 asteroids at 0 are going to Z-fight like crazy things.

the solution?

use stable_sort()

well call me mr-picky but I think I’d be happier if stable_sort() was the default, and we actually renamed sort() to be take_your_chances_and_do_random_crap_sort().

I presume stable_sort is slower… Luckily I’m not sorting asteroids every frame (that would be NUTS), and I only sort things when I have to, so it isn’t mega critical. it led to a bug where the biggest hulk chunks from spaceships did Z-fighting if theyu weighed ewnough to all have a Z-speed of zero, and thus a Z position(relative) of 0, so when other objects spinning away caused a z-sort, their order got scrambled. If you are a non coder and don’t know what Z-fighting is, it’s a flickering effect you get in 3D games where two images seem to be undecided about which one is in front. You often see it on ‘decals’ such as blood splats on the floor or posters on a wall. It’s annoying…

Anatomy of rendering a game dialog box in a custom engine (GSB2)

So I was tweeting that this took forever:

dialog1

It’s just a dialog box for gratuitous space battles 2., why did it take more than twenty minutes to put together? Now… I’ve seen unity, I know it has all these plug-ins that do stuff like this, and that it’s all very user-friendly etc blah blah. But I’m old school. I’m rocking my own custom-written engine, including all the GUI. That gives me huge advantages (mostly speed) and also some disadvantages. The best advantage is there isn’t anything I can’t make the code do.

The pain with this dialog box came in three flavours.

Flavour one was those circular clock-like indicators. In theory, this is really easy, you can just generate a tri-strip of a lot of polygons and draw a curve thats smooth and crisp as you like, as long as you can spare the vertexs. I’m not drawing many, so it’s not an issue. The problem is, when you do that, you get a too-blocky, too un-aliased clunky mess that just doesn’t look ‘right’ when surrounded by lovely aliased everything. I’m not drawing 3D models, so my game has a  nice smooth look to it, and it jarred badly. So I have a sprite of that curve, and I draw a subset of it using a tri-strip arc. It’s a bit fiddly, ant took a while to get right.

Flavour two was the outline of the right-hand part of the window. It’s a bit complex, as it goes in and out and then around the close button and then loops around those circles, and it has to be really slick too, and ironically in this case it looks better drawn as a crisp 1 pixel line, so there is actual hand-crafted code in there to work out all those positions and curve ncie arcs and lines around them.

Flavour three was speed. I like everything in my game to render fast, including GUI. No point in having a fast engine where 95% of the frame is spent drawing a dialog box. That means ensuring that ouline on the dialog is a single draw call with no fuss, that all those tiny animated bits of fluff in the dialog corners and outside the edges are drawn efficiently, that the calculations on that arc outline are as fast as possible, and that the dialog in general; doesn’t use many draw calls.

It’s all horribly, laughably slow really. I probably have a ‘spare render target’ knocking about that I could use to blap this whole dialog to (BTW they resize dependent on the ship, which adds to the complexity), and then only update it when it changed, otherwise just blapping it as a single quad. In practice, the windows various elements update quite a bit.. but I’m sure I could speed up the module icon rendering with runtime aliasing onto spare render targets. I love all this stuff.

But even I know when I’m getting obsessed and need to move on!