I think we've had this conversation in other topics, but I don't think it's been brought up as an actual Feature Request quite yet.
I know that since building the particle engine, it's given me a lot of insight on the specifics of limitations with a wholefully server-side system. I think Lummox mentioned before that allowing certain procs to be able to be called and run completely client-side was not feasible, or at least very difficult.
I still think it's something to look in to, not only for the purposes of say being able to calculate and render effects client-side, but also things like being able to have each client handle certain things that don't explicitly need to be called from the server, such as drawing and handling the client's UI in-game until they actually click on something that requires server communication.
A lot of issues I've noticed is that BYOND just leverages so much on the tiny amount of server resources it has available to it and a lot of things players do in-game could easily be partly or even wholefully put on the responsibility of the client to handle them. Basically anything that doesn't alter the game-state in any way could safely be allowed to be given the responsibility of the client to do. The caveat to that is that would require the developer to be able to know what functions are and aren't safe to give client-side functionality to.
It's sort of the argument between keeping BYOND relatively idiot-proof or opening up potential security hazards to games for the sake of progress.
ID:2112651
 Jul 7 2016, 6:29 pm
|
|||||||
| |||||||
|
Jul 7 2016, 6:44 pm
|
|
Kaiochao
  |
There's a point where you're much better off using a different engine. Aside from already being familiar with the BYOND engine, why are you using it instead of something else? If it's primarily because of its built-in networking system, but you don't actually find the built-in networking system to be sufficient, then you shouldn't be using it.
|
That insinuating that I find BYOND to be insufficient. Ironically enough, I do use a different engine for most things I've worked on. Notably I've been using SDL2 for it's amazing features and usability. It's a great library that I'd recommend for 2D game development until my face was blue.
However, I think that idea of, "If it's not good enough, use something else" doesn't create the evolutionary stress that's necessary for the engine as a whole to develop. That's not really the point, though; and that's not why anyone is really here. I enjoy programming on BYOND still because it's so fast. It's so easy to get out a fully working game in literally days. So far it's an amazing prototyping tool, but the reason I want to see a feature like this is because I think it helps the overall life of the engine as more than just a prototyping tool. I love the engine, the community and the developers, players and friends I've made here and it's that motivation that makes me really want to see the engine expand more permanent solutions for larger projects. | |
You clearly find BYOND to be insufficient if you're making a feature request to drastically change BYOND's strongest feature, which is built-in networking without any hassle.
If you want built-in networking that you don't actually have to think about, consider using BYOND. If you want built-in networking that is moderately easy to set up, but can be bypassed entirely, consider using Unity instead. Or, if you still insist on using BYOND, but you also want to bypass its built-in networking for client-sided effects, you can use JavaScript and HTML5 with the webclient. If there are improvements to be made in the direction of client-sided effects, it would probably be in the webclient API. | |
There's nothing wrong with wanting to do more.
| |
Sure, you can go use another engine like Unity, but you end up doing way more work in Unity. Which is fine and dandy-
However, what does BYOND do really well? It allows you to create games extremely fast. That is BYOND's strength. Sure, you could go use Unity. What if BYOND allowed you to write client side code? I probably wouldn't even consider Unity at that point, unless I really needed a more powerful engine. Being able to call client side code in DM would make the engine more than twice as powerful than it is. Is it feasible? Probably not. Would it be worth the effort if it was? Most definitely. I also don't believe Kats is trying to change BYOND's strongest feature, built-in networking. I believe Kats just wants the ability to write code that is client-side only. It's also arguable if that's even BYOND's strongest feature. The ability to create a prototype with so little code is quite the feature if you ask me. | |
It's definitely not an easy comparison. Ask yourself, "if you were as fluent with Unity as you are with BYOND, which would you use?" Of course, that's not an easy comparison to make, since Unity has a ton more things to learn (besides all the language features of C#), but hopefully you get the point.
Unity also gets criticism for being so fit for rapid prototyping that it isn't used for real, large projects. Unity has a bunch of standard assets which let you create a 2D or 3D platformer, or first person experience (built-in VR support!), or third person RPG; all with great rigidbody physics simulation, just by dragging and dropping prefabs and scripts, without you having to write any code, draw sprites, or 3D model anything. Rapid prototyping is definitely not something unique to BYOND. But I'm not really trying to make an argument for Unity. I'm still trying to be on-topic, which is why I mentioned using the webclient in my previous post. Get familiar with the webclient API and make all the client-sided GUI elements you want, using JavaScript, HTML, and CSS. This is the "more" that you want, right? | |
Not exactly. Since a large number of developers, myself included, strive to use as little of BYOND's dmf UI as possible, we usually default to HUD objects, which to my knowledge, is still being calculated server-side. Even with the webclient, it's the fact that we wouldn't use these UI features in the first place is why we don't really care that they're there.
Also, huds aren't the only benefit from using client-side operations. And to say that adding this functionality would remove what BYOND is best at is kind of moot. There's absolutely nothing saying that the default setting for a proc or something wouldn't be to be completely server-side, but allow the developer to explicitly make certain operations client-side. It would be just like building the separate client-server operations in any other game engine or library, only in BYOND's case, the power comes from the fact that you don't need to compile two separate projects to do so. Working in the same project under the same source code would add a lot of ability to streamline development. | |
There's a point where you're much better off using a different engine. Here's the issue, and this is a big issue with byond. At some point every game made in byond grows up. Having the nice user friendliness of byonds server <-> network <-> client setup is nice, and it makes building a game easier. Having the simple typed but not typed setup of byond is nice, and it also makes building a game easier. but once that game is built, and built on, and expanded, and advanced: What now? You're now 300,000 lines in on a project and having growing pains. What? Do you take those 300,000 lines to a new engine? You and I both know that isn't tenable at even 50,000 lines, let alone 300,000. | |
MrStonedOne wrote:
You and I both know that isn't tenable at even 50,000 lines, let alone 300,000. hold my beer | |
I think Stoned makes a really great point that summarizes hobby development. Even if you wanted to move to a different engine, often times the amount of effort it would take just to get everything set up for translation ends up being more of a headache than it's worth, in all honesty.
It's the ratio between work and motivation that makes making large jumps like that hard to justify when, even though it's getting tougher to expand on, you can get by just enough to warrant not banging your head against C# or Java for the next 6 months. Even when you plan to move to a new engine, often times developers don't realize what kind of nightmare it can be and in the previous anecdote, they bang away at it for 2-3 months before losing steam and just letting that phase of the project go, coming back to BYOND to continue its development there instead until the motivation returns or they come up with a better plan. I would put out there that 95% of all developers who leave BYOND for other engines, do so because they believe it's just not up to par with what they need for even hobby projects, and that's the real issue. Instead of circle jerking the drain, actually solving critical flaws in the engine's infrastructure would make it more robust, flexible, powerful and actually put it on the list of feasible engines in the scope of more ambitious projects. | |
Don't limit BYOND just because a less limited engine already exists. What kind of logic is that?
Should we also not make cars out of metal? I mean we already have wood, and metal is so good at electronics whereas wood is fantastic for carving. I'm also already fluent in wood, so let's only have wooden cars and not make metal ones. | |
I agree with Kaiochao.
Let's say you have two mechanics, mechanic A and B respectively, both possessing a hammer, screwdriver, and a wrench. A client asks them to hang a large portrait on the wall of their home. Mechanic A knows what has to be done without looking at his tool set: nails must be placed in order for this portrait to exist on the wall properly. The job is finished in no time at all. Mechanic B, however, looks at his tool set without considering the requirements for the project, and begins doing this and that with the hammer, screwdriver, and wrench. After so much time, he's burned out and loses the job. The point of this analogy? Mechanic A had clear knowledge of how to use the tools at his disposal, and therefore made progress in efficient time. He had a good idea of what needed to be done and how it needed to be done. Mechanic B had little clue as to the path of least resistance and attempted to push the limitations of tools that just weren't meant for the job. This resulted in time wasted for both him and the client. If you know you need something that Byond cannot handle properly or elegantly, then I don't think you should be trying to use it. | |
FKI wrote:
If you know you need something that Byond cannot handle properly or elegantly, then I don't think you should be trying to use it. Rip features added and being added since 5.0. | |
Lige wrote:
FKI wrote: This. Some people here believe that if you need to use a feature that doesn't exist in BYOND you need to look for another engine, and this sounds totally absurd. You may be able to create something nice even if that feature doesn't exist at that moment (unless you want to create 3d online games, ofc). Furthermore, Feature Requests exist for a reason... people suggest ideas, and Lummox is the one who says whether they are feasible or not. So I don't really understand people who keep stating that you need to use another engine to create a game if you're looking for certain characteristic that may be implemented to DreamMaker at some point.. | |
Adding and completely reworking are two entirely different things.
Lige said: Rip features added and being added since 5.0. Not sure what you are saying here. | |
Some people here believe that if you need to use a feature that doesn't exist in BYOND you need to look for another engine, and this sounds totally absurd. There are some features where implementation would be so absurdly problematic from a semantic standpoint that this point becomes invalid. This is one of them. | |
All I honestly see the gist of the counter argument is literally, "We shouldn't make new things if they're hard".
We're all here on BYOND for different reasons, least of which is because it's actually the optimal engine we should use for our projects. We've been building games around BYOND, which is why we ask for new features in the first place. If we wanted an absolute game engine, we'd look somewhere else, but that's not the point. We work with BYOND because of its community, our history with it and a plethora of other reasons, which is the reason we ask it to be expanded on. BYOND is not an optimal game engine in literally any scenario. Period. But that doesn't mean it can't be, and just because it's not easy or just because there are other options out there doesn't necessarily mean we shouldn't look to continue evolving. That kind of thinking is extremely dangerous and limiting in scope, honestly. If it's not feasible, that's fine, but that's not what the discussion has been so far. So far it's literally been people saying, "If BYOND can't do it, go somewhere else." | |
@Kats: It's not so much that it's hard so it shouldn't be done. The problem is finding a way to force it into a semantic ruleset that assumes precisely the opposite constraints of the system you are suggesting.
Basically, BYOND is built on the assumption of server-directed networking. Leveraging assets on the client would be non-trivial, but here's the problem: How do you cleanly integrate it into the existing structure without all sorts of nonsense workarounds that would make zero sense to anyone who isn't already using the software? Imagine you are building onto an existing house. You can't really knock out your load-bearing walls to open up one of the rooms, so the existing portion of the house is going to remain mostly intact. Now imagine 20 years later you are adding on to this house again. It's never going to make as much sense as a house that was built from the ground up with the current square footage. You are going to have awkward joins and concessions you have to make to work around what's already there. In some cases, it can be much more complex to add on than it is to start fresh. I'm not saying it's not worth the effort. On the contrary. It would make the engine much more attractive to me. Just pointing out that if you are looking for a feature like this one, you are saddling yourself with an engine that's fundamentally, top-to-bottom antithetical to this particular feature. Either you will learn an entirely new BYOND if it ever gets added, or you will learn so many backward workarounds because of the existing implementation that it will push you to environments that considered this particular avenue in the first place during planning rather than at the end of its lifecycle. That may be fine, but Lummox is more interested in features that give him a roadmap of how it is to be implemented. See my collected feature requests for examples. Feature requests that devolve into whining about naysayers generally don't go anywhere anyway. --and it doesn't get you a step closer to a clean semantic implementation outline. | |