I could be wrong but from the earlier screenshot it looks like it just has webclient at the end..
| |
Super Saiyan X wrote:
I recall somebody mentioning this earlier, not sure exactly. > {"<a href="#" onclick="[how 2 topic()]; return false;">test</a>"} The client rewrites those internally so topic calls still work. | |
Tom wrote:
But, that said, so far, we have only ported the client. If this is successful, this introduces a problem, because many of our tools are Windows-only. The server and compiler both work on unix platforms, but there is no interface. More importantly, there isn't a map-editor, which is actually necessary for most games. So aside from being clunky-- "you have to develop your games on Windows but you can deploy them anywhere"-- this is genuinely inconvenient. How do we compile a project on a MAC? I'd assume there is a command line tool based off what you said. I've been working with Objective-C for years and wouldn't mind taking a crack at building a BYOND Mac IDE that can use the HTML5 client. I'm also familiar with how the BYOND map files are structured. | |
Last MAC compile was in the 49x I believe. (Found it, http://www.byond.com/download/build/479/ )
Tom posted recently that they'd look into the possibility of getting a new one out. http://www.byond.com/ forum/?post=1643463&hl=MAC#comment11407968 | |
Super Saiyan X wrote:
I recall somebody mentioning this earlier, not sure exactly. Roughly, yes, we'll wrap in JS. We rewrite the links in the output control, and the browser sends some scripts over to its iframe so it can do the same. Note that things like window.location='byond://nnn' will not work as-is--there's just no good way to set that up. Same deal with dynamically created links: if your script makes them after the fact, they won't get converted. However the iframe for any browser will have a byond.topic() call you can make that should accomplish what you need it to, so any games using advanced JS will want to be prepared for that kind of thing. | |
I have three questions about this change:
1. As I understand this, DreamDaemon will run its own web server on the same port that normal connections run as? 2. Would it be possible to run the web server component on port 80 rather than port 8080 used in your screenshot? 3. If this is the case, would it be possible to run any Javascript on the client side without any restrictions? i.e., document.domain can be altered? What I'm getting at: it will be possible to host a game on play.mygame.com and alter document.domain to mygame.com thereby allowing me to access the game from my website, correct? | |
Incidentally, there was talk of releasing this by the end of this week, but there hasn't been any update on this. Is there a delay, or is the plan to release on Sunday?
I'm sorry if I'm giving undue pressure, I'm considering to develop a game with this system and I'd like to get all my facts straight first. | |
Infnn wrote:
1. As I understand this, DreamDaemon will run its own web server on the same port that normal connections run as? Correct. 2. Would it be possible to run the web server component on port 80 rather than port 8080 used in your screenshot? The screenshot is a little misleading; that was a test running in Dartium, which runs a little virtual server for us so we can test things in the Dart debugger. The actual game in this case was hosted on a different port. You can host on any port. 3. If this is the case, would it be possible to run any Javascript on the client side without any restrictions? i.e., document.domain can be altered? I don't recall document.domain being alterable. But you can supply your own JS code for the game, and your own controls which are defined via JS. What I'm getting at: it will be possible to host a game on play.mygame.com and alter document.domain to mygame.com thereby allowing me to access the game from my website, correct? Ah, that kind of change to document.domain. While you could do that, there wouldn't be a ton of point to it because of how things will be setup. We're planning to allow hosting games on other websites, with a means to go through us to get login info. We're still working that stuff out but it's all in the works. Document.domain shouldn't need to be altered for anything. | |
Yut Put wrote:
Just posting a picture of Footrace required Lummox to adress a couple of issues that otherwise caused the game to not function. I'm sure there are a lot of other kinks to be worked out before release. Because of seamless integration, nothing's stopping you from starting development now! That's being a bit disingenuous considering we don't even know the syntax expected, the exact format everything will take, the way everything will be drawn in reality vs expected, what bugs or shortcomings will need to be worked around, or a host of other details. Not that I'm pressuring for the release of such details or the whole update. | |
Lummox JR wrote:
Ah, that kind of change to document.domain. While you could do that, there wouldn't be a ton of point to it because of how things will be setup. So although there's going to be an HTML5 client the use of Javascript is going to be restricted...? What is the extent of these restrictions? What about putting the game in an iframe and polling the state of the game + sending commands to the game from the parent window, would such a thing be possible? If I'm reading between the lines it's not going to be possible to do that, presumably to hide the proprietary client-side stuff. How much control does the developer get? Is it open to the point where anything that the browser would normally allow is permitted, or are things locked down tight to prevent interaction with the game from outside processes / other frames? | |
Lummox JR wrote:
Super Saiyan X wrote: So, would we be able to interact will the server/client from the browser page itself using JS, without it being in the embedded client? I don't have the best example right now, i'll probably update this with something that makes more sense tomorrow. I'm probably askng the same question as infmn. | |
Infnn wrote:
So although there's going to be an HTML5 client the use of Javascript is going to be restricted...? What I mean is I don't think in JS you can change document.domain except to shorten it to a simpler version of the same domain, e.g. play.mygame.com to mygame.com. But I could be wrong on that. Anyway it's moot since I don't think document.domain will need to enter the picture at any point. What about putting the game in an iframe and polling the state of the game + sending commands to the game from the parent window, would such a thing be possible? If I'm reading between the lines it's not going to be possible to do that, presumably to hide the proprietary client-side stuff. We're actually shooting for an open-source approach on the client-side stuff. How much control does the developer get? Is it open to the point where anything that the browser would normally allow is permitted, or are things locked down tight to prevent interaction with the game from outside processes / other frames? Basically the former. It's pretty wide open and extensible. | |
I'm glad to hear that it'll be possible to play with the client in that manner.
Lummox JR wrote: What I mean is I don't think in JS you can change document.domain except to shorten it to a simpler version of the same domain, e.g. play.mygame.com to mygame.com. That's true, hence why I mentioned reducing "play.mygame.com" to "mygame.com". You would reduce "www.mygame.com" to "mygame.com" as well. Anyway it's moot since I don't think document.domain will need to enter the picture at any point. I don't understand this. There is no way to get an approach like the one I've suggested working without the use of document.domain... right? Other than putting a web server between the game and proxying requests to the same domain, but that may present significant issues with performance. | |
You guys really need to clarify what you are trying to do here. If the idea is to put the game on a website frame and have it interact with stuff outside that frame, that is probably a pain in the ass. However, it really shouldn't be necessary since you can define the entire game (including traditional html) within its own frame, or else you can always use a remote db that both the game and external website components can communicate with.
To be clear, our intent is to provide a url on byond.com that wraps around the actual game url. So you would have something like http://play.byond.com/[mygame] and that would redirect to http://[server]:[port]/[credentials] with the login credentials being done on our end upon connection (user could also sign up, guest login, etc here). You could link to the byond.com url to play the game on our site, or embed it to put it on a social network or your own site. So it's more like an embedded youtube url than an infrastructure to interface with existing websites. | |
Zaltron wrote:
Tom wrote: We'll get a build of the compiler and server before it is out of beta. The standalone client will be written with CEF so it should work on all supported platforms (which currently include the Mac). As I noted earlier, I think it would be best if the dev tools themselves were done in DM to be portable and most accessible. This would probably be a community project once we officially made the DMI and DMM read/write routine a part of the language.. | |
Tom wrote:
To be clear, our intent is to provide a url on byond.com that wraps around the actual game url. So you would have something like http://play.byond.com/[mygame] and that would redirect to http://[server]:[port]/[credentials] with the login credentials being done on our end upon connection (user could also sign up, guest login, etc here). You could link to the byond.com url to play the game on our site, or embed it to put it on a social network or your own site. So it's more like an embedded youtube url than an infrastructure to interface with existing websites. The thing about that...Youtube's HTML5 player (with also uses an iFrame) has an associated API that lets you interact with the embedded player. I think that uses window.postMessage()...that's probably not too relevant to this, though. What I was thinking is that, it'd just be really cool to build a webpage that could interact with the client of any game embedded in it, rather than that being built into the interface of the game itself. The developer of the game would choose to provide hooks to the game or not. some sort of custom API-ish stuff that people could do. I dunno. | |
Show of hands who actually read all of this?
| |
 | |
Super Saiyan X wrote:
Tom wrote: postMessage() would accomplish this nicely, given that document.domain of parent and frame are incompatible. Sounds like a good idea for a library, providing the parsing of messages received via postMessage and defining a communication protocol with a parent window. | |
but how would the new client handle the byond:// protocol? Clearly, simply using byond:// as a link will not work, that'll redirect to the browser and launch BYOND.exe if it's registered properly.
Will byond:// protocol URLs be wrapped in Javascript instead? Like, how else would we make topic calls?