Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Fuzzy Avatars Solved! Please re-upload your avatar if it was fuzzy!

New Update: Making a Game Out of the Web

2»

Comments

  • KappenWizKappenWiz Pittsburgh, PAPosts: 162Member

    Did anyone read the sidebar:

    This is the nitty-gritty stuff, for the potential modders and hackers out there. Here be programmer-speak; you have been warned! Also, please keep in mind that right now this is a general plan rather than a shipping product, and there’s still substantial engineering work to do with this feature on our end. You should expect that things will change as we shake down the implementation. It’s one of the first pieces of infrastructure we’ll be rocking on if we fund, though.

    First, don’t expect to make XMLHttpRequests directly from your own JavaScript if you want to run within the game. We plan to implement a lightweight JavaScript library to act as an intermediary. When running standalone on the web, this library will still speak AJAX and WebSockets while providing an OAuth-style token for user authentication. If you’re running on a server, you’ll of course be able to roll your own through those same public APIs in the language of your choice.

    On the other hand, when your (or our) code is running in the game and using that library, for performance reasons some calls will be redirected into the client rather than actually making an HTTP request. We’ll encourage — and very likely enforce — that everyone use that library rather than going directly to our server. That will ensure UI mods can be as responsive as possible by using data the client has already cached locally, while still preserving the ability to work standalone. This will be an evolving process of tuning, and we may move the implementation behind a particular query back and forth between the two. However, this is the programming team’s own dogfood, so we promise to make it tasty.

    There is a strong possibility that when running in-game, UI mods will be limited so they can’t talk to any servers other than our own (and via our library at that). When code is running in the wild we obviously won’t be able to enforce that limitation, so the token you get will instead provide less access than going through a logged-in and trusted client. Initially, expect a binary system: You’ll either have full access to a character or you’ll have the ability to send data to the outside world, but not both at the same time. We want to make finer-grained controls happen eventually, but “eventually” may not happen in version 1.0 because working through the implications of every possible combination of mix-and-match permissions is not something that can or should be rushed. As a first step the “limited information but with outside access” may become an alternate mode when running in the client.

    The “limited” mode will still include nearly all social and economic data, though. What we’re unlikely to provide when code has access to outside servers is realtime, detailed combat data, exact locations, and similar things that pertain to the action immediately occurring in the game world. We want to actively prevent anything resembling a “global shared hivemind” radar/GPS overlay, so expect information with immediate tactical value to be aggregated, summarized, and deliberately lagged when viewed from the outside. There’s a balance there — we do understand that players will talk on IM and forums outside of the game, so we don’t want to provide less information than they already share via good old-fashioned community. However, please bear with us if we initially err on the side of caution and only incrementally open that end of things up.

    Finally, the usual sort of constraints about rate limits and throttling by IP and account will be in play here. Don’t destroy the server; it’s where you keep your stuff.

    Curious, because the first thing I thought was...HTML and Java? sounds bloated.  But he seems to be on that.

     

    EDIT: Programmers are weird...dogfooding? image

     

  • Corinthian-XCorinthian-X Horn Lake, MSPosts: 86Member
    Originally posted by meddyck
    Originally posted by Plastic-Metal
    Originally posted by meddyck
    How about giving us some updates about the things that got us excited about the game in the first place: a 3 realm RvR MMO with no PvE with different races and classes in each realm and progression through RvR? I look forward to the Hib model video later today.

    IMO the reason CSE are providing technical release information is due to the amount of people running around claiming CU is nothing more than an idea on paper.

    Showing 10,000 instances of an iPad character model running around on a laptop or a video of a dev describing the uber web ui doesn't exactly disprove that.

    The video with the 10k characters in it was proof of concept. It was meant to show that this is what  they are focusing on and the architechture he's building can do what they want it to.

  • skyexileskyexile MelbournePosts: 692Member

    This is gonna be great, im gonna import all my scripts over from Planetside 2, cant wait. kids are gonna be so mad.

    derp.

    SKYeXile
    TRF - GM - GW2, PS2, WAR, AION, Rift, WoW, WOT....etc...
    Future Crew - High Council. Planetside 1 & 2.

  • burfoburfo Blue Mounds, WIPosts: 46Member
    I like the idea they've presented.  Let's see how it pans out.

    Burfo
    image

  • skyexileskyexile MelbournePosts: 692Member

    um i was concerned about this, but a guildie of mine who is a game developer assures me its a good choice and that people like epic games are already on the case:


    http://techreport.com/news/24586/epic-html5-unreal-engine-4-upgrades-the-web-to-a-platform

    SKYeXile
    TRF - GM - GW2, PS2, WAR, AION, Rift, WoW, WOT....etc...
    Future Crew - High Council. Planetside 1 & 2.

  • BetaguyBetaguy Halifax, NSPosts: 2,590Member
    Originally posted by Oldskoo
    Our friends over at  City State Entertainment certainly aren't afraid of taking risks. I am impressed with their vision and willingness to try something new and innovative. This could be a game changer as far as UI's are concerned in the mmo industry if they pull this off. 

    I too think this is a great new innovative idea. Can't wait to get my hands on this title and take it for a spin.

    image

  • CSE_AndrewCSE_Andrew Fairfax, VAPosts: 3Member
    Originally posted by taus01

    No, it is a terrible idea. HTML and JS are shit for client server applications that need performance like an MMO. No matter how much you optimize it. The overhead of JS to get just a small amount of data is ridiculous to a dedicated client server protocol or raw socket communication.

    Its a bad idea no mater how good you are.

     

    From what you're saying, it sounds like you think we're making the ENTIRE game out of the web. Let's make this clear: We're building a standalone 3D client. It will be written in C++, and render to the screen with DirectX. It will speak a custom, compressed binary protocol with our servers to perform low-latency updates to its world state. Period. All of that is exactly what you would expect from a traditional, high-performance, native game.

    The part that will be web-based is the user interface. Now, as the lead client engineer for WAR, I had a lot of oversight on WAR's UI code. Whether you like the game as a whole, I don't think anyone can say "OMG THE UI WAS SO LAGGY". What you may not have known is that Warhammer Online's entire UI was built in another scripting language called Lua -- mostly because World of Warcraft used the very same UI scripting language, and we wanted to attract WoW modders to WAR.

    The performance of JavaScript engines in 2013 absolutely blows away the performance of our 2008 Lua engine. It's not a contest. Take a look at this comparison, as just one example: JavaScript is roughly 11x faster than Lua, on average, and that's comparing against the Lua engine of 2013 rather than the Lua of 2008.

    Maybe your concern is that making roundtrips to the server for AJAX calls will be a slowdown. I'll quote directly, for anyone who watched the video but didn't read the accompanying article:

    First, don’t expect to make XMLHttpRequests directly from your own JavaScript if you want to run within the game. We plan to implement a lightweight JavaScript library to act as an intermediary. When running standalone on the web, this library will still speak AJAX and WebSockets...

    On the other hand, when your (or our) code is running in the game and using that library, for performance reasons some calls will be redirected into the client rather than actually making an HTTP request. We’ll encourage — and very likely enforce — that everyone use that library rather than going directly to our server. That will ensure UI mods can be as responsive as possible by using data the client has already cached locally, while still preserving the ability to work standalone.

    Or maybe you're concerned about rendering and layout performance, rather than the performance of the scripting engine? I'm not. I know where the clock cycles were going on WAR's UI, and I only wish we'd been able to implement some of the optimizations that Chromium and Gecko can give us out of the box. (Really; I've looked at their source code!) There's so much optimization that these teams have spent so many years on; we'd be foolish not to take advantage of that.

    Now, I won't argue, there are some crappy, badly-performing web pages out there. There are also some crappy, badly performing C++, C#, and Java programs out there as well. I'll admit, there are MORE badly-performing web pages out there, but I attribute this to the fact that putting up a web page is so much more accessible than writing in C that people who aren't the strongest programmers have the opportunity to make things. (That's actually part of the reason I want to do this -- by making it accessible to more people, we'll get more stuff created. There will undoubtedly be some bad mods made by bad coders, but you don't have to install them.) On the other hand, there are some really good and responsive web-based interfaces out there. I use chat programs embedded in the webpages of both Gmail and Facebook, so I'm pretty sure you can build an in-game chat window with JS. I manage multiple accounts with Tweetdeck, which has a lot of UI yet runs as a Chrome app. Heck, I even wrote and laid out the article using a wordprocessor that lives on a web page.

    I use these things not because I have to, but because they're some of the best-in-class stuff out there. Not only is this going to work, it's going to be easier and faster than the other MMORPG UI systems I've already done.

  • Corinthian-XCorinthian-X Horn Lake, MSPosts: 86Member
    Originally posted by CSE_Andrew
    Originally posted by taus01

    No, it is a terrible idea. HTML and JS are shit for client server applications that need performance like an MMO. No matter how much you optimize it. The overhead of JS to get just a small amount of data is ridiculous to a dedicated client server protocol or raw socket communication.

    Its a bad idea no mater how good you are.

     

    From what you're saying, it sounds like you think we're making the ENTIRE game out of the web. Let's make this clear: We're building a standalone 3D client. It will be written in C++, and render to the screen with DirectX. It will speak a custom, compressed binary protocol with our servers to perform low-latency updates to its world state. Period. All of that is exactly what you would expect from a traditional, high-performance, native game.

    The part that will be web-based is the user interface. Now, as the lead client engineer for WAR, I had a lot of oversight on WAR's UI code. Whether you like the game as a whole, I don't think anyone can say "OMG THE UI WAS SO LAGGY". What you may not have known is that Warhammer Online's entire UI was built in another scripting language called Lua -- mostly because World of Warcraft used the very same UI scripting language, and we wanted to attract WoW modders to WAR.

    The performance of JavaScript engines in 2013 absolutely blows away the performance of our 2008 Lua engine. It's not a contest. Take a look at this comparison, as just one example: JavaScript is roughly 11x faster than Lua, on average, and that's comparing against the Lua engine of 2013 rather than the Lua of 2008.

    Maybe your concern is that making roundtrips to the server for AJAX calls will be a slowdown. I'll quote directly, for anyone who watched the video but didn't read the accompanying article:

    First, don’t expect to make XMLHttpRequests directly from your own JavaScript if you want to run within the game. We plan to implement a lightweight JavaScript library to act as an intermediary. When running standalone on the web, this library will still speak AJAX and WebSockets...

    On the other hand, when your (or our) code is running in the game and using that library, for performance reasons some calls will be redirected into the client rather than actually making an HTTP request. We’ll encourage — and very likely enforce — that everyone use that library rather than going directly to our server. That will ensure UI mods can be as responsive as possible by using data the client has already cached locally, while still preserving the ability to work standalone.

    Or maybe you're concerned about rendering and layout performance, rather than the performance of the scripting engine? I'm not. I know where the clock cycles were going on WAR's UI, and I only wish we'd been able to implement some of the optimizations that Chromium and Gecko can give us out of the box. (Really; I've looked at their source code!) There's so much optimization that these teams have spent so many years on; we'd be foolish not to take advantage of that.

    Now, I won't argue, there are some crappy, badly-performing web pages out there. There are also some crappy, badly performing C++, C#, and Java programs out there as well. I'll admit, there are MORE badly-performing web pages out there, but I attribute this to the fact that putting up a web page is so much more accessible than writing in C that people who aren't the strongest programmers have the opportunity to make things. (That's actually part of the reason I want to do this -- by making it accessible to more people, we'll get more stuff created. There will undoubtedly be some bad mods made by bad coders, but you don't have to install them.) On the other hand, there are some really good and responsive web-based interfaces out there. I use chat programs embedded in the webpages of both Gmail and Facebook, so I'm pretty sure you can build an in-game chat window with JS. I manage multiple accounts with Tweetdeck, which has a lot of UI yet runs as a Chrome app. Heck, I even wrote and laid out the article using a wordprocessor that lives on a web page.

    I use these things not because I have to, but because they're some of the best-in-class stuff out there. Not only is this going to work, it's going to be easier and faster than the other MMORPG UI systems I've already done.

    Thanks Andrew, I was hoping you would chime in. Though I really doubt that will satisfy him, as he seems to be all-knowing and quick on the trigger to denigrate everything you guys post.

  • JoeShmoe75JoeShmoe75 Bradenton, FLPosts: 20Member
    I dont really know alot about this technical mumbo-jumbo, but Andrew seems to know what hes doing. I've only played WAR way back at first release, but I dont remember any dislikes or problems with that UI. Didn't play Skyrim to see what hes done there, but I have faith. TBH at this stage what more can you have.
  • ayanamijayanamij Atlanta, GAPosts: 2Member
    I came across this post from the CU IRC chat and I just wanted to throw in this ... where is this idea that client-side JS is slow? It isn't. It's incredibly fast. Can AJAX requests be slow? Sure. But that isn't because the client isn't performing. And besides, since when are we talking about writing the core client in JS anyhow? As has been stated before, the rendering engine and core functionality has its own client anyhow.
  • BurgundusBurgundus Evans, GAPosts: 23Member

    Thanks for the note Andrew.  I've always liked how Eve in particular let you do things from the web, and even having a browser in game.  I think it's a great idea. 

    Burgy

  • TamanousTamanous Edmonton, ABPosts: 2,126Member Uncommon
    Originally posted by ayanamij
    I came across this post from the CU IRC chat and I just wanted to throw in this ... where is this idea that client-side JS is slow? It isn't. It's incredibly fast. Can AJAX requests be slow? Sure. But that isn't because the client isn't performing. And besides, since when are we talking about writing the core client in JS anyhow? As has been stated before, the rendering engine and core functionality has its own client anyhow.

    Ya I can't figure out either how people thought this update affected the core client. It clearly mentioned it affected UI planning only and not the game engine. Perhaps the forum warriors geeks should concentrate on understanding verbal and written communication over learning code. 

     

    It's like I tell people at work: I am a client (as in employees) side analyst. There are back room, server side and wiring closet techs too but I have my job because I have a personality and can actually talk and listen to people. :)

    You stay sassy!

  • Plastic-MetalPlastic-Metal Highland Heights, KYPosts: 405Member

    Thanks for posting, Andrew.  [mod edit]

    Keep up the good work, buddy.

    My name is Plastic-Metal and my name is an oxymoron.

    image

  • OldskooOldskoo Minneapolis, MNPosts: 189Member
    Thanks for your thoughts Andrew. That was pretty cool. 

    image

  • taus01taus01 MunichPosts: 1,352Member
    Originally posted by CSE_Andrew
    Originally posted by taus01

    No, it is a terrible idea. HTML and JS are shit for client server applications that need performance like an MMO. No matter how much you optimize it. The overhead of JS to get just a small amount of data is ridiculous to a dedicated client server protocol or raw socket communication.

    Its a bad idea no mater how good you are.

     

    From what you're saying, it sounds like you think we're making the ENTIRE game out of the web. Let's make this clear: We're building a standalone 3D client. It will be written in C++, and render to the screen with DirectX. It will speak a custom, compressed binary protocol with our servers to perform low-latency updates to its world state. Period. All of that is exactly what you would expect from a traditional, high-performance, native game.

    The part that will be web-based is the user interface. Now, as the lead client engineer for WAR, I had a lot of oversight on WAR's UI code. Whether you like the game as a whole, I don't think anyone can say "OMG THE UI WAS SO LAGGY". What you may not have known is that Warhammer Online's entire UI was built in another scripting language called Lua -- mostly because World of Warcraft used the very same UI scripting language, and we wanted to attract WoW modders to WAR.

    The performance of JavaScript engines in 2013 absolutely blows away the performance of our 2008 Lua engine. It's not a contest. Take a look at this comparison, as just one example: JavaScript is roughly 11x faster than Lua, on average, and that's comparing against the Lua engine of 2013 rather than the Lua of 2008.

    Maybe your concern is that making roundtrips to the server for AJAX calls will be a slowdown. I'll quote directly, for anyone who watched the video but didn't read the accompanying article:

    First, don’t expect to make XMLHttpRequests directly from your own JavaScript if you want to run within the game. We plan to implement a lightweight JavaScript library to act as an intermediary. When running standalone on the web, this library will still speak AJAX and WebSockets...

    On the other hand, when your (or our) code is running in the game and using that library, for performance reasons some calls will be redirected into the client rather than actually making an HTTP request. We’ll encourage — and very likely enforce — that everyone use that library rather than going directly to our server. That will ensure UI mods can be as responsive as possible by using data the client has already cached locally, while still preserving the ability to work standalone.

    Or maybe you're concerned about rendering and layout performance, rather than the performance of the scripting engine? I'm not. I know where the clock cycles were going on WAR's UI, and I only wish we'd been able to implement some of the optimizations that Chromium and Gecko can give us out of the box. (Really; I've looked at their source code!) There's so much optimization that these teams have spent so many years on; we'd be foolish not to take advantage of that.

    Now, I won't argue, there are some crappy, badly-performing web pages out there. There are also some crappy, badly performing C++, C#, and Java programs out there as well. I'll admit, there are MORE badly-performing web pages out there, but I attribute this to the fact that putting up a web page is so much more accessible than writing in C that people who aren't the strongest programmers have the opportunity to make things. (That's actually part of the reason I want to do this -- by making it accessible to more people, we'll get more stuff created. There will undoubtedly be some bad mods made by bad coders, but you don't have to install them.) On the other hand, there are some really good and responsive web-based interfaces out there. I use chat programs embedded in the webpages of both Gmail and Facebook, so I'm pretty sure you can build an in-game chat window with JS. I manage multiple accounts with Tweetdeck, which has a lot of UI yet runs as a Chrome app. Heck, I even wrote and laid out the article using a wordprocessor that lives on a web page.

    I use these things not because I have to, but because they're some of the best-in-class stuff out there. Not only is this going to work, it's going to be easier and faster than the other MMORPG UI systems I've already done.

    Thanks for the lengthy explanation. I will look forward to how this pans out. Most engine use some form of script like Lua, as someone that worked with both Unreal and CryEngine i am very familiar with them. I just had very bad experiences with HTML based UI. Not saying it is not possible, Guildwars is using it, i was merely concerend about the performance.

    Thanks again for the information.

    PS: I would appreciate it if the fans of this game would back off calling me a troll. I know you people like this game and take it personal if someone says something bad about it but that does not give you the right to insult people that have a different opinion.

    "Give players systems and tools instead of rails and rules"

    image
  • KappenWizKappenWiz Pittsburgh, PAPosts: 162Member
    Bunch of stuff from Andrew...
     

    Thanks for the lengthy explanation. I will look forward to how this pans out. Most engine use some form of script like Lua, as someone that worked with both Unreal and CryEngine i am very familiar with them. I just had very bad experiences with HTML based UI. Not saying it is not possible, Guildwars is using it, i was merely concerend about the performance.

    Thanks again for the information.

    PS: I would appreciate it if the fans of this game would back off calling me a troll. I know you people like this game and take it personal if someone says something bad about it but that does not give you the right to insult people that have a different opinion.

    Kudos to you for showing back up. The people here are a little ecstatic right now, so kinda giddy and therefore a little charged up. You did kind of come in here saying this was a horrible idea, silly, and it will be kind of fun to watch it fall on it's a$$, so they reacted.

    Anyway, welcome, big ups to you for responding and hope you keep an eye on the project. If nothing else, Andrew has impressed the hell out of me this week with his knowledge, passion, and grounded personality. It will be fun to watch the team develop this game with him and learn a thing or two, so it will be worth it to stick around for that, if nothing else.

     

  • BowbowDAoCBowbowDAoC Granby, QCPosts: 470Member

    I'm not a tech guy at all, and even worst when i have read techincal stuff in english :P

    But i have one question ... WIll this make it easier , harder, or wont change a thing on how people can create cheats / radar etc ?

    i think it is something thats need to be thought about early, would hate to have lots of people with radar and cheats :/

     

    image

    Bowbow (kob hunter) Infecto (kob cave shammy) and Thurka (troll warrior) on Merlin/Midgard DAoC
    Thurka on WAR

    image

  • taus01taus01 MunichPosts: 1,352Member
    Originally posted by kappenwiz
    Bunch of stuff from Andrew...
     

    Thanks for the lengthy explanation. I will look forward to how this pans out. Most engine use some form of script like Lua, as someone that worked with both Unreal and CryEngine i am very familiar with them. I just had very bad experiences with HTML based UI. Not saying it is not possible, Guildwars is using it, i was merely concerend about the performance.

    Thanks again for the information.

    PS: I would appreciate it if the fans of this game would back off calling me a troll. I know you people like this game and take it personal if someone says something bad about it but that does not give you the right to insult people that have a different opinion.

    Kudos to you for showing back up. The people here are a little ecstatic right now, so kinda giddy and therefore a little charged up. You did kind of come in here saying this was a horrible idea, silly, and it will be kind of fun to watch it fall on it's a$$, so they reacted.

    Anyway, welcome, big ups to you for responding and hope you keep an eye on the project. If nothing else, Andrew has impressed the hell out of me this week with his knowledge, passion, and grounded personality. It will be fun to watch the team develop this game with him and learn a thing or two, so it will be worth it to stick around for that, if nothing else.

     

    I still think it is a terrible idea, but thats life, people have different opinions. I am a big fan of DAOC, an old school gamer and happy to see many projects including this one trying to go back to the roots and trying to make a difference in the overall mediocre pool of games released in the last 5+ years. It does not mean hoever that i don't speak my mind if i think something is a bad idea. I know i sometimes come off a bit strong in my words and i apologize for it.

    "Give players systems and tools instead of rails and rules"

    image
  • tleartlear Toronto, ONPosts: 142Member
    Interesting I was always under impression that LUA was hands down fastest for these things. I write a lot of JS both on client and in nodejs. It is a fun and really good language. Just IMO, now if you were going to this this in Ruby I would be concerned..

    Also crappy mods are gona be a problem, spaghetti jquery maining dom.. etc as will supporting gazillion client side frameworks. Emberjs does not work waaaaa!

    Do you guys have someone who really lives in client side js world? Because that its own thing and I wonder if dealing with all the issues it will present is worth it. Still I am excited to see js used
  • RawcRawc Carpinteria, CAPosts: 2Member

    I know this is a couple days late but I was talking with a buddy and another issue I haven't hear brought up occurred to me. I read that the issue of hacks and radar will be addressed, but what about macro systems that simply the game and add a huge advantage. For those that have not seen this issue in other games I will describe it using RIFT as an example.

      In RIFT, there were different abilities on short re-use timers many of which were only usable if another action occurred (i.e. you dodge, someone dodges you, you miss, block, etc). We were able to put macros together that would put as many abilities on one key as you liked and prioritize them. If an abilities was on cooldown or the pre-requisite action had not occurred it would skip down the list until it reached the next available ability. This took a game that was technical and gave better players a slight advantage and made it mandatory to run these macros to compete at a high level. It made the game so simple it was boring and was a game killer for many.

      Will there be a way to keep these out of the game and require players to use skill? Thank you for any response.

2»
Sign In or Register to comment.