ID:492841
 
I posted an update to the pixel movement demo. It's a simple game that uses the Pixel Movement library and a few others. This project is the start of a game that I'm working on but it also serves as a good example of how these libraries make game development easier.

Pixel Movement - This creates the movement system. It handles the movement, collision detection, and keyboard input.

Keyboard - The Pixel Movement library uses the Keyboard library for its input. This makes it easy to add custom keyboard commands to the game - all I have to do is override the mob's key_down() proc. For example:

mob
key_down(k)
..()
if(k == "escape")
level_menu()

That's all it takes to show the level menu when a player hits the escape key.

HUD Groups - The level menu (with the Retry, Exit, and Continue buttons) was implemented in about 2 minutes. The HUD Groups library makes the addition and positioning of screen objects easy. Also, by using the Keyboard library I can set focus to the level menu object so you can press the R key to restart the level (only while the menu is open).

Map Instancing - When the player enters a level they're actually entering a new map instance. You don't have to worry about restoring the initial state of each puzzle - with a single line of code you get a fresh instance of the original puzzle. This also makes it easy to reset a puzzle. If a player dies or voluntarily chooses to restart a level, we just reset the map instance (the library handles this for us).

// to make a new instance
map = maps.copy(zone.target_z)

// to reset the instance
map.reset()

The Map Instancing library also provides methods to retrieve objects by type within a map instance. For example, when a player enters a zone they're moved to the turf of type /turf/start within the map instance. To find the start, this is all it takes:

var/list/turfs = map.get(/turf/start)
start = turfs[1]


Region - Regions are used to associate buttons with doors. The library provides a proc to get a list of objects (by type) that are connected to a source atom by the region. To make a switch open a door, we simply place a switch turf and door turf on the map then place a region on the map connecting the two. Then, we do this to find the doors that are controlled by the switch:

doors = region.get_list(src, /turf/door)

// when the player steps on the switch
for(var/turf/door/d in doors)
d.open()

These libraries handle common tasks that games need to perform. They don't just make it easy to develop this sample game, these libraries can be used in many different kinds of projects. Something that may seem daunting, like creating separate map instances for battle screens is handled by the Map Instancing library in a single line of code. Instead of wasting your time writing code to copy maps you can be more productive and spend your time writing code that uses the map copies.

You don't have to write this common code, you can skip right to writing code that uses the map instance. It might not seem like a big deal, but shaving 5-10 minutes off of every task can make a huge difference. BYOND has a lot of "half creations" because people get bogged down with the generic, common, basic tasks. By the time someone implements an elevation system from scratch they feel accomplished - they don't have to make a game using it, just creating the system itself is an accomplishment. By using libraries you cut out this overhead and jump right to more important things. The concept of using tools that handle generic, common, boilerplate-type tasks for you shouldn't seem strange, that's what using BYOND is about.
I'd rather enjoy creating my own system than use a library for something I can produce on my own; however, that's just my opinion.
lol Was there some confusion about plug-n-play code making things easier?
Obviously, sticking somebody else's already finished code into "your" game is going to remove a lot of the work that you should do yourself *cough cough*Zeta Rips*cough cough*. However, vast majority of BYOND libraries are poorly written. Using libraries also takes away important experience that you would gain by creating the systems yourself. Using libraries tends to limit/steer your design, the same way that using the BYOND engine in general does. In most cases, you will have a severe lacking of the internal workings of the library, and for those of us who are competent developers to begin with, we could probably just write our own, better systems more efficiently than using some library in the first place.

Moral of the story; though using libraries may be "easier", that hardly makes them a preferable method.

Also, as I mentioned in some other topic, these are all libraries that YOU made, so implementing them into some new project that YOU are working on yourself is hardly comparable to a random noob attempting to plug them in.
You guys are sort of missing the point which he emphasized in the last sentence.

Forum_Account wrote:
By using libraries you cut out this overhead and jump right to more important things. The concept of using tools that handle generic, common, boilerplate-type tasks for you shouldn't seem strange, that's what using BYOND is about.

Picking the right libraries to use is also a part of designing your software. If you already understand the problem that needs solving and find a library that suits all your needs then you don't have to waste time creating your own implementation. Just plug in their library and go. Worst case scenario is that the library is less-efficient than what you could have come up with and you notice it. In that case all you need to do is go write your own code that fits that library's API and you've improved efficiency. Best case scenario is that their implementation is far more efficient than what you were thinking of and so you've won in the long run.

Even in the worst case scenario described above you still win because now you know you've solved the problem, just with an inefficient solution. In software design you make it run, make it right, then make it fast. Using libraries cuts out wasted time in the first two steps.

Of course Falacy's point of being constrained by the library is valid, but that is part of understanding the problem that needs to be solved. If you understand what needs to be done you won't pick a library that doesn't meet your needs.
In response to BrickSquadron
BrickSquadron wrote:
In software design you make it run, make it right, then make it fast. Using libraries cuts out wasted time in the first two steps.

Except, most BYOND developers never bother with steps 2 or 3. Most of them can barely handle step 1, and instead of working with things to get better, they should just plug in a library?
In response to Falacy
If you're talking about BYOND developers' lack of understanding fundamental concepts of programming and syntax then no, they shouldn't just try to cobble together some assembly of libraries that seems to do what they think they want to get their game out there.

However, for complex problems it's better just to use libraries instead of creating your own implementation. If you're want to create your own implementation that's great, but if it's something like regex parsing then you're obviously better off using a library that's already written and reading some mathematician's paper on finite automata if you want to learn about how it's done.

This also holds true for problems you might already know how to solve, but have a library that does the exact same thing. Why waste your own time when there's a perfectly good free-to-use library out there?
I agree with both sides. When beginning, having to learn from a library is quite conflustering *yes. i often make up my own words.*

As you learn more it's alot easier to pick up advanced methods on programming as well as cut dev. time. So while I see both points, I'd just like to say.
For a sufficiently complex topic, the experienced gained by implementing it is often insignificant. What's more important is that you understand the concept. Once you understand the concept, implementing it is just tedious work. If you understand how you could copy a map then you don't need to waste the time writing the code yourself - you certainly can waste your time writing it, but you're not gaining much from it.

If you *don't* understand how you could copy a map then you're not ready to create a game and this discussion isn't necessary. People who don't have enough programming experience to understand how these simple libraries might work shouldn't be trying to make games yet. The question of "should they use libraries or not?" doesn't apply. Instead of working on an actual game they should be reviewing basic tutorials to learn how programming works.

There's also the possibility that the experience you would gain by understanding a topic and implementing it yourself is just irrelevant. I use Windows instead of writing my own operating system. I'd learn a lot by writing my own OS but the knowledge I'd gain isn't relevant to what I want to do. I wouldn't benefit from having that experience. The same idea applies to making BYOND games. Many people can benefit more from using the Dynamic Lighting library than they'd benefit from understanding it.
Anyhow, very nice article! And on a relevant note, I'm impressed how you currently have no less than 17 libraries published =). Hope you keep up the good work!
In response to Toadfish
Toadfish wrote:
Anyhow, very nice article! And on a relevant note, I'm impressed how you currently have no less than 17 libraries published =). Hope you keep up the good work!

Thanks! And thanks for counting them =)

This makes me realize how much work some of the libraries need. For 14 of the 17 libraries there's some change I'd like to make (mostly minor changes, but still).

Originally I had hoped that other users would make contributions to the libraries but that hasn't really happened. Not only would this have lightened my work load, but I think the libraries would be even more widely used if they were "our libraries" and not "my libraries".
This ended up being longer than I expected :-/

Some ethereal voice wrote:
You are correct, you should learn how to accomplish the same systems.
Libraries are fine tools to use and should be encouraged when developing a large project, so long as you completely understand what the library does and how to use it

It's tempting to think that way and, in contrast to other viewpoints, it does sound reasonable. But, what you're saying just isn't true. To suggest that you need a complete understanding also suggests the macho attitude that you have to do things yourself and know how everything works.

Having to understand libraries is an arbitrary distinction. There's no reason to stop there. A library is just something you didn't create that performs a function. BYOND fits that same description, so does your OS, so does the hardware that makes up your computer. To say that you have to understand how all libraries work suggests that the details are important, but if you were that concerned about details you'd have to include the details about how BYOND, Windows, and your computer's hardware all work.

Many BYOND games save a player's character by creating a savefile for each player and writing their mob to it. If you needed a complete understanding of file I/O that would mean you need to understand how your operating system manages files and how your hard drive physically stores data. That's clearly overkill. You don't need to know all that. This doesn't mean that all knowledge of low-level details is unnecessary. If your game frequently reads data from the same file you may improve performance by storing the data in memory. This is because disk reads are slow, but to know this you'd need to know *something* about how hard drives work.

The details that are important to you depend on what you're doing. BYOND users are making games, so the details that are important are the ones that might relate to their game. This is why people have no problem using BYOND even though it handles networking for you (in fact, that's why people do use it). You don't know exactly how BYOND's networking works but you don't need to because it's usually not important to your game. This is also, in a way, why people are strongly against ripping. In a rip, the code that's most central to the gameplay was written by someone else - the ripper has no knowledge of the details that are important to their game.

This is why you don't see libraries that cover important gameplay topics. There's not a good combat system library because combat is a crucial part of the gameplay. The details will be important to the developer and libraries abstract out details. There's no way for that situation to be handled well.

The benefit of a library is that it saves you time. You can learn only the details about a library that are necessary for accomplishing your goal. If you implement things yourself you have no choice, you have to understand everything. There's no benefit to understanding everything. If you think that level of understanding is necessary, you're never going to be a good programmer. But that's another topic...
Using libraries will definitely save time just as long they're developed right and are of use to what you need. One shouldn't need to reinvent the wheel unless they can make said improvements to the wheel. I been working on libraries lately to try bringing new or improved things for others to use at a modular level. There are times where people who are capable of studying other libraries or code can build even better versions that end up with a better user/programmer friendliness experience or something that takes a library's concept to a new level.

Of course that isn't always available with closed source libraries (does not apply in DM), but an open sourced library can encourage further improvement of existing libraries or create new ones that take it further. In any case, it is a not a bad idea to use libraries for any features or capabilities you need. You are also still free to build said features/capabilities yourself with the cost of development time. Forum_account is right in the regard it takes time to even build any said features. That's why I haven't released certain libraries yet (though I do sometimes release test versions).

That is all I have to say for now.
I will take part with Falacy on this one 100%. If you can do it yourself, do it, if not learn it. That is the only way to get further in life in my opinion. At least when it comes to something small like creating a game here on BYOND, where you would actually benefit more from doing it yourself. However when it comes to the real world, libraries are inevitable.
If you truly believed in doing everything yourself, like Forum Account previously mentioned, you would not be using BYOND to make games. BYOND libraries, for the most part, are intended to make things easier for you to finish a working game. The goal in game development isn't to see who's the best programmer, it's to make a game people can enjoy.
In response to Doohl
Doohl wrote:
If you truly believed in doing everything yourself, you would not be using BYOND to make games.
If I had the knowledge to make a game engine myself, using something like C++, then I would surely do so. This is what all of you here are claiming, "I COULD do it myself, but I don't want to". You are supporting the use of libraries, a concept that intentionally avoids knowledge, and seriously hinders potential*. All of you claim that you are more than competent, and could easily set up these systems yourself, but would rather save 5 minutes by using a library. Time management itself is not one of the reasons why I use BYOND. I can certainly make things faster here, not because BYOND is some amazing engine that handles everything for me, but because majority of my time spent with other languages/engines is spent researching the most simplistic of material in an attempt to get anything done. Which I have to assume as the true reason that all of you use libraries.

*Lets say Joe plugs in random library #1234. This library handles HUDs for him. Joe masters how to use this library, calling the few simple procs that it provides, but now he wants to make more advanced HUDs, or customize his current ones outside of the scope of this library, or even create an entirely new game without using this library; He will have no idea how to do any of that. All Joe knows how to do is call AddHUD(). By using some library, he has deprived himself of generally important knowledge like screen_loc, client.screen, and even the most basic concepts like how to use objects for HUDs. He may even be under the impression that this library provides some otherwise unavailable features, and that he must include this library to have HUDs in his game. Or the opposite, that this library only augments already existing features, but calling AddHUD() without this library won't actually work.

I am in a situation similar to Joe's. I may be able to use every feature included in the BYOND "library", and be able to create practically anything within its bounds, but I am dragged down by its countless fundamental limitations and generally buggy performance which I have no control over. I can only imagine if I had devoted myself to creating my own standalone projects, instead of wasting that time on BYOND, I would probably be incomparably better off.

The goal in game development [is] to make a game people can enjoy.
Interesting theory, though I'm not sure when the last time that I played a game where "enjoyability" seemed even a minor consideration. Games nowadays are made to attract players, sell copies, and make money. Rarely is a game created for the purpose of fun (for either the developer or player). The grind of an MMO, or slaughter of an FPS is rarely enjoyable, even when on the winning side. Long gone are the days of games that promote true progression or inventively enjoyable gameplay mechanics.
In response to Falacy
I've explained a few times now why this isn't true but those posts may have been deleted.

Falacy wrote:
This is what all of you here are claiming, "I COULD do it myself, but I don't want to". You are supporting the use of libraries, a concept that intentionally avoids knowledge, and seriously hinders potential

If you could do it yourself, there's no knowledge to gain by doing it yourself. The problem is that most BYOND users are bad programmers and don't have a good understanding of their own ability, so when they say "I COULD do it myself..." they're usually wrong. However, when a more experienced programmer says "I COULD do it myself, but I don't want to" they're correct - they understand how things work and they know there's nothing to gain by writing that code.

This library handles HUDs for him. Joe masters how to use this library, calling the few simple procs that it provides, but now he wants to make more advanced HUDs, or customize his current ones outside of the scope of this library, or even create an entirely new game without using this library; He will have no idea how to do any of that. All Joe knows how to do is call AddHUD(). By using some library, he has deprived himself of generally important knowledge like screen_loc, client.screen, and even the most basic concepts like how to use objects for HUDs.

Knowledge of screen_loc isn't important. It's a terrible way to manage an object's position because there's no easy way to read the components of the position back. Moving an existing screen object 12 pixels to the right is a messy operation. Having a way to position and move screen objects without ever using screen_loc directly would be a wonderful thing. If a library could abstract this out, that'd be great.

In a way this does deprive people of knowledge, but people can still look up how screen_loc works if they ever do need to understand it. It's possible that the library abstracts out screen_loc so completely that people never need to understand it. In this case, it's not a problem that the programmer is "deprived" of knowledge. DM programs are ultimately executed as sequences of CPU instructions but this is abstracted out by BYOND (and the c++ compiler used to make BYOND) so that you can write a DM program without having any knowledge of your CPU's instruction set. The same thing that deprives us of knowledge of our CPU's instruction set is also what lets us accomplish more using less time.

Many of your points assume that people are bad programmers. To the average BYOND user, screen objects are very complicated. To the average programmer, screen objects are stupidly simple. BYOND attracts a lot of bad programmers which is probably why you make that assumption. But, if we're going to cater to BYOND's bad programmers, the best DM programming guide would be "stop trying, you'll never figure it out, just play Skyrim instead".

This is probably why many BYOND users are hesitant to use libraries. They're not very good at programming and, to them, screen objects were confusing and difficult to figure out. If it takes weeks for someone to understand how screen_loc works, they'll be against the idea of spending more time to learn how a library works. If we assume this advice is being directed to a decent programmer it makes a lot more sense.
It's also worth mentioning that libraries may just do things better than the user would do. It's not necessarily from a lack of ability on the user's part, it's just that sometimes the best approach isn't obvious. The user could spend the time thinking of the best solution (and this might be a good exercise in problem solving) but it saves them time to use the library. This doesn't mean they're lazy. They're not avoiding problem solving altogether - they're using the library to solve an even bigger problem. If anything it means they're ambitious because they'd rather focus on the larger problem.

For example, the Text library contains the best DM proc for concatenating strings that I've seen. It's not a method that many people would think to use but it's very effective. People who refuse to use the library probably won't come up with a method as effective on their own. Assuming your goal is larger than concatenating strings, there's nothing wrong with using the library (even if you don't understand how it works and didn't think of the approach yourself).
I have to agree with Forum_account here. Falacy is speaking as if every developer is infinitely less competent than he, and none of them know anything in the least about programming. If that were true, he would be correct; they shouldn't use libraries. They should spend their time learning.

However, the developers who know what they are doing like to focus on things bigger. If they need the player to call a procedure that grabs a file that returns a string that they need to separate using commas or other symbols, and call a certain proc depending on what is returned from that text, which then does some more file-grabbing, obviously they don't want to spend all of their time creating an efficient way to handle that text string.

If they have a library that provides the necessary functions they need, such as separating a text string into a list using delimiters, then there is no reason they shouldn't use it.

It isn't that they can't create the same function; it's that it isn't worth the time when it is already created and readily available.
You know, I voiced this concern earlier, this discussion is really distracting from the point of the thread and should be moved to Design Philosophy or segregated from the tutorial otherwise. The tutorial's purpose is to illustrate the benefits of using libraries, so questions and criticism must inherently assume the point of view that libraries are potentially beneficial to be educationally relevant. A discussion of whether libraries do more harm than good is interesting, but placed here it's simply discouraging to someone who might wish to ask a genuinely constructive question.
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.
Page: 1 2