Archive for May, 2006

Silo

I’ve been beta testing Silo for the past month or so. It needs more work, as all software does, but already it’s very strong.

It has been no secret to many that I love Silo - it’s light, powerful, intuitive. After using Max and Maya, Silo is an absolute joy to model in. Version 2 is taking that and making it better - not by adding hundreds of new features, but by adding a few. There has been a core rewrite making it lightning fast, and many of the existing tools have been ‘re-engineered’, combining them and making them more context sensitive.

Hopefully the folks at Nevercenter will get me a Mac version to test soon.

My sculpting tools turned up today (must leave positive feedback), and look great. The trouble is I now have an overwhelming urge to practice dentistry on a child. I got a link to the Shiflett Brothers website, with plenty of examples and tutorials, so now I have no excuse. Even the house is almost done - we painted the guest bedroom tonight.

Mods - why I decline, and how they can be better

What are mods?

Mods are modifications of an existing game, usually for a first person shooter on the PC. Counterstrike began as a mod, and is one of the most popular online games of all time. Some are quite simple, and just add a few rules and some new artwork, while others are complex - total modifications - where you wouldn’t recognise the original game beneath all the changes.

Mod teams are a great place to look into all the aspects of game editing. They more or less give you the opportunity to be in a non-profit games design company. You will be working with other games players who have gotten involved because they like the idea of the mod, and want to gain some editing experience. I’ve worked on several mods in my time, and still get asked to participate regularly.

Why I don’t work on mods

In early 2006 I was approached to help with a mod. I declined, these days my life is too precious to spend my free time making game art. I also have to be careful with *any* mods - technically ANY artwork that I create, even outside work does belong to the company. Website and photography etc. is fine, but any game work can be considered to be in competition. I am sure many game artist have the same contractual obligations.

So, as per usual, I refused to help.

However, on this occasional the request was well written, and rather than a simple refusal, I explained my reasons for not joining and gave what I considered to be some useful advice. The reasons for refusal are the same that many artists need to give and the advice is sound, so I thought that it would be useful to share.

Since I thought it was useful, I thought it might be worth sharing, and perhaps expanded on.

The refusal

Thank you for considering me for your mod. However, on this occasion I will have to decline.

Nevertheless, the offer you sent was well written, and the mod you are working on seems more interesting than many. Because of that, I feel that I owe you a more lengthy explanation for my refusal, and some advice that I hope will be useful to you.

I’ve worked on mods in the past, and I’ve been in the games industry for several years. I’ve worked on some the best and worst selling/rated games, and by now I have an fairly good idea on the reasons why projects can succeed or fail. Please forgive me if at any point I sound critical, you will understand that I don’t know you or any members of your team, or any of your working practices. Much of this may be obvious to you, but there might be complete mods if some of these points were considered.

What mods need

Have you got a concept? A general 2 paragraph concise description that sells the idea is vital. People do not need to know the entire backstory before a game is playable.

Have you got a design? A story is NOT a design. A design document should be a record of everything about the game, BEFORE the game. A design document is fluid, but from an early stage several key elements should be fixed down. Above all it must be comprehensive. Document EVERYTHING - sound, control systems, gameplay elements, missions, models, textures, naming conventions, stats, progression etc. You have to describe everything in a way so that no-one can misunderstand. If you are working on your own, you can forego this to an extent, and just experiment - the best ideas often come this way. Nevertheless, even when working by yourself you will likely find it very useful to record and structure your ideas - for future reference if nothing else.

Have you got a timetable? You must have specific dates for completion of assets and milestones. Setting one or two milestones is not enough - people need to see a lot of short time achievable goals. These can be daily, weekly, monthly - whatever is needed.

Does each member of the team know their job roles? Do they know exaclty what is expected of them, and what quality level of work they are expected to deliver? Do they know what everyone elses role is? Many people miss that last step, but it is vital to know what the other people around you are responsible for, if only to know who you can delegate to, and who you can ask for help.

Is there a project manager? In the old days people thought the project managers were the dreamers who could not contribute. This is not the case, and a good project manager will work as hard as asset creators to ensure that every team member has everything they need. They will make sure all assets are delivered on time. A project manager is often called a producer. ANYONE can be a producer, but very few people do it well.

You must release your work little and often. Waiting months for a stable release is pointless. You don’t need all the animations, all the characters, all the levels before you can begin showing off your work. In most games companies there are personal copies of the game on everyones computer where people can test their own assest and code, then once a week or so these are all compiled into a new updated version. This is used as everyones base for the next weeks work. This means that everyone sees what other people have been up to, and can catch potential problems earlier. If you are modding an existing game hen you need to remeber - YOU HAVE AN EXISTING WORKING GAME! Get something new working, then quickly get people playing and testing. After this you can add more content and gameplay. Rinse and repeat.

Remember - you are doing this to have fun. You are not getting paid, and neither are the other people.

Further notes

Writing this from the point of view of an artist, I would recommend that you retain all rights to your work if the mod fails.

Portions of this article were cannibalised from an early article also written by myself.