ID:100957
 
Only just recently, there has been another BYOND needs built-in pixel movement demand (though different as it suggested monetary support). It's all too common, but each time somebody asks this, I wonder, what do they mean?

BYOND has the capability to move an icon by a single pixel, so this can hardly be the whole topic. Browsing some demonstration on soft-coded 'pixel movement', one can already find the real part behind the request, collision detection (and 'physics'). But people seem to forget is that there isn't just 'one' collision detection system to suite everybody. There are various very different systems, be it a bounding box (plenty of possible shapes!), sprite detection, or even more complex solutions. This is, not to mention the difference in possible 'physic engines' people want hard-coded as well.

I seriously doubt that anybody could find an easy to use system that suits every game people on BYOND could dream to develop.
Even then, you'd have to disregard all the other issues arising as consequences of such a system. If you want performance (something people never cease to complain about with BYOND), you have to implement this completely client-sided, but that opens a whole can of worms, cheating worms to be precise.
Not to mention the problems from BYOND's fully server-sided legacy!

In my eyes, the only viable option is a complete redesign that allows for advanced users on BYOND to customise the client (client-sided processing) and the networking protocol, which would allow for a multitude of libraries (simple as clicking a check-box) to feature 'pixel movement' the way everybody wants it.

The consequence of this thought is a complete redesign of BYOND.

As a summary, whenever somebody requests pixel movement, consider what it is that you really want and if you shouldn't be asking for client-sided processing and customisable networking protocol instead, which would mean that BYOND needs support!
Your support!
Does this mean we don't get native pixel movement? /s
the only viable option is a complete redesign that allows for advanced users on BYOND to customise the client (client-sided processing) and the networking protocol

If you're going to put a lot of work into client-side processing and the networking protocol, what are you using BYOND for? Dealing with the networking and client-side processing yourself puts you much closer to having developed your own multiplayer game from scratch.

There are a few reasons why BYOND doesn't attract many "advanced" users. How would they find it? Most advanced users wouldn't be searching for naruto games. Why would they stay? The community isn't great and the DM language feels old, clunky, and obscure at times (I still have no idea why it's called "copytext" instead of "substring"). DM has lots of quirks: overlays, icons, images, screen objects, scores, interface controls, keyboard/mouse input, naming conventions. Looking at how awkward these things are, it's not likely that someone will look at BYOND and say "now there's a robust, high-quality game development platform."

Client-side processing would be nice but it doesn't fix those problems. That's part of the reason why I've been aggressively pointing out problems with winset/winget, the implementations of current features don't give me hope that new features will be any better. I'd rather see the pile of procs we currently have get some TLC before adding to the pile.

It would be nice, however, to see more client-side effects. I believe that visibility calculations are done client-side. Lighting effects could easily be handled by the client too. In A Miner Adventure it has to update the icon_state of about 70 objects each time you move to a new tile, notifying all nearby clients of these changes can cause a lot of lag. This could easily offload a lot of work to the clients. Even if these things aren't very customizable they'd still be useful.


I agree that soft-coding is the best option for many things. Considering the staff's reluctance to implement frequently requested features* it's usually the only option! The problem is that each new library or demo is placed in the same pile with the other ~2300 libraries and demos and the search feature stinks. A library might exist that does exactly what you need but good luck finding it. I am fairly certain there will be more people that request native pixel movement support than there are people who download my pixel movement demo.

* I wanted to implement a way to flick overlays for my library. I know it's talked about a lot on the forums but the request goes back to May 2001 id:12264! I found some workarounds but not many decent solutions. People have been asking about it for 9 years and it's still not easily possible. It seems like the BYOND staff implements things that are easy to add and things that they want to see, but largely ignore user feedback.
Before pixel movement is added BYOND needs a hell of a lot of other stuff.

Right up top I would say separating FPS from commands processed per second, and then allowing people to set their own FPS for the game to run at.

The way BYOND works at the moment is simple. It runs at 10FPS, and allows you to input 10 commands per second. If you adjust that FPS, say to 20, then you also can input 20 commands per second, and certain things (sleep) also run at twice the speed.
How many frames a game renders per second, and how fast the code run should not be the same, but different.

It might not be easy to add, but really, there is no point at all in having pixel movement, when the game is so slow and choppy it would just be better to use tile based movement.

If those were added then BYOND would be decent for making action games. (It can handle them at the moment, but it is about as suited to making action games as a hack saw is at performing brain surgery)
The Magic Man wrote:
If those were added then BYOND would be decent for making action games. (It can handle them at the moment, but it is about as suited to making action games as a hack saw is at performing brain surgery)

Maybe it's the developer that's about as suited for making action games as a hack saw is at performing brain surgery. I've found BYOND more than adequate for action games. If you're dissatisfied with it's support for action games without realizing what is currently possible I wouldn't expect you to be satisfied with any changes that are made. Either way, you should definitely explore what is possible before saying "that's not possible".
Forum_account wrote:
The Magic Man wrote:
If those were added then BYOND would be decent for making action games. (It can handle them at the moment, but it is about as suited to making action games as a hack saw is at performing brain surgery)

Maybe it's the developer that's about as suited for making action games as a hack saw is at performing brain surgery. I've found BYOND more than adequate for action games. If you're dissatisfied with it's support for action games without realizing what is currently possible I wouldn't expect you to be satisfied with any changes that are made. Either way, you should definitely explore what is possible before saying "that's not possible".

I never said BYOND could not make action games. I just said it sucks at it, and really badly at that.

The amount of effort involved in making an action game with BYOND is more than is needed, and the results are never very good.
Whereas, if I use something like Game Maker, I could make an action game with it in hours that is better than anything that could be made with BYOND. (Seriously, go and play any action game made with Game Maker, and tell me BYOND could do the same).

Sure, BYOND can make actions games. But it's just not very good at it (hence the lack of good action games), and definitely nowhere near as good at it as other, rival programs.
The Magic Man wrote:
I never said BYOND could not make action games. I just said it sucks at it, and really badly at that.

Perhaps I was too subtle.

The amount of effort involved in making an action game with BYOND is more than is needed, and the results are never very good.

DivineTraveller put together Doomed Dreams in about a week (that's a guess, I'm trying to piece together the start date from posts/comments). I put my pixel movement demo together in a day, then made the first version of A Miner Adventure in 3-4 days. These games aren't life-changing experiences but I don't think any of them are bad either. Any way they are bad is the fault of their design, not a limitation of BYOND.
Forum_account wrote:
DivineTraveller put together Doomed Dreams in about a week (that's a guess, I'm trying to piece together the start date from posts/comments). I put my pixel movement demo together in a day, then made the first version of A Miner Adventure in 3-4 days. These games aren't life-changing experiences but I don't think any of them are bad either. Any way they are bad is the fault of their design, not a limitation of BYOND.

Yes, about a week. I started immediately after your initial comment, and finished yesterday.
You people really ought to spend your time using BYOND for what it can do rather than just lurking around the web site complaining about what it can't do.

Requesting features is one thing, but all some of you ever talk about is fundamentally changing the way BYOND has been built to work. If BYOND doesn't suit your needs on such a basic level then go somewhere else.
I think pixel-movement -- obviously with collision detection -- should be as simple as how we now have the different map formats.
A built-in world variable to determine whether the built-in Move() proc uses pixel-movement or tiled-movement. Then, most likely, use the already integrated pixel_step_size -- I think it's that one, not too sure. Can't remember the name of it -- to determine the step size, and yeah, if you understand a bit of DM you'll know there's already built-in variables that seem like they'd go with a built-in pixel-movement and collision system, but there's just no such thing built-into DM yet.

Or, maybe it's an Easter-egg from Tom secretly showing us a soon-to-be system built-in? :D

Most likely not the second, anyways yeah.
Maximus_Alex2003 wrote:
I think pixel-movement -- obviously with collision detection -- should be as simple as how we now have the different map formats.
A built-in world variable to determine whether the built-in Move() proc uses pixel-movement or tiled-movement. Then, most likely, use the already integrated pixel_step_size -- I think it's that one, not too sure. Can't remember the name of it -- to determine the step size, and yeah, if you understand a bit of DM you'll know there's already built-in variables that seem like they'd go with a built-in pixel-movement and collision system, but there's just no such thing built-into DM yet.

What you've described is almost exactly the first example in my pixel movement demo. The only difference is that it uses a hard-coded constant step size instead of using the mob's pixel_step_size var. The demo has about 100 lines of code that you need to include and overriding the movement behavior is as simple as:

client
North()
mob.pixel_move(0,mob.pixel_step_size)
East()
mob.pixel_move(mob.pixel_step_size,0)
// etc.


It's much easier to implement this with DM than it is to have them implement as part of DM.

A built-in approach like what you described quickly becomes inadequate. A driving game or sidescroller might require that you move at different directions (not just the 4/8 cardinal ones) and at different speeds, what do you do then? Having an implementation written in DM gives you the control so you can modify it as you need to.
Forum_account wrote:
If you're going to put a lot of work into client-side processing and the networking protocol, what are you using BYOND for?

<sarcasm>You're totally right, nobody ever uses engines like Game Maker which base around client-sided processing and custom networking.</sarcasm>
Similar to how you can go and include assembler code in C++ optionally, additional functionality doesn't have to be negative.


Forum_account wrote:
I still have no idea why it's called "copytext" instead of "substring"

I'd guess because it makes a lot more sense to those that haven't used another programming language before, or in other words, BYOND's target audience. I'd say that ten out of ten people would have a guess on what copytext does, whereas some might not figure what substring would do.


Forum_account wrote:
it doesn't fix those problems

Actually, a complete redesign (as suggested) would address the issues you mention as well. Client-sided processing was simply highlighted in context of 'pixel movement' requests.


Forum_account wrote:
In A Miner Adventure

Good job copying from D4RK354B3R.


Forum_account wrote:
Considering the staff's reluctance to implement frequently requested features

Actually, that was the real point behind my blog post which seems to be happily ignored here. Most of the 'feature requests' are unrealistic because they either make no sense (a too broad approach like 'pixel movement' which could have dozens of possible very different implementations), or simply strugle with BYOND's legacy (convoluted source code with rather specific predefined ruls).
The Magic Man wrote:
Before pixel movement is added BYOND needs a hell of a lot of other stuff.

If you reread my blog post, I do not suggest adding 'pixel movement', but elaborate why such a request is kind of at fault.

The real request (an complete overhaul) could easily include more emphasis on separation of concern.
SilkWizard wrote:
You people really ought to spend your time using BYOND for what it can do

I completely agree with you, so I won't argue your point ;)
Maximus_Alex2003 wrote:
I think pixel-movement -- obviously with collision detection -- should be as simple as how we now have the different map formats.

Thank you for completely ignoring everything I tried to point out in my posting.


Maximus_Alex2003 wrote:
if you understand a bit of DM

Sorry, I obviously have a very limited understanding of the language that can not rival yours.
I realize you're just trolling at this point. It would be nice to have a slightly-more-serious discussion about topics like this but you don't seem to be able to handle it.

Schnitzelnagler wrote:
Forum_account wrote:
In A Miner Adventure
Good job copying from D4RK354B3R.

I can't possibly be copying D4RK3 54B3R because I'm copying Phong shading, which D4RK3 54B3R did not create =)
Forum_account wrote:
Perhaps I was too subtle.

Doesn't matter how good or bad a workman is. If the tools are bad, he cannot use his full potential.

Bad tools decrease the quality of the finished product.


DivineTraveller put together Doomed Dreams in about a week (that's a guess, I'm trying to piece together the start date from posts/comments). I put my pixel movement demo together in a day, then made the first version of A Miner Adventure in 3-4 days. These games aren't life-changing experiences but I don't think any of them are bad either. Any way they are bad is the fault of their design, not a limitation of BYOND.

Your pixel movement demo could be done in Game Maker, in about 3-5 minutes.

Both A Miner Adventure and Doomed Dreams could be done in GM in maybe a day.

It is quiet a major difference in time when you think about it.

Although, I'll admit, those examples are pretty good for a BYOND game. But again, compared to something made by other programs, they're nothing to brag about.
Go play Spelunky and compare the games. You'll see what I mean.
The Magic Man wrote:
Forum_account wrote:
Perhaps I was too subtle.

Doesn't matter how good or bad a workman is. If the tools are bad, he cannot use his full potential.

Bad tools decrease the quality of the finished product.


DivineTraveller put together Doomed Dreams in about a week (that's a guess, I'm trying to piece together the start date from posts/comments). I put my pixel movement demo together in a day, then made the first version of A Miner Adventure in 3-4 days. These games aren't life-changing experiences but I don't think any of them are bad either. Any way they are bad is the fault of their design, not a limitation of BYOND.

Your pixel movement demo could be done in Game Maker, in about 3-5 minutes.

Both A Miner Adventure and Doomed Dreams could be done in GM in maybe a day.

It is quiet a major difference in time when you think about it.

Although, I'll admit, those examples are pretty good for a BYOND game. But again, compared to something made by other programs, they're nothing to brag about.
Go play Spelunky and compare the games. You'll see what I mean.

As much as i hear you complaining about byond, and talking about how great game maker, it begs the question; Why are you here? If Game Maker is so much better, why dont you stick with that?
Pmitch wrote:
As much as i hear you complaining about byond, and talking about how great game maker, it begs the question; Why are you here? If Game Maker is so much better, why dont you stick with that?

I'm not complaining about BYOND. I am saying it could be better.
Nor am I saying Game Maker is great. I am using it as a comparison as they are both tools designed with the same purpose and intention.

PS. I use both (and more) actually. It's all about using the right tools for the right job, and BYOND is better suited to somethings, while Game Maker is better suited to other things.
The Magic Man wrote:
Your pixel movement demo could be done in Game Maker, in about 3-5 minutes.

The demo is open-source. Anyone can make it in BYOND in less than a minute!

The DM code that you write extends BYOND's built-in functionality. One way for BYOND to become more powerful is for the developers to add more built-in features, the other way is for you to add them yourself.


Edit:
Both A Miner Adventure and Doomed Dreams could be done in GM in maybe a day.

I question the accuracy of this statement and its validity. Without a built-in fluid mechanics system, I don't think you'd be able to implement the water from my mining game in much less than a day. It should be easier to re-create a BYOND game in Game Maker because the design decisions have been made for you.
Page: 1 2