ID:138418
 
To follow up on a thread elsewhere...:

On 8/28/00 10:15 am Al wrote:
On 8/28/00 9:33 am Zilal wrote:
[snip]
But my advantage is that the designers of my coding system are ready and willing to help me with my needs.
[snip]
I think this needs to be emphasised, the only reason I've spent so much of the last few months playing with Byond is the ever present and excellent support.


I'd like to be a bit contrary about this. The only reason I have spent so much time the last year playing with BYOND is because it is a great product.

The support is wonderful (and the attention paid to requests has certainly resulted in improvements to the system), but if it were great support for a typically hard to understand programming language and system, I'd be out of here in a second.

So why I spend most of my free moments on BYOND is:

Clean easy to understand object-oriented model. No small feat, since most OO models are really quite complex to understand, and often rather muddy in their structure.

Beautiful coding language. I respond on an emotional level to beautiful code, and so I respond to DM on several levels. One is the notational clarity -- operators are only overridden in limited circumstances for items where it brings great benefit. In English, things like +, -, += and the like only have special behavior in limited cases, where it really really helps the clarity of the code (it's the only system I've seen use them with arrays, which was a brilliant idea). Next is the indention based code, which does away with brackets -- I can't believe the difference this makes!

Another coding item is the ability to add code to any object. This is so easy and pervasive in BYOND that we don't think about it -- but many systems don't allow you to do that. You would have to subclass the object to add behavior which (as I once posted a creed about) is a bad idea and would have us doing acrobatics to accomplish some of what we now do in a couple of lines of code.

The transparency of the "hard stuff". The last thing on Earth I want to think about is networking and sockets and sound and graphics implementation, and BYOND simply does all this for me, while avoiding the architectural approaches that would complicate things. For example, most systems have a distinction in the code of whether something is run on the server or the client, and you are constantly having to decide which bit of code is where, then you are having to debug all the problems that come up with this.... Some sophisticated programmers no doubt would never use BYOND because it doesn't let them get their hands on that stuff. But I'm very happy for the trade-off toward simplicity -- happy enough that I'm willing to design my games around the limitation rather than switch to another system.

And there are no doubt other things I would think up with time.

The areas of question or concern are:

How well BYOND will handle lag when there are a lot of players in a graphic-based game.

How well it will handle integration of multi-media. Often an effect such as an attack involves multiple animations and sounds going off in coordination (mob's attack animation, missile animation, missile sound; target mob's damage animation, target mob's damage sound, etc). Right now this tends to result in jerkiness and lag and cut off sounds -- even when I'm playing the game locally. However, my hope is that these are items that simply haven't gotten much exposure and stress testing yet, and that as our games come online, these things will be smoothed out. My fear is whether there might be any architectural problems with this stuff.

Lastly, there's the question of interface flexibility, in particular of the map window. I'm very hopeful that we'll be able to move toward the ability to make the map window physically larger (setting world.view to its max is probably a big enough logical space, but it's represented in too small an area). This isn't just glitz -- I am not sure I can create my ultimate goal, a sophisticated Civilization/Alpha Centauri game, without a physically larger map. It just won't be the right experience.


So that is the sum total of why I'm using BYOND and what things I have concerns about. The fact that Tom and Dan are great guys to go through this with is a nice side benefit, but to me it's what they've created that matters!
Wow, thanks! I think I'll tuck this one away for the records :)

Incidentally, the indention-based-syntax was one of those serendipidous discoveries made by Dan. On those occassions when our code has had to overlap we always end up in this "reformatting" battle:

Danist notation:
void main() {
...
}

Tomist notation:
void main()
{
...
}
(Note the superior symmetry)

One day we were talking on the phone (probably bantering about which style was better), and he proposed this ridiculous idea of doing away with braces altogether. "Preposterous!", I said. Then I thought about it and couldn't come up with a good argument against it. But would the masses be ready to accept the future?

(Incidentally, it was with great disappointment that I heard that another language-- Python? -- also does this. I knew such an innovation was too great to be unique.)

How well BYOND will handle lag when there are a lot of players in a graphic-based game.

While there are bound to be bugs, I have great confidence in the network model. Since for the most part the resources can be downloaded beforehand if needed ("Import resources"), it's mainly small data that is transmitted. This new icon stuff worries me a little bit because it opens itself up to abuse, but only time will tell.

How well it will handle integration of multi-media. Often an effect such as an attack involves multiple animations and sounds going off in coordination (mob's attack animation, missile animation, missile sound; target mob's damage animation, target mob's damage sound, etc). Right now this tends to result in jerkiness and lag and cut off sounds -- even when I'm playing the game locally. However, my hope is that these are items that simply haven't gotten much exposure and stress testing yet, and that as our games come online, these things will be smoothed out.

Agreed. I think this is mainly a matter of fine-tuning. We have the capability to determine timing events so it certainly should be workable. I'm not saying that everything will necessarily be easy to perfect, but I wouldn't worry too much.


Lastly, there's the question of interface flexibility, in particular of the map window. I'm very hopeful that we'll be able to move toward the ability to make the map window physically larger (setting world.view to its max is probably a big enough logical space, but it's represented in too small an area). This isn't just glitz -- I am not sure I can create my ultimate goal, a sophisticated Civilization/Alpha Centauri game, without a physically larger map. It just won't be the right experience.

Yes. The interface component is probably the biggest worry, because we have to be careful in trading off flexibility for ease-of-use. There are fundamental limitations with the chosen medium of a tile-based system, but if the designer is willing to work within that we can probably do good by them. Eventually I would like to just release the client header file and lengthy document explaining how users can write their own gui executables. Then die-hards who really want to give their game a specific interface could do so with a fair amount of work. This is a long term goal.
In response to Tom H.
On 8/28/00 2:23 pm Tom H. wrote:
The interface component is probably the biggest worry, because we have to be careful in trading off flexibility for ease-of-use. There are fundamental limitations with the chosen medium of a tile-based system, but if the designer is willing to work within that we can probably do good by them.

Well hopefully I'll be one of those that fit into that...if not I may just have to let the restrictions guide me to a new form of the game, which may not be a bad thing.

Danist notation:
void main() {
...
}

Tomist notation:
void main()
{
...
}
(Note the superior symmetry)


I was a Tomist for most of my programming life, but I'm sorry to say I finally converted to being a Danist.

The symmetry is actually greater with Dan's approach, because it is easier to scan the code and see the beginning and end of a code block.

Um, now maybe we should talk about something non-controversial like religion?
In response to Deadron
[edited: added "the"]
[edited: added a clarification]

Danist notation:
void main() {
...
}
Tomist notation:
void main()
{
...
}

I was a Tomist for most of my programming life, but I'm sorry to say I finally converted to being a Danist.
The symmetry is actually greater with Dan's approach, because it is easier to scan the code and see the beginning and end of a code block.

For Java I use a modified Tomist approach. I indent the braces to the level of the code they surround, like so:

void myFunction()
{
bla;
if(bla)
{
bla;
}
bla;
}

It's the closest I can come to BYOND code. It also nicely highlights the sheer irrelevance of the braces.

By the way, I've done a little reading about Python and I've noticed two things about it:

1) Its overall "attitude" is very similar to DM, and some of the concepts overlap too (indentation; excellent list support). It tries to make life as simple as possible for the programmer.
2) It's very highly regarded by People Who Know. Here's a neat essay from a knowledgeable, if controversial, programmer:

Python testimonial

And an excerpt of the article (hope this is "fair use"):

.... Thirty-two lines, counting comments. Just from knowing what I've said about the class structure, the calling code is even readable. But the size of this code isn't the real shocker. Brace yourself: this code only took me about ninety minutes to write--and it worked correctly the first time I ran it.

To say I was astonished would have been positively wallowing in understatement.... this is an amazing testament to Python's clarity and elegance of design.


(Which pretty well describes programming in DM, on a good day at least. :)


Um, now maybe we should talk about something non-controversial like religion?

I would, except it would be sacrilegious to put it in the "Babble" forum. :)

(By which I mean, not that "Babble" is my opinion of religion, but that it's the only forum offered here where that kind of discussion would be appropriate... hmm, on second thought, maybe we could slip it into World Design! :)
In response to Guy T.
I would, except it would be sacrilegious to put it in the "Babble" forum. :)

(By which I mean, not that "Babble" is my opinion of religion, but that it's the only forum offered here where that kind of discussion would be appropriate... hmm, on second thought, maybe we could slip it into World Design! :)

Ironic, since the term 'babble' actually comes from the Biblical account of the building of the Tower of Babel and YHWH's (the name the Israelites gave their God) subsequent splintering of their languages..... Much like the splintering of computer languages, maybe? heh... okay this is getting way off topic.

-James (YMS in Hebrew?)
In response to Guy T.
On 8/28/00 3:04 pm Guy T. wrote:

Python testimonial

Interesting article. This sounds like my kind of language. I made a hapless attempt to learn Perl about two years ago, but couldn't make heads or tails of it for the very reasons mentioned by this knowledgeable coder.

Did you notice this appropriate quote?

[regarding relevant indentation]
It's hard to blame anyone, on seeing this Python feature, for initially reacting as though they had unexpectedly stepped in a steaming pile of dinosaur dung.

(By which I mean, not that "Babble" is my opinion of religion, but that it's the only forum offered here where that kind of discussion would be appropriate... hmm, on second thought, maybe we could slip it into World Design! :)

Hah! World design, indeed.
In response to Guy T.
On 8/28/00 3:04 pm Guy T. wrote:
By the way, I've done a little reading about Python and I've noticed two things about it:

1) Its overall "attitude" is very similar to DM, and some of the concepts overlap too (indentation; excellent list support). It tries to make life as simple as possible for the programmer.
2) It's very highly regarded by People Who Know. Here's a neat essay from a knowledgeable, if controversial, programmer:

Python testimonial

Ya know, for work purposes I bought all the Perl books and I keep meaning to learn Perl...but I really hate hate hate the impenetrable syntax. And even if with self-discipline you can make most of it readable, the text parsing strings are likely to always be Greek to me...

I think I'll take a serious look at Python, probably as part of putting together my Fully Automated Dantom Website when the new server is available!


Um, now maybe we should talk about something non-controversial like religion?

I would, except it would be sacrilegious to put it in the "Babble" forum. :)

Well "babble" pretty much sums up my feelings about the whole matter.
In response to Tom H.
On 8/28/00 2:23 pm Tom H. wrote:
Danist notation:
void main() {
...
}

Tomist notation:
void main()
{
...
}
(Note the superior symmetry)

I was a Danist, but only because (I think) the tutorial did that, and I still wasn't exactly sure what I was doing, so I did whatever the tutorial did. Then Deadron convinced me to go without brackets. He did this by the sheer force of the impression one gets from him that he is an efficient coder. I don't know if he is or not. But from his posts, you would think he is. In essence, I didn't get rid of my brackets because they bothered me but because they bothered Deadron. With brackets it was easier to tell just how far indented-in that else statement should go, but I also needed to type 3% more characters per proc. Talk about inefficient!

As for BYOND, I love the idea of customizable clients... to me, BYOND is great because you can do some very complex custom things with it, but in no way do you have to to make a great game. Complex things in a program should be available but more bonus than necessity.

(Now I'm wondering if Cerulea lives up to this. I hope so. I tried to make it so you could either just run up to something and hack at it or use some strategy.)

Z
In response to Zilal
On 8/29/00 9:34 pm Zilal wrote:
Then Deadron convinced me to go without brackets. He did this by the sheer force of the impression one gets from him that he is an efficient coder. I don't know if he is or not. But from his posts, you would think he is.


I really appreciate the sentiment (probably more than you can imagine), but I have to bet Dan and Tom are laughing themselves hoarse reading this, since at least one of them has seen my code.

I'm about the most inefficient coder you'll ever meet. I do strive for clarity though, and I hope I do achieve that (while getting a bit more efficient as I learn).


In essence, I didn't get rid of my brackets because they bothered me but because they bothered Deadron.

If only more people thought like this.
In response to Deadron
On 8/29/00 10:54 pm Deadron wrote:

I really appreciate the sentiment (probably more than you can imagine), but I have to bet Dan and Tom are laughing themselves hoarse reading this, since at least one of them has seen my code.

Your code has always looked good to me. At least you have a syntactical notation that you stick to, which I feel to be one of the most important parts of the job. No kidding-- clarity is in this day of blazingly fast cpus for more important than efficiency.

I personally change notations daily, and spend half my time renaming variables and what-not. Heck, I'm not even a Tomist as advertised: in my C code I'm actually a pseudo-Tomist, going with Tomist style for functions and Danist style for instructions (like if()). And in DM, I am (er was) a Danist! Argh. Luckily the braceless notation saved the day.

In essence, I didn't get rid of my brackets because they bothered me but because they bothered Deadron.

If only more people thought like this.

Hah!
In response to Tom H.
On 8/29/00 11:20 pm Tom H. wrote:
I'm actually a pseudo-Tomist

A heretic! Get him!

(Actually I'm thinking this sounds like that Bokananist religion described in Vonnegut's Cat's Cradle...)