Hmm, this sounds to me like something an employer might say to justify paying their front-end developers less :)
Yep real world. Client side developper are by the dozen because it is fun and fullfilling (and the code quality/skills are 'less' important in the final result than ergonomy/design (wich is as complicated as picking the right architecture patterns). Does not mean they are really good, but plenty ressources means averaging the pay, and it is a lot harder to raise your name above the rest. On the other hand on the server side it is harder to find a position to begin with. That is how it works. Never said one is better than the other or but the big money is never where you can find plenty people fighting for the same position.
>Last time I checked, Blizzard still made you buy World of Warcraft's client.
Last time I checked, a subsription is included in the price. (and yeah I find this perticulalry dumb from people to accept to pay the client…but thats anothe r matter, if they can get away with it why not…)
> Or are you trying to convince yourself it's "training" for some future "job"?
No, I say, if you have a hobby where you will pour a lot of time, why not kill two birds with a stone in the process. Cannot hurt. Would be stupid to not think of it to begin with.
22 Mar, 2013, quixadhal wrote in the 62nd comment:
Votes: 0
A hobby is a hobby. If you treat it like job training, it's no longer a hobby…. now it's work. The very fact that you'd limit your choices of languages to ones that might be useful for your future employment shows that you're no longer treating it as a hobby.
By that train of thought, the only people who should enjoy fishing as a hobby, are people who plan to work in the commercial fishing industry.
If you want to make a MUD, make a MUD. Don't worry about work-related crap, because you're not at work. If you start letting work dictate your off-time activities, pretty soon you'll find yourself always on the clock, and headed for burnoutville.
NOTE: If you're very familiar with some langauge at work, that's a valid reason to use it for your hobby… but not because it's the best choice, because you don't have to deal with another learning curve.
23 Mar, 2013, Rarva.Riendf wrote in the 63rd comment:
Votes: 0
Quote
A hobby is a hobby. If you treat it like job training, it's no longer a hobby…. now it's work. NOTE: If you're very familiar with some langauge at work, that's a valid reason to use it for your hobby… but not because it's the best choice, because you don't have to deal with another learning curve.
I said if you can mix both without killing the fun, better to do it. I never said it is an absolute goal. And that is something you can apply to whatever hobby you have. I never said to pick an unappropriate langage as well. Pick one you like, there are enough different langage to pick one you like and is useful as well. LPC does not seem to apply unless you already know it. C does not apply cause dealing with text and memory management nightmare when performance is no longer a real issue not really worth it. It leaves plenty enough langage to pick from that are used in jobs. you can even go pick ADA or Scala ….but LPC ? gimme a break. Why not brainfuck (well if you are masochist it ca be your choice of fun..sure)
I don't think it's even factually sound that front end people are making less than back end people these days. Not significantly, anyways. The front-end engineers at our consultancy make as much as the back-end engineers. It's a lot of work, and it's market driven, because there's *not* a legion of programmers capable of doing quality work on the frontend that both looks right and is good code. I think what is true is you can get by at some companies being a really bad front-end developer, but it's not as possible as backend. The pay is going to be based on the companies requirements and your skillset. The other thing I would say is the most valuable people can do both frontend and backend work with a high level of competence at our company.
Despite all the unreasonable HATE aimed at LpMUD's around here, there are some very good reasons to use LPC if you want to make a MUD.
First, it's been around for 20 years. There are quite a few people who know it, and most importantly, are right here in the MUD community, using it to make MUD's. That's a nice resource to use. Sure, you can use python, or ruby, or javascript… but then you have lots of people who use them for OTHER things, and only a few who have used them for MUD development.
Second, why do you really want to re-invent the wheel? Your players won't care how efficient your socket handling code is. Nor will they notice how elegant your file I/O is, or the way you handle error conditions like infinite loops in your mud script code. An LPC driver already handles that for you. It's done. Why do it again?
Third, I again suggest you ask yourself why you're making a MUD in the first place? Are you making one because you want to make a game for people to play? Or are you making it for some other reason? If you're making a game, presumably you want to use something that is known to work well for making games, and you want to spend your time coding the game itself, not sockets, and file handlers, and sandbox engines.
There's a reason I can look at the mudlist of mud's connected to I3 and see 90 muds online… Of those, 6 are not a Dikurivative or an LpMUD codebase. 5 of the 6 "oddballs" are CoffeeMUD (java). I3 isn't the whole universe of muds, but it's a reasonable subset. If other langauges are so great, why don't we see any of them in production? Why are there lots of "test" games in ruby/python/etc, but very few actual games running with players?
Could it be that most of the people who wrote a new mud in a new langauge spent so much time and energy reinventing the wheel in their own langauge, that they ran out of steam before getting to the actual game part?
23 Mar, 2013, Rarva.Riendf wrote in the 67th comment:
Votes: 0
Quote
If other langauges are so great, why don't we see any of them in production?
Who actually cares about i3 to begin with ?
Quote
Why are there lots of "test" games in ruby/python/etc, but very few actual games running with players?
Muds are pretty much a dead breed, and nobody cares about the back end anyway. It is not langage related. And yeah those are tests from people realising that getting people to actually play a mud is where the real work is.
Quote
I don't think it's even factually sound that front end people are making less than back end people these days. Not significantly, anyways.
May depends in wich country you look, but I look in France. And banks will pay more, and they have lots of server. Web services is a lot more common. Creating a E-Commerce website is like copy paste for any web agencies. Not much value in there. (as an example)
May depends in wich country you look, but I look in France. And banks will pay more, and they have lots of server. Web services is a lot more common. Creating a E-Commerce website is like copy paste for any web agencies. Not much value in there. (as an example)
I don't know about France. I'm talking about LA, NY, Tokyo, Seoul, and Singapore. :)
23 Mar, 2013, Rarva.Riendf wrote in the 69th comment:
May depends in wich country you look, but I look in France. And banks will pay more, and they have lots of server. Web services is a lot more common. Creating a E-Commerce website is like copy paste for any web agencies. Not much value in there. (as an example)
I don't know about France. I'm talking about LA, NY, Tokyo, Seoul, and Singapore. :)
I have less data in US and Asia off course, but Canada seemed about the same as I looked into going to at a time. I won't keep arguing on that, maybe I am wrong for other markets. I found pretty logic that the more a market is crowded with worker the less you pay them. And well front end marjet is a lot more common than back end market hence more people in it. (and with more people harder to prove that you worth more.) I am pretty sure a good developper can get about the same salary in every kind of position. I think it is a matter of easier way to find a job but average pay is less, or harder to get a job but starting pay is higher.
Quote
Second, why do you really want to re-invent the wheel? Your players won't care how efficient your socket handling code is. Nor will they notice how elegant your file I/O is, or the way you handle error conditions like infinite loops in your mud script code. An LPC driver already handles that for you. It's done. Why do it again?
Because all that can be done in less time than to learn in LPC to begin with ? (provided you already know the langage you will code your mud in) Mud is not rocket science, you dont really need a community for the coding part unless indeed you dont use your own codebase and need help because well you did not write it…I came here because I needed help to nuderstand why the hell I ran into problem in my old ROM codebase, problem I would never had, had I written my own code…
The market is crowded with lousy developers. Yes, you can go find a "web developer" a dime a dozen. But if you need a sophisticated developer that understands the full range of tools that your team is using, and is writing well tested frontend code…that market isn't saturated and it's just as hard to find them as it is to find the backend engineers.
I don't think it's even factually sound that front end people are making less than back end people these days. Not significantly, anyways.
May depends in wich country you look, but I look in France. And banks will pay more, and they have lots of server. Web services is a lot more common. Creating a E-Commerce website is like copy paste for any web agencies. Not much value in there. (as an example)
I think I understand what shaped your perception, and you're right that it varies based on country. My home country has a similar market for tech jobs. There's a big difference when most businesses don't see a website as "mission critical", or when the competition has a cookie-cutter e-commerce website, as well. In the U. S., I only consult for clients for whom the website is the center of their business, and who need a website that "does things" and "stands out". In that kind of market, there really is no difference which part of the "web application" you are developing. Ideally, you could do both with equal ease.
Ten years from now, I'll probably be writing the same post about some new language that I believe is inferior to C or JS because it's, uhm, not my cup of tea.
It will be D. However, you will argue that it is superior to C++. :wink:
Also, I suggest to anyone who doesn't quite like javascript to use a javascript compiler. I use coffeescript and really enjoy it. There's one ones out there.
The code it compiles to is still very good, and it's quite a bit more maintainable.
You can also get better type checking this way. The better JS compilers do clever things like convert
int i; i++;
into
var i; i = (i + 1) | 0;
Thus allowing JIT code to perform type inference :grinning:
Despite all the unreasonable HATE aimed at LpMUD's around here, there are some very good reasons to use LPC if you want to make a MUD.
First, it's been around for 20 years. There are quite a few people who know it, and most importantly, are right here in the MUD community, using it to make MUD's. That's a nice resource to use. Sure, you can use python, or ruby, or javascript… but then you have lots of people who use them for OTHER things, and only a few who have used them for MUD development.
Second, why do you really want to re-invent the wheel? Your players won't care how efficient your socket handling code is. Nor will they notice how elegant your file I/O is, or the way you handle error conditions like infinite loops in your mud script code. An LPC driver already handles that for you. It's done. Why do it again?
Third, I again suggest you ask yourself why you're making a MUD in the first place? Are you making one because you want to make a game for people to play? Or are you making it for some other reason? If you're making a game, presumably you want to use something that is known to work well for making games, and you want to spend your time coding the game itself, not sockets, and file handlers, and sandbox engines.
There's a reason I can look at the mudlist of mud's connected to I3 and see 90 muds online… Of those, 6 are not a Dikurivative or an LpMUD codebase. 5 of the 6 "oddballs" are CoffeeMUD (java). I3 isn't the whole universe of muds, but it's a reasonable subset. If other langauges are so great, why don't we see any of them in production? Why are there lots of "test" games in ruby/python/etc, but very few actual games running with players?
Could it be that most of the people who wrote a new mud in a new langauge spent so much time and energy reinventing the wheel in their own langauge, that they ran out of steam before getting to the actual game part?
I think one of the better reasons to use a different language is if you know that it offers some advantage that you want to utilize to improve some aspect of a basic game system that already exists. I.e. you like DIKU, but want something specific to be different that turns out to be easier to do in, say, an interpreted language.
I don't think the i3 argument is particularly valid. The I3 spec sort of expects you to know LPC/LPmud stuff and is in fact implemented primarily for that system without much regard for others. It's not impossible, of course, or there wouldn't be any I3 code for anything else. I know there's some on here for Java, which I intend to try to get to work at some point with my code, but that's not my priority. Nevertheless the dependency of that on a subsystem of a particular server program and not existing in other codebases presents a hurdle to jump, perhaps an entirely unnecessary one. In particular most muds are small because the playerbase is limited, it's not like you play WoW and your buddy plays GW2 and you want to chat while playing your respective games.
So, whether muds are on the i3 network is not necessarily a good measure of whether they exist or not. Besides that there is a fairly limited group of interested people overall (compared to MMO players at least) and the ones in the know almost certainly play or have played a DIKU derivative. I.e. that's what they are familiar and comfortable with, so it will be difficult to get them to switch to a radically different system. Although, arguably DIKU and it's other relatives sort of define the quintessential MUD, in the sense that everybody implements a similar system.
25 Mar, 2013, quixadhal wrote in the 75th comment:
Votes: 0
Just to note, AFKMUD used to implement I3, and I've updated that code for my own DikuMUD. It's not hard, just slightly tedious.
it's not like you play WoW and your buddy plays GW2 and you want to chat while playing your respective games.
It's funny you should say that. I actually play both games, and belong to a guild which does indeed want to chat across game systems. We use voice chat to accomplish this, and both SOE and Blizzard have cross-game chat systems implemented, although only within their own franchises. Still, it's nice to talk to your friend who logged into Starcraft while you're playing WoW.
My argument for I3 isn't so much a "muds not on I3 don't exist" thing, as a "I3 is a network FULL of people who code muds, maybe it'd be useful to be connected to such a thing while you're building your own?"
My argument for I3 isn't so much a "muds not on I3 don't exist" thing, as a "I3 is a network FULL of people who code muds, maybe it'd be useful to be connected to such a thing while you're building your own?"
I think a forum is much better suited for the purposes of devs helping each other. A pastebin being one of the more obvious reasons. And, for anyone who would be mostly on the "giving end" of help, much less intrusive. I would get nothing done if both my players *and* aspiring devs from other games could page me with stuff that has nothing to do with moving my game forward.
26 Mar, 2013, quixadhal wrote in the 77th comment:
Votes: 0
*chuckle*
I don't think competition is even a valid concept in the MUD community. Maybe in 1995, but is there REALLY anyone out there worried about having their playerbase "stolen"?
The isolationist method works well when there's a huge pool of resources and players to draw from. That's not the case anymore… anything that helps MUD builders, coders, and players find one another is probably a good thing.
Have you ever actually used either I3 or IMC2 (when it had people on it)?
It's surprisingly handy to be able to ask a simple question and get an answer without wading through 12 search queries that give you tons of things you DON'T need… especially when you know what you want to do, but can't remember what the object/function was called.
And of course, both networks are implemented as channels.. you can easily turn them off if you're busy (or redirect their messages to another window).
26 Mar, 2013, Rarva.Riendf wrote in the 78th comment:
Votes: 0
Quote
Still, it's nice to talk to your friend who logged into Starcraft while you're playing WoW.
I am sure it is very practical to hear to build more zerg while your guild tells you to kill that dragon:)
26 Mar, 2013, quixadhal wrote in the 79th comment:
Votes: 0
Clearly, you don't understand the "social" aspect of gaming. Perhaps if you tried not being practical, but actually having FUN, it would make more sense why you'd want to talk to your friends even when not on the same game.
26 Mar, 2013, Rarva.Riendf wrote in the 80th comment:
Clearly, you don't understand the "social" aspect of gaming. Perhaps if you tried not being practical, but actually having FUN, it would make more sense why you'd want to talk to your friends even when not on the same game.
Clearly when I play a social game, I play the same game than the people I socialize with. Maybe an education but kind of finding rude to pay more attention to other people than the one I have in front of me (virtually speaking). Especially since those dont care about those friends they dont know about in other games.
Yep real world. Client side developper are by the dozen because it is fun and fullfilling (and the code quality/skills are 'less' important in the final result than ergonomy/design (wich is as complicated as picking the right architecture patterns). Does not mean they are really good, but plenty ressources means averaging the pay, and it is a lot harder to raise your name above the rest. On the other hand on the server side it is harder to find a position to begin with.
That is how it works. Never said one is better than the other or but the big money is never where you can find plenty people fighting for the same position.
>Last time I checked, Blizzard still made you buy World of Warcraft's client.
Last time I checked, a subsription is included in the price. (and yeah I find this perticulalry dumb from people to accept to pay the client…but thats anothe r matter, if they can get away with it why not…)
> Or are you trying to convince yourself it's "training" for some future "job"?
No, I say, if you have a hobby where you will pour a lot of time, why not kill two birds with a stone in the process. Cannot hurt. Would be stupid to not think of it to begin with.