Monthly Archives: June 2011

There is something very tricky about selling games through demos. The problem is, the complexity of interaction required for the full experience.

Take a fairly complex strategy game, like Gratuitous Space Battles. To really appreciate what the game offers, you need to experience the visual excitement of a big battle, preferably two different ones to show the variety of ships, fleets, backdrops and visual effects. You need to experience the way the honor system works, and the shop section where you unlock new modules. You need to see the design screen, and put ships together, try out the deployment screen with the different ships orders, and you need to see the variety of missions to choose from. Plus you need a brief bit of challenge play to see the online integration, and if we are talking all the DLC, you need a run through of campaign maps, campaign repairs etc…
To explain how to do all of this in the game takes AGES, and you only really learn it by doing it. Lets call the time taken to experience brief elements of all of this time ‘T’.

Now lets take a movie, such as…oh I dunno… Enemy At The Gates. This film has a bit of character background (Vassili as a child), it has high drama (the crossing of the river) it has the characters of Khrushchev, Tania, the rivalry with Danilov over Tania, the death of Koulikov, the betrayal of Sacha…etc blah blah.

The difference is, that we don’t need to ‘learn’ how to experience any of that. A 3 second clip of stuka divebombers… CHECK, a 3 second love scene clip CHECK… and we can jump from one to the other no problem. This means that the time taken to experience brief elements of all this is T2. I think T2 is maybe T/10
Where it all gores wrong, is generally peoples attention span is A, and T > A > T2.

What a geeky way of saying it’s easier to sell a movie than a game :D But what I’m getting at is that the very NATURE of games (interaction) means that it’s much harder to provide an effective demo. (although to be fair, books have the same problem)

And this is what I’m worried about with my next game (GTB). It’s actually got a ‘sort-of-backstory’, and to explain the mood and the style of the game will take more than 30 seconds. Gratuitous Space Battles was pretty much summed up in it’s title, and this one won’t be. So I muse nervously on how to hold peoples attention while I explain the background to the game.
The mechanics of the game are pretty simple by comparison. I’m just taking an existing genre, flipping it, scaling it up, and setting it against an original backstory.

Plus lots of stuff blows up and it should look nice, in a GSB kinda way :D

Check this out, it’s just great :D It’s a big, heavy duty mod for GSB:

The full forum thread for the mod is here:

http://positech.co.uk/forums/phpBB3/viewtopic.php?f=23&p=48689#p48671

basically it adds BIGGER ships (dreadnoughts) to the game, which is awesome, and something that any hardcore GSB player should probably take the time to check out. I love this sort of stuff happening to the game, especially now that I’m 100% in next game mode, and don’t have time to tweak GSB or add anything new right now. It is effectively new, fresh and free content for newcomers to the game, and all done by GSB players without any input from me.

It does seem that modding is less widespread than it used to be. Maybe big budget PC games are too hard to mod now, or maybe the developers and less supportive? who knows. It certainly reminds me that I need to ensure I make time to make my next game just as moddable as GSB is.

Possibly no work can get done this thursday / friday. My home office is getting a much-needed new roof, and I will be laptop bound for that time. I hope it doesn’t rain when the roof is half-off :(

 

I have this class in my code called ‘smart texture’. I’ve had it for several games now. It basically lets me tell a sprite to use “gun.dds”, and it transparently converts that to the LPDIRECT3DTEXTURE9  and doesn’t mention it. It keeps ‘gun.dds’ in memory, and if I ever lose the screen (alt+tab), and need to rebuild stuff, it will replace the invalid surface pointer the next time it gets drawn with a fresh copy.

MAGIC.

Trouble is, that means keeping a list of every smart texture, so that I don’t miss any when recovering from alt+tab. That’s easy, but I ended up using texturedsprites (with a built-in smart texture) everywhere, and thus the list, for a full battle could be 20,000 textures long.

F**k.

So here I am, effectively keeping a record of me trying to fix this…

It’s 5.35PM Sunday. The wonders of aqtime show me that when I ditch the current level and load in a new one, I am killing off about 8,000 smart textures. Every one is going through it’s destructor and removing itself from the smart textured list. This sucks. I need this to be faster. First instinct is to speed up the destructor, but obviously that’s treating the symptom, not the cause. The real problem is 8,000 smart textures. That isn’t so smart, when 2,000 of them are probably pointing to the exact SAME surface in directx… I need to rethink this system, and NOT break any other code…

I *do* have a system called GUI_TextureCache which does some ‘fixed’ storing of textures I use all the time, like UI stuff, buttons etc. This is obviously a similar task to what I want to do here, in that I need a dynamic dumping ground for commonly used textures pointers. I’m concluding that the cleanest way to handle a fix would be within my SmartTexture itself. it can do some clever caching, and then nobody will ever know any code changed!

Realisation that this means I still keep all these smart textures knocking about, with their ‘gun.dds’ strings. That offends me, as a programmer, but tbh, even ‘longcomplextexturefilename.dds’ is only 30 characters, so with 2,000 units I’m wasting 60k here. Big deal.

Right, so the plan is when I call SmartTexture::SetTexture(“gun.dds”) it may, or may not add itself to a list of textures that would need rebuilding, based on if its already in the list.

Problem: I can’t do that, because it means checking the whole list every time I call SetTexture(). That might even be *slower*. However, my current ‘SetTexture’ goes through a list to grab the pointer, how slow is that? It looks like currently its about half as much time as all those smarttexture destructors, so it might be a win. Plus my SetTexture() stuff uses a MRU caching system which could make ti super fast when loading in 100 identical units…

5.50PM Actually realising I’ll need a totally new class to handle this. it needs to be done a different way, not with existing smart textures. Balls. Surely it can be done? Hold on.. Surely its just a matter of indirection. The purpose of a smart texture is to hold a surface pointer it can rebuild if needed, but it doesn’t have to hold a direct link. It could actually hold an indirect link.  One more piece of pointer indirection is trivial. I just add a new CLoadedTexture class that handles rebuilds, and the smarttextures can point at those, meaning no need to keep a list of them at all, as their pointers never go invalid or need rebuilding.

6.25PM everything coded except the actual rebuild() calls for alt+tab. I’ll comment the errors out for a quick test… GAH, it crashes immediately. fixed easily enoguh, and the code RUNS! hurrah, but it doesn’t seem AMAZINGLY faster,. Quick! to aqtime! what the hell… it’s slower?…

6.35OM. Hah! looking at it backwards, it’s about 75% faster. how much time does that knock off loading in a new level now? 5.28 seconds down to 2.1 seconds. That’s pretty good. I’ll code in the rebuilding stuff and give it a quick test…

6.50PM Alt+tab doesnt work, I get just a black window, but that may be something else. I’ve checked in my current code, and am investigating alt+tab issues now. It looks like the restore code hasn’t worked on this new game at all yet. I consider my (dumb) smart texture code fixed :D

 

The SMTG bundle runs out tonight at midnight. If you missed the earlier blog post, then I suggest just going here:

http://www.showmethegames.com/bundle1.php

And checking it out. It’s five hgh quality indie games, on a sort-of-strategy theme, than are bundled together for $28.50.

On the topic of SMTG, that brings me to the question of the sites future. I’m really please that SMTG is up and running, that it gets some traffic, that it looks nice, and that it has the support of so many developers.

That’s the good side.

The bad side is that the site earns $0, and actually costs some bandwidth, plus also the site takes time to develop further. Frankly, I don’t have the time to dedicate enough effort to constantly add content, and I can’t afford to hire a full time (or even decent part-time)  site manager to handle it. I like to have total control over stuff, so I’m not looking for a volunteer, I prefer to pay people and then tell them what to do :D

So although SMTG works very well, and definitely drives sales to developers etc, I’m unsure what will happen to it next. I’ll continue to add new games that I think are really awesome, and I hope to find some time to add features and improve upon it over time, but it’s not going to grow like Steam or even Moddb, because of lack of time. Maybe when my next game has shipped I’ll get a lot more free time and spend a few months on it, but I already have to find time for top-secret-side-project #1 as it is… Ho hum.

AQTime

June 10, 2011 | Filed under: GAME FOUR | programming

Yesterady I bought AQTime. It’s $600. That ain’t cheap. It’s profiling software, so basically its something that helps me write faster code. I’ve used it before, and it’s extremely good. I hope I can make my new game faster and smaller-memory-footprint than GSB by using it.

Already I’ve found out that some code that I thought was fast (searchlights) is in fact scarily slow. What’s more, I know the exact lines of code that cause the problem and it’s likely easily fixed. yay!

Plus fog of war code is done and dusted. Double yay.

I hope to have some interesting screenshots to show off in a few weeks. I’ve done the flashy graphics stuff before the gameplay balancing and level design, which means early screenshots of GTB will look nicer than the frankly awful early GSB ones :D

Also… there was a fox in the field opposite the house yesterday. It seemed to be just prowling about, midday, in the sun. Who needs springwatch when you have a fox? :D