I learned a majority of the basic programming principles from BYOND and it was my first experience with a lot of basic concepts, the call stack included.
| |
Thank you Tiberath. I realize I was wrong all those times I've ignored DivineTraveller's advice to do it better. Time to recode some systems! :D
| |
I'll say three things:
First, "set background = TRUE" would be rather pointless here. All it does is essentially insert a sleep(-1) at the end of every loop. As you already have a sleep() there, it's redundant. Overall, I'd say the background setting is rather overused. Second, I recall making the same mistake a long time ago. I was using tail recursion like this to run some AI routine, and one day decided to leave my game running overnight for whatever reason I had at the time. Of course, it exploded, I came to entirely the wrong conclusion as to why (I believe I assumed it had something to do with the garbage collector) and I got straightened out by Lummox in the end, I think. And third, it would be nice to have a tutorial that covered some more nuts-and-bolts programming stuff, but I'm not sure if anybody who needed to read it WOULD read it. Better to just ensure that the available resources teach things the right way the first time around and leave the "why" for if people want to learn more about programming in the future. | |
There are two issues in play, really.
The first is that the target audience is wrong. Easy game development should've been rapid game development, and they are entirely different in nature. The first expects to not have to learn things which aren't easy (i.e. computer science), the latter simply expects to get going rather quickly. The second is that no material on BYOND comes even remotely close to covering these things - The DM Guide demonstrates easy and rapid, but never goes into anything complex. The complex issues are then bumped into by programmers once they get a game of some size on its legs, and then it collapses because of things like horrible control flow, bad recursion, typecasting wrong, no debugging method or tests, etc. In other words, computer-science related issues. Because of the fact that the language is incredibly easy to pick up and just 'do stuff with', running into problems usually means giving up or trying to hack their way around it - Why? Because they can't recognize the source of the issue, nor are willing to read 'boring' tutorials to create games with an 'easy' language. Even if those tutorials were created specifically for DM (Hash tables, recursion, call stack, control flow, tree structures, greedy/dynamic algorithms, etc. etc), they wouldn't get read by the people running into the problems anyway. As has been alluded to already, I suppose. | |
You're mistaken, if such tutorials did exist specifically for DM, I bet there would be a large number of DM programmers who read them. Be them beginner or not. You're making the assumption that every starter programmer is a source download away from a game where they want to be. I'm sure there are plenty of newer programmers in the community who are at least trying to do it the right way.
The people I target in this post, which is designed to punch them in the arm more than teach them anything, are the ones who will argue until they're blue in the face that because something works, it's right regardless of what anyone else says. And I think I got through to at least one or two of them that the more they argue topics they don't know much or anything about, the less seriously the people who actually do help them will take them. | |
Tiberath wrote:
You're mistaken, if such tutorials did exist specifically for DM, I bet there would be a large number of DM programmers who read them. Be them beginner or not. You're making the assumption that every starter programmer is a source download away from a game where they want to be. I'm sure there are plenty of newer programmers in the community who are at least trying to do it the right way. Whether I'm mistaken or not is up to guessing unless someone does go and write said tutorials. I don't make any assumptions about programmers at BYOND except to note that the majority of them are here for easy game creation. That doesn't mean they aren't trying, but there are differences in the amount of work someone is willing to do for something they are told will be easy, and something they are told will be quick to work with. However, I'm pretty sure that given past experience with such things, generally speaking the large majority of programmers on BYOND would not make use of them. This isn't to say that there aren't individuals who would, or that your article is pointless. Its simply an observation :) | |
Whether I'm mistaken or not is up to guessing unless someone does go and write said tutorials. Feel free to write those articles, it'd help me put a few more things into perspective. ;) Not to mention give people more stuff to link people to and help make explanations better. However, I'm pretty sure that given past experience with such things, generally speaking the large majority of programmers on BYOND would not make use of them. Well, categorising the programmers of BYOND into the already ill-defined beginner, intermediate and expert fields. I'd say more intermediate programmers would use such articles. Which in turn helps people already capable of pushing out games capable of pushing out better games. As you state, lots of users are here for easy game creation. So we'll throw them into the beginner categories, where as those who came for easy game creation a while back and are now more interested in learning the gritty stuff are left somewhat without useful resources. As most articles on BYOND seem to cater for the beginners in an attempt to get them to learn to be slightly less dependant on the help forums. Either way, I'm fairly sure I've lost the plot of what I was saying now or whether or not I was on topic with my reply at all. I'm sleepy. | |
As we say here in the states, "you can lead a horse to water, but you can't make him drink." We create tutorials for the thirsty horses out there; those people looking for tips on how to become a better programmer. We don't expect lazy-ass kids who only want to hack together a barely functional result to care why it works and improve their code as a result.
This doesn't mean we stop writing tutorials. It does mean we shouldn't get all that bent out of shape when we encounter people whose code sucks and it doesn't look like they care to improve it: they simply don't see the necessity. It's a problem of their core philosophy. Programming experience and learning the necessity to better your programming practice go hand in hand. The tutorials are there to show them the way when they are ready. This talk of attending classes as being such a red hot necessity is ill-founded. I wouldn't be surprised if there were a lot of people who passed computer science classes who are as bad at programming as the most rank BYOND novice. Although they could parrot the right answers, they still lacked the experience that built that fundamental understanding of the necessity behind knowing the answers. Thus, they would quickly forget all they learned, which probably wasn't much because they didn't understand the reasons behind the answers to begin with. Besides, all matters computer science get obsolete rather quickly. When I took an Intro To Programming class some 10 years ago, what they were teaching was procedural programming, with object oriented programming being mentioned as a footnote. Having already taught myself how to program BASIC and C, about the only useful thing I got out of that class was the concept of a bubble sort. I eventually picked up object oriented programming out of necessity for learning JAVA, but I essentially had to unlearn the procedural mindset. In the same way, all this supposedly indispensable knowledge of "hash tables, recursion, call stack, control flow, tree structures, greedy/dynamic algorithms" - all of this may well be obsolete when some hot new platform comes around that no longer works on the same principles or else middlewares them all into pointlessness. I had been dabbling in programming for well over a decade before encountering BYOND, but all of a sudden I was flabbergasted. There is no fixed starting point for the code, just a whole lot of events that happen which you tailor to your games. What's more, if I don't allow the code I add to end, rather than keeping the game going, it causes the game to lock up! What madness is this?! It's a whole different ball game when you have an actual active environment for which you are mostly coding calls to handle various things that happen (e.g. specific handling when a player logs in). However, I have grown to enjoy the system in time. | |
Just ping it by Lummox or Tom.