Dante_Zero wrote:
all good coders were oncen good rippers, am I wrong?
Dante_Zero wrote:
Yea, well how else would we learn?
Whoa, that assumptions hurts. As a self made expert (and seeing as how this is the perfect opportunity to make a post discussing the depraved "programmers" I complain about) I just have to get my two cents in here.
The truth is, all good rippers end up being just that... good rippers. I have yet to meet someone who started off by infringing on other peoples' work and ended up becoming a good programmer from it. The closest thing that you could actually learn a small amount from is reverse engineering.
If you truly want to become a good programmer, you need to set aside other peoples code and make your own. I have been asked many times how I got good at programming, and "I started by ripping off other peoples' work and learned by it." will never be a given answer, for that is far from the truth. In fact, I allways tried to stear clear of other peoples' code as much as I could; I picked up Zilal's beginner's tutorial when I first started, but other than that I learned almost exclusively by wading through the reference and by practicing, lots and lots of practicing. Of course, I had to come to the forum at times to ask for help when I became stumped, but even then I asked for help in understanding the functions I had at hand instead of asking how to program the system at hand.
If you want to "learn" by "creating" games using other peoples' code, that's your call; but I will try to go in depth in this post about better ways to learn.
If you want to learn how to program (or even just want to create a program but don't care about the learning) starting by taking someone elses game and trying to jump right into adding advanced features on par with its level is one of the worst things you could do. Not only does it keep you from learning good design philosophy, but it will also gain you bad programming habbits (especially if the code you are using is a bugged up scrapheap itself, as I have been told is the case with the Zeta code). Some programs are designed to be learned from by disecting them, and doing so with them can be beneficial. However, those programs are designed with teaching in mind; and they usually contain code on the level of the intended user and will not drown the user in their vastness if taken one step at a time. I do not consider these types of programs to fit into this category of "Take random game's code and create a rip to try and learn." Rather, they are in a category called demos. (Demo being short for demonstration.)
Next on the list, and often abused (though not as bad as the above rip scenario), is taking a bunch of libs (lib being short for library) and demos and copy/pasting their code into a few new code files and calling them a new game. Demos are not meant to be included into your code, I would like to make that clear right now. Including demos will only create a tangle of code that does not support other code in your game and leave you with a buggy, unworkable mess. If you understand the basics then using a demo can be beneficial, but only by opening it up as a testworld and disecting it, not by including all its code into your game. Libraries can be helpful if you want to include a feature you cannot make yourself (or do not feel like spending the time to make yourself), but allways read the relevant documentation on them and be sure you understand them before you use them in your main projects. I have seen many projects ruined when their owners try to use a library incorrectly and mess up their code trying to get it to work. Create a test world in which to learn to use the library if you must. I have also seen people copy/paste a libraries code into their own and try to alter it to their specific needs; don't do this unless you know full well what you are doing (or unless you are doing it in a test project and trying to learn how the thing works). Lastly for this paragraph, some packages are meant to be a library/demo hybrid which can be included to another project or used alone for learning purposes; and if you use these, remember the above recommendations concerning its variation (lib or demo) that you are using it for.
Now that I have most of the don'ts out of the way, I will go into more of the dos. I shall try to start off from the beginning.
When you first dive into the learning process everything can be quite confusing, especially if you do not have any prior computer programming experience. Picking up one of the beginner's tutorials is the best way to go at this point in time (I suggest Zilal's beginner tutorial. It is the one I picked up when I started.) At first everything might be difficult to learn; but if you stick with it and mess around with the things you learn in the tutorials, and with any other tidbits you pick up along the way, you will be understanding it better and better all the time. Eventually you will get to the point where you feel like you have broken through a learning barrier and you will be able to create mini practice worlds with ease. When you get to the point where you can make worlds with objects on them and have given the players the ability to do some simple things (Such as attack an enemy on the map or talk to others they see.) you are on your way to success. At that point I suggest you do lots of practice and experimentation while browsing through the reference and looking for any functions or variables that you can understand and also going through the various other tutorials in the tutorials section. Practice and experimentation are key! You might have bad design philosophy for now, but since you are practicing doing it yourself instead of messing with other peoples' code you will learn how to do it better.
Once you are to the point where you can look through the reference and understand what most entries mean even when you see them for the first time you are at the mid point of this particular journey. At this time, if you still do not have the design philosophy skills to do many things yourself you can browse through the demos section and try to learn from them, many will be suited to your skill level. After seeing what some of the demos do, if you think you can duplicate the effect then do so; but try also to alter the outcome to however you want it to be. This brings up a very important point, one which many people fail to understand when trying to program. There is no "the way" to program anything. There are a multitude of different styles of any system and every style has a multitude of different ways to create it. When programming, don't think "What sort of things can I add, and how do I create 'the system'?" but rather you should think "What sort of things can I add, and how exactly do I want them to be done? How can I make a system to do specifically that?" That right there is something most people fail to understand, that programming is as much an art as it is a science and you paint your picture with your personal brush strokes to make the end result look exactly how you want it. It is at this point in your programming journey that you must drill that into your head if you have not allready, and you must practice and experiment to familiarize yourself with the nuances of various techniques and designs so you can eventually create what you want when you want it.
Once you get to the point where you understand the vast majority of functions the Dream Maker has to offer (and the various variables and how you can use them) and can manipulate them all to accomplish most needs you have, you are on the tail end of the first journey. It is at this point that you want to go through the reference like a book and soak up any functions and variables you have missed and researching any that were too difficult for you before to learn them now. Also, it would be a good idea to try and use most of the features that you have not yet used so you can be sure you understand them. This includes learning about savefiles if you have not allready done so and manipulating graphics using image objects and the client's screen list variable (These things come in very handy when you want to start dabbling in special effects.)
After you have all that done you can consider yourself to be done with your first journey. You are at a point where 95% of your learning is in the form of design philosophy and experimenting (yes, you still have the experimenting to do even at this point, in fact now more than ever) to find ways to accomplish things you did not even think of when you started your quest for knowledge. I say ninety-five percent will be design philosophy because you still might learn a li'l tidbit about Byond now and then that you did not know before. It is at this point where you should be able to pick up just about anything and at least understand what the code is doing even if the greater whole that it is supposed to accomplish is beyond your design philosophy. Yes, there is that word again: design philosophy. That word is extremely important, those with good design philosophy can often do even more than those who know all the functions, features and variables inside and out (For an example, I was creating decent combat systems and item inventories with usable/equipable items before I even understood the contents variable, before I understood Byond's lists even. I can do it much better now that I know more, but still I was able to do it when my knowledge of DM was next to nothing because design philosophy is my specialty.)
Once you accomplish all of the above (The dos, anyway.) you will find yourself spiralling to ever greater heights of programming eliteness. You will find yourself doing things such as putting text on the map, creating buttons and menus on the map screen too, saving information with ease, creating worlds that interact with each other as if they were the same program even though they are definately not, leaving the Byond default tile-based movement behind when you want something more accurate... and even greater things if you stick with it and put your mind to the test at every turn.
If you are interested in the path I took, it is even easier to explain than the above long-winded text. I picked up Zilal's beginner tutorial to give me the boot in the right direction then used the reference almost exclusively. I did lots of testing and experimenting, creating li'l games here and there (Most of them never completed since I am self-critical and don't think they were worth releasing.) The only demo I ever took to learn from was Nadrew's HUD demo (I picked that up when I was trying to understand screen objects), and the only library I have ever used was Gazoot's Dmpmaker. Of course, there is nothing wrong with using demos and libraries; but I did not even want to see the code in them... I wanted to learn everything on my own as best I could so I could completely self-dependent and objective (Also for the bragging rights, but that's just a trivial nicety. ;) ) (I still use Gazoot's Dmpmaker library on rare occasions since I have not felt like making my own dmp making code yet, thanks Gazoot.) Because of my stubborn ways and my constant, unrelenting practice and experimentation I can now do most of the things I want in any project I work on (The obvious ones not doable being those things which Byond simply cannot do, such as printing, creating more windows, ect..)
I hope you found all that to be insightful and beneficial, and if you decide to follow that path I wish you good fortune. This post is meant to help all you who are struggling to learn how to program but are turning to the wrong places. If you do follow it, and you do so with a passion, then I guarentee you will have better programming habbits and be able to do more in the end than if you were to stay down your current path.
I tried to go in-depth on this. Feel free anyone to link others here to help them see the light. ;)
