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!
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.)
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.
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.
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.