At EuroMysterium 2005, I gave a presentation related to the experience I got while working on a group Agebuilding project called Verenia. It contains lots of guidelines and hints for everyone who is wanting to start a new game (whether it's an adventure game or not, Myst-style or not, doesn't matter).
The presentation slides are available for download (1.9 MB; PDF).
A presentation with only images and no speech doesn't make a lot of sense, so I made this page, which contains the text of my speech. I wrote the text in a hurry, so don't blame me for inconsistencies, grammar error, spelling errors, etc.
Let's get started.
This presentation is about Verenia, an old project of mine, an adventure game. More specifically, this presentation is about the experience I got while working on Verenia. This presentation should be especially interesting for those who are thinking about starting an adventure game.
On this slide you can see some Verenia concept art. For those that don't know yet, Verenia has been canceled. It failed. It's dead and it's not coming back.
Why did it fail?
Firstly, I didn't have enough experience. I had never ever done something as big as Verenia before. I did have a few experienced people by my side, but that was not quite enough.
Secondly, I was too ambitious. I was overconfident, I really thought I could make Verenia into something great.
There was no decent project lead either. Again, I didn't have enough experience as lead developer. I delegated too many responsibilities to others.
There's much more, and I will explain everything in detail in this presentation.
I made this presentation to show you what exactly went wrong and why. I'll sum up many do's, many don'ts and many guidelines for everyone who's wanting to create a game. I believe that what I'm about to tell you in this presentation has a great value because I'm writing this out of personal experience.
Verenia started by drawing some random sketches at school. I must have been bored or something.
At some point I scanned my sketches and showed them to random people, and there was one guy which liked my sketches so much that I just had to make a Myst-style adventure game out of it. And so I did!
With a very rough storyline in mind I started advertising everywhere. It didn't take long before I managed to assemble a huge team.
I assigned every team member a job and I was naive enough to think the hardest part was over. As it turned out, nothing was less true.
Verenia had a bad start, and the way it started, Verenia was doomed to fail.
First set of guidelines: assembling a team.
You will need a team if you want your game to become successful. You will need age designers, modelers, texturers, musicians, programmers, and many more people.
However, don't start with a large team. Keep it small! Four people is enough; you can recruit more people later if there's a need. Small teams advance much more quickly.
Set up a good and reliable means of communication. You will need working e-mail and proper forums. There's nothing more important than effective communication.
You'll probably also need a multidisciplinary team. It will enhance the sense of realism greatly. If possible, try to recruit physicians, biologists, engineers, and more.
Assign everyone a job. If they don't know what exactly they're supposed to be doing, they won't work and leave. If their job is finished, give them a new job immediately or as soon as you can.
Very important is that you stay in control. Don't let anyone take over the project. If you can't lead your own projects, other people definitely won't be able to.
Obviously your team needs to work. My experience has told me that your team mates only work when you work too. Don't do nothing; people will stop working and it's difficult to get them back on track. If you're really unlucky, people will leave and not come back. Ever.
A friend of mine, Sivrehn, who is currently working on Ilathid, came up with the idea of having some kind of "developer activity meter". Every developer has his own "activity score". On a scale from zero to ten, a score of 0 would mean that the developer is doing nothing, and a score of 10 means that the developer is working very actively on the project. It might be a good idea to have a similar system in your project.
A sidekick is very useful. If possible, have a sidekick who lives close to where you live. It'll speed up development much faster than interacting over forums.
If possible, have a public relations department (really doesn't have to be big, maybe one or two people). PR people should keep members updated about their assignments, advertise and invite talented people.
Let teammates influence each other. For example, a musician can help define the "feeling" of an age. As long as musicians don't start creating ages by themselves, it's fine.
Verenia's team was too big. I recruited too many people at once. By the time some team members were needed, they were already gone because they lost interest.
The team was a bit of a chaos. I assigned everyone a job, but the developers were working on each other's jobs. This slows development down a lot, and some developers even quit because others were doing what they were supposed to be.
The latter was probably because I didn't have enough control over the project. "Do whatever you like" doesn't work. Honestly.
At Verenia I started recruiting everyone straight away: modeller, texturers, musicians, programmers, etc. Some of these people didn't have anything to do, so they left. Eventually everyone was gone, and we still didn't have a good storyline or decent age designs!
Writing a good storyline is very important. A decent storyline is, in fact, more important than good-looking graphics.
Designing ages is probably what you will start with, but it is not the most important. The storyline should come first. Design your ages around the storyline, not the other way around, because adding a storyline to a couple of ages is difficult. A basic idea of how the ages are going to look like is fine, though.
You should write the storyline with very few people. If possible, write the entire storyline all by yourself, and then discuss it with others to enhance it. Don't start writing a storyline with your entire team; there'll be more plot holes than storyline.
Verenia did it the other way around. I started with a couple of age designs, then decided to make a game out of it, which meant adding a storyline later. It didn't work. We tried dozens of storylines but none of them worked.
All storylines were full of plot holes.
Everyone was working on the storyline. It kept changing, new ideas popped up all the time. Half of the time I didn't even know what the storyline was like. (I still don't.)
Every developer uses his or her own programs to do what he or she wants to do. Different software means different file formats, and different file formats usually means trouble. Two 3D modelling programs can use completely different file formats. For example, merging two islands made by different programs can be troublesome. Try to stay compatible; find a way to convert one file format into another before it is too late.
Also, it is important that you stay legal. Don't let people use illegal software, especially when you're going to sell your project. If you use material made by someone not on your project, give them credit.
Don't create a hype too soon. Everyone gets this wrong. I made the same error with Alurio. Only show screenshots or pictures of your game when there really IS something to show, and not before. If you don't, people will get interested too soon and lose their interest when the game's ready.
Keep your project's files secret. Don't let anyone leak pictures or screenshots or movies. It may not be a bad idea to have every developer sign a Non Disclosure Agreement.
Keep all files on a central web server, where all developers have access to, where every developer can upload their work so other developers can see and judge it. Don't forget to back up regularly, there's nothing worse than losing a month's work!
Show your progress to your developers. They'll realise that the project is being worked on, and it will encourage them to contribute. Roadmaps are very useful for that. Internal newsletters are a good idea; keep all developers up-to-date.
Deadlines: it is usually pretty difficult to set precise deadlines, but they should still serve as guidelines in order to get things done in time.
Research is crucial, especially when your game is set in a universe which is constantly changing, such as the Myst universe. Don't make a Myst game which uses trap books!
Stay compatible on the player's side: everyone wants to play your game, and not everyone has the latest high-end computer. Keep the system requirements as low as possible to allow almost everyone to play your game, because that's what you want.
At last, but not least, a decent web site helps a lot. People will not be interested in your project if the web site is bad—even if the project itself is doing well. A decent web site is necessary if you want to recruit people.
So, these are some hopefully useful guidelines that should get you on your way of making a great game.
Now, there's a couple useful and interesting web sites I'd like to show you.
First, there's Trac. This is a very, very good project management system. At the moment I use it for Alurio. Definitely worth a look.
And, there's Ilathid. Ilathid is a project run by one of my friend, Sivrehn, who also worked on Verenia. This game was started when Verenia was cancelled. It's doing very well; I suggest you check it out as soon as you can.
Thank you for your attention! I hope this presentation really helps to get you and your project started well. Good luck!