I feel like some kind of monkey even asking, like I've failed an obvious test...
How do I see the code that's gone into Byond games?
Am I even allowed to? Should I even be trying?
I'm the newbiest of newbies. I'm just starting out in trying to learn programming. The Byond tutorials are great and a bit of a decider in my choice of easy-to-use development, err, thingo to learn, but what I really want to do is peer into the workings of a fully developed game. Specifically, I'm trying to take a peek at Crispy's pretty damn cool YAGSACG. But no code files seem to show up.
What do I do, if I can?
I promise not to ask any more questions for a couple of months if you can answer this one.
ID:167041
May 10 2006, 4:07 am
|
|
May 10 2006, 4:18 am
|
|
You can't.
|
You can't. And that "peeking" is probably "copy-pasting the code, using it without knowing what it does or how it works, and claiming it as your own", as we've seen a zillion times.
|
BYOND does not use script files, it actually compiles the source much like C++ or VB does. You cannot see the source unless you are given the source to begin with. I would recommend doing some tutorials before trying to reinvent the wheel or try to understand other peoples programming styles. If you notice on the left bar, there is a Tutorials link, I would recommend the ZBT tutorials.
|
SmellyTerror wrote:
Should I even be trying? Learning by example is certainly a valid path; But depending on who you are, it might not be the best of ideas. Start with the tutorials, look at the Guide/reference (particularly the Guide though) and read up on it. Experimenting by yourself is typically good enough to get started; If you have questions on how to implement something, these forums should be ample for asking -- Just be sure that you realize what you're asking, and that you're detailed and thorough enough that someone can tell what you're trying to do without having to have background knowledge of some game or concept that people may or may not know. Cheers and good luck, Alathon |
In response to Mysame
|
|
Mysame wrote:
You can't. And that "peeking" is probably "copy-pasting the code, using it without knowing what it does or how it works, and claiming it as your own", as we've seen a zillion times. Well no, for me it wouldn't be, since I wouldn't know how. Whatever you've seen a zillion times is not really known to me since I am, as I said, a complete newby. Thanks for the beligerant answer, though. Really lights the spark of good will. The reason I want to see a completed product is that, as I go through the tutes, I want to see what they're talking about. How it actually works, basically. Tutorials always include some basic example (showing the value in the method), but that doesn't really show how a complete package gets put together. And so far I haven't found a person writing a tute who has the good will that extends to including the code of a completed product - beyond the very, very simple. I have no idea what a completed, complex program looks like. That's what I'm after. Can't be done? Fine. But the implication I'm trying to steal work is just crap. |
In response to SmellyTerror
|
|
That's silly.
I'm working on a number of projects right now. None of them are "finished" products, but some of them could be passed off as finished with a few modifications. Those projects, because I break up and categorize my code a lot, consist of between ten and fifty dozen code files, each containing 50-200 lines of code. By the time I finish those projects, their size will have at least doubled. If you're a brand-new-bie, you don't want to wade through my morass of code, however modularized, documented, and thoughtfully categorized it might be (in many instances, it is all of those things). You would be troubled by the triple-threat of a) figuring out what individual procedures do, b) deciphering the meaning and function of large blocks or structures of code, and c) understanding the ways in which the various systems utilize and interact with each other. If you are brand new to writing code and designing programs, I suggest starting with small things, thinking and understanding on the single-procedure level, and afterwards trying to piece hundreds of single procedures together into a game or "fully developed" project. If you would like help with any of those stages, or if you just have general questions, please feel free to e-mail me at piratehead c/o gmail dot com. Best of luck learning how to operate computers on a fine level, and even better learning how to orchistrate all those fine operations. :-D -PirateHead P.S. If you want me to send you a fat source code to something, I will. If you can decipher it and learn from it, power to you. |
In response to Alathon
|
|
Alathon wrote:
SmellyTerror wrote: Thanks very much for a good answer. Basically, I'm reading stuff about commenting, and looking at example code that's ordered alphabetically, and wondering if people really do that. Do people make something like sub-folders for different functions? Are variables referenced in one spot to make them easy to change, or is that not practical? Most importantly, is there some important and overarchiing design principle that people actually use, but that I've not seen or even thought of? ...I'll wait until I have more experience, ok. But surely people want this sort of stuff eventually? Surely people don't just reinvent the wheel every time they learn to program? It's like I'm learning to read, but can't actually see a book. Sure I won't be able to write one yet, or even read one, but it'd be nice to know how it all turns out. Anyway, see you all in a few months. |
In response to SmellyTerror
|
|
SmellyTerror wrote:
Mysame wrote: It seems as though he is a bit bitter to all of those people with their Dragonball fangames that turn out to be rips of the ever-outdated and popular zeta source code. It should really be taken off the hub, therefore making it harder to find, but y'know, no one has yet. Forgive him. And, if you're looking to see some really complex code, look at SwapMaps (there are only a few people on BYOND who understand the programming completely). It's a tad bit outdated, but gets the job done, and overall is an excellent program. http://developer.byond.com/hub/LummoxJR/SwapMaps |
In response to SmellyTerror
|
|
Well, everyone forms their own style of programming, which includes how and where to put almost everything. It also strongly depends on the game.
For B-Net(My chat program), I had about 4 .dm files. 1 for world procs and world variables, 1 for mob procs and mob variables, 1 for chat output specific procs, which I had as a world proc, but they where so large that I felt they needed their own .dm and 1 for Topic(), which was very large. But for OpenRPG, I had a different system entirely, which is too long to list here. As for variables, they are best grouped together based on atom type. For all /mob/ atoms that share a variable, they should be grouped together, or at least that is they way I see it. If you have: mob You are going to have troubles finding variable B at some point. So: mob Would be a better system. As for putting them in order, that is all up to you, I know I don't. I normally cluster variables based on relation to a certain are of the game, and by most-likely variable type, but this is all just the way I prefer to do it. As you can see from above, I am not a whitespace fan, which is a strong contrast to what most people believe. It all compiles the same though. |
SmellyTerror wrote:
Crispy's pretty damn cool YAGSACG. Well thankyou. =) YAGSACG's code is pretty messy though; it wouldn't be a good choice to learn from. |
I promise not to ask any more questions for a couple of months if you can answer this one. No! That's not the right attitude. You should be looking at librarys and demos to get an idea of how to layout your code etc. Don't worry about asking questions, because the only stupid question is one that goes un-asked. |
In response to Crispy
|
|
You just don't want us to find all your Nazi gold, do you, Crispy?
|
In response to Jp
|
|
*mumbles* <font size=-2>Curses, foiled again.</font>
|
In response to SmellyTerror
|
|
SmellyTerror wrote:
...I'll wait until I have more experience, ok. But surely people want this sort of stuff eventually? Surely people don't just reinvent the wheel every time they learn to program? It's like I'm learning to read, but can't actually see a book. Sure I won't be able to write one yet, or even read one, but it'd be nice to know how it all turns out. Well, there are probably quite a few demo projects out there you can take a look at, if thats what you want. The danger in that is that not all of the content you'll find here is entirely as 'clean' as it should be; If theres one thing that learning by example usually creates its bad habbits. Also, its not really comparable to re-inventing the wheel; The sourcecode to a game is so vastly different from person to person (No comment on using stock code and barely modifying it) depending on programming habbits, knowledge, et cetera that there isn't a set formula for how to do things. Even on implementations of well-known algorithms and similar, there are multiple ways to achieve the effect (Although in those cases it almost always comes down to effeciency). There are quite a few demo's that refer to specific parts of games, and while I haven't looked there are probably a few complete games chugged away in the Demos section somewhere. |