Wednesday, 17 December 2014

Never leave well enough alone

Wednesday, 17 December 2014
A problem with any mature homebrew system is that it doesn't necessarily mature at the same rate you do. I started Icar when I was 14 years old: mutants, guns, killer robots, warrior monks, more guns were all prime features. As I grew up, so did the game, settling on its core mechanics in 1996. Since then, the largest change has been Space Combat (which got more complex then less complex) and Hacking (which got less complex).

I believe that if the ethos of the game's background is strong enough, you can swap out the mechanics without too much harm. DnD has done that successfully for years. You might not like the mechanics on any given iteration but the DnD ethos of background and core concepts remains familiar enough to be called DnD. I've even (semi-jokingly) suggested swapping out all the Icar mechanics for the lightweight Shared Pool; just to see if it was still fun to play.

Backgrounds can mature, mechanics can be swapped but that leaves the assets of the game: its art, layout and phrasing of text. As your experience grows and the tooling becomes more affordable, you will undoubtedly find that the assets do not age well. You can see how much the Droid poster-child, the Mk3 has evolved over the years on the right. It pains me to post the old images but I hope it helps budding artists see a very long progression!

Perfect is the enemy of done

I'm a tweaker. I tweak. Endlessly. I see something I am not happy with and I want to change it. Once I have seen something that I'm not happy with, it will eat away at me until I do something about it. I know that it is useless to fight it. It's part of what makes me me.

Raymond Loewy, a legendary industrial designer, wrote the book "Never Leave Well Enough Alone" where he made the case for looking at things that had a long established style and then changing them. When creating an RPG from afresh then I would recommend doing just that - looking at the long established style of fantasy/supers/sci fi/modern RPGs and then changing them. When you have a lumbering monolith of 20 years work, you can't do that - you would end up going around in circles. In that respect, working on mature games is just like writing a new one. Sometimes you have to accept that something wasn't quite right and move on to the next thing.

Not quite following my own advice

Icar began life on a Zenith 2Mhz PC, single colour (yellow Hercules monitor) with dot matrix printer and everything saved on a 360KB 5¼ inch disc. Today Icar is created on a PC running four cores at 2.67 GHz with 12GB of RAM. The current Icar assets folder is 11GB on a 2TB drive. When I started doing the 3D models in 1996, I had a 200Mhz computer and a modest render would take a day and a night, in 1999 I went to 400Mhz and it would take the same time because I would use more complex models! The more I learnt, the more power I needed. Spare time is my new enemy.

While working on the Fleet Setting book (check my progress on Trello), I have been detailing the Droids and I'm up to the Mk 5 (the Droid pod). The Droid pod is a one-use spacecraft for delivering a clutch of Droids to a planet's surface. I wanted to start the model by clustering together a clutch of Mk3 Droids (my favourites) and building around them.

Then I started to see the errors in the model and began fixing them. I finished four hours later. To help you understand why I had to change it, I've put together an image that points out what I see when I look at a render. You might need to click through to the large image as the details can be subtle. Icar's rulebooks are all created at 600DPI and downsized to 300DPI for the PDF, you'll see them at 300DPI.

Powered by Blogger.