Forum_account wrote:
Falacy wrote:
DM based pixel-movement cannot be effectively accomplished without destroying everything via tick_lag
If you want games to be "more responsive and graphically appealing" you'll have to lower tick_lag. This isn't an opinion - for as long as motion pictures have existed people have known that 10 frames per second is insufficient.
I agree that tile-based movement often makes BYOND games look awkward, but its not the only problem. Almost all games (byond or not) look bad at 10 fps. Adding pixel movement to BYOND won't change that, 10 fps will still be insufficient. It would have to use a higher framerate, so I'm not sure what problems you think a built-in solution could avoid.

If this is the case then why not just make a post to request the FPS being raised to an appropriate level? I mean, I don't know much about this topic but would that be possible with BYOND? And if so, how would raising the frame rate actually help make games look better or less awkward?
Enough with the bolding replies, please. It's annoying.
If this is the case then why not just make a post to request the FPS being raised to an appropriate level?

This is already possible. Lowering world.tick_lag increases the framerate.
Lummox JR wrote:
Enough with the bolding replies, please. It's annoying.

But that's exactly as he intends to sound. ;)
Falacy wrote:
http://store.steampowered.com/app/105600/

I'm not sure why you posted that link. If you want to make games like that using BYOND you should be asking for control over the client's graphical display. There's nothing in that video that BYOND can't do but because the BYOND server has to manage all objects used to create all visual effects, some of the things seen in the video would be impractical.
Of course there's nothing there that BYOND couldn't do, as I said before, practically anything is possible. However, if you were going to go through all the trouble to convert BYOND into an engine capable of handling the things that that game does, then you might as well just build the entire thing yourself from scratch.

I more or less posted that video to show exactly that: A game that's fundamentally no better than any of the quality games on BYOND has sold more copies in a single day than the entirety of BYOND has seen in free users since it started years ago.

If BYOND was willing to take just a few steps in the right direction, it could potentially be successful.

I also posted it here so you specifically would see it, since you seem to be into mining adventures
That game looks like Minecraft went side-scroller. How original.
It pretty much is, and its not even as good as Minecraft IMO. Point is, something like that should be easy to create with BYOND, but with the current systems, its closer to impossible. Pixel movement would be a big step towards accomplishing it, and client sided graphics would help too.

EDIT: Also, while I'm thinking about it: Pixel movement should take multiple direction key inputs at the same time, so that you can move at angles. Current BYOND games should probably do this...
Falacy wrote:
It pretty much is, and its not even as good as Minecraft IMO. Point is, something like that should be easy to create with BYOND, but with the current systems, its closer to impossible. Pixel movement would be a big step towards accomplishing it, and client sided graphics would help too.

The reason that game would be difficult to create with BYOND is not because BYOND lacks built-in pixel movement. You can use a library for that, it's easy. The problem is that BYOND doesn't allow for any custom client-side processing so all of the visual effects (lighting, on screen text, etc.) would have to be managed by the server. This will eat up the server's CPU and bandwidth whether you have built-in pixel movement or not.

EDIT: Also, while I'm thinking about it: Pixel movement should take multiple direction key inputs at the same time, so that you can move at angles. Current BYOND games should probably do this...

My pixel movement library already does that. The default movement scheme makes you move northeast if you're pressing up and right. It also contains a demo where the left/right arrow keys make the player turn and the up/down keys make the player move. http://www.byond.com/developer/Forum_account/PixelMovement
Forum_account wrote:
The reason that game would be difficult to create with BYOND is not because BYOND lacks built-in pixel movement.
Depending on how far you extend your description of pixel movement, that's far from the only thing that BYOND is missing.

You can use a library for that, it's easy.
I could just write the systems myself, but considering what a complicated, backwards process it is to go from tile movement to pixel movement, and what a common/standard feature it is in every decent game in existence, there's really no excuse for BYOND not to have it.

The problem is that BYOND doesn't allow for any custom client-side processing so all of the visual effects (lighting, on screen text, etc.) would have to be managed by the server. This will eat up the server's CPU and bandwidth whether you have built-in pixel movement or not.
Though that is vaguely a problem, that concept effects all systems in all BYOND games, it should be no more or less of a problem for a project like Terreria. On-screen text and lighting systems can be made just as easily and efficiently, if not more-so, than DM based pixel movement. High quality HUD systems should be built-in, but that's another issue, and built-in lighting wouldn't hurt either.

My pixel movement library already does that. The default movement scheme makes you move northeast if you're pressing up and right.
Its not something too complicated to implement, my non-pixel-movement games do it, its just something that should be a default behavior.
Falacy wrote:
Though that is vaguely a problem, that concept effects all systems in all BYOND games, it should be no more or less of a problem for a project like Terreria. On-screen text and lighting systems can be made just as easily and efficiently, if not more-so, than DM based pixel movement.

The problem isn't that these systems (lighting, on screen text) are hard to create, the problem is that BYOND requires that all processing be done on the server so these features bog down the server. Non-byond games that have custom client software don't have this problem. Instead of the server needing to tell each client where to position each letter to spell a word, the custom client can be told "write this word" and it handles the rest.

Because performance is the problem, client-side processing is the solution. A library for BYOND that handles dynamic lighting cannot be as efficient as client-side lighting. There is a huge benefit by handling it on the client. Built-in pixel movement would still be handled through client-server interaction, which is no different than how a library would handle it. There's really no benefit to be had, just a lot of potential for disappointment when the built-in feature doesn't work how you want it to.
Forum_account wrote:
The problem isn't that these systems (lighting, on screen text) are hard to create, the problem is that BYOND requires that all processing be done on the server so these features bog down the server.
On-screen text systems can be created that use practically no CPU. Lighting is a more intense process - depending on what exactly you're doing with it. Though controlled client-sided processing could help, built-in systems for both would still be better, especially if they were built-in + client-sided.

Built-in pixel movement would still be handled through client-server interaction, which is no different than how a library would handle it.
It would most likely be at least slightly more efficient when handled internally. It would also be more standardized and accessible than any library. You could make the best pixel-movement library in existence, doesn't matter much if nobody else ever uses it.
Falacy wrote:
You could make the best pixel-movement library in existence, doesn't matter much if nobody else ever uses it.

The only thing preventing widespread use of FA's pixel movement lib (aside from regular old lag) is the fact you can't just slap it into another game and see instant results. I think the chief cause of this is the way BYOND's macros work, there's no easy way to import a set of macros into another interface file. Having the special keyboard input handling only serves to complicate the lib with things completely unrelated to the actual pixel movement.

There's also the fact BYOND's lib updating is a little weird. When you update a lib it just pastes new files over old ones rather than creating a fresh copy of the lib. You'll sometimes end up with "dead" files you don't need but include them in the lib anyway.
Falacy wrote:
On-screen text systems can be created that use practically no CPU

CPU is only part of the problem, bandwidth is the bigger issue:

http://www.byond.com/members/Forumaccount/forum?id=333

You can read all of the details on that forum post, but here's the short version:

I made a program that simulates on screen text in a controlled setting so the network profiler's measurements are accurate and consistent. Just placing 18 letters on the screen for 8 seconds, then removing them requires sending 4.6 KB of data to the client. Visual effects (moving the text, making the letters bounce, etc.) can double or triple the data sent.

Watch the Terraria video again and see how many objects exist that don't have to be controlled by the server. When a rock breaks and the fragments fall, the motion of the fragments can be governed by the client. If it takes 4.6 KB of data to display 18 letters on the screen in a BYOND game, think of how much bandwidth you'd use in a BYOND game trying to recreate some of the sprite-heavy bits of that video.
Forum_account wrote:
CPU is only part of the problem, bandwidth is the bigger issue:
That depends entirely on the server. Any type of machine dedicated to hosting, even with just a 10MB upload speed, should be able to easily handle the traffic for a BYOND game. CPU can much more easily get maxed out, from just a few loops. And regardless, BYOND seems to have some flunky built in fault that causes games to lag even if the system is barely using any resources.

I made a program that simulates on screen text in a controlled setting so the network profiler's measurements are accurate and consistent.
You're doing it wrong. You shouldn't be creating/deleting the objects every time, you should rarely use del() in general. Bouncing animations should be handled in the icon, if you don't want to manually animate them, then you can easily create a tool to generate such an effect. Overlays don't work well in general, and unless they've improved upon them, overlays work even worse with/as screen objects, and there's no reason for you to be using them the way you are anyway... If you want to maintain a reference to a single message, so that you can easily remove it, then use a list of objects, and then remove it from the client's screen. Build a halfway efficient system, and let me know how that works out. You should more or less only need to update icon_states in order to display a message to a player.

Obviously, performance would be better if we could offload certain aspects onto the clients, but that's a completely separate issue.
Falacy wrote:
Obviously, performance would be better if we could offload certain aspects onto the clients, but that's a completely separate issue.

It's obviously a separate issue, but it sounds like this is the issue you're actually concerned about. You're looking at other games thinking "this *should* be easy to make with BYOND, why isn't it?" and it has nothing to do with built-in pixel movement. The answer is because DM developers have no control over how the game client works, so the neat graphical effects that make games look nice are very impractical for multiplayer BYOND games.

BYOND seems to have some flunky built in fault that causes games to lag even if the system is barely using any resources.

Can you explain this better? I hope you're not talking about:

1. The fact that the BYOND server processes commands every 0.1 seconds (by default) so the processing of a client's keypress will be delayed by 50 ms (on average).
2. The latency experienced by all messages sent over the internet.
Forum_account wrote:
It's obviously a separate issue, but it sounds like this is the issue you're actually concerned about.
Pixel movement is 99% of the issue here. And sure, some of that graphical flair may be lost for efficiency, but most of those effects would be easy to pull off regardless. Offsetting some graphical pixel effect is much easier and more efficient than full blown pixel movement - though it would be somewhat inclusive.

Can you explain this better?
Not really, just the inconsistent lag/lag spikes that all BYOND games seem to demonstrate, and the general slowdown that they all seem to get hit by with large player counts, even when the machines they're on are nowhere near being stressed. More importantly, the fact that these slowdowns occur without first stressing the system. As I explained in some other issue: My server was using some x amount of its bandwidth, I logged in to one of the games hosted on it, and I was downloading the resources without the overall usage increasing - meaning performance must have been decreased elsewhere, and that it wasn't taking full advantage of my available speed. Also, how hosting multiple servers on the same machine seemingly have little-to-no effect on each other CPU wise - one can be maxed out at 100+% world.cpu, while others are at 0%, and how world.cpu goes to 100% without actual processing cores maxing out.
Falacy wrote:
And sure, some of that graphical flair may be lost for efficiency, but most of those effects would be easy to pull off regardless. Offsetting some graphical pixel effect is much easier and more efficient than full blown pixel movement

You're right that it doesn't take much CPU or bandwidth to create a single particle effect. The problem is that to create nice visual effects you need hundreds of particles. Somewhere between having 1 and 300 particles it starts to be a burden. Same for dynamic lighting - its easy to do for one tile, but for a game you need to do it for every tile. Updating one object's icon_state every tick isn't a problem, but updating 500 is a problem (especially when you consider how many clients need these updates).

Whether its built-in or not, the server handles pixel movement so there's no way to greatly lessen the CPU/network load. You seem to think that user made pixel movement could not possibly be efficient, but there are several examples of multiplayer BYOND games with pixel movement (and they're all fairly popular and commended for their quality and polish). What you're saying does not match reality.

The real hangup seems to be that people don't want to admit that they used a library and they don't want to admit that they (a DM expert) struggled to learn how to use the library. I don't mind if people use my library without giving me credit. I included lots of resources (demos, help files, etc.) so that people have ways to privately learn to use the library. Maybe I should set up a way for users to anonymously ask questions.
Page: 1 2 3 4 5 ... 8 9 10