 |
| |
|
|
Velociryx
|
 |
of Candle'Bre
Apr 1999
time: 05:25
|
|
I started this….informal diary at our old site, and figured that now….new year….the dawning of the second year of our adventure, it might be a good idea to pick those threads back up here, in this place, since it will be here that we look to for player input.
These notes are mostly for myself, but I believe that they could hold valuable bits of information for anybody who has the notion in their head of striking out into uncharted territory and trying to create something new.
Perhaps not, and if not, then at the very least, I’ll have these notes for my own reference.
Who knows….it might even make a half-interesting read….
****
January 30th, 2003
Stuff I’ve learned over the past year:
1) Indie, volunteer-based project don’t do timetables very well, and you set yourself up for disappointment if you put much stock in them. This is because….$hit happens. Real life occurs, whether you want it to, or mean for it to, or not. And because of the rampantly unpredictable nature of real life, if you are hell-bent on using a scheduled approach in a volunteer driven project, you’ve got to build in an allowance for that rampant unpredictability….which of course means, you make a guess, based on your latest hunch of the moment. SWAG methodology (Scientific, Wild-A$$ Guessing). And that’s just the way it is. The reason for that, if you wanna delve deeper into it, is because you’re working with people who are DONATING their time and energies to the project. You’re not paying them, and you have no hold over them or how they use their free time. Put their feet to the fire for missing an arbitrary deadline, and you’ll find yourself with one less volunteer, and worse, you’ll get the reputation as a hard-case, and new people will be less likely to volunteer in the future. By far then, the best answer is to throw the notion of an ironclad schedule out the window and wing it. Sounds crazy….sounds counter-intuitive, but it’s the truth. (and along the way, you’ll find yourself getting increasingly better at using SWAG methodology, which means your guesses will increase in their accuracy, and it will appear that you know precisely what you’re doing! Groovy side effect, that).
2) Be happy when people tell you you’ll fail. Might as well be happy about it, cos you’ll hear it, and you’ll hear it from pretty much everywhere. When we started out, I heard it from here on ‘poly, I heard it from my friends at work, my family….all over the place. Nobody thought we could do it, and maybe in the end, they’ll be right. But they haven’t been right so far, and that’s what I’m focused on. See….that’s the kind of thing that if you let it get to you….if you let it eat away at you, it will….you start focusing on the negatives and you forget about all the progress. At that point, you’re as good as sunk. Don’t be stupid. Don’t fall for the obvious trap. Take what the naysayers are telling you, and use it as fuel for the fire. Everybody who’s telling you that you can’t is actually telling you can, but in reverse….just put the image in your mind of the naysayers wiping egg off of their faces when the game is released, and you’ll be fine. Let them have their say. Don’t argue about it, just produce results that proves them wrong. At the end of the day, that’s the only thing that matters.
3) Don’t put any stock in statistics. Yeah yeah….98% of indie projects fail, blah blah blah. So what? If you focus on that 98% figure, you’ll almost certainly fall into its range. Ignore it. Do what you do and let the chips fall where they may.
4) Every project needs a leader. Design by committee works. We’ve proved that it works, because the discussions here and at our design site have generated ideas that no one person could possibly have thought of. But….when the chips are down, there needs to be ONE person who says with authority what’s in, and what’s out. That’s the way to keep a unified design. That’s the way to make sure it all hangs together. Not to degrade the value of group discussion in the least, because that’s where the real magic is, but when the dust settles, there needs to be a singular person acting as the gateway between idea and implementation, and that person had better be prepared to take some lumps here and there if the issue or feature under consideration has strongly polarized supporters/opposers.
5) The project leader needs to be prepared to learn new stuff. Fact is, you may or may not have all the expertise you need to make the project fly. If you recruit all the right skill sets, you’re either amazingly lucky, or you’re paying them under the table. The reality of indie projects is that you won’t have access to an art guy to work on a particular component just at this moment. You won’t have a sound guy to make special effects for you, and because of that, even if you know NOTHING about it, if you want the project to succeed, you’ll get in there and learn it. You’ll throw yourself into it and get something going. Maybe it’s not perfect, and maybe it’ll be replaced later on when you DO have someone with the skills to make a better widget, but in the here and now, if you want progress, you do what needs doing, and you don’t b*tch about it.
6) The project leader needs to be prepared to spend some money. Money = faster progress. You don’t need to wait around to find a sound guy, and you don’t need to spend months teaching yourself to play a few instruments. Just drop the coin and buy some freakin’ music. Make it happen! The team is looking to YOU, as project lead, to make stuff work. To bring the pieces together. Not that learning to play a variety of instruments is a waste of time, but in terms of bringing the project to conclusion, it surely is! You can’t teach yourself all that AND get good enough to get anything close to production quality music out of the effort in any case, so if you find yourself lacking in a particular area, spend the money and make it work.
7) Roll with it. Roll with every wave, every upset, every startling new event, and every setback you are confronted with. Don’t try to meet them head on, just be flexible enough to handle it. This will at times, call on just about every skill you’ve got….patience, diplomacy, tactfulness, and above all else, perseverance. If you are not prepared to weather the storm, then don’t go out in the rain in the first place. Find another hobby with fewer headaches and potential pitfalls. That would be my recommendation, anyway.
8) Diplomacy, honesty, and mutual respect are the keys to avoiding big, flashy blowups between team members. In the year that we’ve been together, there have been times where different groups have disagreed. It happens. Not once has this resulted in a big blow-out flame fest in our team. We’ve had members come and go, we’ve had members drop out for a time because of real life issues. We’ve had members just vanish entirely without a word, but we’ve never had a flame war in the entire time we’ve been together. If you can’t keep a team together without putting them through a periodic flame war, find something else to do. Flame wars are more destructive than anything else I can think of. They scar the project in all sorts of unseen ways. Fracture and weaken your progress. If you have one, seriously consider temporarily shelving the project for a cooling off period. Don’t try to work on it in anger. It will show.
9) Be prepared to do a lot of research! Even the most awe-inspiring designer doesn’t know every d@mned thing, and if it’s relevant to the project, don’t wait for someone else to do it, jump in there and do it yourself. Later on, if you find someone who’s a natural fit for whatever it was you’re researching, by all means, turn it over to that person, but don’t just expect stuff to happen….MAKE stuff happen!
10) If you’re the guy (or gal) in charge, always remember that although you’re the one that people see most often, you’re not the most important member of the team! Fact is, without the people working with you, you’d be a big goose egg. Nothing. Worse than nothing, cos you’d be a guy with an idea, but with zero in terms of execution. Ideas are cheap. Execution is everything, and it’s the efforts of the team as a whole that drives the execution, not you. So…don’t go thinking you’re more important than you are. Good way to derail the project, that.
We made….no…correction, *I* made a lot of mistakes along the way from start to where we are now, and if I had it to do over again, here’s what I’d do differently (I post this here so that other folks considering launching their own projects might avoid some of the pitfalls we encountered).
1) Think small. Don’t try to design the game lock, stock, and barrel right from the start. Rather, use an organic design process. One of our team members (Gasdd) lobbied strongly for a very small feature set we could start coding on right away. Get that working and build on it. We shoulda listened. That would have been the better approach.
2) If you’re not a programmer, put ONE person in charge of code. That person can have help and backup to work on specific segments, but there should be one person who designs the code, makes all the variables, and sets stuff like that up. This way, your program has internal consistency and cohesion, rather than being a laundry list of component parts (lesson from DeepKimchii).
3) Don’t wait for volunteers to say “hey, I got some free time…I can begin work on X” Keep a constantly up-to-date list of stuff to work on, and actively solicit help from team members who aren’t presently involved in a particular project, and who are “idling” at the moment. If people have free time, fill it.
4) Take time off! Don’t work on the project nonstop till you burn yourself out and then have to take a month off to recover. Small doses, mixed with small breaks.
Perhaps the biggest lessons learned though, are these. However long and hard you imagine the process of creating a game to be…..double it. Then double it again. At least.
At that point, you might be somewhere in the ballpark.
Second, building a whole new world from the ground up takes time, so don’t think you’ll be able to do a bit here, and a bit there and see tangible signs of progress right away. If you’re looking for the instant gratification of tangible signs of progress, take up painting or something. This probably isn’t for you. You’ve got to be willing to stay up for two and three days at a time hammering out rules and clarifying things so the code team knows what the h3ll you meant to say, write, re-write, and then re-write some more.
You’ve got to be willing to make yourself available to discuss even the most minute detail of the game world, cos it just MIGHT matter in terms of the game, and you’ve gotta have it covered, just in case. No detail is too small….nothing is unimportant. Be prepared for the long journey….be prepared to go months without seeing tangible signs of progress, and you just might make it….
More later,
-=Vel=-
|
|
| |
|
|
|
DeepO
|
 |
supporting Candle'Bre
Jan 2002
time: 06:25
|
|
Vel, a very good list... you obviously thought a ot about it. But there are 3 things you forgot to mention...
1) The leader needs to put in a lot more time then he is expecting anyone of the other members to contribute. It might seem trivial, but if I can only guess to what kind of time you spent on this project, I'm dazzled... It really is part of your life for a long time.
2) The leader needs to type faster then anyone else.
Quite handy in chats, or in rewrites (which happen often). If you weren't a writer with a lot of experience in creating massive amounts of text, I doubt that we had come this far.
3) Create a fun place to be, instead of a dry project where the only thing one can do is work.
The minicontests have been nice, but one of the things that has appealed me most from the start CB is that from time to time, we see stories appearing, which are incredibly fun. They help to bring the team together, as everyone will find it easier to donate time if it is in the first place for friends. Creating a friendly atmosphere is harder then it looks, but CB has certainly succeeded here.
DeepO
|
|
| |
|
|
|
Velociryx
|
|
of Candle'Bre
Apr 1999
time: 05:25
|
|
 As always, DeepO, you fill in the blanks I miss! Thank you! And thank you for the kind words, too!
Your first point brought me up short....I guess I never really sat down and thought about how long I spend per day working on the project. If I had to make a guess....sheesh...I'm not even sure I could!
My boss here at work has graciously given me an hour a day of work time to devote strictly to the project (that's time I don't have to do anything work related at all), and I can usually squeeze another hour or so in, in-between stuff at the office. So that'd be two hours a day, get home by 6:30, eat dinner, and start working at around 7:30 (rounding up to 8, to keep it simple...LOL), wrapping up between midnight and two in the morning, so we can average that to 1, for another 5 hours. Six days a week, allowing for a day's break in between, and sometimes longer if I'm going out of town. Figure a minimum of 300 productive work days on the game....::shiver:: I don't even wanna do the rest of the math!  Couple thousand hours so far, and about a trainload of sweet tea!
The second point got a chuckle outta me, too! It's true....of all the classes I ever took, it's the typing that I use most often...by far. And it really has come in handy! As you say, there was an extended period where we were revamping and revising rules, tightening things up and making changes right and left to get the core systems in place....all of that could have taken considerably more time if not for good speed at the ol' keyboard. So...I learned to type on a Royal Electric....*G* The principles are the same at least....
And the third...ahhhh yes! That's where the magic is, in my mind! It is my hope that when we officially move into "Beta Release Mode" and start getting people playing the game, we'll see an outpouring of game related stories and such! Might even host some contests along those lines.....
Excellent additions, Master DeepO....and thank you again....
-=Vel=-
|
|
| |
|
|
|
Velociryx
|
|
of Candle'Bre
Apr 1999
time: 05:25
|
|
More notes to help folks considering starting their own indie project:
Continuing along the lines of stuff I’ve learned over the past year, here’s a few more tips, tidbits, and pointers that would-be project leaders might want to keep in mind:
1) Figure out if you’re a generalist or specialist early on, and play to your strong point. In my case, it’s an easy one. I know a little bit about a lot of different stuff, but the few things I know a lot about aren’t really relevant to the nuts and bolts of putting a game together. Therefore, I classify myself as a generalist. I’m not the guy that coders can come to if they run into something they can’t figure out. I’m not the guy who’s “up” on all the most advanced anti-aliasing techniques in photoshop. And I know that. What’s groovy about knowing that is the fact that there’s a certain power that comes with that knowledge. Because I know that I don’t know, I also know who I need to recruit. I need to recruit specialized folks who DO know, and get them jazzed about the project. And further, once I HAVE some specialist folks working with me, I need to make sure they have lots of interesting stuff to do, and make sure that other people on the team KNOW who the specialists are. That way, if there are problems and questions, we know who to ask! Sounds minor, sounds self-evident, but you’d be surprised how sneaky this particular little detail can be. Save yourself some time and trouble. Analyze who you are and what your strengths are, and be honest about it. You’ll be able to better figure out what kind of skill sets you need.
2) People first, skill sets second. This kind of project is LOOOOONG term. It’s not two weeks and you’re out, and because of that, I would rather have ten marginally skilled people who got along well than 2 highly skilled people who get on each other’s nerves and can’t work together. The friction that would result would be bad for the project. Probably bad enough to sink it. I’d rather not take the chance. (fortunately, we’ve been able to attract a cadre of folks who are both very skilled AND who all seem to get along quite well, so this hasn’t been a problem for us).
3) Don’t micromanage! People sign on to indie projects because they’re jazzed about the concept, not because they wanna feel like they’re trapped in cyberspace with the babysitter from Hell! Don’t be that person! Let people know what needs doing, and in what order, get people interested in doing those things, and let them go! Don’t go badgering with “is it done yet?” e-mails, and don’t treat people like they’re morons. You picked these folks to be on the team for a reason. Stay the hell outta the way and let them do their thing.
4) Know when to break the rules. Sometimes you gotta step in, either because tension is rising between two people, or because real life issues are impacting the ability of someone to get stuff done (and oftentimes, if you get people who are really into the project, they’ll be loathe to admit that they really lack the time to do it justice). So when faced with that, don’t let it fester for months. Write an “is everything okay” e-mail. Talk to the people in question. Make it work.
5) You can never have too many art and sound guys. No such thing.
6) You GET good people by having a good, exciting, original concept (nobody will get excited about working on what is essentially yesterday’s news). You KEEP good people by creating an interesting and engaging environment, and by making sure they’ve got interesting and engaging stuff to work on.
7) ASK! If a day goes by that you’re not asking questions….to the team, in the public forum, in private messages or e-mails, to total strangers who have skills your team needs, then you are not doing your job, as the leader of the group. If you need to ask what to ask, then you don’t need to be the leader, and that’s okay. That’s better than okay actually, because it means that you will (if you follow the thinking to the next logical step) find someone who KNOWS what to ask, and get that person excited about your idea. He’ll lead for you, using your vision as a guide.
8) See the team as your family. You’re gonna be with them, and they with you, for a long, long time (see above, the point about this kind of project being long-term), and hand in hand with that, PLAN for the long term. Nope….you probably can’t rely too heavily on schedules and such, but you can generally order things, and get to them as you get to them, and do that…project your thoughts and ideas on a rough timeline into the future. That will be your guide….your roadmap.
Almost seems like I’m writing a “strategy guide” for indie projects, doesn’t it?
-=Vel=-
|
|
| |
|
| |
|
|
|
Velociryx
|
|
of Candle'Bre
Apr 1999
time: 05:25
|
|
Yep....I 'member that now....IIRC, 'twas in the original "Crest of a Knave" thread, over at the old forums....groovy....
And it really IS just like that....there are dangers, traps, pitfalls, unexpected attacks on the flanks....everything about the *process* of taking a game from concept through design, and on to finished product relates directly to strategy gaming in general.
Using that as a frame of reference makes me much more comfortable than I might otherwise be, cos with that thought in my head, I'm in familiar territory. We're playing a big, real time, multi-player, cooperative strategy game....cool....
-=Vel=-
|
|
| |
|
| |
All times are GMT. The time now is 05:25.
Apolyton Time is 00:25. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
30-01-2003 22:07
|