ID:1755294
 
It recently came to my attention that not everyone who wants to develop for the webclient has seen the current documentation for it. Knowing that, there are probably a lot of unresolved questions people have regarding development.

This thread is for webclient developers--or any who are just wondering about it--to fire away with any questions they might have. Your feedback could be very helpful to improving the documentation, and might even merit a FAQ section.

I'll get the ball rolling with questions I've seen a lot here, and will update as new ones come in. Eventually I can add this to the doc. Also if you've seen a question repeatedly asked that you think belongs here, please let me know.


Webclient FAQ


Q: Will I have to change my game to make it webclient-compatible?

A: Probably not. The only major things the webclient does not support are menu controls and multiple map controls, and some obvious stuff like client-side savefiles. Pretty much everything else should work, but check the documentation to be sure; a list of differences between the webclient and DS is at the end, and there's also a list of which skin parameters are supported. If you have a .dmf skin it should be translated automatically. Menus are a possible later refinement, although anyone could write a menu control of their own because the webclient is very extensible. (Currently menu info is not translated from the .dmf, but that may be added later so that anyone who creates a menu control would have it available.)

Q: Can the webclient run on a tablet?

A: Yes! Older tablets may have trouble, and there appear to be some issues with the default Android browser at this time, but mobile Chrome and Safari are capable of running the webclient. I've tested it myself on an iPad Air running iOS 7.

Q: But the webclient can do less than Dream Seeker, right?

A: While there are a few things the webclient does not currently support, that list is very small. The list of what it can do that DS can't is actually much bigger, and growing. The webclient is highly extensible in a way that DS never could have been. For the first time, you can create your own controls. They don't even have to be physical controls: You can define a class that does nothing but act as a game manager and pass info back and forth via winset/winget. You also get the power of a modern browser under the hood. While the server does the heavy lifting and manages multiplayer aspects of the game, clients can be prettied up with better-looking components than ever before.

Q: Do I have to write my webclient skin as a .dms file?

No. The .dmf skin, if present, will be converted for you by the server. However, if you do supply a .dms skin, it can be used to give the webclient a separate appearance than the one used for Dream Seeker players, and a .dms skin can also take advantage of any custom controls you might define.

Q: Can I run the webclient on my own site?

A: Yes. Dream Daemon will provide embed code for an iframe to include on your site.

Q: Will I be able to run my game on portals outside of BYOND, such as Kongregate, Newgrounds, Gamejolt, etc?

A: For any of those sites that support iframes, yes. The only caveat is that we don't currently interface with their login systems; webclient games use only BYOND accounts or guest accounts for the time being.
Will I be able to run my game on portals outside of BYOND, such as Kongregate, Newgrounds, Gamejolt, etc? If so, what's the process like for the BYOND developers... will you guys have to work with the API of different websites one by one, for example? Hopefully it's not too time consuming.

Edit: Can we still package our projects as standalone games like BYOND currently allows with the installer?
In response to Pixel Realms
Pixel Realms wrote:
Will I be able to run my game on portals outside of BYOND, such as Kongregate, Newgrounds, Gamejolt, etc? If so, what's the process like for the BYOND developers... will you guys have to work with the API of different websites one by one, for example? Hopefully it's not too time consuming.

Edit: Can we still package our projects as standalone games like BYOND currently allows with the installer?

To the best of my knowledge, yes.
<iframe src="http://www.byond.com/play/embed/embeded/IP_HERE:PORT_HERE" width="640" height="480"></iframe>


If I am correct, those portals allow embedding as well. So it should be feasible.

Packaging projects as standalones also seems to still work in the BETA. I have an installer as well as one that comes with the preloaded resources.
In response to Xirre
Will we be able to package multiplayer byond games as standalone native applications, while also taking full advantage of the webclient's features?
In response to Pixel Realms
Pixel Realms wrote:
Will I be able to run my game on portals outside of BYOND, such as Kongregate, Newgrounds, Gamejolt, etc? If so, what's the process like for the BYOND developers... will you guys have to work with the API of different websites one by one, for example? Hopefully it's not too time consuming.

That is our intention (and, in fact, is one of the main purposes of a web-based client). Those sites would have to accept iframes, of course. Maybe someone could do the legwork to see what support is available, and what else is needed on our end to make it happen.

Can we still package our projects as standalone games like BYOND currently allows with the installer?

Not at the moment, but I would like to eventually provide a CEF-based exe that could be used for this purpose. Unlike the old byondexe, it would probably be completely detached from BYOND (not using keys).
In general, we'd like to make this as versatile as possible while still hopefully getting a piece of the revenue share (ads and subs) to keep the business (and development) going. Popular games that use the subscription model are really the focus here, and we will do everything we can to work with the developers to come to a mutually beneficial arrangement.
If someone manages to sell a game or app for a mobile device, any consideration for how we won't show the BYOND ads? Seeing an ad after paying .99 won't go over well. Seems like the same problem for sites like Kongregate who make money off of their own ads. Could be a problem not worth considering until someone is ready to launch.

At any point will we be able to customize the WebClient UI you wrap around the game to optionally include/exclude some or all of those interface options?

In response to PopLava
PopLava wrote:
If someone manages to sell a game or app for a mobile device, any consideration for how we won't show the BYOND ads? Seeing an ad after paying .99 won't go over well. Seems like the same problem for sites like Kongregate who make money off of their own ads. Could be a problem not worth considering until someone is ready to launch.

It's probably the kind of thing we'd think about closer to launch, yeah.

At any point will we be able to customize the WebClient UI you wrap around the game to optionally include/exclude some or all of those interface options?

Which UI are you referring to exactly? Do you mean the hotbar control at the bottom?

If so, the hotbar can be extended or overridden, and if you use a .dms skin it doesn't need to be included at all. Any skin with a default pane (which is to say, basically any translated skin) will have status, hotbar, and dpad controls included by default. I don't currently have any options in mind for how they would be disabled without using a .dms skin, but I'm open to ideas.
Is there any intention to explore getting multiple map controls to work with the webclient?
In response to Devourer Of Souls
It hasn't been ruled out for the future, but it isn't a high priority at this time.
Is it possible to get icon data from the server? That would allow developers to create their own map controls.
In response to Sir Lazarus
Yes, actually. You can call browse_rsc() to load files in the dynamic rsc, which then seems to be accessible via HTTP:

[server_url]/[image]

You can use that to load sprites from the game to use in the webclient. This doesn't seem to be very well documented, though...
In response to Sir Lazarus
Several ways.

1) Using the filename as a relative URI works if you've used browse_rsc() for it.
2) If you have the local icon ID used on the webclient (this is accessible via various methods) you can use icon/[id].png to get it.
3) If you have the atom ID (this can be obtained a number of ways, including via output), you can create an img tag with the attribute atom=[id], and then call the control's atomIcon() method to get a data URL for the atom and all its overlays/underlays--though it won't go outside of the image's bounding box, and maptext is not included. It is often advisable to call byond.fillAtomIcons() afterward in case the necessary files haven't all been received yet. I'll have to expand on this in the documentation and maybe make this method more malleable.

Doohl, you raise a good point about documenting the relative URIs.
Would it be possible to release all or most of the webclient's Dart code somewhere? I think it would really help us make more contributions if we could see what was actually going on.
In response to Multiverse7
We have talked about releasing the Dart code at some point, so that's something we're strongly considering.
I think the .skin command and any others should be documented. It seems to be very useful for talking to the webclient from the server.

Commands have always been a vital part of BYOND's interface, but many developers here tend to neglect them due to the obscurity of the syntax. The syntax gets much worse when you are trying to work with commands from the server side, because then you have to worry about having just the right number of backslashes for your quotes and newlines to escape the wrath of the parsers. I think some sort of command translator might be helpful, but that's another issue.
Any plans to allow us to customize the splash screen that loads games, along with link()'s server transfer? As long as projects keep the BYOND logo as the centre piece?
In response to Multiverse7
Multiverse7 wrote:
I think the .skin command and any others should be documented. It seems to be very useful for talking to the webclient from the server.

It is documented, although not very well. I can expand on that.
In response to Pixel Realms
Pixel Realms wrote:
Any plans to allow us to customize the splash screen that loads games, along with link()'s server transfer? As long as projects keep the BYOND logo as the centre piece?

Yes, we want to allow splash customization. Now that we have a way of "pinging" a game for availability (this is what happens when you hit the Play button), it can send back a splash screen in a future iteration. We haven't figured out how we want to set that from the developer's side, but that's on the list.
In response to Lummox JR
Lummox JR wrote:
We haven't figured out how we want to set that from the developer's side, but that's on the list.

If there's doubt, I have a suggestion:

world/GetSplashScreen(ckey, address)

Similar syntax to world/IsBanned. It's supposed to return either null (for the default splash screen), a resource ('path/to/resource.png') or an external file ("path/to/resource.png").

By doing it this way it would be possible for developers to embed client-specific information in the splash screen. Most may leave it alone, but AFAIK it should be just as easy to create a proc for it than it would be to create a variable to store it in.
Page: 1 2 3 4 5 6