18 Mar, 2013, plamzi wrote in the 1st comment:
Votes: 0
It seems that in the past few weeks, a number of people came along and said something to the effect of "I wrote my own web server." And then, someone else came along and said something like, "I can see how that can be a lot of fun!"

Maybe I'm not geeky enough to even be here, but I'd like to think I'm totally in touch with my inner geek. And still, I find that kind of conversation utterly perplexing in a game design forum. If you're one of those folks who say and feel such things, you don't have to read the rest of this post. You just have to tell me, what is it about doing things that have already been done that you find so interesting??

In my own coding travails, the times I've written something from scratch where I could have leveraged existing code can be counted on the fingers of one hand. In one case, I needed something to be lightweight (for mobile users) and without dependencies, and knew it would always stay limited in functionality (e. g. basic DOM scanning utility functions rather than including jQuery). In other cases, adapting existing code which I found to be poorly written would have been more work, I felt, than "rolling my own".

In any game-related project I start, I look for the tallest (and best) stack of existing code I can pile up in order to reach what I want to get to. This is especially true for "framework" code like a web server, socket server, client platform, etc. I recognize there are a whole lot of coders much more technical and accomplished in their area, who write code specifically so others can build on top of it. So, when I want to create something new, there is no part of me that thinks, "Well, before I get to designing the actual game, obviously it will be a lot of fun if I learned Assembler, built my own compiler, then my own OS, then…"

Don't get me wrong. I totally get why someone would want to write a web server. What I don't get is why someone whose end goal is, in their own words, a web-based game, would want to write a web server.

I've heard the usual reasons, and I don't buy most of them. Yeah, you learn stuff. But you learn just as much, if not more, when you are writing something that hasn't been written before. I sense that part of it is about bragging rights, but I am personally impressed more by completed projects than by talk of web servers written from scratch. And I know that some people tend to "enjoy the process" more than the end result, but why not pick a process that actually contributes something novel? Is it about having the gumption to think you can solo-write a better web server than anyone else has, including those who started in the 90's?

And finally, if you want to, one day, have a full-feature game server, but you want to start with building all the groundwork code for it, why not recognize that writing a web server is a project in and of itself? That's what I would do, break it up into small parts so I don't break into utter despair by seeing how far into the future my end goal actually is.
18 Mar, 2013, Kline wrote in the 2nd comment:
Votes: 0
plamzi said:
You just have to tell me, what is it about doing things that have already been done that you find so interesting??


For me, this is a hobby, as I'm sure it is for most people on these forums. With any hobby the enjoyment you get is what you make of it, and unique for each person. I learned years ago after being at the helm of a few different games, some successful, most your run-of-the-mill "dream that never left the ground", that I'm not that interested in the actual world, story, design, etc. I'm not interested in the game as much as I am the parts under the hood. Would I like to create something that people will use any enjoy? Certainly, I can't think of many people who create anything for the same of "just doing it" and with no desire to see it used or recognized further; but having others use what I create isn't my top priority, so I'm not too worried if something ever "ships" as long as I'm getting out of it what I want to: enjoyment, learning, etc.

I've been able to take the skills I taught myself from "rolling my own" in numerous situations and apply them to my professional life, more than once. It's one thing to understand a specific API or interface to an existing product / game server / whatever and be a wizard within that realm, knowing the specifics and idiosyncrasies of that system, but it's something different to understand the how and why of what makes it possible so that you can more easily adapt to other systems.

Another reason I enjoy starting fresh is that I can leave behind any existing quirks or problems (and possibly create new ones instead ;) and it's a good mental exercise. I like thinking about and solving abstract problems, or planning how I feel would be best to design something, and then seeing if what I planned was actually a good solution or not in practice ("it looked good on paper"). I can't do that with gutting and re-fitting someone else's existing work, or at least not very well. The few times I tried I found myself doing more gutting / cleanup to remove the features I didn't want or that weren't part of my vision than I ever did implementing my own ideas; not that fun.

Also, there's never one "best" solution depending on the problem you're looking at solving. If your goal is to ship a playable game product as rapidly and stable as possible, then yes, there's probably a narrow realm of pre-built servers or packages that would be best to adapt to your own needs. That's not my goal though. I like trying things out of the ordinary to learn why other people might not choose to do things that way: is it too much work for too little reward? Stability problems? Resource problems? Or is it just something that hasn't been considered before due to other priorities taking place (ship the product as fast as possible)?
18 Mar, 2013, plamzi wrote in the 3rd comment:
Votes: 0
Kline said:
The few times I tried I found myself doing more gutting / cleanup to remove the features I didn't want or that weren't part of my vision than I ever did implementing my own ideas; not that fun.

Also, there's never one "best" solution depending on the problem you're looking at solving. If your goal is to ship a playable game product as rapidly and stable as possible, then yes, there's probably a narrow realm of pre-built servers or packages that would be best to adapt to your own needs. That's not my goal though. I like trying things out of the ordinary to learn why other people might not choose to do things that way: is it too much work for too little reward? Stability problems? Resource problems? Or is it just something that hasn't been considered before due to other priorities taking place (ship the product as fast as possible)?


I totally understand what you're saying, but I think that's because it falls in line with what I would do as well. What I don't understand is when someone reaches way back for no practical reason that I can discern. The fact is that you don't need to write a web server (or a web browser) in order to write a web-based game. It's also pretty much a fact that if you choose to write one, you will end up with something less stable, secure, and maintainable than if you used a library/app supported by an entire community of coders.

It's a question of degrees, of course, as I'm sure someone can look at my work and say I've gone too far into writing my own stuff the same way I'm looking strangely at people writing web servers for their game. But I know why I made my choices, they all seemed practical, and I can defend them. I'm just curious if that's also the case with the people whose choices I don't understand.
18 Mar, 2013, KaVir wrote in the 4th comment:
Votes: 0
I feel the same way when I see people jogging. It's not that I don't jog - I do. Often. But only because it's faster than walking, and I find walking even more boring than jogging. I just want to get from A to B.

At the end of the day, it's really depends on your motive. Some people enjoy the journey, others are only interested in reaching their destination. Neither is right or wrong, they just want different things.
18 Mar, 2013, Idealiad wrote in the 5th comment:
Votes: 0
For me writing 'from scratch' is mostly about skill development – program design, learning fundamental language APIs, and so on. I have nothing against using a full stack (and often do). However I've found somewhat counter-intuitively that 'from scratch' is often simpler (from a learning perspective) than full stack.

I think this approach can be valuable even for a professional developer. For example, in my (non-programming) work I use many time-saving tools. But when I use hand tools, out of choice or necessity, the skills I practice seem to reinforce the skills of my normal trade craft.
18 Mar, 2013, plamzi wrote in the 6th comment:
Votes: 0
KaVir said:
I feel the same way when I see people jogging. It's not that I don't jog - I do. Often. But only because it's faster than walking, and I find walking even more boring than jogging. I just want to get from A to B.

At the end of the day, it's really depends on your motive. Some people enjoy the journey, others are only interested in reaching their destination. Neither is right or wrong, they just want different things.


I get the part where people want different things :) But I think there's an interesting psychological twist here, which is the part I don't get. Using your analogy: If someone stops a jogger who was seen running around the bus station for several hour, and asks them what they're doing, most likely they're going to say they're just running to keep fit. If they try to claim that they're actually running to catch the bus, that's bound to puzzle some folks, no?
18 Mar, 2013, KaVir wrote in the 7th comment:
Votes: 0
I think you've missed the point of my analogy.

Let me ask a question. Why do you run a mud?
18 Mar, 2013, Idealiad wrote in the 8th comment:
Votes: 0
@plamzi, correct me if I'm wrong, but you are implying that

* there are some people who want to make a game
* they write everything from scratch
* these people also would rather get to the destination instead of enjoy the journey (related to KaVir's point).

The problem is that this third point is just conjecture. I haven't seen anyone here say "I want to write a game so bad, but oh well, guess I have to write a web server first".
18 Mar, 2013, plamzi wrote in the 9th comment:
Votes: 0
KaVir said:
I think you've missed the point of my analogy.

Let me ask a question. Why do you run a mud?


I'm not sure why you feel the need to explain the difference between enjoying a process and reaching a goal. Probably because you didn't read very much past the thread's title, which was meant to be catchy.

Let me see if I can re-state my point yet again in the terms you are outlining:
You run a mud because you enjoy the process. You say "I'm running a mud", which in and of itself indicates continuous action. By the same token, people say "I'm learning the violin", for which process a lifetime is not enough, and no-one is going to expect the learning to be over at some point.

But then, sometimes you say "I'm creating a game" just like you can say "I'm making a violin." This statement implies a goal. For a violin, we can say it's a violin when it can produce a violin-like sound. For a game, the point at which it becomes a game is probably the same–when someone can play it.

The statement also implies a reasonable starting point. When I hear someone say "I'm making a violin," I picture them going to a carpenter to pick out the wood. What I don't picture is them planting a cherry seed to grow the tree from which the violin is to be made. When I see someone planting a cherry seed, I expect them to be aware that the tree is going to take quite a while to grow, and that if their end goal is to make a violin, planting that tree is not getting them any closer to their goal.

Now, I understand that some people, when they say "I'm creating a game", what they're really saying is "I'm improving my coding skills, and I don't care if I ever create a game." And even, "I'm going to say that I'm creating a game, but in fact I'm going to take every possible detour to make sure I never actually end up with one, because that's not what I really want." And here, finally, is my original point: why say that you're creating a violin, when you're really growing a tree? There's nothing wrong with growing trees, is there?


Idealiad said:
I haven't seen anyone here say "I want to write a game so bad, but oh well, guess I have to write a web server first".


http://www.mudbytes.net/index.php?a=topi...

The other example I had in mind when composing the OP was stuff I read people say in the thread on websocket servers that you started.
18 Mar, 2013, salindor wrote in the 10th comment:
Votes: 0
Since I am one of the people who said they wrote a webserver from scratch I figured I should reply.

At the most basic level, I wrote it from scratch because I wanted to and everything that follows is just the excuses I gave to rationalize my decision :) But really I did look around first, it like looking for that perfect desk and not finding it so you decide you will just build your own. So really everything below the line are my excuses for whatever they are worth.

Not all runners run to get fit or catch the bus, some runners run for the simple joy of running.

———————————-
When I was first researching the various webservers out there, I couldn't find one that quite fit the bill for what I was looking for. The closest one was node.js and I don't like javascript (its against my religion to use javascript in server code;) ).

I was also curious, in my searches I found many places that claimed apache was slow and so my thoughts were… could I get my sockets to respond faster? After all I have been dealing with client-server communications since a freshmen in college and even had a few programs I had to write which required the communication path to be optimized. Could I take this knowledge and apply it to a webserver and be just as good as the fastest webservers out there?

I did consider security in my implementation; after all you can't get a masters in multi-party cryptography and not think about it as you write code. I have an advantage over a popular webserver and that is my webserver is specific to my needs. I only have the features I need and nothing else and will ignore any tag I don't recognize. I sanitize the inputs prior to processing them and pull a few tricks to outright reject some connections that are spooky looking with mundane error codes so as to slow the perpetrator down. Basically my possible vulnerabilities are the libraries I choose to use rather than implementing (like anglescript and openssl–I have about half a dozen) and any buffer overruns I may have missed (but I try and sanitize all length variables).
18 Mar, 2013, quixadhal wrote in the 11th comment:
Votes: 0
In many cases, I would guess people decide to write something from scratch because nothing they find out there will do what they want it to do, without major, systemic, changes. In that case, it may be just as much work to fully understand the existing code and change it, as it is to just write it all yourself.

Some people also just like to KNOW how every nut and bolt fits together, and enjoy the process of seeing it come together from a box of parts.

As to somebody writing their own web server to make a web-based game… I think those people underestimate the task. It's an easy mistake to make, since we've all seen the web servers in perl/ruby/etc that are about 20 lines of code. Of course, those are only meant to serve up a pretty fixed type of content on a fairly low volumne, NOT what you actually hope for when making a game. :)
18 Mar, 2013, KaVir wrote in the 12th comment:
Votes: 0
plamzi said:
The statement also implies a reasonable starting point. When I hear someone say "I'm making a violin," I picture them going to a carpenter to pick out the wood.

I picture them buying a second-hand violin, adding an extra string, and calling it "highly modified". But perhaps I'd feel differently if I was interested in making violins.
18 Mar, 2013, Idealiad wrote in the 13th comment:
Votes: 0
Well, they'd probably advertise first for a string-refitter.
18 Mar, 2013, Lyanic wrote in the 14th comment:
Votes: 0
plamzi said:
When I hear someone say "I'm making a violin," I picture them going to a carpenter to pick out the wood. What I don't picture is them planting a cherry seed to grow the tree from which the violin is to be made. When I see someone planting a cherry seed, I expect them to be aware that the tree is going to take quite a while to grow, and that if their end goal is to make a violin, planting that tree is not getting them any closer to their goal.

I suspect that is where your fundamental lack of understanding lies. As contrived as the example is, I can see someone planting a cherry seed with the intent to make a violin. I'm sure someone at some point in history has done precisely that, along with many other similar undertakings of long, slow, arduous processes with a specific end goal in mind throughout. Some people work at a slower pace, particularly those who enjoy the journey as much or more than reaching the destination. "I'm making a game," is not the same statement as, "I'm making a game quickly."
19 Mar, 2013, salindor wrote in the 15th comment:
Votes: 0
Besides making a webserver isn't as hard as it sounds… More annoying than anything.

If you wanted a better analogy; it would be like going into the forest to pick your tree for the wood used in the violin vs just buying the ready cut lumber at the store.

Salindor
19 Mar, 2013, Sorressean wrote in the 16th comment:
Votes: 0
Here are my reasons for writing something from scratch.
*Even though you've discredited people that do it to learn, I actually do write things from scratch to actually learn. I've started designing an operating system from scratch. Sure there are other operating systems out there, sure mine will never actually be used somewhere. I'm not telling the world "I'm designing an OS to compete with windows," but I do it for both the fun and the learning experience. I can tell you that I have learned a hell of a lot more by actually designing this OS and getting to where I have with it (no, it's not very far) than I would have say, using an API.
*Sometimes an API doesn't really teach you everything you want to learn. You can use APIs all day long, but when you actually sit down to design the system under those APIs, you actually start learning the internals. Calling functions or methods and getting back what you hope is the right thing and moving on is vastly different from actually understanding the internals of the system, both how and why it works the way it does.
*I designed my mud totally from scratch because I didn't see any suitable codebase to work off of. Nakedmud is what everyone seems to love if you're looking for a non restrictive license, but it's not being developed and it really should be. It was easier for me to design my own mud engine and have it work the way I wanted than it was for me to overcome the limitations and mess that is Nakedmud.

There are many reasons for actually building something from scratch; something that none of your analogies never really worked for. Some do it for bragging rights for sure, but many people actually have reasons for designing something from scratch. I personally find that piling up 500 libraries and using them all to develop something is going to make more of a mess than it would to rely on a couple libraries (usually boost and a couple others) to get the job done.
19 Mar, 2013, Chris Bailey wrote in the 17th comment:
Votes: 0
I only write things from scratch because I'm ignorant and completely incapable of understanding code written by others.
19 Mar, 2013, Runter wrote in the 18th comment:
Votes: 0
I'll boil my answer down to something small. It's the culture of C. C has long had a culture of people just starting from scratch, and a real aversion to using libraries and code already developed in your project. It comes from an era where people were constantly fearful of malicious code and without any real way to find out if a library is legit or not. Especially predating widespread distribution on the internet of code. Most mudders have picked up the same culture from working with codebases that never use libraries and basically have solved the problems themselves. It's my position that writing stuff from scratch can be fun, and it can be educational, but you don't have to spend all your time reinventing wheels to gain knowledge, or to have fun. You can actually do those things while contributing to existing projects, and develop products that other people will use. You'll find that's pretty fun and educational too.
19 Mar, 2013, Kline wrote in the 19th comment:
Votes: 0
Runter said:
C has long had a culture of people just starting from scratch, and a real aversion to using libraries and code already developed in your project.

I don't consciously think of it like this, but yes, this is true, at least for me.

One more reason I start fresh is to avoid any external dependencies only because of how damn annoying it is when I've tried to download a package source to compile and use it only to find out the insane amount of dependencies it has. By the time I've collected all those additional libs and packages something is usually broken or won't play nice with existing package versions I have for other software, etc. I never want someone to have that problem with something I write; worrying about specific versions of external dependencies and having to compete with other packages that may need a different version than I do. Download, compile, use. There shouldn't be anything else to do.

Every time I hit Google to learn about how to do something new in C++ that I haven't tried before the top results are usually Stack Exchange and the top answers are "Use boost". I hate that! I don't have boost on my system, I can't guarantee it will be on anyone else's system, and simply saying "use boost" does nothing to explain any rationale behind how/why/what "using boost" is doing to solve the problem other than knowing how to interface with a 3rd party API. I'm sure boost does wonderful things and has earned a spot as a near defacto-standard in many commercial products, but I don't write software commercially and do get annoyed by how heavily people push to just use boost to solve all your woes.
19 Mar, 2013, plamzi wrote in the 20th comment:
Votes: 0
Runter said:
I'll boil my answer down to something small. It's the culture of C. C has long had a culture of people just starting from scratch, and a real aversion to using libraries and code already developed in your project. It comes from an era where people were constantly fearful of malicious code and without any real way to find out if a library is legit or not. Especially predating widespread distribution on the internet of code. Most mudders have picked up the same culture from working with codebases that never use libraries and basically have solved the problems themselves. It's my position that writing stuff from scratch can be fun, and it can be educational, but you don't have to spend all your time reinventing wheels to gain knowledge, or to have fun. You can actually do those things while contributing to existing projects, and develop products that other people will use. You'll find that's pretty fun and educational too.


I find this a very insightful post, and it rings absolutely true to my experience. Another manifestation of the "generational" divide you're describing, I think, is when people go to extra lengths (and self-imposed limits) to make a codebase agnostic to the type of persistent storage used. To me, that's holding yourself back (and clipping the wings of all the less-than-stellar coders that you're supposedly building this codebase for). To the person writing the storage-agnostic codebase, it's probably like the "Braveheart" battle speech :)

Of course, we're all free to go about our hobby in any way we damn' please. It's just that recently, the pragmatic side of me finds it a source of frustration to hear solo devs who refuse to benefit from the wisdom and work of others. We are now later on in the coding game and we can, and should, rest on the shoulders of giants. One of these days, to refuse to "hitch your wagon" to an existing API/library/framework will be completely synonymous with consigning yourself to writing vaporware for your own edification.
0.0/83