If I have a good answer, but you can't comprehend it, I still have a good answer.

OneFishDown wrote:

I leave BYOND the day that happens. That lowers the amount of talent and knowledge required to make a game. Shall that one day happen, I suppose I'll eat my words. I thought BYOND was a community of programmers, working together and helping each other to better their programming skills. I guess that was just wishful thinking.

Maybe I'm misunderstanding your argument, but this sounds pretty arbitrary to me. I mean, if lowering the amount of talent and knowledge required to make a game is truly a bad thing, then doesn't it follow that BYOND itself is a bad thing? Wouldn't people be better off using C or assembly language?

I think using libraries makes perfect sense if the library precisely matches what you need to accomplish. If no such library exists, then rolling your own is obviously the best (and only) way to go. For example, even if someone writes a really great social verb library, I still may not be able to use that "say" command, because I might need my "say" command to consider exotic things like walkie-talkies and intercom systems. In such a case, I have no choice but to do it myself.

It also makes sense to write your own library if you just want to teach yourself the concepts involved. Say you want to learn about A* pathing or whatever, and you know there's a decent library out there, but the subject interests you enough that you really want to get down and dirty with it. Great! There's no substitute for learning by doing.

But... if you know that the perfect library already exists for a given task, and you don't expect there's much you could learn from implementing it yourself, it makes sense to use the library. If you still want to ignore it and write one yourself, that's perfectly all right -- it's your time, after all. But it hardly seems sensible to scoff at those who choose to let libraries handle the rote responsibilities, and who reserve as much of their time as possible for the areas of the game where they can best express their own vision of what will make the game unique.

OneFishDown wrote:

Deadron wrote:

Game making and programming are unrelated.

I program. The result of my programming is a game. Thus, I made a game. Unrelated eh?

A movie is filmed with a zoom lens...zoom lenses and acting are not, however, related.

An actor doesn't necessarily know anything about operating the camera, editing the film, or adding the foley work. A foley artist doesn't necessarily know anything about acting.

When a director decides to make a movie, they focus on what they are good at (which might be writing, or working with actors, or great visualization), and they hire someone else to do the other parts. They hire a writer, a cinematographer, actors, etc.

Now the director may also be a great actor, or a great writer, or whatever. But if they are it's coincidental.

The director and those working for him make use of existing tools. They don't, as a general rule, invent new cameras or new kinds of film stock. They use the tools of the trade (the libraries of the film world) to put together a film; they use existing tools so they can spend their energies making creative decisions for the film.

A great director is able to make a great film even though they couldn't personally do each part required to make the film happen, and even though they didn't invent new film stock.

When a game designer decides to make a game, they decide whether to do it as a card game, a board game, a party game, a computer game, etc.

They don't have to know how to manufacture the cardboard for their board game in order to design the game; but at some point they will have to work with someone who knows about cardboard make some boards for them. They don't have to know how to write a computer program to design a game to be played on the computer; but at some point they will have to work with someone who knows about programming to implement the game design.

The game designer might happen to have a knack for making cardboard or they might not; they might happen to have a knack for programming or they might not. Their game design abilities have nothing to do with cardboard or programming, though. They are entirely unrelated.

What I'm getting at is since the skills of programming and game design are unrelated, if we require you to be a great programmer *and* a great game designer in order to make a BYOND game, we'll only ever get a handful of great BYOND games.

If we make it so that there is a toolset that allows great game designers to make computer games with out being great programmers, then we will have many more great BYOND games.

None of this has anything to do with you. It's wonderful that you want to be a great programmer and game designer (so do I!). But people who only want to be great game designers and not great programmers are not stupid, and they are not less than you. They may even have talents in other areas that you could not hope to match.

That makes sense. Filmmakers use already existing tools to make the movie-making process easier. So computer game makers would have some tools that they use to make game-making easier. The problem is, you see the tools as these libraries, I see the tool as being BYOND.

In other words, your answer consists of convincing me that the answer is irrelevant?

OneFishDown wrote:

There's only so many combinations of libs.

Well, that depends on how many people release libraries...

I can sort of see both sides of this. It would be kind of nice to be able to release compiled libraries, so that people couldn't mess with the code and then complain that the library is broken. However, I learned more about coding from reading through libraries than from pretty much anything else (I did break a few :). I would hate to see people not release libraries with code at all, but it might be nice at some point in the (distant) future to have this as an option.


As far a using libraries being a form of cheating, I strongly disagree. Libraries allow me to spend time on the key parts of my projects, and the parts I enjoy working on. This allows me to make those parts better, since I didn't have to spend as much time recreating available library functions. I'm assumming you aren't opposed to development teams, (pretty much no major game is made by a single person) so maybe it will help to consider libraries as code provided by team members.

OneFishDown wrote:

What it comes down to is the fact that I don't like libraries. Libraries should save you time. If you know how to make the wheel, you shouldn't have to re-invent it. If someone uses 20 libraries and doesn't understand them, did they make the game?

Yes; as rhetorical questions go, that's just silly. If you put Legos together and don't understand how they're extruded from plastic molds, did you really build something?

I write nearly all the code for my games, that's just the way I work. Why should I re-write an A* pathfinding routine when I could make my own just-as-good pathing routine in an hour or two? When I am done making a game, I like to be able to say that I made it. There are so many libraries and demos available here that someone could slap a few together and make a "game".

If only! Deadron's right to say that this is a worthwhile goal and the closer we get, the better off we'll be. What need is there to understand precisely how a library works if it does what you want?

It would take me a short time to tell someone how a tile-based pathfinding routine works. I cannot control whether or not they understand it.

Yes, but how long would it take to build the library?
The most important lesson I've learned in my life is that it may be easy to understand at a high level how an algorithm works, but difficult to implement it at a low level. Lesser programmers might (or might not) understand what you tell them, but then have a witch of a time putting it into code themselves. Why should they have to go to the trouble.

More to the point: Should you have to know how to build a motor from scrap metal in order to use it to build a robot? I'm sure it's worthwhile information, particularly if you're looking to improve the efficiency of something or other. But if Radio Shack sells the parts you need, using them could be the difference between completing a project and abandoning it.

As for all those "how long would it take you to..." questions of yours: I'll cross those bridges when I come to them. When I need one of them I'll find out how long it takes me to make.

Ah, but how long would it take someone else? You may be content to do everything manually, and that's fine; you're not likely to finish much that way, though. Still it's good to make more libraries, so people can produce games that they otherwise couldn't--or be inspired to produce games they otherwise wouldn't.

I don't use libraries. If I can't do it myself, then I should learn how. I am not re-inventing the wheel. (expanding on the wheel metaphor) Your wheel doesn't necessarily fit my car. I know what kind of wheel I want, so I'll make it myself.

But a part of any engineering, including software engineering, is knowing when to adapt your design to what's available.

I know where you're coming from; I'm not apt to use libraries a lot myself, and usually I'm way too good at seeing how something or other doesn't fit what I had in mind. But there are libraries I do plan to use, and when the time comes to use them they'll help a lot.

Meanwhile I've begun to make some of my own, because sometimes teaching is less important than making; SwapMaps is much easier used than understood, when the mechanics of the savefiles are tricky and it does some complex things that most wouldn't think to duplicate. And there's another place where implementation and high-level understanding part ways: In most problems there are subtle intricacies that can't be explained except in depth, and a library can address them whereas a tutorial (even a good one) usually won't.

Lummox JR

For reasons relating to the community standards, I'm not even going to tell you what I see as being the tool here... I guess your main point is that everyone should stick to what they're good at. Following that idea to its natural conclusion, I suggest you give up on trying to use sarcasm.

OneFishDown wrote:

Not to drag up this thread (not that its old or that "dead") but there is a difference between coding and programming.

If you take "coding" to mean "asking for 'The Code' for a given, usually poorly specified, feature", then yes, there's a big difference. But in conventional usage among programmers, the two words are identical. There aren't even any subtle nuances of difference, as far as I know, except that the term "coding" is less well-known to the general public.

Sariat wrote:

Look, if One Fish Down wants to be selfish and all that good stuff, let him. I don't care. I really don't. There's tons of other people that DO help. And I am proud to be one of them. Not all people learn from source code but some do. And those that do, are worth it.

Who's being selfish here? i.e. Look at codeclient