Jump to content
  • 0

Discussion about why Intersect could not be used for Web or Mobile


muxebv

Question

Hello everyone,

 

As some of you might already have read in my other topic I am quite new to the Ascensiongamedev community.

I like the  intersect client quite a bit and think it has a lot of potential moving forward. So far we have been able with a group of a few people to prepare quite some comprehensive looks into the engine and despite of a few bugs running into an great experience.

 

However its also unfortunate that I read a lot about whether it would or wouldnt be possible to use this in the web browser because its used on C#. 

There are in my opinion a few discuss able topics were anyone could decide whether it is possible or not but hopefully with an brainstorming mindset and collaborative consideration to improving the possibilities of Intersect were possible whether this is within or out of the box.

 

The first options I have looked into were a few old school methods that I thougt might would run into some possibilities I ran into a few topics that did not state that it was impossible but spoke with a few modern and classic developers that did claim that it would by far not be the best solution to consider the first few options. Let me share what we have came up with.

 

Option 1: Find a way to convert it from C# to C++ and from there find a way to use emscripten to convert it to a webassembly. This is when I still thougt it was c++ based instead of C#.  (This option would have been "Pragmatic compiling of C++ to WebAssembly" but seems to not going to be an considerable option at all.) Like I mentioned at first I thougt the source was on C++ I only included this one based on the fact that I had done a lot of research about it and the fact that ive seen C# to C++ topics via sdks's, libraries or other bootstrapped based solutions or compilers.  

 

Option 2:  Find a way to convert it from C# to either JS which seems to be an doable task in terms of programming but takes according to few devs aprox 2 to 3 weeks of steady focus on the job and obviously knowledge on the procedures. I thougt of a more old school method that sometime works to run certain softwares in Java Applets within the browser. Some might know the MMORPG Game Runescape 2 from 2001 till 2016 was a massive browser game (3D) build in Java with a lot of C#. They rebuilded the engine to C++ in 2016, ive seen some guides, tutorials and topics about converting C# to Java or even an webassembly but off course that requires the actual C# source which I believe are only in the hands of JCSnider. So JCSnider should this be of any use to you by thinking out of the box I hope we are able to figure something out .

I tried to experiment with our own web browser that we have released a few months ago, to avoid thinking im marketing it im not going to mention the name unless receiving permission from a mod/founder to attempt something themself later, Basically our browser has an build in console that can load .exe files inside the web browser we have released. However for some reason Intersect is one of the only tools ever that I havent been able to import in the browser (might be locked via some method, ill approach a few more attempts). When this is the case and there might be a way to get it functional within our own browser then as far from suitable as it still is it would be the first way to support it in a web browser. The goal then would be to convert that particular function from our browser which is build in react Native to support React JS. Then it could be brougth within an weburl with an universal ip solution to load multiple clients for example. (again far out of the box). 

Option 4 that I came accross is to find out more about cshtml5 which claims to be able to do the following

" You can finally build amazing cross-platform web apps using pure standard .NET .C#, and XAML with Visual Studio, as well as compile Silverlight to JavaScript "

if this is the case then perhaps again JCSnider could find a way to make this possible knowing he has the full source.  
 

Another option that I ran accross but it depends alot on the fps and framebuffering that I dont know enough about in regards of Intersec right now is using Game Cloud Servers were the array of the current client/game is being used to then make a javascript website that can ask a webserver for the "pixel data".  This last option should not be prefered it might end up requiring a FEW VPS or VMWare installations if you planning to make a game for the bigger audience. Right now we are looking at the option of making an intersect based game for a bigger audience that is already following us and we are really hesitating about the options moving forward and also the vision and spirit behind the community/network.

 

Anyway this was just to spin off some concepts, ideas, thougt processes and brainstorm triggers I hope anyone here is going to share their knowledge and feedback on it as comprehensive as you wish any contribution to this topic I believe is to be considered valid research towards the future of Intersect.

 

 

Link to comment
Share on other sites

10 answers to this question

Recommended Posts

  • 5

We're not saying that you can't take Intersect's source code and migrate it in various ways to run on Android, IOS, or even in Web. And in the process of developing Intersect I have attempted all 3 at various points in time. [Android, Web]

 

The Intersect Client is written in C#, but only uses libraries that are compatible with Mono (a cross platform .Net framework) so we can have Linux and Mac support. Several technologies exist already that allow C#/Mono code to be cross compiled to web assembly or similar to run in a browser. Unity does that, for example.

 

If you wanted to get Intersect's client running in a browser or on a mobile device in the future you're best bet is migrating the code into a Unity project, and then using Unity to compile for mobile and/or web. Alternatively, MonoGame (which Intersect already uses) offers project templates for mobile devices, and web is in the works.

 

Nothing is as simple as copying some code over and watching it happen though. Here are the early challenges I faced when attempting this task:

 

Unity:

  • All rendering, audio, networking, and input functionality must be re-coded to hook into Unity's systems.
  • Project assets must be imported into a Unity project, a script would be needed to configure the proper settings for each graphic.
  • Shaders would have to be rewritten for Unity.
  • Loading of graphics, and other resources would need to be rewritten for Unity.

 

Unity Web Export:

  • All the Unity challenges above.
  • Server and client would need a new socket system since html5 only supports websockets.
  • Performance in browsers is pathetic.
  • Content size/memory limits which would make games extremely limited, or only allow games to be played in web on high end pcs.

 

Unity Mobile Export:

  • All of the Unity challenges above.
  • Code required to hook into mobile keyboard. (Not easy, or bluetooth keyboard required)
  • Entire UI would need to be redesigned in a mobile friendly way. (Would take forever)
  • Crashes when trying to update ui from networking threads or when networking threads try to check Unity.Time -- lots of function rewrites would be required to get around that. 

 

MonoGame Web:

  • Simply not capable at this time. Their web deploy side of things isn't advanced enough yet.
  • All the same challenges faced under Unity Web Export would surely apply here anyways.

 

MonoGame Mobile:

  • Code required to hook into mobile keyboard. (Not easy, or bluetooth keyboard required)
  • Entire UI would need to be redesigned in a mobile friendly way. (Would take forever)
  • Packaging assets is annoying and difficult.
  • Performance is better than Unity mobile, so that's actually a good thing -- but I believe less devices would be supported (especially on the Android side of things)

 

 

Bottom line:

 

It is possible to get an Intersect client running within a web browser or on a mobile device. I have done both at one point in time. (No, I will not share my work/code in that regard, nor does any of it work anymore anyways.)

 

Getting the Intersect client to run on mobiles/consoles/or within a web browser requires rewrites of major functions for each platform including rendering logic, audio playback, network sockets, ui design, input handling, etc. Make no mistake, the work involved is long and hard. You're effectively rewriting the most complicated portions of the Intersect client which means the skill required to make this happen the same as developing the entire Intersect engine itself.

 

Cross platform support for this community beyond Windows/Mac/Linux is not one of our goals, and that is not something I'd expect to change for a very long time. I'll encourage other developers to tackle this once we're open source, and I will be available to answer questions here on the forum, but beyond that you all are on your own.

 

 

Edit: Obviously a complete client rewrite/port to a native language for your target platform (ie javascript for browser) would result in the best performance at the expense of the longest development time. I don't foresee anyone attempting that anytime soon though. 

Link to comment
Share on other sites

  • 2

I didn't touch on CsHtml5 because I don't think it has any chance of working for Intersect specifically. It could never automatically translate stuff like MonoGame that utilizes OpenGL, and in my opinion you'd be better off rewriting the client from scratch in pure js before attempting that particular option.  

 

Releasing the source early, even under an NDA isn't something I want to get into. We're already super close to the point where we are going to release it to the public anyways. Just a little more patience :)

Link to comment
Share on other sites

  • 1

Well you sure wrote a lot there but i doubt any member of the intersect team will do any of these,but probably someone will take the initiative to do it after source gets released.

 

In details:

1) Hmm maybe.

2) Nop it would probably mean to write it from scratch in js...

3) Making your own browser wont make any difference because still the game developer would have to tell the player to download the browser so why to go to all the trouble of installing a browser instead of simply downloading the game client ?

4) That's some news sounds like a way but probably not like i said so don't keep your hopes unless you are planning to do it your self.

Link to comment
Share on other sites

  • 1

I think that pursuing option 4) might be interesting because

- It doesn't take too much work to retrieve the displaybuffer (No matter how many vertexbuffers you use, you will always end up having a displaybuffer in adressable memory)

- It would allow to write apps that are future proof (NVidia has already made some advances in this field)

 

The step you would have to take would be

1) Remove the output to a frame (for efficiency)

2) Create a set of sockets that send and listen to browser clients

3) Calculate the framebuffers and send them over the sockets

4) listen, recalculate etc...

Link to comment
Share on other sites

  • 1
On 10/3/2019 at 4:14 PM, muxebv said:

 

Hello JcSnider, Oke atleast thank you for responding on this and letting us know a bit more about things, I did do a quick  read on http://www.monogame.net/ and found the following but im sure you already attempted it anyway. Im not sure if its interesting Ive just attached some extra information below for anyone else in the future that want to look at it them self should they decide to go for it.

 

http://www.monogame.net/downloads/

their web demo > http://www.monogame.net/webdemo/ < 

 

I am currenly exploring further to what the options are of gaming cloud servers Ill post more information about that.

 

 

 

That fps though...

Link to comment
Share on other sites

  • 0
37 minutes ago, Devo said:

Well you sure wrote a lot there but i doubt any member of the intersect team will do any of these,but probably someone will take the initiative to do it after source gets released.

 

In details:

1) Hmm maybe.

2) Nop it would probably mean to write it from scratch in js...

3) Making your own browser wont make any difference because still the game developer would have to tell the player to download the browser so why to go to all the trouble of installing a browser instead of simply downloading the game client ?

4) That's some news sounds like a way but probably not like i said so don't keep your hopes unless you are planning to do it your self.

 

Hello Devo, I am very glad to see how fast you are replying. We are already quite far ahead with our own game engine in what we like to achieve for the game and we just found out yesterday about the topic online here in regards of the online capacity. I wanted to enter with a long and founded topic to also properly introduce myself, my point of view and what we have looked in ourselves already as a team.

 

I understand that some are wishful thinking, some might be possible some not. We are willing to "contribute" to the solution whether we will realise the solution or not is off course also not something that we can guarantee but I thougt this spin off was certainly a first nice start.

 

1: Im glad you think option one might be an option ill look further into it and share it back to this thread. After all the more wisdom we share today the more knowledge there will be here tomorrow for the next person that does his/her attempt.

 

2: Yes I also came to this conclusion but Im quite hopefull about the old school java applet possibilities im not 100% done researching that one yet all though we all would agree that that is not how 2020 should approach it if there would be any kind of way to achieve that that even for private servers only due to an issue of not being capable of doing big games it would still be a step forward to not having it possible at all. In the past I have had some experiences with using java to open additional file types to still work in the browser after a bunch of compilations, conversions and, etc. 

 

3: I understand that having the own browser is not the solution because indeed its still a browser. But I also wrote that its react native based and that the technique we used could potentially be rebuilded for "web" (in terms of loading an .exe or other kind of application for windows or mac or linux inside the browser area directly). Then it would no longer be inside the browser of us however but inside the actual web browser anyone uses within the domain that would recreate the frame / ( Emulator if you like to call it that ) to run the client still. This is still something im studying on my end and if it has any potential ill share it here. 

 

4: I am not sure if we are allowed to post links but the url that I came accross was the following: cshtml5.com

 

5: You seemed to have missed point 5 were using game cloud servers that launch consoles with the game loaded in them on vps/dps mechanisms. That one is actually certainly possible but yet to be tested how  good intersect will react on that.

 

6: Is another option someone has just told me I myself have 0% idea about this one because I dont know much about unity but it said if you could find the source code of the unity Player that it might would have a shot. Someone with more knowledge about this one may know how to come accross that. One thing for sure, after today there will be more information, topics and searches towards intersect on mobile or browser and that alone creates more google web pages so more odds of growing towards new developers within this community! 

 

(Off Topic) If we can contribute in some ways here or if you have suggestions or things you think we could be helpfull with also please just let us know.  (Off Topic)

Link to comment
Share on other sites

  • 0
7 hours ago, jcsnider said:

We're not saying that you can't take Intersect's source code and migrate it in various ways to run on Android, IOS, or even in Web. And in the process of developing Intersect I have attempted all 3 at various points in time. [Android, Web]

 

The Intersect Client is written in C#, but only uses libraries that are compatible with Mono (a cross platform .Net framework) so we can have Linux and Mac support. Several technologies exist already that allow C#/Mono code to be cross compiled to web assembly or similar to run in a browser. Unity does that, for example.

 

If you wanted to get Intersect's client running in a browser or on a mobile device in the future you're best bet is migrating the code into a Unity project, and then using Unity to compile for mobile and/or web. Alternatively, MonoGame (which Intersect already uses) offers project templates for mobile devices, and web is in the works.

 

Nothing is as simple as copying some code over and watching it happen though. Here are the early challenges I faced when attempting this task:

 

Unity:

  • All rendering, audio, networking, and input functionality must be re-coded to hook into Unity's systems.
  • Project assets must be imported into a Unity project, a script would be needed to configure the proper settings for each graphic.
  • Shaders would have to be rewritten for Unity.
  • Loading of graphics, and other resources would need to be rewritten for Unity.

 

Unity Web Export:

  • All the Unity challenges above.
  • Server and client would need a new socket system since html5 only supports websockets.
  • Performance in browsers is pathetic.
  • Content size/memory limits which would make games extremely limited, or only allow games to be played in web on high end pcs.

 

Unity Mobile Export:

  • All of the Unity challenges above.
  • Code required to hook into mobile keyboard. (Not easy, or bluetooth keyboard required)
  • Entire UI would need to be redesigned in a mobile friendly way. (Would take forever)
  • Crashes when trying to update ui from networking threads or when networking threads try to check Unity.Time -- lots of function rewrites would be required to get around that. 

 

MonoGame Web:

  • Simply not capable at this time. Their web deploy side of things isn't advanced enough yet.
  • All the same challenges faced under Unity Web Export would surely apply here anyways.

 

MonoGame Mobile:

  • Code required to hook into mobile keyboard. (Not easy, or bluetooth keyboard required)
  • Entire UI would need to be redesigned in a mobile friendly way. (Would take forever)
  • Packaging assets is annoying and difficult.
  • Performance is better than Unity mobile, so that's actually a good thing -- but I believe less devices would be supported (especially on the Android side of things)

 

 

Bottom line:

 

It is possible to get an Intersect client running within a web browser or on a mobile device. I have done both at one point in time. (No, I will not share my work/code in that regard, nor does any of it work anymore anyways.)

 

Getting the Intersect client to run on mobiles/consoles/or within a web browser requires rewrites of major functions for each platform including rendering logic, audio playback, network sockets, ui design, input handling, etc. Make no mistake, the work involved is long and hard. You're effectively rewriting the most complicated portions of the Intersect client which means the skill required to make this happen the same as developing the entire Intersect engine itself.

 

Cross platform support for this community beyond Windows/Mac/Linux is not one of our goals, and that is not something I'd expect to change for a very long time. I'll encourage other developers to tackle this once we're open source, and I will be available to answer questions here on the forum, but beyond that you all are on your own.

 

 

Edit: Obviously a complete client rewrite/port to a native language for your target platform (ie javascript for browser) would result in the best performance at the expense of the longest development time. I don't foresee anyone attempting that anytime soon though. 

 

Hi JcSnider thank you for replying to my topic that as one of the things I was hoping for indeed. 

 

I do understand your point of view but I do think that every developer has his own knowledge, skills and experience in the industry. 

So by creating this topic on its own there is already more information available on your website then there was ever before which is a good thing.

This allows other developers to get in on things and try to figure out the possibilities. Im quite confused why no one has answered on the game cloud server option btw because that one would allow it without any actual recoding just need to figure out the array that loads the game which I guess we cannot see without the source code. Me and my team could attempt something if you would be willing to share the source code in private under an signed NDA with our company MUXE BV (completely up to you off course). 

 

We are very open minded to collaborate with your project and to grow it as a community oriented/sided support party with our own directions of were we believe we want to go with this engine.  We have our own work in progress at the moment experiencing with a variety of things that we are looking at and considering to expand. Including a connection with Blockchain Technology all though will most likely be our first attempt. 

 

At this point in time I will not answer anything about what you mentioned in regards of unity or monogame because it will require more studies from my end to be able to reply to these topics but I did notice that beside the game cloud servers options you also didnt look into another option that I came accross which might be more interesting.

 

http://www.cshtml5.com  <  C# to HTML 5. Let me know if you think if this could be of any use

 

Link to comment
Share on other sites

  • 0
1 hour ago, jcsnider said:

I didn't touch on CsHtml5 because I don't think it has any chance of working for Intersect specifically. It could never automatically translate stuff like MonoGame that utilizes OpenGL, and in my opinion you'd be better off rewriting the client from scratch in pure js before attempting that particular option.  

 

Releasing the source early, even under an NDA isn't something I want to get into. We're already super close to the point where we are going to release it to the public anyways. Just a little more patience :)

 

Hello JcSnider, Oke atleast thank you for responding on this and letting us know a bit more about things, I did do a quick  read on http://www.monogame.net/ and found the following but im sure you already attempted it anyway. Im not sure if its interesting Ive just attached some extra information below for anyone else in the future that want to look at it them self should they decide to go for it.

 

http://www.monogame.net/downloads/

their web demo > http://www.monogame.net/webdemo/ < 

 

I am currenly exploring further to what the options are of gaming cloud servers Ill post more information about that.

 

 

Link to comment
Share on other sites

  • 0
21 hours ago, Devo said:

 

That fps though...

We continued our study and we arent agreeing on the above yet. Basically theres an history in computer development and theres much more then our current generations sometime know as a solution. Basically the option we are looking in is www.jsil.org or www.pcjs.org as 2 additional alternative solutions that might not make it perfect but atleast makes it possible. 

 

We will soon update the community here once we have achieved our first web based intersect output. 

Link to comment
Share on other sites

×
×
  • Create New...