Let's start with an example of what I mean.
Space Station 13 was a very popular game. The owner eventually released a map maker for it. After you made the map, you'd send it back to him. He'd recompile, and send you the compiled game.
It must have been annoying for him, having to recompile all those maps. Whenever he left, they was no way to get new maps. But there was still a large fan base. And darn it, they were going to get their custom maps!
So then they made a program to inject their maps into the game. Then they decompiled the code and added new gameplay elements.
To get a new map, they went to those extreme lengths. Any programmer of a sandbox style game will tell you that the best part of making a game is making peoplecurious. Unfortunately, BYOND gives you two choices: 1.) You can compile it, and nobody can mod it, or, 2.) you can ncompile it, and it's the next dragon ball.
But lets say you could compile part of the code, and leave the rest uncompiled. Now they can make new maps (though I hope there would be an option to precompile maps, so they'd have to look for secrets) AND compile them. That, and they could leave hooks for people to modify attacks, stats, etc...
What do you guys say? Think it's a good idea?
ID:260644
 Oct 20 2008, 10:52 am
|
|
Sounds like you want a scripting language implemented, and that's perfectly doable! A clever DM programmer will be able to handle it. The game, of course, will take a hit to speed.
I wish we had regex support and that the eval() function would be expanded to include all of the available operators. But, the eval() idea is perfectly doable via DLL. Imagine the implications! Imagine the speed! | |
I really doubt the idea is feasible.
| |
Guy Hendricks wrote:
or, 2.) you can not compile it, and it's the next dragon ball. I'm okay with that as long as its fun and not anime or something that would appeal to the anime crowd. Nothing like a popular open source game to draw in a different bunch of users. | |
The concept you're looking for here is extensibility. An extensible game is easy to modify because it keeps all of its important elements in separate files that get loaded at runtime.
A classic example of this is DOOM. In that game, .wad files contained all of the graphics, sounds, and level information, so you could make major changes to the game by just compiling a different .wad with an external program. Duke Nukem 3D took this a step further with the .con file, which was a mini scripting language you could use to control how items behaved (though frustratingly, it didn't let you mod in a flamethrower). Quake also let you recompile its internal code, using a language very much like C. The key question to ask with extensibility is how much you need or want. Creating a scripting language is a bit drastic but it does open up more flexibility--as much as your language allows. Maps and monsters are probably the easiest things to make user-changeable, since you can base monsters off some generic monster AI and just modify their base stats, and maps are just a set of tiles. If you have a Roguelike game that uses procedural content generation, you could script up a mini-language for generating content and that would allow people to develop new room/level types with relative ease. However, ultimately I'm having trouble seeing how this discussion fits into BYOND Features, since it's clearly a Design Philosophy issue. It'd be difficult to build extensibility into a game that doesn't already have it by creating a new language feature. When you make a game extensible it's a design choice, and the degree of extensibility depends on how far you go toward implementing that choice. Lummox JR | |
Essentially the snag with Regex is finding a suitable library for BYOND to build on, as you'll see in the previous threads.
| |
Lummox JR wrote:
However, ultimately I'm having trouble seeing how this discussion fits into BYOND Features, since it's clearly a Design Philosophy issue. It'd be difficult to build extensibility into a game that doesn't already have it by creating a new language feature. When you make a game extensible it's a design choice, and the degree of extensibility depends on how far you go toward implementing that choice. I was requesting that we can have precompiled Dream Maker code. I admit, the explanation of why we should have it is a bit design-philosophic, the the main point of the topic is a request for precompiled DM code. Say, for example, you want people to make maps and compile, but you don't want them to have the full source code. You don't mind if they give themselves advantages or make new missions. This would be the ideal way to do it. All you need is an example or two rather than a clunky mission editor, a laggy scripting language, and a slow map loader. Also note the same could be done if you came up with an encryption for Byond code, applied that at compile-time for marked code, had a password to decrypt, and only decrypted to compile or when the password was entered. For us, it'd be lazier but more efficient. Course, for you it's another feature to implement. I know how that feels (though not to the extent you do). But you'd make a lot of people happy. Think about all the times you'd love to let someone use your feature, but don't want to let anyone else have the code. With precompiled DM code, you could have the best of both worlds. | |
Guy Hendricks wrote:
Say, for example, you want people to make maps and compile, but you don't want them to have the full source code. You are able to define the basics that would be used in your map (visual objects) and give that to them to use. The people that make the maps should have little to no reason to be using your source unless they are extremely trusted. Not to mention, if you included a map loader you could have people create and test these quite easily. All you need is an example or two rather than a clunky mission editor, a laggy scripting language, and a slow map loader. You do realize that all of those things would make development easy in the first place, not to mention that the tools you speak about are able to be optimized and made almost as fast as the DMB itself. A scripting engine is an easy way to create dynamic worlds in a much easier fashion than hard-coding it into the game, not to mention that it is more flexible. The map loaders are slow probably due to a multitude of reasons that I cannot comment on but I would wager that unoptimized code would be the problem. That would be easily fixed by comparing times to a DLL/SO version of some libraries. <small>By the way, "laggy" is the worst term I have heard of.</small> George Gough | |
Guy Hendricks wrote:
I was requesting that we can have precompiled Dream Maker code. I admit, the explanation of why we should have it is a bit design-philosophic, the the main point of the topic is a request for precompiled DM code. Say, for example, you want people to make maps and compile, but you don't want them to have the full source code. You don't mind if they give themselves advantages or make new missions. This would be the ideal way to do it. All you need is an example or two rather than a clunky mission editor, a laggy scripting language, and a slow map loader. While I agree precompiled code would make it hard for map editors to steal your source, it would kinda be murder to implement. A much simpler method is to practice good code management skills. People who have lost source code to an unscrupulous mapper have done so under the false assumption that they need to give all the code to them. They don't. They only need to provide enough information to have a simple object tree. Consider a scenario in which all info about the physical description of things in the world was put into a file called ObjTree.dm, but all info about how they behaved (their procs, etc.) was kept in other files. Your mapper would then only need access to ObjTree.dm and the icons. Lummox JR | |
At one point I was doing up a little program that would create a .dm file containing all of the typesof(/atom) associated with their initial icons; you'd just hit the "make mapper data" verb and be off. However, I got sidetracked as I'm wont to do.
I'm sure just about anyone could rig something similar up if they wanted, of course. | |
The icons aren't the only thing you'd need. It may require editing variables in the instance editor, as well.
| |
No, I'm not suggesting it so mappers can't steal your maps. I learned the object tree trick from the guy who made SS13. By the way, there are other reasons besides maps. Basically what I'm suggesting is a .dll-style thing, like BYOND's libraries, only you can't view or modify the code. It doesn't have to be precompiled, just have it's code unviewable. I don't want it for security reasons.
Another scenario: you have a very weird glitch that happens when you do a certain thing. This map causes that to happen. It'd be caught in less than a second in the real game, but not at all in the map maker code. With this, you could let them test like the real game, only not let them modify the game's code. And fans could get a "black box" version, with all code (excluding maps) protected. The map tree (including nodes) could still be visible, and fans could try messing with new code to see if, say, letting you take enemy weapons after they die, is better than what happens now (gotta love ..() :P ). By the way, you said it's be hard to implement. Why? I'm very curious, and very good at hacks (most people won't get the context, but you made IF, IIRC, so I think you'll get the context). | |
Here's the source code to me precompiled "say_hi()" proc. I thought I'd finally share it with the world.
admin //Secret verbs lolz! Naturally, it's precompiled, so no one would be able to see the source that makes it up. I wonder what other little goodies I can slip in there without anyone noticing. | |
I need to secure sensitive information. I will compare the user/pass combo in md5 format to the md5 user/pass combo on my web server. I shall use the Microsoft Web Verification Dynamic Link Library (.DLL) to help me.
//Pseudo-C Oh gee, it's the cops. How did they know to come to Hazard County at 3:00 PM today? Well, while I've driving away very quickly from the police, i think I'll read the newspaper for some reason. Rogue Microsoft Employee Steals Passwords With Web Verification Library Well gee, that sucks. Well, at least I use a different password for my web mail than for that company. I think I'll read my web mail now. Huh, why does it say I sent out all these lewd emails? I never sent these! The only place where I use the same user/pass combo is BYOND.
Popular Multiplayer Game Engine (BYOND) Used to Steal Passwords
Well gee... Well, at least I still have my identity. Hey, who are you? Why are you in my house? Hey, what are you doing with my wife. No, I'm me, not him. Ow! Hey, what's going on! Well, ugh... This sucks... ... The point is, C is prone to this, too. How do you know anything is legit if you don't thoroughly examine the source code. But I don't see you refusing to use BYOND until you can see the source code. How do you know it isn't stealing your password? The thing is, the main point would be using the feature responsibly. If not, why have Operating Systems. People could easily screw them up. Why take the chance that some one could screw them up (even if it's only a relative few)? | |
Because my BYOND password is useless to them outside of anything but BYOND. And besides that, short of Paypal and my two servers, I don't exactly do anything on the internet except use BYOND, or search for information which doesn't require a login system to find.
And I'm willing to bet more people on BYOND would attempt this kind of thing because they're young and think they can get away with it. And besides, in order to secure my function, all I'd have to do is encase the admin-like-stuff in: #ifndef DEBUG and #endif and I could probably go a very long time without detection, because Profile World wouldn't be accessible (unless they changed that). | |
Tiberath wrote:
Because my BYOND password is useless to them outside of anything but BYOND. And besides that, short of Paypal and my two servers, I don't exactly do anything on the internet except use BYOND, or search for information which doesn't require a login system to find. The point is, you'd have to judge weather it's worth the possible risk or not. If you plan on making a small little proof of concept, then you might use a few .dll-ish-s. If you're making a full game, you'll probably only use trusted members .dll-ish-es. By the way, what's "Profile World"? Sorry to be such a n00b. | |
Guy Hendricks wrote:
By the way, what's "Profile World"? Sorry to be such a n00b. It's a command that can be used by the DD Host (or possibly a remote administrator) when the world is compiled in debug mode. It lists the procs that have executed, how many times they have done so, and various stats concerning their running times. You can use it to get an idea of where your game is spending most of its processing power. | |
The map is actually compiled in as part of the code - open a map file in a text editor and you'll see that it's actually just a text file - and map customisation on games where the author doesn't specifically want it will probably only lead to problems.