How did you learn BYOND?
I have spent 4 days watching videos, reading the forum, and searching articles. I can find no tutorials that bridge the gap from: Hello, world! to advanced coding.
the SIMPLEST of things seem to be impossible to find.
What am I missing?
the DM guide is useless if you dont already know a certain level of coding, but at no point have I found any REAL information on how to do anything.
It seems to go straight from infantile "here's how to create a new environment" straight to: "you should now completely understand coding, youre on your own."
Obviously, theres plenty of people who have grasped the information, but where did you get it?
Should I just go back to Game Maker?
Suggestions?
ID:132540
 Jul 6 2010, 4:54 pm
|
|
|
Jul 6 2010, 5:15 pm
|
|
Leur
 |
I looked at work other people made, took it apart piece by piece, tinkered around with it and learned how to make similar stuff myself like the first few months I was learning how to code. After awhile of tinkering and learning how things work you'll begin to understand how everything in DM works, and be able to create things yourself for other people to take apart and tinker with. Even using a shotty source to learn from is alright, since you can see where mistakes were made, and register in your mind to not make those same mistakes.
|
Chitownhustla wrote:
I have spent 4 days watching videos, reading the forum, and searching articles. I can find no tutorials that bridge the gap from: Hello, world! to advanced coding. Where exactly are you getting stuck? What do you understand? What can't you figure out? If you don't tell us what you're having trouble with there's no way we can create tutorials to help you. I can write a tutorial about the topics I found confusing, but that might not help you at all because there are different topics that confuse you. | |
I thought I was pretty clear on my problem, but perhaps not.
I guess I was expecting, like any other application, that there would be step by step tutorials and instruction for every phase of BYOND. If I wanted to look up SPECIFIC questions where would I do so? For instance: How do I spawn a mob on my map, via a verb or clock? Just sending me to: http://www.byond.com/ members/?command=reference&path=proc%2Fnew#comment_1 does no good at all. Where do I find details on how/why the code works? How to implement it? How do you properly use For statements? http://www.byond.com/ members/?command=reference&path=proc%2Ffor%2Flist#comment_1 -- again, no help. I dont want to have to ask on a forum for every single thing step by step... I want to be able to research and learn. I dont see where that is available for BYOND. | |
Chitownhustla wrote:
For instance: How do you properly use For statements? If you read the entry for new, you would understand how to create a mob. If you would have read the two other entries the person provided you for locate and while. Then, you would see how to set a location on the map for this mob, and how to create a loop. If you read the guide you would also learn about loops, as well as timers such as spawn and sleep. The problem isn't that the information isn't out there, the problem is you aren't using it. The guide shows you everything. Starting from how to create a world, to explaining how to use built in features, what variables and functions are, loops, timers, if/else statements, pretty much everything. If you actually read it and try to learn from it rather than ignore it or skip around then you would do just fine. | |
You are very helpful Ulterior Motive.
Thank you for taking the time to reply to my thread with such brilliant advice. | |
You could attempt reading these, though they aren't finished.
| |
Chitownhustla wrote:
the DM guide is useless if you dont already know a certain level of coding, but at no point have I found any REAL information on how to do anything. Chitownhustla wrote: If I wanted to look up SPECIFIC questions where would I do so? That is actually the core of the problem you encounter. Your goal is to create your envisioned project and that is right where you start, which is a common misunderstanding. Please allow me to use an example. Let's say you want to write a decent little poem in a language you do not yet speak. You should not try to gather specific words and paste them together in no meaningful order, but instead, you should try to learn the grammar, the basic syntax and some of the more complicated language aspects (be it language unspecific, such as allegory, or be it language specific such as a saying). Now with that very basic knowledge, you could create the most beautiful poem. With programming, there is a very similar concept, going from basic to more advanced and progressing, instead of jumping right into the tricky stuff. I'm not sure where you see the jump from creating a simple project to 'you're on your own now' in the DM guide. Actually, the next step from creating a project is in displaying the ability to unite and structure specific tasks, as far as I remember (indention as means to combine several instructions). If you never browse/rush through a 'boring' section of the guide, but instead work your way through and try to comprehend the deeper meaning, could you provide some detailed examples on where you encounter a too steep progression? That would be most helpful for improving such material for others. | |
Programming isn't simple and you shouldn't expect to pick it up and be programming complicated things in a short amount of time. Don't rush through the tutorials copying and pasting code, and then think you're really learning anything. Type it in, compile it at every step of the way, play around with it and tweak it to do other simple things, and get a grasp of what it is you are learning before moving on. Check out http://www.byond.com/docs/guide/ and slowly go through it making sure you understand what it is you are going through.
Do not expect mastery of programming in 4 days or even any time soon. The people who have grasped the information properly and are using it at a competent level either have had prior programming experience or have been learning and practicing what they have learned for awhile. That said if learning to program isn't the goal and you just want to quickly slap together a specific style of game there are probably better tools out there for what you want. If game maker works for you and achieves the goal you want why aren't you using it :P? | |
Improving the learning resources we have available here is something that we have discussed for quite some time. Some have even started on replacements which they thought would work better, but nobody (to my knowledge anyway) has finished doing so.
If you would like to go through the learning process and are scouring the site for resources and having difficulty, perhaps you present us with a good opportunity for proper feedback. Please, let us know which resources you think you understand well enough and which ones seem like there is a large gap in the learning process. I know what you're talking about since I was there once upon a time too. It took me a lot of digging over a long time to break that barrier. But that was many years ago (It's been almost a decade now!) and I can't see things from that point of view anymore. It would be great if you could help, from the users' perspective, to improve on the learning resources. I think Byond is underutilized because of the lack of good developers, so anything that can be done to remedy that would be good. Also, I must remind you again: keep in mind that Byond is generic on purpose. So you might find tutorials and demos created by other users specifically about "How to do X" if X is something that is done very often by many people, but usually you will not find something that explains how to do what you want. Rather, the system is set up so that, upon knowing proper programming concepts and being familiar with this language, you can structure it to make whatever you want (well, almost). | |
Chitownhustla im just starting coding to, and i feel overwhelmed aswell it feels like there is so many things and i don't know which is a basic to start at and what do next because it feels like i get lost within the movement and end back at where i started,
but i guess the best thing is just to keep trying, but atm it seems impossible to figure out how to feel byond as language, a right now it feels like a set of rules your just memorising..and can forget easily and don't know how they work properly making it difficult to try and structure your own basic code. But i hope you figure out a way people have done it and even thourgh it seem impossible all we can do is just keep trying and be determined not to stop | |
The suggestion I always give is simple. Learn by creating examples. The hardest part of this suggestion is being patient and setting your super awesome amazing game ideas aside for a little while.
Steps: #1. Think of something simple. An example could be: "Adding a monster that randomly walks around on a map". #2. Create this example by scouring BYOND resources and asking questions as needed. #3. Don't polish the example, just get it working as originally intended. #4. Constantly repeat steps 1-3 (see below for when to stop) If you run out of ideas you can look at existing games and interfaces and ask yourself, how did they do that? You can also ask for simple challenges after sharing what you have done so far. I recommend telling people what genre of game you're interested in and to provide a challenge commonly associated with making that type of game. If you dedicate yourself to this exercise and crank out around 50-100 examples over a few months, you should be ready to tackle some basic games. Most people try to create their dream game while learning which is fine (not really). Just understand that in most cases, you will bury yourself in mistakes which is expected. The next natural step is to start day dreaming of a another new grand game idea. You'll start to tinker and before you know it, the old dream project is on the back burner indefinitely. In other words, I recommend doing the example exercises and then tackling several very simple games (tic-tac-toe, puzzle game, maze game, side scroller, but no RPG's) before moving to mid-size projects. You will build confidence and REAL skill. Ok, in short, try to create one very simple example for each feature your dream project will have. If you can create them all individually, your well on your way to bringing them all together in a single project (your dream game). ts | |
Tsfreaks wrote:
Steps: I think this is good advice, but I don't quite understand #3. Why not polish these examples? I think that adding new features that you didn't initially plan on having is an important step. By adding features to an existing project you'll see how your original design made is difficult (or easy) to add new things. It is important to learn how to structure your project so it's easy to augment. I definitely agree that it's best to start small and have reasonable goals. By focusing on simpler, individual tasks you can improve your skills and still have a sense of accomplishment. | |
About #3.
These examples are not for "publishing" although you can share your efforts and solicit feedback and I encourage that. Do put on your peer internet armor and be prepared for any kind of feedback. Most is good but it can and often does come across as insensitive. The goal of examples is to declare, "Done! What's Next?" and to do so very often. Polishing adds tons of fluff that is not required to meet the original requirement. By building 50-100 personal and generic examples, you have effectively given yourself a private reference library. If you try to build "demos" which is what you are suggesting, then you effectively bury your simple example behind a ton of fluff and it takes 25x longer to complete. Demo's (good ones) are often times in the medium size project range. Demos also undergo a more rigid review process. If you want to take several existing examples and merge them into a new example that does something new, that's fine. Again, keep it generic, make it a new project, give it a self describing name, and again, only add the core requirements. An example. Your creating a teleporting example where a mob enters a turf and is teleported to another. The mob, grass, and teleporters do not need to look pretty. They don't even need to resemble anything. The point is about understanding the minimum code necessary to make a mob teleport from one location to another. Don't wast time on fluff. One more bit of advice. Game ideas are truly a dime a dozen. I have around 50 unimplemented game ideas just sitting around. While your working on your game or hopefully examples, you will think of new game ideas. This is good. Let yourself indulge to the point where you get the core game idea written down and tucked away. Don't spend more than a few minutes (1-20) writing down your initial thoughts. After the new idea has been logged, get back to the examples. When you've done your 50+ examples, review all the games you thought of including the original game and ask yourself this question. "Do I want to make any of these games?". If one really stands out to you, ask yourself this. "Have I made examples of all the features this game could need?". Get back to work. Once you have a game in mind and feel pretty confident that you could bring everything together into a single game, make a design document. Be grossly detailed with all the features, units, events, sounds, graphics, and etc. Go back to making examples when you find new unproven features. If you can complete a detailed design document that outlines the entire game from beginning to end AND you have proof of concepts for everything, you're ready to start writing a game. Most importantly, your prepared to finish. I beleive the rest will just come together if you take this route. There are other ways of course, but this is my recommendation if you want to create large world RPG's from scratch. I beleive my recommendation is far less work with more payoffs than trying to tackle the big game right from the start or even from a ripped project. ts | |
Yeah Tsfreaks thats sounds like a good idea, and i have gotten a bit more understanding of why i was that confused as i have gained a minuit more understand of what im coding in DM, right now after a few more tests i am to try to troubleshoot what was wrong before and work on what is was lacking at first i gained using that technique to improve and your idea sounds like a good idea to work on,
Mostly i would say my confusion was not understanding fully the argument that was writing in dream maker, and i want to be able to think of it what im doing fully in english and convert it to make sense in DM, but lacking how the coding concept work such as the way you link different part of the code together to make a feature and how to define , what im trying to say is its forming sentence's without knowing what are the rules of how the words and letters work to form that sentence, but knowing how that sentence work but not being able to use the letters and words out of that sentence for a totally different sentence, because i fail to understand the different ways of forming those sentences and how they can work, being able to seperate the code and piece it together with and understanding how they can connect...urgh i tried to explain >_>, but it seems im getting a little bit better so this problem hopefully will be overcome btw falacy ty those guide's were great and certain explanations allowed me figure out how work on some things | |
If you can complete a detailed design document that outlines the entire game from beginning to end AND you have proof of concepts for everything, you're ready to start writing a game. Most importantly, your prepared to finish. Writing a detailed design document requires more insight than you'd have if you've only created simple, toy examples for each feature. Many issues appear only when features are combined. The issues can be non-technical too: the code in your examples might be good, but the content and game mechanics might end up being bad. You can't know some of these things until people are playing the game. For any significant project you should never expect that your design doc explains precisely what needs to be done. There are also a lot of bad habits you can develop by focusing only on small demos and never working on them again once they are complete. If you never work on them again you can write awful code and use nonsensical variable names - the code only needs to make sense to you for the time it takes to write and debug it. Starting out small is a much better idea than starting out big, but making the jump from small to big isn't as easy as you suggest. Writing a 10,000 line program is much harder than writing ten separate 1,000 line programs. Writing simple example programs is a good way to practice, but you also need practice combining these simple examples together. | |