Multiple frames for code

Apr 12 2008, 3:31 pm
Chessmaster_19	Well, there's just a lot of back and forth arguing here: "It'd be useful" "No it wouldn't" "I have a different method" "It'd be useful" "No it wouldn't" ect. I think the point here is that it'd be useful to some people, even if it's not everyone, and I think it'd be useful to a significant number of players to consider adding it.

Apr 13 2008, 12:15 am

In response to Chessmaster_19

Kaioken

You're quite right. But that's how arguments are, what do you think we should do instead? :P

Chessmaster_19 wrote:

I think the point here is that it'd be useful to some people, even if it's not everyone, and I think it'd be useful to a significant number of players to consider adding it.

It wouldn't make any difference for players. :P

Anyway, as has been said this would probably require a notable amount of work to rewrite things in the Dream Maker code and would take time, which I rather be spent on BYOND itself anyway. This kind of stuff is more of an IDE thing yes, as has been said. We have a command line compiler now so we have no reason not to make our own IDEs if we want special features and as such.
Similarly, you don't even need to use Dream Maker to code. So for now if you really wanted these features you could use any common text editor that has the special features you want to edit .dm files, you only need Dream Maker (or dm.exe) to compile. You won't get syntax highlighting off the bat, but you'll get anything else.

Apr 13 2008, 6:42 pm In response to Flame Sage
Jamesburrow	Yeah, I wish he would too, but as I'm not willing to make it, I don't want to really complain about the length of time it's taking him to do so :P

Apr 13 2008, 6:43 pm In response to Obs
Jamesburrow	You mean something along the lines of the hellishly horrible intellisense? Hell no.

Apr 13 2008, 6:46 pm In response to Kaioken
Jamesburrow	Of course it would make a difference to players if the developers design the games better, as the players then have a better game :P

Apr 14 2008, 1:50 am In response to Jamesburrow
Kaioken	Hehe. But in actuality this wouldn't make developers design games better, I'm all out for things that can do that kind of stuff (hence I said I prefer the staff worked on BYOND itself rather than Dream Maker convenience features). This would just make it possibly easier by being more convenient to some developers, but it wouldn't really change the outcome of their code. :P

Apr 14 2008, 8:53 am In response to Kaioken
Jamesburrow	It could. If it is easier to code, chance are the developer will have an easier time doing a better job ;) If it's a hassle to code, more developers will do just a half-arsed job and produce a cruddy game. Granted, many "developers" will anyways, but at least we can TRY to decrease the ratio a little :P

Apr 14 2008, 3:18 pm

In response to Kaioken

Chessmaster_19

Kaioken wrote:

You're quite right. But that's how arguments are, what do you think we should do instead? :P

Well, it's really not the argument itself that I'm trying to critique, it's the topic of the argument. Arguments are really the point of posting a suggestion on here, but if they're just pointless useless arguments, the topic will probably get locked. I was trying to say that there's no point in arguing about whether or not it would be useful. It would be useful to some. There are better things to argue about.

It wouldn't make any difference for players. :P

Right. Players was a mistype. I meant developers. If I wanted to keep defending a mistype, I could state that what developers aren't players, but there's no point, it was an error.

Anyway, as has been said this would probably require a notable amount of work to rewrite things in the Dream Maker code and would take time, which I rather be spent on BYOND itself anyway. This kind of stuff is more of an IDE thing yes, as has been said. We have a command line compiler now so we have no reason not to make our own IDEs if we want special features and as such.

Now, I have no knowledge of compiler coding. So, I'll just apologize right now for arguing out of ignorance, but I'm gonna do it anyways.
I personally have always assumed that the majority of a compiler consists of the actual compiling, converting the code into something the computer can read, error checking, ect. It seems to me that it wouldn't take a complete overhaul of the DM code to implement this idea in its simpliest form.

As for whether or not it would be worthwhile for BYOND itself, which is of course the most important question, I believe it could be. As Jamesburrow said, help for developers means better games. Also, I believe helping out the developers helps BYOND in general, for example:
1) New Developers. I've found that some BYOND coders can be a little... elitist at times. (No one get offended, please. I'm not naming names) The jump from player to coder is a huge gap, and I think anything that can be done to help encourage players to make the leap would be good. The more user-friendly the DM compiler is, the easier time players will have becoming good developers.

2) Developers will be able to find "continuity error" in their code easier. While basic coding can be learned relatively fast, it takes years of experience to be able to think through a thing of code and think through possible ways that that code can be defeated by other chucks of code running symultaneously. (Even I'm not good at it) If developers can compare two sections of code side by side (or one on top of the other, as it may be), loopholes would be easier to spot when coding, or to find later when you get an error. If you want to talk about improving how well BYOND games run, helping to eliminate many runtime errors would be a great start.

3) Developers would be able to write more complicated code a little easier. More games might use things like html and browser based interface (requiring Topic() procs) and less on the same old popup boxes.

Anyways, these are just ideas that came to me right now. The point is, benifits to the developers would be benifits to BYOND, so saying that you would rather have the time spent on "BYOND itself" is less of an issue.

Apr 14 2008, 4:07 pm
Obs	Those procs are independent.

Apr 15 2008, 9:36 am

KodeNerd

Inuyashaisbest wrote:

Obs wrote:

Those procs are independent.

independent = relies on self
dependent = relies on outside

So a player can call it whenever he wants? hey Free levels just type LevelUp! Wouldn't really be a fun game now would it?

He has some sort of point. You should try to at least make it so that the underlying functions can be used without the dependent functions.

George Gough

Apr 15 2008, 9:59 am

Kaioken

You're missing the point. Being called from isn't being depended on.
The point is that those 2 procs don't rely upon eachother to run; they don't need each other to run (although, you could say that EXPCheck() depends on LevelUp() because without the LevelUp() proc it wouldn't compile). You can run one without calling the other. Otherwise if LevelUp() could only ever run successfully right after EXPCheck(), you would just put it's code in the end of EXPCheck() and there wouldn't be a point to making them separate.

For example - LevelUp() is not dependent on EXPCheck(), because it can run without the latter ever being run or even without it existing. So, separating it from EXPCheck() is useful, say, in the case of a reward for the quest, you could give the player a reward of a free LevelUp() without needing any exp by calling that proc directly, "alone", independently. If you had the level-up portion incorporated in the EXPCheck() you'd need to do ugly, bad hacks with changing exp to an appropriate number so the proc let's the mob level up, then undo your changes to exp.