how libraries make things really really easy in Tutorials & Snippets

Page: 1 2
#20 Mar 14 2012, 11:38 pm
I'm not even sure where this notion of them locking topics due to insults came from in the first place.

Not this thread, but a similar one from about a week ago was locked for that exact reason. Basically he's trying to avoid a flame war (and a locked thread) by removing the insulting comments. (even if they weren't THAT insulting)

No, I never said that they don't learn how to use the library, that would just be ridiculous. They don't learn to use the concepts that the libraries themselves make use of.

Hopefully that's what the tutorial will do. I'd like to see step by step of how the library was made and how to use it, that's probably the best way to put across the concepts as well as teach its use. Learning how to drive a car isn't enough,knowing how it works, then how to drive it, that usually gets the idea across.

Which is exactly why nobody should be using libraries?
Well, saying that you shouldn't use libraries because you could learn by trial and error is silly. That's akin to saying "don't read books, you should go out and learn about the world on your own." Books are faster, but only if you actually understand them. Libraries are faster, but only if you understand them, not just how to use them, but how and why they work.

This seems to be why he's making the tutorial though, to teach the concepts, the code, and how to implement it properly so that people don't have to waste their time learning by trial and error and can instead learn the same information by way of guidance.

I can see why you dislike people using libraries, you believe it stunts their ability by making things too easy, I understand that. However, not helping at all is just as bad as giving them everything at once.

I mean, have you ever built a cell phone? I bet you still use one, or a phone of any kind for that matter. How would you feel if someone called you lazy or stupid for not building your own phone from scratch?

Libraries are tools, using them without understanding them is bad, yes, but removing them completely is worse. Some people don't even try to code when they realize how difficult it can be at first. Having a library could bolster their resolve while they work on trial and error in other parts of their projects.

It IS a double edged sword, but I'd rather cut my hand on my own blade than be completely defenseless.
#21 Mar 15 2012, 5:07 am
In response to Bravo1 (#20)
Things are starting to get way *way* off topic, so here's hoping to getting back on topic:

Using the Map Instancing library to reset levels will reset the level to the exact same initial state. Suppose, instead of using the library, you just called world.Repop() to restore all enemies in the level you had killed. The enemies that weren't killed won't be reset. Calling the map's reset proc will delete and recreate all mobs.

What this means is that if the level has a part where the player has to make some tricky jumps while avoiding enemies, the timing and positioning of the enemies will be consistent each time you reset the level. If the enemies weren't deleted and recreated each retry, the timing might change from attempt to attempt. This way, the developer and players know that the timing will be consistent.

And that only takes a single line of code =)

Bravo1 wrote:
I mean, have you ever built a cell phone? I bet you still use one, or a phone of any kind for that matter. How would you feel if someone called you lazy or stupid for not building your own phone from scratch?

This is a good example. When you want to make a phone call, building a phone sounds like it's related to your goal (and in a way, it is), but not building your own phone doesn't detract from your ability to make a phone call. The same can be said about using a library when you're making a game - it seems related to your goal but using libraries to handle lower level details doesn't detract from your ability to make a game.

That's also a good example because most people don't know how to build phones. You don't need to know exactly how a phone is constructed to know how to use one properly. The same is true of libraries.
#22 Mar 15 2012, 6:05 am
In response to Forum_account (#21)
I think Falacy's point is that he would like to know how to build a cell phone from scratch, for the sake of knowledge. Though it would be nice to eventually know everything in the universe, I'd like to leave that to the theoretical physicists.

I made a library of my commonly used procs because I'm too lazy to keep rewriting them. If I had to, I could definitely rewrite all of them at any point in time, but it's just tedious. This is another reason I find for using libraries, it's just like copy/pasting, but with a click of a checkbox.
#23 Mar 15 2012, 6:23 am
In response to Kaiochao (#22)
Kaiochao wrote:
I think Falacy's point is that he would like to know how to build a cell phone from scratch, for the sake of knowledge. Though it would be nice to eventually know everything in the universe, I'd like to leave that to the theoretical physicists.

I made a library of my commonly used procs because I'm too lazy to keep rewriting them. If I had to, I could definitely rewrite all of them at any point in time, but it's just tedious. This is another reason I find for using libraries, it's just like copy/pasting, but with a click of a checkbox.


At some point previously Falacy mentioned that he also reuses his own code from other projects to suit them to his needs for new projects.

That's using personal libraries, which in effect is the same thing.

It's fairly counter productive to always start from scratch with every project.

I believe Falacy's main gripe is that alot of people who begin DM are impatient. Rather than seeking out knowledge they want to get to point B of owning a game, no matter how generic or crappy it may be, simply because they are too impatient and lazy to take the time to improve their own skills. And I agree with Falacy fully on this point: I can't tell you how many people have approached me about helping them with games, yet when I offer my assistance I find they aren't even familiar with the guide and are already trying to apply overlays or can't figure out why "this character won't die" or why they keep getting "src" errors.

No matter how much you stress to those people the importance of studying, it never gets through. I literally have one guy I know who has been studying DM for upwards of two years.. all because he insists on trying to use libs to piece together a project.. when a week of studying and learning would have benefited him so much more in the long run, and to this day, he refuses to simply take the time and study the guides and references, citing that it's "boring".


This does not make me inherently dislike libs however. A tool is only as good as it's user. If you were facing a trained soldier and you were both armed, yet you have no experience or training, well you understand the situation. It's not really anyone's fault that people misuse libs, except the person misusing the lib.

In the hands of a capable programmer, or someone who understands it's proper use, they are powerful tools that can be used for great things, however, they can also be very detrimental (As Falacy has done a very good job of pointing out.)
#24 Mar 15 2012, 6:50 am (Edited on Mar 15 2012, 9:47 am)
In response to Kaiochao (#22)
Kaiochao wrote:
I think Falacy's point is that he would like to know how to build a cell phone from scratch, for the sake of knowledge. Though it would be nice to eventually know everything in the universe, I'd like to leave that to the theoretical physicists.

I think there's more to it than that. He doesn't distinguish one part of a DM program from another. To create a BYOND game you have to write DM code, so writing DM code is always important to your game. Using a library means there's some code you didn't write, but because all code is important to the game, you should write all code yourself.

It's just bad software engineering and I think it mostly comes from the fact that BYOND does so much for you. People look at tools like BYOND and think it's the whole game engine and they just have to code some special attacks and they're done. They treat all of the code they write as one single application layer running on top of BYOND. There's still a lot of underlying infrastructure you need to write to turn BYOND into your game's engine. It's like the difference between OpenGL and OGRE. You can take a simple OpenGL example, add some keyboard input, and have something that looks like a game. But, without any separation between the graphics engine and the game you're not going to get very far.

That's why a lot of BYOND games never get finished. Without thinking about code in the right way things get too complicated and eventually the project becomes too difficult to work on. This is also why most BYOND games are RPGs - there's less infrastructure to create. Add a chat verb to any project and you can call it an RPG. BYOND users struggle to create anything more complex than that because they're trying to build their game as a single layer on top of BYOND.

These kinds of programmers don't understand abstraction. That's why these same people are hesitant to use libraries. Not only do they fail to see the value in having a library abstract details out for them, they also don't view their own code in this manner. They don't implement things in a way that details are abstracted out because they just don't think that way.

I made a library of my commonly used procs because I'm too lazy to keep rewriting them. If I had to, I could definitely rewrite all of them at any point in time, but it's just tedious. This is another reason I find for using libraries, it's just like copy/pasting, but with a click of a checkbox.

In that case you're re-using code that you wrote, so I don't think many people will have a problem with that. When you use a library, you're using code that someone else wrote, but there's nothing wrong with that either. A lot of my libraries handle tedious things so you don't have to bother writing the code yourself.

It's also possible for libraries to handle complex things that you couldn't necessarily write yourself, but that's fine too. For example, if you wanted to encrypt values in savefiles you could use an encryption library. You don't have to understand how the exact algorithm works to be able to use it. If you're trying to make a game and have no interest in going into the field of security and cryptology, it doesn't matter.

Edit: Some of my libraries include things that are probably out of reach for most DM programmers. For example, the Region library contains some decently complex algorithms that are hard to understand, but provide features that are easy to use. While it's ultimately best for a novice programmer to eventually learn how these algorithms work, until they're ready, there's nothing wrong with using a feature they don't understand. Most people use BYOND's DM compiler without understanding how compilers work.
#25 Mar 15 2012, 9:10 pm (Edited on Mar 15 2012, 11:31 pm)
In response to Forum_account (#21)
Forum_account wrote:
* map library *
The general concept of what calling reset() does is understandable. However, your example of how to create a new map is simply map = maps.copy(zone.target_z). I have little idea what this does. I could assume that maps is a variable included in your library, and contains data about all of the z layers of the map, but what about the rest of this? If this was truly the way to create a new map, then map would also have to be an included variable, which means you can only ever instance a single map to it. What is a zone? Another included variable? Would I not just send a desired z level here to begin with? Why is this zone or a reference to one of its variables even relevant?

*Build a phone!* This is a good example.
It isn't all that great of an example. In this case, the phone would be BYOND. Though I am somewhat in support of people ditching BYOND entirely, to build their own projects from the ground up (or at least finding a better engine, like Unity), that is somewhat of an over-expectation, and not really relevant to this argument.

In this case, it is more like you have a cell phone with an address book in it. You learn how to use this address book, but never how to actually dial a number. Now say your cell phone dies, you have to use your house phone, or some random payphone, but you have no idea how to dial an actual number. Or, what happens if you have to call somebody who isn't already in your address book, you won't even know how to add them, only how to select numbers that are already listed for you. This is the same concept as using a library in DM, you are avoiding the knowledge of how to use the actual features, by "abstracting out the details", as you keep saying.

That's why a lot of BYOND games never get finished. Without thinking about code in the right way things get too complicated and eventually the project becomes too difficult to work on.
Personally, I seem to have the exact opposite problem. I do fine implementing the core systems for my games. It is when I get past these systems, and it comes to implementing 300 nearly identical enemies/weapons/whatever, where all I have to do is tweak 2 lines of code per item, when I get bored and uninterested by that tedious aspect of creating content.

This is also why most BYOND games are RPGs - there's less infrastructure to create. Add a chat verb to any project and you can call it an RPG.
I assume you mean RPs here, and not RPGs. A text chat with no meaningful gameplay (which is what most "popular" BYOND games are), is a lot different than an RPG (something like Final Fantasy), which are one of the most complex genres to develop.
#26 Mar 16 2012, 5:51 am
In response to Falacy (#25)
Falacy wrote:
Forum_account wrote:
* map library *
The general concept of what calling reset() does is understandable. However, your example of how to create a new map is simply map = maps.copy(zone.target_z). I have little idea what this does. I could assume that maps is a variable included in your library, and contains data about all of the z layers of the map, but what about the rest of this? If this was truly the way to create a new map, then map would also have to be an included variable, which means you can only ever instance a single map to it. What is a zone? Another included variable? Would I not just send a desired z level here to begin with? Why is this zone or a reference to one of its variables even relevant?

Questions toward a library or its features can be answered in either its documentation or through posting in its forum.
#27 Mar 16 2012, 5:53 am
In response to Kaiochao (#26)
Kaiochao wrote:
Questions toward a library or its features can be answered in either its documentation or through posting in its forum.

Good thing he posted this super informative tutorial then.
#28 Mar 16 2012, 6:03 am
In response to Falacy (#27)
Falacy wrote:
Good thing he posted this super informative tutorial then.

This is a tutorial about "how libraries make things really really easy." It's not a tutorial on how to use each of the libraries he referred to (that's why he referred to them; there's more info when you click the blue links).

The examples were given to show how easy and simple it is to add a functionality to your game. You can assume this simplicity already stems from the programmer's knowledge of the library, the same way it comes from the programmer's knowledge of DM. That same presumption also goes for the statement, "BYOND makes it easy to make games," because you can't use BYOND well without knowing how to (and anyone who does are called rippers by this community, haha).
#29 Mar 16 2012, 6:30 am
In response to Kaiochao (#28)
Kaiochao wrote:
That same presumption also goes for the statement, "BYOND makes it easy to make games," because you can't use BYOND well without knowing how to

If there was a full tutorial just to cover such a claim (which would be almost as ridiculous as this topic), then I would at least expect it to have functional examples. The old default "Create" page used to show simple code for a chat verb, for example, after making such a claim. The code examples provided with this tutorial are ridiculously simplified, probably in an attempt to take this foolish library propaganda even further, and would just cause runtime errors, unless unknown extra work was completed by the user.
#30 Mar 16 2012, 6:46 am
In response to Falacy (#29)
To reiterate what Forum_account said, this is a topic aimed towards decent programmers, not people new to the language. If the reader doesn't understand how to set their project up for using the library in one line, they must not be a decent enough programmer. And again, any questions anyone has on how to use the library can be answered by it's resources and forum, just like BYOND.
#31 Mar 16 2012, 7:16 am
In response to Falacy (#25)
Falacy wrote:
However, your example of how to create a new map is simply map = maps.copy(zone.target_z). I have little idea what this does.

The library's hub entry explains how this works. Here's how you copy a map:

// make a copy of the second z level
var/Map/map = maps.copy(2)
world << "The new copy is on z level [map.z]."

The maps.copy() proc creates a copy of the specified z level and returns a Map object which contains information about the map instance (it also contains reset(), repop(), and other procs).

What is a zone? Another included variable? Would I not just send a desired z level here to begin with? Why is this zone or a reference to one of its variables even relevant?

A zone is a kind of turf defined by the game. When you're on the world map and press space bar, if the turf you're standing on is of the /turf/zone type, it creates an instance for the z level the zone points to.

If this was truly the way to create a new map, then map would also have to be an included variable, which means you can only ever instance a single map to it.

The original post leaves out some of the details. The game uses an Instance object to manage each instance. Each Instance contains a reference to a single map object, so while each instance can only hold a single map, to create multiple copies you just create multiple Instance objects. The line to create the map instance is taken from the Instance object.

The Instance object has all of the game-specific logic for managing a level. There's more to it than just what the Map Instancing library's Map object provides. It works something like this:

mob
    var
        Instance/instance

    key_down(k)
        ..()

        if(k == "space")
            var/turf/zone/zone = loc
            if(istype(zone))
                instance = new(zone)
                instance.enter(src)

Instance
    var
        Map/map
        turf/start
        turf/world_loc

    New(turf/zone/zone)
        map = maps.copy(zone.target_z)
        start = map.get(/turf/start)
        world_loc = zone

    proc
        enter(mob/m)
            m.loc = start

        restart(mob/m)
            map.reset()
            m.loc = start

        exit(mob/m)
            m.loc = world_loc
            map.free()

This way the game isn't bogged down by the details of managing the map instance. As the process of creating an instance becomes more complex, the code that uses it doesn't change. When the player clicks the button to restart an instance, it only calls the restart() proc and all of the details are handled there.

[Edit: This is just how you use a library. While the details of what a zone is weren't obvious, it is obvious that some steps are taken to use the library appropriately within a project.]

A lot of people would not use the Instance object and just handle the code directly in the key_down() proc (or, more likely, in a verb the player clicks). With that kind of approach, there's no one place to make changes to keep things organized. Changes to how instances are created would impact the mob's key_down() proc, which doesn't make sense. This is how BYOND projects get disorganized an unmanageable. It takes effort to actively remember when things aren't where they belong and you can only remember so much. When you take the time to make a place for each function to belong, the code is much easier to work with.

Using libraries reinforces this idea because a library is a place where you're tucking away code. People are often hesitant to use libraries because they don't understand this concept and don't apply it to their own code. When you start programming, 100% of the challenge is just figuring out how to write code that does what you want to do. Once you know how to program the problem becomes organization - it's easy to write code to perform a task, but the problem is keeping a large amount of code organized so you can work on the project effectively.
#32 Mar 16 2012, 8:20 am
In response to Kaiochao (#30)
Kaiochao wrote:
To reiterate what Forum_account said, this is a topic aimed towards decent programmers, not people new to the language. If the reader doesn't understand how to set their project up for using the library in one line, they must not be a decent enough programmer. And again, any questions anyone has on how to use the library can be answered by it's resources and forum, just like BYOND.

I don't mind answering questions here (this is not as off-topic as other tangents have been), but I don't think the questions being asked here make sense. Falacy seems to be trying to suggest that the library is confusing and hard to use, but this topic assumes that people have a decent understanding of DM - certainly a good enough understanding that they can figure out how read and understand a library's documentation.

There's really no difference to using a library and using DM. It doesn't matter if the maps.copy() proc is part of DM or provided by a library, it's easy to understand either way. People want to get to a point where they believe they understand DM's features. Using a library means there are more features for them to learn and, if they didn't know how to create the library, it shows that they weren't as good with DM as they thought.

A lot of people view DM programming as a series of procs you have to master. Once you learn how to use vars, if statements, loops, locate(), view(), step(), etc., then you know how to program. A DM library is made using those procs, so it would follow that if you understand those procs you don't need the library. A program, however, is more than the sum of its basic elements. If you know understand lists, if statements, and loops, you don't automatically understand how sorting algorithms work.

This is why people think they need to move onto C or Java once they've "learned DM". They don't realize there's more to programming than what they know about the DM language. Libraries show them that there's more to it and some people can't wrap their head around that.
#33 Mar 16 2012, 9:39 am
Falacy, you keep making the same points whlie ignoring what other people say. I don't think it's possible that you're making an effort here. I don't mind discussing this topic but it's not worth saying the same things over and over.

If you are being serious, re-read some of the posts here and try again.
Page: 1 2