In response to OneFishDown
And you had no good answer to that question. Thus, you are being hypocritical. Shame on you.
In response to Garthor
If I have a good answer, but you can't comprehend it, I still have a good answer.
In response to Deadron
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?

Maybe you were trying to say that you can make a game without having to do any programming. If you are saying that people could make games by combining libraries, I don't see how that would make great games.
In response to OneFishDown
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.
In response to Gughunter
Gughunter wrote:
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?

RPGMaker is too extreme on one end, C and assembly language are close to the other extreme. BYOND lies somewhere in the middle. Though BYOND might be too specialized, it seems to me that it's getting more versatile.

I think using libraries makes perfect sense if the library precisely matches what you need to accomplish

Precisely. I needed a simple pathfinding routine, so I wrote one.

It also makes sense to write your own library if you just want to teach yourself the concepts involved.

I agree, that's what I did.


Like I said before, I am eager to learn more, so I expect others to be eager too (I guess that's sadly where I'm wrong). I could've used a library for the pathfinding, but then I wouldn't learn how. I don't like to use libraries. To me, using one is cheating. To my way of thinking, the more and more libraries people rely on, the more limited the games will be. There's only so many combinations of libs. To me that path seems quite downhill. I don't mind the fact that there are libraries, but I'd rather not see people encouraged to rely on them, instead of learning how to make them.
In response to OneFishDown
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.

In response to OneFishDown
OneFishDown wrote:
To my way of thinking, the more and more libraries people rely on, the more limited the games will be. There's only so many combinations of libs. To me that path seems quite downhill.

There are a limited number of words in the dictionary. There are a limited number of grammatical rules.

Yet people put them together to create infinitely varied books.
In response to Deadron
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 response to OneFishDown
OneFishDown wrote:
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.

Arbitrary distinction.

The problem is, the people who choose to use the libraries are not stupid and may not even be less smart than you.

That is the one and only reason I continue to post, is to respond to the insults you have made toward people who work differently than you.
In response to OneFishDown
In other words, your answer consists of convincing me that the answer is irrelevant?
In response to Garthor
I answered the question by proving the question to be invalid itself. I made a statement referring to code, and you strecthed it to apply to other things, and then you asked why it didn't make sense. You missed several key points,so of course the question would be invalid. The answer is only irrelevant because the question makes no sense.
In response to OneFishDown
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.



In response to OneFishDown
Okay, let me re-state the question, as you are incapable of finding it out yourself:

If you are so opposed to libraries, then why do you use the procs that Dan and Tom wrote for DM? Why do you even use DM?
In response to OneFishDown
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
In response to OneFishDown
I'm not a programmer... I'm a game developer. I don't know the first thing about coding.* BYOND is a game-making community. If we were about programming, there would be as many people making, I don't know... abstract mathematical formulae and income tax forms and spreadsheets and things... as there were people making games.

There are people out there who have better ideas for games than you or I. How do I know this? Because there's always someone better. These people may or may not have the programming knowledge needed to make a game, but they may have all the other knowledge necessary... things like game balance, plot control, aesthetic design principles, an intuitive grasp of "fun"... things that, if you're talking about "making a game" rather than "coding a program", are waaaaaay more integral to the process than the actual programming.

If BYOND reaches the point that Deadron's talking about, there will be tons and tons of really crappy games made by losers who just walked in the door, yes. Good news for you: you will never, ever have to play any of those games. Better news: the people I just described, they will also get a shot to make their games, and if you choose to, you will be able to play them.







*Which is, always comment your code. I also don't know the second thing, which is, always make back-ups. These two pieces of ignorance are why so many of my projects fall apart.
In response to OneFishDown
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.
In response to Lesbian Assassin
Not to drag up this thread (not that its old or that "dead") but there is a difference between coding and programming.
In response to OneFishDown
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.
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.
In response to Sariat
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
Page: 1 2 3 4