Monday, 12 December 2011

Destroyed by my own Destroyer

Destroyer enemy now rendered and mostly coded up.

Unfortately for me, they do exactly what it says on the hull.

Also encountered by first crash bug in the game. Accessed a pointer I shouldn't have. Silly mistake in the code as I'd already checked for it. Debugging tools saved the day as I found and fixed it within seconds.

Monday, 5 December 2011

Derailed 2 - In the Sidings

The game has been on hold for a couple of weeks, while I finish work and testing on my database for scale modellers (KitBase). Hopefully normal service will be resumed next week.

In the meantime, here are some links to other Indie games I've been playing recently:
(lulls you into a false sense of security with cute stylings then exposes its full depth and difficulty)
(hardcore shooty fun)
(space shootemup with lots of customisation options)
(couldn't resist a plug for my previous game - imagine Oids, Thrust and Asteroids with more guns!)

Have fun!

Monday, 21 November 2011

Vicious Little Interceptors and Difficulty Levels

Added in some nasty little Interceptors for a bit of variety. They are more aggressive on the way in but fire less on the way out.

Difficulty level code is implemented, at least in the gameplay - still need to add the menu options. At the moment it ranges from Space Slug through to Impossible.

A couple of screens showing me getting into a bit of bother:

I have uploaded a video of me playing on Insane (second to hardest):

At the moment, I can't beat it without losing at least one life. Need more practice!

The final game will have the option of an energy bar (shields) and for the truly dedicated arcade headcase a 'Hardcore Mode' with single shot instadeath.

Comments welcome.

Monday, 14 November 2011


I have spent quite a lot of time on my other product (KitBase) this week. I have realised again that working on database applications is generally easier than games and progress is more easily achieved. I'm not saying that the technical skills are necessarily harder (although they are different) but that achieving 'goodness' and predicting outcomes consistently is much more challenging.

I think that the differences are largely down to the weighting of:
  • Objectivity vs Subjectivity
  • Plumbing vs Sculpting or Crafting
  • Design and Realisation vs Experimentation
(There are probably many more of these but the above spring to mind).

To elaborate:

Subjectivity vs Objectivity
Games are extremely subjective. A game that is loved by one crowd may be hated massively by another. Business applications can usually be made to fit many different users without alienating half of them due to the more objective nature. Trying to make everyone happy during gamedev tends to result in a mess that nobody likes, either that or two games in one. Either way, a stupendous amount of hours can be burnt up trying to make a game 'liked' only to upset the original lovers of the game.

Plumbing vs Sculpting or Crafting
Business applications are generally built by fixing together various technologies (plumbing) to fit with the business requirements (databases, form systems etc). Rarely are entire systems built from scratch. Games on the other hand tend to be created by building (or buying in) some base functionality then continuously refining and chipping away until you end up with a good, playable, (hopefully marketable) game. Not easy - particularly the last part in my case (see Gravity Core on the right).

Design and Realisation vs Experimentation
Again, business applications are largely built in a methodical manner - even when built using Agile methods. Sometimes functionality may not work out and is scrapped but generally the design is built piece by piece until a required level of functionality is reached. The next phase of the application can usually be visualised by a designer then realised pretty accurately. Quite often with games, the end result is quite different to your original vision as some key features may not work as you envisaged or rebalancing may yield a very different gameplay experience. Huge amounts of time can be spent tweaking, refining and reworking the design with no obvious finish line.

Clearly all software is elements of all of these things but the emphasis is in different directions for games and 'serious' software.

Now that progress has been made on the other project, I'll burn some hours on gamedev next week.

Monday, 7 November 2011

Polish and Tweaks

Most of the development over the last week has been adjustments to the player ship model and re-lighting all of the ships from the top left. The ships were originally used in Gravity Core and were top lit. This provided interesting shading in GC because the ships were rotated, whereas the new game has the ships rolled instead.

I also reworked the Gravity Core shuttle into more of a fighter configuration and corrected the centre of gravity as this was causing the spin to be odd (notice how the upside down ship at the bottom is smaller).

The below image shows the new ship at the top and the old one at the bottom:

I've also brightened up the enemy Interceptors a bit whilst still retaining their sinister colouration. The player ship gained some pretty glowing jets as you can see below:

Back to gameplay over the next week I think.

As ever, comments are welcome.

Monday, 31 October 2011


Video posted showing 70s of attack waves.

Starting to be fun!

Sound Loops and Attack Waves

Added a couple more sound effects (interceptor engine hum and flip whooshes). Built the code to handle sound loops to integrate the former.

Also (and more fun!) added a lot more attack waves. The game has about 70 seconds of gameplay now and it's actually working pretty well synchronising the attacks to the music. It's pretty hectic and tough towards the end as the music builds up. When I implement difficulty levels, the current level is likely to be 'Hard'.

I planned to link in another video when I wrote this post, but it's still uploading to YouTube. I really need to do some compression before uploading...

Here are a couple of screenshots in the meantime:

Monday, 24 October 2011

More sounds and graphics

Added more sounds and graphical effects today, along with the first bits of the damage system. The sound system has been upgraded to overlay firing sounds and the like using alternating channels. This makes the weapons fire sound much better.

The glow effects are looking pretty nice on the enemy shots. Just need to rework the ship models and brighten everything up somewhat.

I've uploaded a first video to YouTube:
(note that this is still a work in progress and will change quite a lot before release)

Sunday, 23 October 2011

Social Media Marketing

Just finished reading 'Zarrella's Hierarchy of Contagiousness: The Science, Design, and Engineering of Contagious Ideas'.

It's short (100 page) book that looks at the spread of ideas from a scientific (statistical) viewpoint. Of particular interest to me are the lists of keywords that result in retweets and Facebok sharing. It's good to read a new media marketing book that focuses on experiments and results, rather than fluffy ideas.

A bitesize read that's worth a couple of quid on Kindle:

(or $3.15:

Monday, 17 October 2011

Now They Shoot Back!

Experimented with some more shrapnel effects today. Now shrapnel is spawned in the shape of the ship being destroyed, then thrown out in all directions. It does work but the effect is somewhat lost in all the chaos of fighting. Spent a bit too long on this!

Also set up the firing routines and rendered some initial enemy shots (as per the screenshot). Gameplay is beginning to take shape.

Monday, 10 October 2011

Shrapnel and Particles

Spent most of today adding in particle effects. When enemies are destroyed bits of metal fly off in all directions along with some small fireballs. I may have gone a bit overboard initially.

I still need to experiment a bit with the balance and also look into spawning some shrapnel in the shape of the ship being destroyed, to give the illusion of a ship breaking up.

Tuesday, 4 October 2011

Interactivity and Processing

Cliffski's tweet about megatextures being a brute force approach reminded me of Chris Crawford's book "Chris Crawford on Game Design" (a good read). Megatextures allow artists to create huge, rich images to represent landscapes and backgrounds; however the images will be fixed. The opposite approach is to use procedural texturing which allows for virtually infinite backgrounds but only within the constraints of the algorythm's sophistication.

In his book, Chris talks about Process Intensity versus Data Intensity. Most modern games seem extremely biased towards Data Intensity, even though they have complex physics, game systems and artificial intelligence. This unfortunately results in games that are more like movies with limited interaction (the single player aspect of COD4 was way too short in my opinion).

I have a preference towards procedural generation for maps and enemies, as this makes for more emergent gameplay and unexpected events. Gravity Core has procedurally generated maps which worked pretty well. The difficulty is creating interesting scenarios and set pieces and reducing repetition - I didn't completely succeed with Gravity Core in these areas. I would like to take this further in future games.

The next (free) game won't be procedurally generated as I'm aiming for a simple vertical shooter however I do have another procedural game cooking in my brain.

Monday, 3 October 2011

Lighting Effects

Code is now in place for circular lighting effects (for explosions and shots). The balance still needs to be tweaked but it's coming together and starting to look a bit prettier.

Shrapnel code needs to be finished so that explosions throw out bits of ship.

Comments Fixed

The embedded comments box wasn't working on the blog for some reason. Need to dig around and find out why but I have switched on the pop-up for the time being. Thanks to Ian for pointing this out.

I have also switched on anonymous comments. Hopefully this won't result in spam or abuse.

Sunday, 2 October 2011

Screen Resolution Choice

Do PC games really need a screen resolution choice these days?
This question struck me when designing the menus for the game. Most reasonably modern PC's have LCD monitors therefore the screen resolution for the desktop and in a game should match the monitor's native resolution to avoid blurry pixels. Older (CRT monitor) machines will have a desktop resolution that is suitable for the monitor.

This leads me to think that the game should just pick up the desktop resolution and always use that.

As a side note it's irritating when you install a new game and the resolution is 1024x768 when the desktop is set to 1680x1050 or similar. This seems to be a leftover from a bygone era and long gone are the days when a game has fixed resolution (e.g. Starcraft I).

The only reason I can think of for changing the resolution is to turn down the detail on a bleeding edge game but this will still ruin the crispness of the graphics on an LCD screen. It seems more likely that polygons, anti-aliasing and effects would be reduced.

I might be wrong about this... we'll have to see if there's a backlash when my games don't include the option!

Monday, 26 September 2011

Particles and Shrapnel

Managed to get some of the code in place for the particle system.
Not finished yet another step towards releasable game...

Slow Mo

Just got back from holiday in Cornwall. Had some very nice walks and got the little one out onto the beach - he loved it!

Back in the real world... transferring my domain to a separate registrar. Took me a lot of searching, discussion and frustration to find a suitable one. I was going to go with GoDaddy (recommended by a few fellow indies) but you can't transfer a domain to them somewhat bizarrely.

Ended up going to 123-Reg (thanks Eddie for the recommendation). Their support was notable. I posted about switching to them on Twitter and they tweeted me (spookily). Still haven't got used to companies monitoring Twitter for mentions.

I asked them how long the transfer would take and they came back very quickly with some help how to find out in the Control Panel. Good so far.

Later on I tweeted a more complex question and they responded by phoning me and providing me with some solid advice (my knowledge of Domain Name Servers and the like is pretty basic).

The domain fiddling has resulted in gamedev being rather slooow.

Friday, 16 September 2011


First screen shot of the work in progress. Still a lot of work to do on the visual effects and models but there is something vaguely resembling gameplay now. You can shoot things AND they blow up!

The enemy ships are likely to be reskinned and re-lit at the very least. The player ship will be replaced ultimately but I'd like to keep the same feel as Gravity Core.

Glow effects are still to do, along with shrapnel and other particles being thrown out by explosions.

I'm still keeping the game code compatible with PC and Mac as a I go along.

Tuesday, 13 September 2011

More functionality now completed in the new shooty game. Ships now fly onto the screen, flip and spin then zoom off. Enemy ships can also be destroyed but simply disappear 'in a puff of logic' at the moment. Reminds me... I should really read Hitchhiker's Guide books again.

The menus still look better than the game at the moment...

It has begun

As development of my new game is reaching the point where screenshots are viable, it seems like a good time to set up a blog. I embraced Twitter a few months ago and set up pages for on Facebook. This seems like the next logical step.