BIG NEWS: New Line Rider version "Line Online" with integrated website in development

Back in September, Conundrumer contacted me about a class he was taking in college/university called Web App Development. They could choose anything they wanted to build as a team project for the class. He wanted to build Line Rider.

Three months later, I am excited to announce that development is underway and I am getting excited. This is both a new Line Rider website, AND a new Line Rider version, Line Online. Here are some things in the works:

• Share tracks instantly via an invite function built into the web app
  
• Live collaborating. Works similar to Google Docs in that you can both edit the same track at the same time and chat within the track page itself. The original creator controls who is invited to see and/or work on the track.
  
• Version Control, which is basically undo/redo on steroids. Pick up from exactly where you left off after a crash without ever worrying about saving.
  
• Video export made simple and easy.
  
• Integrated forum discussion board linked to the web app, using discourse software
  
• Beautiful website design! In my opinion, anyway.
  

Conundrumer is currently busy with finals (which include development of this) so he may not be able to be here to respond to everything, but I am in touch with him so I can be his spokesperson. There is a demo/mockup site I have access to but it is very unfinished and not secure at all so we are not comfortable sharing it with all of you yet. But here are some screenshots:
https://imgur.com/a/6FAY0

The site design framework is there, the live editing is there and works beautifully, the biggest thing that is missing is playback and physics, which conun is working on right now. (Bosh is not actually present in the version yet, lol)

I'll keep you all updated!

FIRST
I'm sorry for that.
Now, I had a DREAM about this and decided not to share it so as not to just be ranting about this unattainable idea.
Now it's all too real.

ESPECIALLy the live editing. That was what excited me the most, because I was JUST about to make that suggestion and ask how feasible it might be.

I still dislike discourse

TheRevTastic wrote:I still dislike discourse

it's not final yet

hit me with everything you got

FYI I'm making the code open-source on GitHub around next week. For those of you who are adept at Javascript (everything's in Javascript), you'll be able to contribute.

Which build are you basing this off of? Open source is awesome too. I'll be wanting to help with this. Everyone here knows how much if a hard on I get with version development.

He is making the whole thing from scratch.

Details on how it will differ from previous Line Rider builds are still being worked out.

Imo new physics aren't a problem as long as they're reasonable and g-wells are still possible.

^Coming from someone who probably doesn't know the scope of his request

HG42 wrote:Imo new physics aren't a problem as long as they're reasonable and g-wells are still possible.

^Coming from someone who probably doesn't know the scope of his request

You really do not have the slightest clue as to the scope, no. but I still love you
I'm new and have an extreme prejudice against changed physics. And in fact, it would be more than possible to basically translate the code which is responsible for the physics in the flash version and port it to Javascript and thus retain perfectly accurate physics and interface. The coding would also allow us mere mortals (like me) or more inept coders to customize the game a little bit or add features to their likings.

At that,
THIS WILL DRAW LOADS OF USERS.

This is such an exciting development. My brother and I have been discussing and he says this would be loads of fun for him to get into the game more (he watches you guys [and myself] in adoration because this game seems so cool to him).

I am going to be that guy that asks if tracks from the offline version will be somehow compatible with this new fancy build?

I've spoken with mhenr18 in the past and he said that it should be possible to reconstruct the trigonometric functions that Actionscript uses by analyzing the compiled assembly code and replicating it in Javascript. When he was working on a beta2 compatible version, he took an easy way and directly embedded the physics engine in the application using some nodejs virtual server trickery, which isn't possible in the browser. There's also the option of transpiling the Actionscript code to assembly to Javascript, but I haven't looked into that.

The only thing that concerns me for any deterministic physics engine is making sure that floating point operations are rounded consistently across all platforms, but from past months of research and testing, this doesn't appear to be an issue (maybe my test isn't good enough): www.tinyurl.com/IsMyBrowserFPCompliant

Whatever the option, I won't be the one porting the beta2 physics engine, but I'll define the interface of the physics engine and help make tests for beta2 conformance. mhenr18 already has a utility that parses beta2 tracks from .sol files so I'll define the interface of scene objects and leave the porting implementation to someone else as well.

For those who are curious: I'm making my own physics engine because I'm planning to make other sandbox games that will be able to support huge numbers of entities, hopefully only limited by your graphics card.

rabid squirrel wrote:

TheRevTastic wrote:I still dislike discourse

it's not final yet

hit me with everything you got

I don't really know, I just find forum scripts like that to be very disorganized and hard to find your way around. TBH it'd be awesome to have vB3 again because that was my favorite of all, even the later/newer versions of IPB or XenForo.

I can help with porting the physics over, LR's collision across all versions is pretty simple and universal (differences between each are how it detects collision). Hell, I'd be willing to port over the whole thing if you guys just worry about the online stuff.

About b2 physics: The pursuit of b2 compatibility was one of the main reasons I never released full versions of my native builds. I wanted b2 compatibilty for a long time and spent ages working on it.

It's *exceedingly* hard, if not impossible. I even directly ported (as in copy pasted) the b2 simulation engine into a browser based solution. I used node-webkit because that lets me load sol files locally, however the actual simulation portion was run in what was essentially Chrome. Didn't work.

You can recreate the engine and have it feel exactly like B2, but you can't preserve compatibilty with existing tracks. The only solution I see to this if you really want existing B2 tracks to work is to write a "headless" engine that doesnt render anything but still runs in a Flash Player on the server and just has simulation duties. That engine can then communicate with another server process using a local socket, and the server could send back the simulation data over the internet for playback in a fast client.

It would be a giant hack but it would at least work. For browsers with a Flash plugin installed you could run the headless engine locally to save needing to use the network.

It's not trig that's needed, it's correct rounding and a square root that gives results exactly equal to the Flash one. Browsers are *not* required to maintain a certain precision for their Math.sqrt functions, which makes this somewhat hard. In practice they may just call down to the C stdlib sqrt(double) function however I haven't looked.

I'm currently playing with some native rendering code that pushes millions of lines at 60fps and working on optimizing texture access and spatial storage to support tracks of this size. I won't have a non-mobile internet connection for a week so I'm not going to be contributing immediately (and I definitely won't be contributing the physics engine - that stuff doesn't interest me).

I don't think b2 compatibility is strictly necessary, as long as the gameplay works similar that we can't notice a difference when making new tracks, what difference should loading old tracks make? We will always have FP standalones to load them with.

We can probably make this a team project, I believe one of the biggest issues we've had with future builds is we've never been able to focus on one 'definitive' build. If we simply break down the whole project into different parts and keep constant communication, this could be a really cool project. I mean, pardon me for injecting myself on this, but if me and shotoku focus on the porting and main "line rider" aspect of it, Mhenr can focus on rendering and performance improvements, and conundrummer can work on the multiplayer and network aspects of it, we can have a serious well thought out build that's more than a typical update like what me and Mhenr did with the flash builds.

I'm actually realy glad that the porblems listed with backwards comnpatibility are the only ones being run into.
I love the hackish idea, and if it comes down to it that would work out fine.
If you can figure out how and to what precision Flash performs square root calculations, you should be able to write a square root function which can truncate to/calculate to the same results so long as maffs are compatible.

If I understand conun correctly, floats and precision in your average joe trig is completely consistent between the different environments so that's an ENORMOUS plus.

I was way wrong about the scope of the compatilibity request myself, now that I read your responses.
I thought the main issue was porting the original code, but taht could in essence be as simple as a copy/paste. The actualy subroutines and functions Actionscript uses themselves mst be perfectly simulated or ported over as well, and that could be a whole'nother animal, and may even require access to code or utilites which would require special licensing or permission (like that should even bother us that much.)....except with the magnitude of this undertaking, and how far it's already come, and the prospect of new useres, I really hope this all checks out in the eyes of marketers and developers alike.

I love you kevans for the team idea. I wish I could be on it but I'm nowhere near as versed as you all are.

Shotoku's point about us not being able to notice a difference (which, it is more than possible t make it negligible in difference to the human brain excpet that as time goes on the style will be slightly marked by the minute changes in physics) is valid and I support it. I simply wanted...ya know...to not have to switch to this exclusively once it becomes a stable build and not be able to bring my old tracks with me.
And I'm sure I won't be the only one who thinks that.
I appreciate all the informative responses. I wish I were a bigger part in this than "anticipator"

I say we ought not to worry making it B2 portable and I am kind of shocked how much time you say you put into that, mhenr. I'm with shotoku - as long as it feels like B2 I am happy. Yes there will be a switch because we have to start all new tracks, but I don't think that that is unreasonable to ask of people. After all we are switching to a totally different platform here.

Hoping conun will post in more detail about his plans for physics. I don't want to quote private discussions here but I am seeing totally divergent trains of thought from him and you guys.
EDIT:

Conundrumer wrote:For those who are curious: I'm making my own physics engine because I'm planning to make other sandbox games that will be able to support huge numbers of entities, hopefully only limited by your graphics card.

Okay so you did kind of announce it but what you neglected to mention is that this engine does not have gravity wells (or at least you are thinking about scrapping them) and is therefore nothing at all like beta 2. I REALLY hate the idea of multiple physics engines on a single web app because it just muddles everything trying to figure out what version a track was made in, not to mention an easy way for people to switch between them? or understand the difference? It all strikes me as crazy-making - I think we need one standard engine here.

Team stuff I will leave to conun as the creator of this project. This forum section is open and available.

Rev - if the best option you can give us is vB3 and the only reason is "I liked it" that's not really gonna sway us

If you make it a group project put it on a private github or something else that can do something similar to github. Easiest way to keep communicated without actually having to contact each other thanks to commit comments etc etc.

Edit: I also don't see the problem with the physics being different. People can finish their current tracks with FP then move onto the new version at a later date.

Edit 2: Rabid I did give more of a reason then that...

I've been doing team management with my group members, so I can work something out in distributing the work. Important question: Is there a problem with making LineOnline (+Line Rider JS) open source?

Re. Physics engine: Trust me that I know what's in the spirit of Line Rider.  I know that supporting multiple physics engines is not in the spirit of Line Rider. I just need to get some fresh perspectives (ie not our perspectives, I already understand you guys) on the nature of quirk, on our community, and on what excites people about Line Rider.

In the mean time, the repo for my physics engine is public: https://github.com/conundrumer/line2d

Conundrumer wrote:I've been doing team management with my group members, so I can work something out in distributing the work. Important question: Is there a problem with making LineOnline (+Line Rider JS) open source?

Re. Physics engine: Trust me that I know what's in the spirit of Line Rider.  I know that supporting multiple physics engines is not in the spirit of Line Rider. I just need to get some fresh perspectives (ie not our perspectives, I already understand you guys) on the nature of quirk, on our community, and on what excites people about Line Rider.

In the mean time, the repo for my physics engine is public: https://github.com/conundrumer/line2d

Yeah. I can probably help you with that.

I have some thoughts that may be of interest to you on development.

Conundrumer wrote:I just need to get some fresh perspectives (ie not our perspectives, I already understand you guys) on the nature of quirk, on our community, and on what excites people about Line Rider.

Well lucky for you, I have a few friends of mine who have discussed this with me.

What it seems to boil down to are one of two things: The time and dedication it takes to make a track, and the complexity of the gwell system.

With time and dedication, to them it feels like something like a massive scenery track isn't worth their time, or they lack the artistic values to draw something. I have to partly agree with them on this because 1) it does take time to make a scened track, and 2) I myself know the feeling of not having the artistic edge. They've also commented on the time it would take to make a track look decent. Not once will I ever mention how long it takes people to make a track, and the statement is along the lines of "I don't have the time to do that." If anything, this online version should provide the tools to make that easier. Such as a fill tool or something, idk. Well I do know a lot of things that would streamline EVERYTHING, but that's not my call.

When it comes to the gwell system, it's really really difficult to convey that it's a "good" thing. I'll be asked "How do they do that dashed line thing" or "How come all those random lines don't crash/kill him?" When explaining, I feel that as soon as the word "glitch" comes out of my mouth, it turns them off from the system. I was at first turned off as well, before I understood gwells, I associated it with "cheating". And that's typically what glitches are affiliated with, a 'glitch that lets you get infinite items' or something along those lines. If we are to keep the gwells, and obviously we are, they need to no longer be perceived glitch. They need to be presented in the same way as we interpret lines, just another 'trick'.



Hope that sheds some light.

[senpai] kevans wrote:

Conundrumer wrote:I just need to get some fresh perspectives (ie not our perspectives, I already understand you guys) on the nature of quirk, on our community, and on what excites people about Line Rider.

Well lucky for you, I have a few friends of mine who have discussed this with me.

What it seems to boil down to are one of two things: The time and dedication it takes to make a track, and the complexity of the gwell system.

With time and dedication, to them it feels like something like a massive scenery track isn't worth their time, or they lack the artistic values to draw something. I have to partly agree with them on this because 1) it does take time to make a scened track, and 2) I myself know the feeling of not having the artistic edge. They've also commented on the time it would take to make a track look decent. Not once will I ever mention how long it takes people to make a track, and the statement is along the lines of "I don't have the time to do that." If anything, this online version should provide the tools to make that easier. Such as a fill tool or something, idk. Well I do know a lot of things that would streamline EVERYTHING, but that's not my call.

Kevans lad you are on the right track.

FreakingKoalaMan wrote:

Conundrumer wrote:I've been doing team management with my group members, so I can work something out in distributing the work. Important question: Is there a problem with making LineOnline (+Line Rider JS) open source?

Re. Physics engine: Trust me that I know what's in the spirit of Line Rider.  I know that supporting multiple physics engines is not in the spirit of Line Rider. I just need to get some fresh perspectives (ie not our perspectives, I already understand you guys) on the nature of quirk, on our community, and on what excites people about Line Rider.

In the mean time, the repo for my physics engine is public: https://github.com/conundrumer/line2d

Yeah. I can probably help you with that.

I have some thoughts that may be of interest to you on development.

I'm curious what you have in mind. If you'd rather not post in the thread, you can share your thoughts with me through PM. EDIT: Haha I thought I posted this as a PM

excite

[senpai] kevans wrote:What it seems to boil down to are one of two things: The time and dedication it takes to make a track, and the complexity of the gwell system.

With time and dedication, to them it feels like something like a massive scenery track isn't worth their time, or they lack the artistic values to draw something. I have to partly agree with them on this because 1) it does take time to make a scened track, and 2) I myself know the feeling of not having the artistic edge. They've also commented on the time it would take to make a track look decent. Not once will I ever mention how long it takes people to make a track, and the statement is along the lines of "I don't have the time to do that." If anything, this online version should provide the tools to make that easier. Such as a fill tool or something, idk. Well I do know a lot of things that would streamline EVERYTHING, but that's not my call.

When it comes to the gwell system, it's really really difficult to convey that it's a "good" thing. I'll be asked "How do they do that dashed line thing" or "How come all those random lines don't crash/kill him?" When explaining, I feel that as soon as the word "glitch" comes out of my mouth, it turns them off from the system. I was at first turned off as well, before I understood gwells, I associated it with "cheating". And that's typically what glitches are affiliated with, a 'glitch that lets you get infinite items' or something along those lines. If we are to keep the gwells, and obviously we are, they need to no longer be perceived glitch. They need to be presented in the same way as we interpret lines, just another 'trick'.

Yeah IMO you basically hit the nail on the head here.

What this means for the future of line rider is honestly pretty scary, but I don't think anyone could have summed this up better