Enough with the bolding replies, please. It's annoying.
But that's exactly as he intends to sound. ;)
Lummox JR wrote:
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. | |
I guess you don't pay attention, Falacy.
Doomed Dreams Portal DM Darkness Springs & Things RPG Pixel-Movement Demo | |
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. | |
Forum_account wrote:
The problem is that to create nice visual effects you need hundreds of particlesThat depends a lot on the effect you're trying to pull off... You surely don't need 300 pixel chunks to show a tiny block breaking apart. For smaller effects, you don't even need to update them every tick, just use animated icon_states and an initial random offset. 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 problemThat depends a bit on the situation. You could have a lighting system that only effects a few tiles at a time. The only time you should need to update every tile's lighting is if there were some sort of day/night cycle, and you shouldn't need to update them every tick regardless. Also, assuming BYOND has some half competent network pre-processing, which in previous discussions they have claimed that it does, the server shouldn't be updating all of those tiles to every client. If you're at 1,1,1 and some tile at 100,100,10 gets modified, BYOND shouldn't be notifying you about it. (especially when you consider how many clients need these updates).Considering what a failure practically every game on BYOND is, the number of clients that would need those updates would probably be one. You seem to think that user made pixel movement could not possibly be efficientI don't think that at all. If anything, you seem to be the one obsessed with efficiency on this topic. Pixel movement shouldn't be any more or less efficient than any other system BYOND would fail at performing. 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)Wheres that? I can think of very few games with pixel movement. Casual Quest's pixel movement is broken. Decadence only uses it for projectiles. Kajika made a Megaman pixel movement demo a long time ago, but it used standard BYOND controls which didn't work worth a crap, and wasn't multiplayer (seems to have been updated since I last played it). Your Mining Adventure game is probably the best, if not only, example that I can think of, and I've never tried it multiplayer. "Fairly popular" by BYOND standards means 10 players, its not exactly an accomplishment, or a situation that should be stressing a system by any means. [library stuff]Exactly, those are a few of the many reasons why I don't support libraries. In most cases, people won't even bother trying to understand them. In the time it would take just to grasp the user-level functionality of most libraries, any competent programmer could just write their own version of it. And even if you do master the use of some random library, that knowledge is going to be worthless towards most other projects/BYOND in general. | |
And even if you do master the use of some random library, that knowledge is going to be worthless towards most other projects/BYOND in general. I don't understand that. If you want to make only one game that uses pixel movement, learning anything (whether its built-in or part of a library) would be a waste. It's not a waste because its a library, its a waste because you're only making one game. If you want to make several projects that use pixel movement then the knowledge isn't a waste. | |
This is already possible. Lowering world.tick_lag increases the framerate.