ID:259212
 
Im not trying to point out the obvious or be rude but do you feel the current 'engine' is anywhere near useable?
On 9/6/00 2:30 am Q Bert wrote:
Im not trying to point out the obvious or be rude but do you feel the current 'engine' is anywhere near useable?


Very much so, in my opinion.

But you should form one yourself. If you use the DM InfoCenter link on the left you can look at the tutorials, documentation, libraries and demos everyone has put together.

You can also download BYOND and access the hub to try out the games that people are working on.
Im not trying to point out the obvious or be rude but do you feel the current 'engine' is anywhere near useable?

If by usable you mean reliable, then yes -- my experience is that it's quite robust. "Show-stopper" bugs are rare, and less severe bugs are fairly rare too (at least compared to the complexity of the system).

If by usable you mean accommodating to the programmer, then yes -- I've never used a language that lets me code as quickly as DM. And the integrated development environment is incredibly user-friendly.

If by usable you mean suitable for the purpose of serving multiplayer games over a network, then yes -- I've played them!
It's very useable. (Usable?) The features and programming language are incredible. The fact that a new patch comes out every couple of weeks is probably a little frightening, but really, this software is in much better shape than a lot of products on store shelves that I can think of.

There are two ways to look at the frequent updates: either BYOND has more bugs than the average program, or all programs have about the same number but Dantom is the only company that bothers to quickly fix them. I'm leaning toward the latter hypothesis, myself.

Z
In response to Zilal
On 9/6/00 10:12 am Zilal wrote:

There are two ways to look at the frequent updates: either BYOND has more bugs than the average program, or all programs have about the same number but Dantom is the only company that bothers to quickly fix them. I'm leaning toward the latter hypothesis, myself.

I can't speak for other software companies so I won't comment on the reliability of their programs. For us, the frequent releases serve as a trade-off: you get to immediately see new bug-fixes and features (mainly requested by you), and we get to have immediate testing of the latest stuff. In my experience, this model works better than releasing huge improvements every year or so (ala DUNG 1 -> DUNG 2), since it gives constant feedback and generally prevents disastrous decisions or implementations. Things are starting to stable off a bit now, though, and when we get our host running and do some advertisment we hope not to release as frequently (aside from necessary bug-patches, which will always come about as needed).

Note that, despite all of the updates, most of the stuff we release isn't mandatory. For instance, the current 250 release is backwards-compatible to 236, which was some-time ago. If you use newer features (like the icon tinting), these worlds of course won't run in old servers, but the program will merely spit out a warning and tell the user to get the latest version. So if you treat the releases as more of "expansion packs", then they can be fun, as well as proof that we are, and will continue, working on this project.
In response to Tom H.
Note that, despite all of the updates, most of the stuff we release isn't mandatory. For instance, the current 250 release is backwards-compatible to 236, which was some-time ago. If you use newer features (like the icon tinting), these worlds of course won't run in old servers, but the program will merely spit out a warning and tell the user to get the latest version. So if you treat the releases as more of "expansion packs", then they can be fun, as well as proof that we are, and will continue, working on this project.

Well said!
On 9/6/00 2:30 am Q Bert wrote:
I'm not trying to point out the obvious or be rude but do you feel the current 'engine' is anywhere near usable?

Definitely. Even without any programming experience, one can enter into BYOND, and after a few questions, reading the FAQ first (the link is http://www.erinet.com/gjsfaun/byond/byondfaq.html), you can make a functioning game, in a fraction of the time it would take you to make one using one of the "more powerful" languages. In my opinion, BYOND is a bit more powerful, because it takes away all of the hard things, like port management, and still creates a useful interface.

The 'engine' itself, the Dream Seeker, runs almost perfectly smoothly, even in a recent test where BYOND developers spanning from east to west across the States (and in my case, a little bit into Canada too) played a couple games together. Smoothness, however, is of course limited by how the designer makes their world. If you were to execute 50 functions per second, then yes, the program would run down. But even C++ can't run 50 functions per second, transmitting data through ports, and not experience slowdown. BYOND is a lot faster than many of the multiplayer games out there; except perhaps RTS games in the industry, which don't actually send ANY data to the players unless it is needed (eg. they will only send graphics for a certain portion of the entire map, they will only tell clients the hit points of a unit if the unit is currently selected, etc.).

I don't see what's obvious about the engine NOT being usable... in fact, I'd say that that's just a lack of familiarity talking. Once you jump into the thick of things, and actually experiment with some code and games, then you should be able to reach a conclusion. I won't stop you from refusing though, it's your choice after all. But... "don't knock what you haven't tried!". =)
In response to Spuzzum
On 9/6/00 2:40 pm Spuzzum wrote:
If you were to execute 50 functions per second, then yes, the program would run down. But even C++ can't run 50 functions per second, transmitting data through ports, and not experience slowdown.


Thankfully BYOND can execute many more than 50 functions per second, and smoothly. It's probably more accurate to say something like "If you are trying to send every player 50 pieces of information every 1/10th of a second you may experience slowdown".

But even then it's a matter of server speed and connection speed. If you had a dedicated beefy server on a T1 line and your players were on high-speed connections, then even sending every player 50 pieces of information every 1/10th of a second would probably be fine.

In other words, as usual in the Internet world, the pipe connection and server situation will more frequently be the problems, while BYOND is unlikely to be the problem.
I totaly dissagree C++ can easily execute 50 functions a second depending on what they are...I was talking more about whatever method of displaying graphics you people use,are you using bitblt hehe?That would explain why the graphical part is stuck in windows as well.Maybe you should consider releasing a DirectX version or DOS?If you need help with either i can help you get a DirectDraw / DOS version up and running in couples days at mosts..This would greatly increase the FPS's and such

bitblt really isnt good for games..thats why all decent games are in DOS or if in windows using a graphics library such as DirectX ..OpenGL etc etc

Again i do not mean to be rude.. i just want to offer help.. i could also handle linux/BeOS ports depending on how the networking code is written

It doesnt matter what language its in as long as its not in some language no one has heard of i can still help :-D
In response to Qbert
On 9/6/00 10:39 pm Q Bert wrote:
Again i do not mean to be rude.. i just want to offer help..


Great -- why don't you take a look at some of the libraries provided by users in the DM InfoCenter area and see what area of functionality is missing that might fit your expertise.

Dantom has made it very easy for anyone to contribute.
In response to Qbert
On 9/6/00 10:39 pm Q Bert wrote:
I totaly dissagree C++ can easily execute 50 functions a second depending on what they are...I was talking more about whatever method of displaying graphics you people use,are you using bitblt hehe?That would explain why the graphical part is stuck in windows as well.Maybe you should consider releasing a DirectX version or DOS?If you need help with either i can help you get a DirectDraw / DOS version up and running in couples days at mosts..This would greatly increase the FPS's and such

Actually, the FPS isn't low because of BitBlt()-- it's low because by default the server is only ticking away every tenth of second. So the map is refreshing at 10 FPS, which for standard action games is extremely low. The tick_lag parameter can theoretically be used to adjust this time, probably up to 50FPS or so on good machines. I say, "theoretically", because I just found a limitation in the windows timer that prevents resolutions better than about 1/10th second, so once I fix that this will work.

You are correct about BitBlt() not being ideal, although for most applications it seems to be ok. We didn't want to use DirectX because that isn't as portable and requires more libraries and we wanted to keep the package size down extremely small. The more components involved, the less stability, and we're having problems already! And don't get me started about DOS. While it is true that many PC games still use it, it's a dead-in-the-water platform. If anything, we'll do our Linux graphical port next. All of the stable code is on UNIX already anyway.

BYOND is not optimized for graphics; that much is self-evident. The reason that we haven't considered the FPS to be a big issue is that the bottleneck for the most part is either network lag or server computation (due to lots of things happening at once). While we could probably optimize the client to manage some of the glitz offline, but it would only be an illusion since it wouldn't sync up with the server.

On the other hand, seeing as many people are writing single-player games, this is a consideration. And we have even done it to an extent-- the "smooth movement" (which isn't as smooth as I'd like yet) is an example. Eventually we'll get it right.

One thing that is nice about having low-res graphics, though, is that people tend to concentrate on the content a lot more than the flash. It's a shame how many projects die prematurely just because the coders tried to overglitz them before they bothered worrying about the content. BYOND provides a system that emphasizes the design, while providing a base for simple graphics that in some cases look quite nice. And they will get better over time.
In response to Tom H.
On 9/7/00 12:04 am Tom H. wrote:
The tick_lag parameter can theoretically be used to adjust this time, probably up to 50FPS or so on good machines.


I could definitely see playing with that for single-player games (and possibly multi-player if the server is dedicated).

One important aspect of this is that the games would have to be tweaked to work as expected, I assume. If we're getting 50FPS and that means ticks happen 5 times as fast, then my game is likely to zoom by and be over before the player blinks.

If this is accurate, then I imagine it would be good coding technique to use a #define for your default sleep()/spawn() values, so they could be adjusted as necessary for the tick lag.

In response to Deadron
If this is accurate, then I imagine it would be good coding technique to use a #define for your default sleep()/spawn() values, so they could be adjusted as necessary for the tick lag.

Naw, just multiply the sleep time by the inverse of tick lag. Eg.

sleep(3*(1/world.tick_lag))

A bit more work, granted, but it should function.
In response to Spuzzum
On 9/7/00 3:47 pm Spuzzum wrote:
Naw, just multiply the sleep time by the inverse of tick lag. Eg.

sleep(3*(1/world.tick_lag))

A bit more work, granted, but it should function.

A good idea, but I think I'll still use a define:

#define SLEEP_MULTIPLE (1/world.tick_lag)
#define SLEEP_1 (1 * SLEEP_MULTIPLE)
#define SLEEP_2 etc


Note that I am not in a situation to test any of this, so I imagine some of the syntax/algorithm is incorrect.
In response to Deadron
A good idea, but I think I'll still use a define:

#define SLEEP_TIME (3*(1/world.tick_lag))

How about this? (Untested...)

#define sleepinv(x) sleep(x / world.tick_lag)
In response to Deadron
On 9/7/00 12:22 am Deadron wrote:

If this is accurate, then I imagine it would be good coding technique to use a #define for your default sleep()/spawn() values, so they could be adjusted as necessary for the tick lag.

I think sleep() and spawn() are in 1/10th seconds already, so they shouldn't have to be adjusted. Or do you want them to be in ticks?
In response to Guy T.
How about this? (Untested...)

That would make it even faster if the tick_lag were lower... =)

#define sleepinv(x) sleep(x*(1/world.tick_lag))

The above should work, though.

(Of course, because tick lag can't be dropped any more (I think), this is untested too.)
In response to Tom H.
On 9/7/00 7:18 pm Tom H. wrote:
I think sleep() and spawn() are in 1/10th seconds already, so they shouldn't have to be adjusted. Or do you want them to be in ticks?

I'd have tons of work to do if it were changed to ticks, so I guess it's obvious which side I stand on... if tickwise sleep() and spawn() procs are really desired, though, we can negotiate.

Z
In response to Spuzzum
#define sleepinv(x) sleep(x / world.tick_lag)

#define sleepinv(x) sleep(x*(1/world.tick_lag)

But... isn't (x * (1 / t)) the same thing as ((x * 1) / t) ? I thought I was just rephrasing what was already there! I guess I better get some sleep before I start spelling things worng to...
In response to Zilal
On 9/7/00 8:05 pm Zilal wrote:
On 9/7/00 7:18 pm Tom H. wrote:
I think sleep() and spawn() are in 1/10th seconds already, so they shouldn't have to be adjusted. Or do you want them to be in ticks?

I'd have tons of work to do if it were changed to ticks, so I guess it's obvious which side I stand on... if tickwise sleep() and spawn() procs are really desired, though, we can negotiate.

Reminds me of a joke I made up a while ago:

Majority of UN Negotiations:
"Yes!" "No!" "Yes!" "No!" "Yes!" "No!" "Yes!" "No!" "I declare war!" "No!" "Yes!" "No!" "Yes!"...
Page: 1 2