Inside3D!
     

Modding Success And/Or Completing a Project?

 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion
View previous topic :: View next topic  
Author Message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Mon Jan 25, 2010 2:17 am    Post subject: Modding Success And/Or Completing a Project? Reply with quote

What would your thoughts and advice be to any given new modder on how to ...

1. Complete a first project.
2. Mistakes/goals that can cause a project to FAIL.
3. What it takes to win.
4. How to gain a reputation as someone who "gets stuff done".

I always liked this little tutorial by LordHavoc:

http://www.inside3d.com/showtutorial.php?id=41
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
ceriux



Joined: 06 Sep 2008
Posts: 968
Location: Florida, USA

PostPosted: Mon Jan 25, 2010 3:21 am    Post subject: Reply with quote

i have issues with all of these cause i cant follow my own rules.

1. Complete a first project.
start small and finish then expand larger
2. Mistakes/goals that can cause a project to FAIL.
aiming too high right off the bat.
3. What it takes to win.
good ideas and content =)
4. How to gain a reputation as someone who "gets stuff done"
just finish what you work on.
_________________
QuakeDB - Quake ModDB Group
Back to top
View user's profile Send private message Yahoo Messenger
qbism



Joined: 04 Nov 2004
Posts: 82

PostPosted: Mon Jan 25, 2010 4:44 am    Post subject: Reply with quote

1. Complete a first project.
Choose the project based on material and human resources that are already available, and clearly define the scope. "Define" primarily means "limit". The modder doesn't need to have all the answers from the start, but needs at least enough knowledge to form the concise questions that bridge from point A to point B.

2. Mistakes/goals that can cause a project to FAIL.
#1 for me is feature creep: Adding "just one more" thing to the to-do.
#2 is "the grass is greener": some other code base or bsp compiler or mod will seem better the moment a commitment is made. At some point put the blinders on to other mods.

3. What it takes to win.
Don't move the finish line after the race has started. When the scope is met, polish it to some reasonable level and release it. Polish may mean beta-testing, writing docs (!), and/or packaging the project neatly. This is only the first project, not the last!

4. How to gain a reputation as someone who "gets stuff done".
Besides literally getting it done, pick a forum or make a site to respond to comments after release. Patch major bugs if you can. At this moment a modder may be sick of the project and not want to deal with criticism or bugs; yet this feedback is valuable to learning how your project is perceived and how to proceed with the next one.
_________________
http://qbism.com
Back to top
View user's profile Send private message Visit poster's website
Junrall



Joined: 21 Sep 2009
Posts: 136
Location: North West Oregon, USA

PostPosted: Mon Jan 25, 2010 5:05 am    Post subject: Reply with quote

1. Complete a first project.
---Break the project into smaller goals.
---Polish up a finished goal then move on to the next goal.

2. Mistakes/goals that can cause a project to FAIL.
---Not staying focused on a goal's end result... such as adding in "cool" features that originally weren't part of the goal. Instead, jot down these "cool" ideas and add them later.
---Getting bored or hitting a "brick wall". Take a break!

3. What it takes to win.
---A polished mod is one thing... try adding detailed help file that's actually helpful.
---If you got time for a few questions... answer them, don't blow people off.

4. How to gain a reputation as someone who "gets stuff done".
---Hop on to a forum and let people know about any goals you have finished and whats next to come.
---When finished, support your mod! Don't let it flail about... take to heart any bugs people tell you about.
_________________
Good God! You shot my leg off!
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Mon Jan 25, 2010 10:24 am    Post subject: Reply with quote

  • Pick achievable goals.
  • Be prepared to let features go if required.
  • Be prepared to accept trade-offs.
  • Keep in touch with your users and listen to them.
  • Ship! Even if it's an unfinished beta, get code out the door, get people using it, and get their feedback coming in.

_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
Supa



Joined: 26 Oct 2004
Posts: 122

PostPosted: Mon Jan 25, 2010 4:38 pm    Post subject: Reply with quote

1. Complete a first project.
Start small. Understand that your goal isn't to complete something neat, it's to learn how to complete something in the first place. Focus on learning as much as you can, not doing. Don't be afraid to make mistakes, but make ABSOLUTELY sure you learn from every single one of them. Most of all, don't get discouraged, try to stay determined. If you're the type of person who gives up on things at all, you will NOT be able to make it in this field.

2. Mistakes/goals that can cause a project to FAIL.
I'm split on this one.

As a programmer, I'd say the only action that can cause a software project to fail is to give up on it. You can always rebuild it, you can always learn from your mistakes, so a goal cannot inherently kill your project - only you can do that.

As a game designer, I'd say any goal that ultimately is a waste of time will make your *game* project a failure. If you're not doing something new or if you're doing something that's counter productive to what a game is, don't bother. :P

3. What it takes to win.
Never stop learning. Never, ever, pass up an opportunity, especially one to learn. Never become engrained in any particular type of thought - if you're thinking in the same manner today as you were a year ago, you just wasted a year. And to repeat myself again, keep a good attitude and try to cultivate paitence within yourself. You WILL lose out on an opportunity and you WILL waste your time and the time of your team members if you don't have the determination and paitence to see a project through to the end.

So most importantly, you have to WANT to win more than anything else, you have to want to see everything you do through to the end no matter what happens.

4. How to gain a reputation as someone who "gets stuff done".
Get stuff done. *Alot* of stuff, because not everything you do will be noticed or make an impact. And keep getting things done. :P
Back to top
View user's profile Send private message Send e-mail
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Tue Jan 26, 2010 2:17 am    Post subject: Reply with quote

Supa wrote:
As a programmer, I'd say the only action that can cause a software project to fail is to give up on it. You can always rebuild it, you can always learn from your mistakes, so a goal cannot inherently kill your project - only you can do that.


Haw! Haw! Haw!

I like it! Very Happy
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
dreadlorde



Joined: 24 Nov 2009
Posts: 86

PostPosted: Tue Jan 26, 2010 2:28 am    Post subject: Reply with quote

Some quotes to live by:

Rob Pike wrote:
Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.

Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest.

Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)

Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.

Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.[9]

Rule 6. There is no Rule 6.

Ken Thompson wrote:
When in doubt, use brute force.

Eric S. Raymond wrote:
Rule of Modularity: Write simple parts connected by clean interfaces.

Rule of Clarity: Clarity is better than cleverness.

Rule of Composition: Design programs to be connected to other programs.

Rule of Separation: Separate policy from mechanism; separate interfaces from engines.

Rule of Simplicity: Design for simplicity; add complexity only where you must.

Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.

Rule of Transparency: Design for visibility to make inspection and debugging easier.

Rule of Robustness: Robustness is the child of transparency and simplicity.

Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.

Rule of Least Surprise: In interface design, always do the least surprising thing.

Rule of Silence: When a program has nothing surprising to say, it should say nothing.

Rule of Repair: When you must fail, fail noisily and as soon as possible.

Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.

Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.

Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

Rule of Diversity: Distrust all claims for “one true way”.

Rule of Extensibility: Design for the future, because it will be here sooner than you think.


And of course, Worse is Better.
Back to top
View user's profile Send private message AIM Address
jim



Joined: 05 Aug 2005
Posts: 400
Location: In The Sun

PostPosted: Tue Jan 26, 2010 3:58 am    Post subject: Reply with quote

dreadlorde, these seems good. Good for other stuff than programming as well.

I've never completed a mod project (fully). Unless single map projects count. Though I should have some answers for mistakes/goals that fail.

Well, my first project failed (released incomplete), because I kept adding too much new features before I had completed earlier stuff. Then there were bugs too, which I might have fixed if I hadn't been so keen on adding new (buggy) features. So don't try to add every cool feature you or someone else can think of into your mod. Most likely some of these features don't even work well with each other (nothing related to bugs now).

Well, then my recent projects have also failed.. much more. But these have failed more due to some depression and indecision on what to do. I also think that they've failed because I started doing them from the wrong point. Therefore I recommend to change the starting point for a project if something keeps failing constantly.
_________________
zbang!
Back to top
View user's profile Send private message Visit poster's website
Wazat



Joined: 15 Oct 2004
Posts: 732
Location: Middle 'o the desert, USA

PostPosted: Tue Jan 26, 2010 6:37 am    Post subject: Reply with quote

Adding new features during a product's development is called "feature creep", and it bedevils many projects both in hobbies and in careers. Sticking to a set of objectives and pushing additions off until later is necessary to get a project finished.

That said, you don't want to never add features or make changes to the design (remember, feedback is important and sometimes an addition or change can make all the difference).

1) Start small, such as a weapons mod. This will be a good stepping stone and you'll learn a lot. Replacing each weapon in the game with one's own creations is how most of us got our start. You can progress to more complex stuff later on.

2) A newbie starting a team of fresh newbies into an ambitious project without a plan or precise, achievable objectives and milestones. That's a good combination of failure triggers, right there. Wink

Remember, there's nothing wrong with being new. You just have to understand that you're just getting started, and you need to start small and work your way up. Even most of the very seasoned veterans here have trouble completing a moderately ambitious project.

3) You have to keep at it. You have to want to succeed, and you must keep going. Many projects die because people get frustrated, bored with the project, distracted by other things, etc.

4) Well... put simply, Get Stuff Done. And do it consistently over the long-term, instead of just at first. Frankly, there are a lot of posers out there who masquerade as good team leaders who will accomplish great things if we all join them, yet they don't have the commitment or know-how to truly see it through. I should know, I'm one of them. Smile

If you want to be known for something, demonstrate it. Someone who gets stuff done? Do it -- make a mod, complete the features, tie up bugs & loose ends, and release the bugger. Repeat with a new mod, or with new features for the newly released mod. Starting small and working your way up is a good way to do this, because you don't want to be in over your head on your first try. Continue to push yourself and explore, but don't lie to yourself (or others) about your abilities. Smile

Show your commitment and continue to make progress, release updates (be that an alpha, a playable prototype, or just screenshots & news), and keep team members motivated. Set moderate milestones and work toward them, so that progress is obviously being made, and a goal is in sight. Then you're getting stuff done, instead of running blindly in the dark and guessing when you can stop.

Being known for getting stuff done means actually doing it. Anyone can craft an image; but to be known for it, you need to live it. Commit yourself to a project and see it through.

</preach>

That's the only way I've ever gotten anything done, and that's mostly at work. I'm lazy about my hobbies, which is why they tend to go nowhere. Wink
_________________
When my computer inevitably explodes and kills me, my cat inherits everything I own. He may be the only one capable of continuing my work.
Back to top
View user's profile Send private message MSN Messenger
Teiman



Joined: 03 Jun 2007
Posts: 309

PostPosted: Tue Jan 26, 2010 10:55 am    Post subject: Reply with quote

I am not a "real programmer" so my list is very short:

1) Don't use magic numbers.
2) D.R.Y.
3) Write easy to read code.
Back to top
View user's profile Send private message
Baker



Joined: 14 Mar 2006
Posts: 1538

PostPosted: Wed Jan 27, 2010 9:05 am    Post subject: Reply with quote

qbism wrote:
Besides literally getting it done, pick a forum or make a site to respond to comments after release.


True --- and make sure the site is hosted somewhere that is going to have longevity. Hopefully somewhere free or very low cost. It used to be that PlanetQuake was good for this. Anymore it looks like may SourceForge is the place, although they only accept open source projects.

Which is good because open source is largely part of the formula of winning too.

The most likely person to use a project's source code is ... the author of project. Far too many projects shoot themselves in the head by losing source code --- to actual code or map sources or model sources.

Winning:

1. Market your work outside "home base". And do it every place that fits, do not be afraid your work will be negatively received. If it was worth completing, it is worth taking a little bit of time to make people who might be interested aware of its existence.

2. Make screen shots. Make a video. If someone doesn't understand what your work is or can't visualize it, that's bad.

3. User feedback, like MH said is critical, and a forum thread can serve as a queue to accumulate bugs or future improvements.

4. Learn proper English, don't type in all lower case, spell words right ... people -- and therefore your project -- get judged by the presentation of the work.

5. Make instructions, and make the instructions "for dummies" because then everyone else for can figure it out.

6. Don't be afraid of your current skill limitations -- if you are trying and listening and making an effort to learn -- those are going to change.
_________________
Tomorrow Never Dies. I feel this Tomorrow knocking on the door ...
Back to top
View user's profile Send private message
goldenboy



Joined: 05 Sep 2008
Posts: 310
Location: Kiel

PostPosted: Thu Jan 28, 2010 5:09 pm    Post subject: Reply with quote

Know when to drop something. Know when to walk away. If something limits your growth, get rid of it; don't feel bad when dumping something. Don't be a masochist. If people treat you like shit, leave them and waste no second thought about it. Take with you and salvage what you can. The fact is, even a failed attempt is a learning experience.

Never, ever overcommit to something. Be ready to make an ordered retreat at any time. Retreat is a very valuable tactic. It can be a lifesaver. In short, when you enter a ship, bring a life vest.

Or better, bring your own ship.
_________________
ReMakeQuake
The Realm of Blog Magic
Back to top
View user's profile Send private message
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Thu Jan 28, 2010 8:13 pm    Post subject: Reply with quote

goldenboy wrote:
Know when to drop something. Know when to walk away. If something limits your growth, get rid of it; don't feel bad when dumping something. Don't be a masochist. If people treat you like shit, leave them and waste no second thought about it. Take with you and salvage what you can. The fact is, even a failed attempt is a learning experience.

Never, ever overcommit to something. Be ready to make an ordered retreat at any time. Retreat is a very valuable tactic. It can be a lifesaver. In short, when you enter a ship, bring a life vest.

Or better, bring your own ship.

That gets my vote. I've seen plenty of projects fail in Real Life because the people who were undertaking them became too invested in them to be able to walk away (or even just say "stop") when things weren't working.

Another valuable RL lesson is that you can deliver but still fail. An example is a project tracking app I'm currently trying to untangle. To say it's an unholy freaking mess would be kind. Oh yes, the thing was delivered, and oh yes, it's being used, but it has all kinds of weird tentacles growing out of it and is completely unsuitable for it's primary customer base - overkill in areas where it needs to be subtle, and virtually non-existent in areas where it needs some meat.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group