Well most of the time when you make your precious game you are more defensive then a bear is to her cub. Well have you ever thought, "I direly need this extra programmer...but he might rip...what do I do...?". Well I'm pretty sure that alot of people have thought of this but why not just put all of your variables in a DM file so they can do the rest without bugging you? Then all they have to rip is variables.A complete idiot can do that. Tada~?
ID:151855
 Dec 24 2008, 2:40 am
|
|
If I need help, I either use someone I completely and utterly trust, or when I do get help from someone I am unsure of, I ask them to make it a stand alone thing, so that I can plug it into my source.
| |
Greetings Choka.
I never work with another programmer, it's how I role. If I ever need help, I jump right into Chatters and ask, though don't use Chatters as a reasource for programming problems, it's a comminuty.... Just talk have fun. Anyhow, if you ever even decide to have another side-programmer, I would advise as Schnitzo said, to use modular programming and only pass on the bits needed, e.g(Interface, Documentation). Overall, I wouldn't ever even attempt to gather up several other programmers to help me on my projects, How would I ever learn if I do the parts I can and my side-programmers do what they can?? Huh huh?? Thanks Much. Haywire | |
Haywire wrote:
I never work with another programmer, it's how I role. If I ever need help, I jump right into Chatters and ask Overall, I wouldn't ever even attempt to gather up several other programmers to help me on my projects, How would I ever learn if I do the parts I can and my side-programmers do what they can?? I dare say that this depends on the size of the project. While I agree that the average BYOND programmer is not used to serious (shared) development, most every bigger project makes use of multiple persons working at a given time, to speed up the process. It might be tricky when you have to wait 10 years before releasing a game/project solo, while 15 people could do it in less than a year. | |
Haywire wrote:
Greetings Choka. I'm currently trying to work on a solo project, and my last project was in a group. Well, doing it alone has its merits, I would argue that there are advantages and disadvantages of going both ways. And actually, I've learned quite a bit by working with other people. Sure, I didn't write the actual code for the bits that they wrote, but often, I would have done something one way, but they used a different (perhaps more effective) way that I wouldn't have thought of. Plus, if you want to learn about programming, it's unrealistic to say that "I'm just gonna always go solo". In the real world, if you go into programming, you're virtually always going to be group programming, and if you don't develop the ability to work on a project with others that could be just as bad as not knowing how to code something. (Now to the original topic) As for working with other people there are really two different approaches: 1) Equal partnership: In which everyone working on the project is roughly equal. It's not simply one persons project with a "side-programmer". Usually, I'd imagine you'd have to start a project like this, it'd be hard to simply add an equal partner halfway though. 2) Unequal partnership: (Ok, so I couldn't think of a better name) One person is the main programmer, and the others simply help do other aspects of it, and put it together. Now, if you don't want to do a project solo, I'd recommend the first one. When you have an equal partnership, and you all started the project from scratch, it's highly unlikely that anyone on the project is going to want to simply rip the project. It's adding people halfway through a project where trust becomes a real issue. One approach is what everyone else has said, the modular programming, only passing certain parts. Another approach might be to give whoever is working with you an older version of the game. (Assuming you hold on to older versions) Yes, they might still rip the older version, but they'd do less damage, and, unless you've made significant overhauls to the core functions of the project, an older version should allow them to make whatever they need, with only minimal editing when the feature is implemented in the main project. Another approach might be to give almost all of the code, but take out the body of some of the core functions (and perhaps anything that you wish to keep top secret), that way, if they decide to try to rip, they'd have significant work to do to get the game running. There's also the option of doing it secretly. Instead of removing something entirely, just take out a few lines so that it doesn't run properly, or gives many bugs; basically anything to sabotage the game. Yes, this is less secure than only giving them an interface, but its much less work (and, if you aren't modular programming already, you don't have to rewrite your entire project) and there can be advantages to allowing other coders to see most of the code as well. | |
Chessmaster_19 wrote:
When you have an equal partnership, and you all started the project from scratch, it's highly unlikely that anyone on the project is going to want to simply rip the project. Even best friends can get into a fight and part, which is a case you want to avoid, as that is more frequent within on-line environments. Why take unnecessary risk? Chessmaster_19 wrote: Another approach might be to give whoever is working with you an older version of the game. I doubt that this would be a good idea. People stealing source code usually do not care for the quality of said code, so the damage is still going to be serious and the gain is next to naught. Using non up to date code is prone to causing trouble and, even worse, error. Chessmaster_19 wrote: Another approach might be to give almost all of the code, but take out the body of some of the core functions Which is exactly describing modular programming. You hand out what a programmer needs, the documented interface of a function. Chessmaster_19 wrote: just take out a few lines so that it doesn't run properly, or gives many bugs Yet again, what would you profit? There is next to no security in that, as fixing the code is as easy as posting it on the code problem forum nowadays. You'll sure find someone happy to jump on the subject and fix the code for you. But, worse, there is no gain in the attempt as the programmer can't test and rely on the function since it would error out. Chessmaster_19 wrote: but its much less work (and, if you aren't modular programming already, you don't have to rewrite your entire project) and there can be advantages to allowing other coders to see most of the code as well. Why is it less work? Just copy pasting the proc definition doesn't seem a tricky task to me. At least compared to erasing parts of the code. Not to mention that, should you have written inefficient, bad code, it might be a smart idea to rewrite it before releasing the game/project anyway. And what would be the advantage of other coders to browse your work (other than suggestions on performance issues)? | |
Bottom line: The only real security is working with someone you trust.
| |
Alathon wrote:
The only real security is working with someone you trust. I dare say that this is false security. Trust is often granted too fast/free, especially by younger people. There are countless incidents proving that thesis to be found on-line. I think that everyone who ever worked in the support segment of a bigger on-line game can confirm a vast amount of the trouble encountered (be it lost accounts, malicious software, lost possessions, etc. pp.) deriving from trust substituting security. While I'm an advocate of security by obscurity myself, I would only see it as additional measure and not as substitution, just like with trust. | |
The solution has been stated. Modular Programming. It's getting easy to do that once you get used to the abstract-ness at times.
George Gough | |
AN IDEA FOR THE BYOND STAFF.
To increase security of code, would it be possible to have external .dm files that interact with the .dmb file in a sense that they may be changed by a programmer and then include with the rest of the code as the programmer runs the code. In the package files section a user may be asked whether he would want to include external code. This will be saved in a folder called external code or whatever which will be packaged with the .dmb file. PROS -Security added and more people on forumn will start to work together and make groups ie Evolution Gaming. CONS -It may bring risk to the reinvention of the .dmb decompiler hence less security What do you think | |
No, the staff has already said this isn't possible or not worth it or something. I forget, but it was already suggested.
Also, this goes into BYOND features, not design philosophy. | |
It's not so much that they can't, but more that it is not practical for a whole slew of reasons, at the very least taking time away from more important development issues.
Plus there are a variety of freely available code-management/revision control tools designed for groups: GoogleCode, Bazaar, Subversion, Darcs (personal favorite), CVS, DCVS, and a slew of others. | |
What you could and should do though is modular programming.
By exposing only the interface (together with a detailed documentation!), you allow for complete interaction with your code, while you warranty for good object oriented design, security and stability.
Imagine you'd be writing a library.
These have to apply to these exact rules.