I’ve been tweaking and fixing a few small things lately, sounds that do not play, some graphical problems, and some bugs caused by recently introduced new features (I managed to screw up the way shields worked when I added cod to make ’stacked’ shields less effective.

In amongst this, the only true ‘new’ feature that has gone in is the alliance ‘lightning gun’. It’s basically just a beam laser, but drawn entirely differently. 10 minutes of reading photoshop tutorials got me up to speed with rendering lightning, and then a bunch of rendered strips of lightning later, I wrote code which works out how many ‘chunks fit in a beam, and stuck together a string of them so the ship looks like its electrocuting its enemies.

The code isn’t that simple, because you want the beam to zig zag everywherem, but hit its origin and target exactly, which is a bit fiddly. I also had it change which bits of lightning to use every 10th of a second so it looks like it flickers, and had to ensure that multiple beams from the same ship start at different points so you can’t tell the same texture pattern was being used.

Having said all this, the biggest effort was picking out a sound effect for it, which I’m still not happy with and am not confident is playing right. 30 minutes of previewing sounds of electrical static is a bit wearisome in 86 degrees in the indoors with an overheating PC by your legs.

All good fun I guess.

Bookmark to:

I have nothing to say today except Zap Zap BANG! Fizz! etc:

Bookmark to:

Every space movie has deflector shields, and so does GSB. here is the current system:

You can optionally add shield generators to your ships. The more the merrier, and some provide more shield points than others. The total shield points get added together as the shield strength. This strength needs top be blasted to zero to knock out the shields. In this respect, all generators act as a linked unit.

3% of weapon hits somehow luckily get through the shields anyway (luke skywalker lucky shots)

Shields have strength, but also resistance, and weapons have shield damage, and shield penetration. If shield resistance > shield penetration, the weapon is totally ineffectual. Otherwise, shield damage is applied to shield strength

Shields recharge over time. You need to totally blast a ships shield strength to zero to stop it recharging.

Now for the new bit (working on it now…)

Shields will have ’stability’ which indicates the integrity of the energy field. Special weapons (probably torpedoes) will be able to interfere with the stability. If the stability is reduced to zero, the shields will temporarily collapse, effectively turning them off and allowing weapons to penetrate. These shield disruptor weapons will ignore shield strength and resistance, working on totally different principles. The only defence against them will be point defence lasers and ECM beams to scramble the torpedoes.

This way I’m avoiding the possibility of just havign seriously ’shielded-up’ ships that are effectively impossible for enemy ships to overcome. Another possibility I’m toying with is preventing shield generator modules from being 100% additive, but maybe on a sliding scale.

So 1 shield module = 100% of its strength, 2nd shield module adds 80% of its strength, etc etc.

Thoughts?

Bookmark to:

I have a vaguely usable hacked together damage editor which means I can make a few improvements to the ships now. I’ve only done 1 so far, but with the tools in place the rest shouldn’t take more than a day. Here is a screenshot showing a federation cruiser and the changes:

A) This shows that some damage has knocked out the lighting on the warp nacelle. This is actually just visual and does not correspond to engine damage, that would be a nightmare, but it still looks better than them staying on Also, two of the tiny orange lights have been knocked out by another hit (bottom A)

B) These tiny impact ’scars’ are new. By having a lot of these scattered around the ship, the targets selected by enemy ships seem less predictable and more random, although they are pre-assigned in truth, and then scrambled in order.

C) My editor lets me easily add ‘permanent’ smoke or spark effects to each damage texture, so they don’t seem too similar. Most major impacts result in a complex smoke and flames emitter anyway, but only some of those smoke effects stay around for the lifetime of the ship.

This screenshot was taken using my debugging hacks, so it’s not really representative. Normally a ship hit this much would be flying through a lot of debris and maybe hulks from other ships, so it would look a bit better

Comments?

Bookmark to:

Have you read Outliers? It’s a book by Malcolm Gladwell. Not his best book,  but it’s quite good. It’s basically a theory that assumes that really successful talented people get where they are because they just put the hours in. He looks at The Beatles, Bill Gates, Sports stars, all different areas of work and investigates peoples backgrounds.

The guess is that you need to do something for 10,000 hours to get good at it, which is roughly 10 years full time. The Beatles had performed for that length of time before they became an overnight success

I’m a strong believer in the idea that almost anyone can do anything if they just put the hours in and concentrate. I occasionally muck around playing a digital piano. I’m not very good. My limits are the intro to Fur Elise and the intro to Wait For Sleep by Dream Theater. That’s about it. But I *know* that if I spent 10 years full time really going for it in terms of practice I’d get bloody good at it.

They say that school isn’t about teaching you stuff ‘per-se’, but teaching you how to learn. That’s a valuable thing to know. If the thought of sitting down with a book and learning some new skill depresses you, it’s really worth beating that. It opens up so many possibilities.

I have absolutely zero natural aptitude for programming. my DNA is pretty similar to everyone else’s.  I went to a relatively good school (state-run) and my mother taught me to read very young. Everything else was hard work.

You can tell I have no actual talent, because I’ve probably done my 10,00 hours and I’m still not rich or famous. I started programming at age 11 on the ZX81. I’m 40 this year.

I’m still trying though

Bookmark to:

My editors and tools are always really bad. Something has to give when you are a lone developer and with me it’s tools. I’m slowly getting better at it. It’s just a time thing. Today I spent most of the day getting my feeble ship hull editor to let me graphically position and assign particle emitters to damage sprites. (Screenshot below).

basically when a ship gets hit a pre-defined chunk of a damage texture gets drawn at the impact point, and it comes with a number of attached particle emitters. they are only visible fairly close up. there is also an additional temporary emitter that’s much bigger, but these ones are the tiny sparks that flicker over the burning hull of the ship after the smoke and flames have died down.

It took much longer than it should have to get this in, but it’s good because previously I placed them by hand in paintshop pro, then noted the pixel position and copied it to a text file. (laborious eh?)

This way I can placed dozens a minute and thus there will be a lot more of them :D. Tomorrow I’m going to do nothing but set up fleets and play out battles to check everything works and that the range of weapons and defences is acceptable.

Bookmark to:

After a few minutes playing Arm-A II today, it was obvious that camera-motion-blur is really cool, and I needed to get on with putting it into GSB. Half a day of monkeying around with poor documentation and I have it in and working, and togglable etc. It needs some fiddling to get it right still. The nice side effect is that when a big explosion makes the camera shake, the blur kicks in automatically. You can’t really tell with a small jpg, but it’s quite a nice effect in motion. Of course it does have a drawback, in that if you freeze the game in mid-shake-blur and then move the camera, everything is blurred, because you were near the explosion when it happened. I think thats quite acceptable tbh.

I also got some more optimising done today, which means I can consider adding in a few more gratuitous effects for peoples whose gaming PC’s are as good or better than mine, and want the game to look as gratuitous as possible

Bookmark to:

Some people have asked me if the GSB ships are sprites or 3D models. They are put together by an artist in a 3D modeller, then rendered out as sprites top-down, with some fairly neutral lighting. The game then draws them as sprites. There are additional ‘damage’ and ‘hulk’ sprites for damaged ships, and the turrets are drawn separately on top, and flashing lights and engine trails are done separately too.

As normal 3D models they look pretty good, like this in fact:

The problem is, these are VERY high poly models. You might be able to have a game with 4 or 5 of them, but not fity at once, and not with tons more going on, all on an older PC. I think space strategy games work better in 2D than 3D, unrealistic though that may be. I also think that using 3D models to do 2D sprites can give you a good compromise between high detail and decent performance.

Having real 3D models in the art pipeline opens up more possibilities for editing and doing variants of those ships too. I’ll probably do a few renders for the loading screens and the website as well.

Bookmark to:

I think GSB will turn out to be a game that has some decent screenshots. This is the first one I’ve taken for use as a desktop wallpaper. I’ll get some better (more frantic) ones done at some point, but here is the first one:

Here are the links:

1920×1200 res

1680×1050 res

1280×1024 res

It’s more of an indicator of how much stuff fits onscreen at higher resolutions rather than any attempt at showing off the engine right now. I’ve toggled the UI off for this screenshot. Any thoughts?

Bookmark to:

I’ve been testing a bit of a worst case situation for the battle screen in the game where there are just TONS of fighters, and they all have contrails and running lights and you try to see as many of them as possible onscreen.

Not surprisingly the game chugs pretty slowly during that. I’ve been looking at ways to speed the rendering up and have realised something I haven’t been doing enough of is lazy execution.

So what is lazy execution in non coding terms?

Imagine your program is designed to tell a robot how to cook (hey why not?). You might have a bit of code that says “Go to the fridge and grab some butter”. That involves a ton of steps, it would involve moving towards the fridge, locating the door, opening the door, removing the butter, etc.

So what you probably do is write some code like this:

And all is lovely and wonderful. Now later on in the programs development you realise you need to do that a lot of items, so your code in another area of the game looks like this:

Weird recipe huh? Anyway. this sort of code gets written a lot, especially on big games, because the guy writing the fetchitem code is a different guy to the one writing the recipe code. Often recipe-coder has no idea what happens inside the fetchitem code, so he can’t see any reason to not call it multiple times.

Of course, the sensible re-written code is this:

Now the downside is, that’s a pain to code, because you need to be aware of the circumstances and write code in each case to handle it. This is what lazy execution solves.

Lazy execution means that when I write the code that says “open door”, I don’t actually open the door at all. I just make a mental note that someone wanted the door opened, for reasons we can only speculate about. The good news is, if someone else asks to open the door immediately afterwards, I don’t need to do anything at all.

The real ‘action’ happens when someone calls the ‘takeitem’ code. At that point, the clever lazy stuff says “whoah! you cant take an item without the door being open, I better open that now. At this point, the previous instructions that had been ignored actually get put into action.

The drawback is that the fridge door close needs to be lazy too, which would impact on your carbon emissions

Obviously its more complex than that. Incidentally, this is how a lot of directx works. When you call SetRenderState or SetTexture, sod all happens. It only actually does anything if you render something.

The really good news about using lazy code, is that you can optimise anyway all redundancy. In my case the pseudo code causing some issues was stuff like this:

By making the Lock() lazy, the lock is never called (nor is unlock) in cases where no particle needs to be drawn. On big maps, with most of them off screen, this is quite common.

Bookmark to: