How to Write a Game: The Wesnothian Approach
Moderator: Forum Moderators
Heh... as much as I hate it when people revive old threads... I can't help myself here. Reaching the end of my senior undegraduate year, I've come to appreciate this very topic as part of a larger thesis for my senior project.
Err, but first, heh, I should preface by saying how much I enjoy wesnoth. Not to suck up or anything; I've been playing wesnoth for a while now, just never bothered to join the community. So now that I finally got lured in as I mused through the topics, I might as well take the oppurtunity to say "Great game, keep up the good work."
Anyways, on topic. I, like most other software developers, have an understanding of the same problem that you have described; procrastination and lack of motivation, and projects dying early. However, I have also been considering different ways of approaching this problem using an adapted form of a more familiar software engineering model, the waterfall model. Anyways, currently I'm still in the early processes of developing a game as my graduation thesis, so I can't explain my ideas clearly right now, but I -did- notice that many things you described as being part of your development philosophy are very different from the one I am using. Your project being successful, I was just curious if, in the future if and when my project matures, you would be interested in discussing this topic in length; comparison/contrast our software philosophies? Err, I'm really interested in learning something about the process you used, especially given that, from what you have said, it looks very similar to the highly controversial "extreme programming" (aka lame name) development model.
Bah, don't mean to sound so creepy, but the project is required for my graduation, so I'm trying to make it more credible by doing some "reaching" out to some other developers.
Err, but first, heh, I should preface by saying how much I enjoy wesnoth. Not to suck up or anything; I've been playing wesnoth for a while now, just never bothered to join the community. So now that I finally got lured in as I mused through the topics, I might as well take the oppurtunity to say "Great game, keep up the good work."
Anyways, on topic. I, like most other software developers, have an understanding of the same problem that you have described; procrastination and lack of motivation, and projects dying early. However, I have also been considering different ways of approaching this problem using an adapted form of a more familiar software engineering model, the waterfall model. Anyways, currently I'm still in the early processes of developing a game as my graduation thesis, so I can't explain my ideas clearly right now, but I -did- notice that many things you described as being part of your development philosophy are very different from the one I am using. Your project being successful, I was just curious if, in the future if and when my project matures, you would be interested in discussing this topic in length; comparison/contrast our software philosophies? Err, I'm really interested in learning something about the process you used, especially given that, from what you have said, it looks very similar to the highly controversial "extreme programming" (aka lame name) development model.
Bah, don't mean to sound so creepy, but the project is required for my graduation, so I'm trying to make it more credible by doing some "reaching" out to some other developers.
---out of context quote of the (next time I get around to changing it):
"... But thats just because you're turning into a werewolf. Nothing to worry about."
"... But thats just because you're turning into a werewolf. Nothing to worry about."
Oed: Sure, I like to discuss and learn from other programmers
I don't think my development style is that much like Extreme programming, since I don't use pair programming (though I'd like to try it, if I found a good partner), and don't put the emphasis on unit testing that Extreme programming does.
Good luck with your project!
David
I don't think my development style is that much like Extreme programming, since I don't use pair programming (though I'd like to try it, if I found a good partner), and don't put the emphasis on unit testing that Extreme programming does.
Good luck with your project!
David
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
In my opinion extreme programming is a little too.....extreme. I read about it in a magazine and how it "saved" this software development company in California, but it just seems so iefficeint to me. Besides, I would feel creeped out if I was programming and constantly had someone standing there, watching me over my shoulder.
Hero of Allacrost, a 2D open source RPG. Check it out at http://www.allacrost.org.
I think pair programming could work very well with two people who are very 'in sync' with each other. However, given two arbitrary programmers who are pair together, I'd say about 1 in 10,000 would be a suitable match
David
David
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
- Viliam
- Translator
- Posts: 1341
- Joined: January 30th, 2004, 11:07 am
- Location: Bratislava, Slovakia
- Contact:
From my experience, I find it better when there is always possibility to discuss the project with someone, who also deeply understands it. Also, 90% of problems take 10% of time, and 10% of problems take 90% of time -- but what is a problem for one programmer, does not have to be for another, so sometimes the project can be split to two parts, where each of them takes the "10% of time" for its author. (Good modularity solves a part of this, too.)Roots wrote:Besides, I would feel creeped out if I was programming and constantly had someone standing there, watching me over my shoulder.
Of course the personalities must "match" each other. BTW, the longer I do programming, the more I am convinced that writing the code is the least important part of the process. The sooner one starts to write, the more one has to re-write. Not being able to write (because another one sits at the keyboard) can be a good opportunity to think. Somehow I noticed that the more I write, the less I think, and it is very useful to stop, and liberate my hands from the keyboard for a while.
I've recently finished a programming project using extreme programming-and I wouldn't recommend using it unless you have a very good reason to do so. The aim of the project(apart from writing software) was aimed at testing the value of extreme programming with a small team of programmers in the APL language, and see if it worked faster than conventional models.
If you try it, be REALLY sure you have a programming partner that thinks and works like you do-or it will be a loooooong project. Also, count on several days/weeks just getting into the specific type of working together required for XP. Also, ignore the rule about changing partners every so often, it will delay any project immensely. As for the other rules of XP, just use the ones that make sense to you from the start, and don't continue using a rule if it doesn't work for you.
If you try it, be REALLY sure you have a programming partner that thinks and works like you do-or it will be a loooooong project. Also, count on several days/weeks just getting into the specific type of working together required for XP. Also, ignore the rule about changing partners every so often, it will delay any project immensely. As for the other rules of XP, just use the ones that make sense to you from the start, and don't continue using a rule if it doesn't work for you.
Project leader of Heroes of Ardania (http://ardania.havocaos.com/)
One thing I might add ... keep a diary of what you do on the project each day. I've found that when I hit the wall through a sudden drop in motivation or a seemingly insurmountable problem, reading back through the progress I've made in the past tends to put things in perspective & make me want to keep at it rather than drop the project. Its also good to have a record of what you went through rather than get to the end & wonder where all those months/years vanished to.
Re: How to Write a Game: The Wesnothian Approach
Not to bring the focus off XP or anything, but David's methodology just blew my mind.
I've worked on many projects now, most of them have failed, miserably, and I have to say, the ones that haven't failed have been the ones that either:
1) Kept the intrinsic motivation. (As Dave says, "Early Gratification")
2) Has had external significance. (Release early, release often.)
Both of which Wesnoth has been doing since it's initial release.
-mjg
P.S.
What is remiscent of XP from Dave's methodology is it's inherit agile philosophies. (See http://c2.com/cgi/wiki?AgileProcesses).
I've worked on many projects now, most of them have failed, miserably, and I have to say, the ones that haven't failed have been the ones that either:
1) Kept the intrinsic motivation. (As Dave says, "Early Gratification")
2) Has had external significance. (Release early, release often.)
Both of which Wesnoth has been doing since it's initial release.
-mjg
P.S.
What is remiscent of XP from Dave's methodology is it's inherit agile philosophies. (See http://c2.com/cgi/wiki?AgileProcesses).