ID:138369
 
I've only been working with Byond for a little while here, however; having done professional game development, I find a few things a tad lacking. These are just my opinions, of course. A small list of things i'd consider integrating/improving;

Surfaces/generic blitting techniques- The whole 'tile based map' ordeal considerably constrains against development. Hell, couldn't even make a decent clone of Galaga, due to the movement algorithems tied to the tile based map. By using the generic concept of surfaces and sprite blitting, a whole new level of flexibility could be obtained through game's engine.

Server trailing client recognition option- It makes some serious impositions about the kind've game a person can create when all client operations are apparently buffered for netlag, thus creating a slight lagtime between keypress and proceedure execution. This may be fine for some games, but some require client-intensive movement, whereas the server doesn't need all that much data from the client. Perhaps the server was only serving as a highscore database in the first place, and only receives data from the client upon completion of a 'game round'. It should be a development option to specify if activites are client intensive (instant client responses to keypresses/events) or server intensive (client waits for packet confirmation from the server before continuing activity, as it is now).

Windowing API- I've been doing a little something like this, working within the Byond system itself, creating a windowing library to extend functionality of all games. However, one is still bound to a certain format for the Byond executable's window. One should have total control of how the window interface looks/operates, via interface with a windowing API, with properties/methods to create/manipulate the actual Windows used, operating system side, with the game. Everything from text boxes/radio boxes, to custom controls. (A good candidate to ensure x-platform capability for this would be to integrate the API directly into the Byond application, by switching whatever Windowing lib you're using now, with wxWindows. *www.wxwindows.org* An x-platform GUI/Window lib, very useful.) This would be a compliment to the afformentioned surfaces/blitting suggestion mentioned earlier.

Alpha blitting/transparencies, layers- Self explanitory.

Just my $0.02.

Altrich/Coen
EML: [email protected]
ICQ: 2030467
IRC: irc.othernet.org, #angband
I don't presume to speak for Dantom (and if I did, they'd find some clever way to put me in my place), so take this with a grain of salt. :)

Your points are very good (though I admit I don't have the technical knowledge to fully understand them all). I imagine at least some of them are on the list of future improvements. However, there are a few things worth considering:

1) This whole system is the work of two guys who eventually have to start publicizing it and, if there's any justice, start making money off it. Every potential new feature has to be weighed against the amount of time already spent building the system, fixing bugs and adding features requested in the past.

2) The system isn't designed to be a completely "all-purpose" game construction kit. You can make action games to a certain extent, but the roots of the system are in old text-based dungeon crawls like Rogue. Yes, a decent Galaga might be pretty painful to make; but a decent chat room, or RPG, or text adventure, or board game, or really weird thing (we already have a couple of those :) is a breeze. At least compared to doing the same thing in C.

3) The target audience is quite broad. Ideally, the system should be learnable by anyone who's willing to sit down and take the time to work with it. That dictates a certain amount of restraint on Dantom's part. You don't want to add too many features that will be incomprehensible to newbies and casual users.

4) It works! That may sound a little facetious, but it's a point worth mentioning. I've participated in multiplayer BYOND games and had a great time. There are some BYOND-like works-in-progress out on the Internet, but very few are usable and I haven't seen any that matches BYOND for versatility, ease of use, or overall good design.

Anyway, I hope I don't sound too confrontational. I think that some of the things you suggest just aren't within the territory BYOND has staked out, so to speak. It's great for what it's meant to do, and as time goes by, hopefully it will be capable of doing more and more...

In response to Guy T.
On 10/2/00 11:06 pm Guy T. wrote something wonderful!

I'll just respond to this post, because it pretty much answers the questions perfectly. I'll try to give a little input from the Dantom point of view too.

1) This whole system is the work of two guys who eventually have to start publicizing it and, if there's any justice, start making money off it. Every potential new feature has to be weighed against the amount of time already spent building the system, fixing bugs and adding features requested in the past.

Amen to that. I consider myself to be a fairly compentent programmer (and Dan an excellent one), but we only have so much time between the two of us. Almost all of the suggestions that come through here are valid ones, and not out of the question, but we have to draw the line at some point. If we could redesign the system from scratch, we would likely change certain fundamental aspects-- the restricted tile-system, for instance-- but going back on those now would introduce massive delays and severly compromise the stability of the system. Even adding supposedly simple features (such as the recent support for larger maps) take on the order of days to implement, mainly because the project has become so massive. But we aim to please, so we will continue to add items to "The List" and therefore at least keep the glimmer of hope that we will be able to someday satisfy all.

2) The system isn't designed to be a completely "all-purpose" game construction kit. You can make action games to a certain extent, but the roots of the system are in old text-based dungeon crawls like Rogue. Yes, a decent Galaga might be pretty painful to make; but a decent chat room, or RPG, or text adventure, or board game, or really weird thing (we already have a couple of those :) is a breeze. At least compared to doing the same thing in C.

Again, Guy is right on the money here. I've tried to stress that the one type of thing you really don't want to start with BYOND is an arcade game-- namely anything that depends on the using an accurate location of an object to gauge the action. Since BYOND is really symbol-based, rather than pixel-based, this kind of thing performs very poorly. Not only that, but the intentionally slow frame-rate is ill-suited for standard shoot-em-ups. With the 252 release, you can get around this restriction to some degree by lowering the tick_lag (which will actually work due to a new timing system), but the response still isn't very good.

There are a few simple things we can do to improve the graphics, and once we settle down a bit we can investigate them. I'm not talking about drastic changes, but rather simple things like smoothing out the movement through better (user-controlled) timing, reducing redraw flicker through an alternate graphics API, and so on.

One related point brought up in the original post was the fact that things tend to be sluggish due to the lag between client and server, which may be unnecessary for games that only want to communicate with the server occassionally (ie- to report high scores). The easy way around this is to simply run the program locally, as a client-server, and then communicate with the "central server" (to report high scroes, etc) through world.Export(). This is how the BYONDHome works, and how I would envision a Napster-clone from also working.

3) The target audience is quite broad. Ideally, the system should be learnable by anyone who's willing to sit down and take the time to work with it. That dictates a certain amount of restraint on Dantom's part. You don't want to add too many features that will be incomprehensible to newbies and casual users.

Yes! While we could add features to layout dialogs, add buttons, handle sliders, and so on, it would quickly defeat one of the main points of this project: to allow users to make a game quickly and easily. Years of gui struggles have convinced me that this is one of the most irritating aspects of all programming, and I consider it a great benefit that BYOND is somewhat tyrannical in restricting your choices in that regards. This is not to say we can't be more generous; for instance, allowing users to display nice looking "stat bars" would be a useful feature (and one already on The List).

At some point we hope to separate the gui from the backend enough to allow serious programmers to use a BYOND library to manage the network, while supplying their own front-end to display the result. It's easier said than done though, both for us and for the ambitious user.

4) It works! That may sound a little facetious, but it's a point worth mentioning. I've participated in multiplayer BYOND games and had a great time. There are some BYOND-like works-in-progress out on the Internet, but very few are usable and I haven't seen any that matches BYOND for versatility, ease of use, or overall good design.

Probably the best point of all. The few GoBs (games of the week) I've attended have been absolutely thrilling, even though they didn't involve 3D games produced by teams of programmers and artists. Playing the games with the designers is even better; you get to witness their delight as you fall for a secretly planned trap (or expose a most unplanned bug)! After the last GoBfest I was truly driven to make my own game to test out in multiplayer .. but alas these damn feature requests kept me at bay. This month, I swear!
In response to Tom H.

Amen to that. I consider myself to be a fairly compentent programmer (and Dan an excellent one), but we only have so much time between the two of us. Almost all of the suggestions that come through here are valid ones, and not out of the question, but we have to draw the line at some point. If we could redesign the system from scratch, we would likely change certain fundamental aspects-- the restricted tile-system, for instance-- but going back on those now would introduce massive delays and severly compromise the stability of the system. Even adding supposedly simple features (such as the recent support for larger maps) take on the order of days to implement, mainly because the project has become so massive. But we aim to please, so we will continue to add items to "The List" and therefore at least keep the glimmer of hope that we will be able to someday satisfy all.

Well, here's a thought. Open the server/client to a point where third-party 'modules' can alter the display and perhaps write their own interface libraries. This could be as simple as rooting out the hard code behind the 'tile based system', simplify the process to be run through one dynamic module which has a generic interface, so someone else could write a library to interface with these hooks. I realize this sounds like a lot of work, but I do have a few thoughts on the topic. (P.S. - If Tom does read this, i'd enjoy explaining the concepts in person. This is the very same Coen who was the first to learn the DUNG language, once upon a time, presuming you remember)


3) The target audience is quite broad. Ideally, the system should be learnable by anyone who's willing to sit down and take the time to work with it. That dictates a certain amount of restraint on Dantom's part. You don't want to add too many features that will be incomprehensible to newbies and casual users.

Yes! While we could add features to layout dialogs, add buttons, handle sliders, and so on, it would quickly defeat one of the main points of this project: to allow users to make a game quickly and easily. Years of gui struggles have convinced me that this is one of the most irritating aspects of all programming, and I consider it a great benefit that BYOND is somewhat tyrannical in restricting your choices in that regards. This is not to say we can't be more generous; for instance, allowing users to display nice looking "stat bars" would be a useful feature (and one already on The List).

At some point we hope to separate the gui from the backend enough to allow serious programmers to use a BYOND library to manage the network, while supplying their own front-end to display the result. It's easier said than done though, both for us and for the ambitious user.

First, see my afformentioned comments. Second; When dealing with languages such and C and C++, there is always a stdlib, which provides a great deal of functionality over the system. Any novice can learn ANSI C, but still lack the technical knowledge to put it to practical use. (Programming theory, game loop, signal handling, etc) BYOND could be opened up to the point where third-party written libraries written in Dung's own language could open up the flexibility to appeal more to the experienced programmer. This doesn't mean sacrificing the ease of the core language, merely allowing the more experienced to take advantage of alternative features.



4) It works! That may sound a little facetious, but it's a point worth mentioning. I've participated in multiplayer BYOND games and had a great time. There are some BYOND-like works-in-progress out on the Internet, but very few are usable and I haven't seen any that matches BYOND for versatility, ease of use, or overall good design.

Probably the best point of all. The few GoBs (games of the week) I've attended have been absolutely thrilling, even though they didn't involve 3D games produced by teams of programmers and artists. Playing the games with the designers is even better; you get to witness their delight as you fall for a secretly planned trap (or expose a most unplanned bug)! After the last GoBfest I was truly driven to make my own game to test out in multiplayer .. but alas these damn feature requests kept me at bay. This month, I swear!

*smiles* Let's talk. I've been wanting to do a number of games for quite some time. Being a fellow programmer, I know you understand what a pain it can be when you've to do it all yourself.

Adios,
Coen
In response to Coen
Well, here's a thought. Open the server/client to a point where third-party 'modules' can alter the display and perhaps write their own interface libraries. This could be as simple as rooting out the hard code behind the 'tile based system', simplify the process to be run through one dynamic module which has a generic interface, so someone else could write a library to interface with these hooks. I realize this sounds like a lot of work, but I do have a few thoughts on the topic. (P.S. - If Tom does read this, i'd enjoy explaining the concepts in person. This is the very same Coen who was the first to learn the DUNG language, once upon a time, presuming you remember)

Um, if they designed it, don't you think they'd remember?

First, see my afformentioned comments. Second; When dealing with languages such and C and C++, there is always a stdlib, which provides a great deal of functionality over the system. Any novice can learn ANSI C, but still lack the technical knowledge to put it to practical use. (Programming theory, game loop, signal handling, etc) BYOND could be opened up to the point where third-party written libraries written in Dung's own language could open up the flexibility to appeal more to the experienced programmer. This doesn't mean sacrificing the ease of the core language, merely allowing the more experienced to take advantage of alternative features.

This is an invitation to disaster... see below. I arrived in the summer of '99, so I don't claim to have been using DUNG/BYOND longer than you have, but I've been using it long enough to know that this program is pretty damn good as it is. Have you tried out all of the new features, like the browse window, smooth movement, the instance editor on the mapper, range(), block(), orange(), pick(), icon palette changing, usr << "text", and billions of other features that make this much better than it was a year and a half ago, or even a year ago?


After the last GoBfest I was truly driven to make my
own game to test out in multiplayer .. but alas these damn feature requests kept me at bay. This month, I swear!

*smiles* Let's talk. I've been wanting to do a number of games for quite some time. Being a fellow programmer, I know you understand what a pain it can be when you've to do it all yourself.

Myself being a fellow programmer, I also know how people value their own work. Dantom intends to make money off this software; not by charging for downloading or obtaining full versions, but instead by allowing users to charge for their worlds and deducting fees from when people pay for or exchange back some BYOND currency, BYONDimes. Besides, there are two, and both in my opinion are quite adept, even if Tom himself doesn't think so.

You can't release open source to something you intend to insert money into, because then people will create versions to avoid those schemes, and then people will download those creations to avoid those schemes, and the entire system fails, all because someone wanted to have more features.

Sorry. I might sound a bit more offensive than you and me like. But this project has been alive for several years, when they were consistently adding new features, and now, finally, they're trying to stop influx of new features in favor of getting a perfectly running, perfectly efficient system. Perfect's not possible, but close to it is.

Again, sorry if I sound offensive. I can't speak for Dantom, but I think Tom or Dan would mirror my thoughts.