Top Mud Sites Forum - View Single Post

Ide · 03-08-2010, 12:43 AM

Well...I know this is classic, but please accept my apologies for reframing your question.

First of all, memory management is basically a non-issue with a dynamic language such as Python, which is perfectly suitable for writing a mud. Furthermore, to continue with the Python example, there are at least two excellent library options (Twisted and MiniBoa) to take care of networking. So that's done too. I'm sure you could find similar options with other non-C-like languages.

Program design is of course the crucial third leg you'll need to stand on so to speak, but that's really no different from game design (in fact, it's highly dependent on your game design) when you get right down to it. So if you're doing one there's no reason you don't have the intellectual capability to do the other, and I think you should, for reasons which I'll get to in a moment.

While it may be bad form to recruit from your current games, I don't think that should stop you from doing it. In fact it's your best option, and if you're not willing to do it, honestly I don't think you should consider starting a game of your own. However let me say this doesn't mean you make a recruitment post on the game forums or whatever; I'm just talking about friends or people whom you've developed a trusting working relationship with over time. Because while it's not unheard of to find someone like this with a general ad on TMS or Mudconnector or so on, it's highly unlikely. IMO It just doesn't make sense to eliminate out of hand your best option.

All that said...

The only coders you want to attract to your game are ones already doing projects. The only thing that will tear them away is if you have done something cool. In my opinion this means, at the very least, taking a stock codebase and rewriting and rescripting many of the areas from scratch, or, if possible, showing them the work you've done on other muds, whether that be areas or systems code, or just other games you've done in general, such as RPGs, graphical games, etcetera.

While you may recruit other coders with a simple ad, or perhaps some background stories or sketches of your game design, I don't think that will result in a successful working relationship in the end.

03-08-2010, 12:43 AM	#2
Ide Senior Member Join Date: Feb 2006 Location: Seattle Posts: 361	Re: On how to recruit coders Well...I know this is classic, but please accept my apologies for reframing your question. First of all, memory management is basically a non-issue with a dynamic language such as Python, which is perfectly suitable for writing a mud. Furthermore, to continue with the Python example, there are at least two excellent library options (Twisted and MiniBoa) to take care of networking. So that's done too. I'm sure you could find similar options with other non-C-like languages. Program design is of course the crucial third leg you'll need to stand on so to speak, but that's really no different from game design (in fact, it's highly dependent on your game design) when you get right down to it. So if you're doing one there's no reason you don't have the intellectual capability to do the other, and I think you should, for reasons which I'll get to in a moment. While it may be bad form to recruit from your current games, I don't think that should stop you from doing it. In fact it's your best option, and if you're not willing to do it, honestly I don't think you should consider starting a game of your own. However let me say this doesn't mean you make a recruitment post on the game forums or whatever; I'm just talking about friends or people whom you've developed a trusting working relationship with over time. Because while it's not unheard of to find someone like this with a general ad on TMS or Mudconnector or so on, it's highly unlikely. IMO It just doesn't make sense to eliminate out of hand your best option. All that said... The only coders you want to attract to your game are ones already doing projects. The only thing that will tear them away is if you have done something cool. In my opinion this means, at the very least, taking a stock codebase and rewriting and rescripting many of the areas from scratch, or, if possible, showing them the work you've done on other muds, whether that be areas or systems code, or just other games you've done in general, such as RPGs, graphical games, etcetera. While you may recruit other coders with a simple ad, or perhaps some background stories or sketches of your game design, I don't think that will result in a successful working relationship in the end.