CreateJS()

I am shamelessly going to admit this:
I copied the minified JS source from chrome and expanded it to discover more about this wonderfully crafted webapp.

Hats off to the devs, I'm surprised on a daily basis how cleanly freeriderhd runs as a web application.

Not the canvas el, the web site. As a UX/UI guy, this place is a real spectacle. I show it to my dev friends when they need inspiration.​

Anywho, are you using the CreateJS suite exclusively, since it does practically everything? We're relying on Kinetic at the moment and I'm beginning to get worried about it's support going forward.

Also: The queries controlling the canvas's calculated size are perhaps the most precise I've seen.

Does EaselJS do this out of the box or were they hand written?
​

https://github.com/kevbost
DriveSlow()

 

Hey Kevin.
Thank you for the compliments. I am responsible for majority of the front-end work + game.

The webapp was started in the height of the backbone.js 'movement', so its highly dependent on that for its routing and views. We also utilize templates to render majority of the content client side, allowing for faster page transitions. I would like to start moving towards using react , moving forward and on future projects.

​

Originally when we started developing the game portion, I researched different libraries to assist in some of the UI and certain objects in the game. One of the projects we did at Kano utilized Kineticjs , so I did look at that, but decided on moving forward with Easeljs ( Createjs ) . I highly recommend it over kinetic mainly for the community and support, as well as its preloadjs , soundjs , util libraries. In the current state of the game, we did not use createjs for anything but the GUI (mobile controls, powerup sprites, and smaller icons). The actual game canvas management is all hand written.

However, I am currently in the middle of rewriting the game ( as I find the current codebase is not optimized , organized in the way that I want, and I had learnt a lot while developing), I am moving towards not using createjs at all. We are moving towards a completely single page app, meaning we cannot rely on easeljs and misc libraries to clean up memory / not memory leak.

Let me know if you have any more questions.
(Obviously need to state please do not use our code in your projects as its not open source)

 

Char working this game harder than he works chuck. Hats off, pants down. 10/10 gr8 m8

 

We went hard on Backbone and ParseJS at The Iron Yard. It's a really solid system, versatile. At work we're using Knockout, of which I'm not a complete fan of. So when you say you're working towards an SPA, are you also abandoning your Backbone system for something else? I don't know enough about React to know if it works as a controller etc.

I'm really interested at this point in time in the expanding sidebar trend. So while studying yours and others, I noticed the way that the fr canvas resizes. I only have second hand canvas experience through PaperJS, but I remember having a hay of a time with screen resizing and the canvas. So I guess my question is, how did you get that to be so clean? Is your resize function erasing the canvas el and redrawing it?​

Edit 1: GET http://community.freeriderhd.com/favicon.ico 404 (Not Found)
Edit 2: At screen width ~480px + on forum posts the report like reply edit buttons misformat.

 

Yeah, I am just getting into react now, and so far its great. It is basically one big state machine view. It doesn't have a router/controller like backbone, so I am not sure how you would handle pushstate etc.

We are constantly altering the breakpoints of the left side menu, when it snaps in place etc. We are going to be making some changes to that at some point. Its all utilizing media queries and css3 transitions , translateX etc.
As far as the canvas resizing.
In the current state , the game is inside an iframe, and that iframe resizes though media queries. We are going to be moving away from the iframe due to porting to mobile limitations. Natively when you resize the canvas element, it clears automatically. (One of the ways to clear a canvas is to set canvas.width = canvas.width ) . On the next tick, it will repaint. Every tick the canvas gets cleared and repaints. Therefore we are not doing anything special with canvas resizing. The main thing to remember is that everything in your game needs to react to game.width and game.height. These should be updated when resizing obviously.

[/QUOTE]
hah, yeah, I have noticed this, its on the lower end of the priority list .

 

My boss yesterday afternoon asked me to spin up a simple site to use as a prototype for the new corporate home page, and looking at react examples... it's pretty cool. I think while wireframing I'll try out some react functionality.

You're member number 3, haha that's awesome. Also, the breakpoints are awesome, I could resize the window all day and be happy.

I'm not doing the canvas work, and of course we're not building a game, so when we move back to the section that utilizes the canvas I'll take a look into what my coworker has written and talk to him about the canvas.width = canvas.width trick.

So the next thing that I've wondered about is the origin of the FR code. I mean, FR has been around for a while now, between FR2, CanvasRider, BlackHatRider, FRHD, who the H word wrote it? It probably started as flash, no? But then canvas rider got into trouble which spawned BH, then FRHD showed up like a knight in shining armor.

I can imagine that the full story must be a decent tale, but the part that I'm curious about is: did at any point, a stranger come in and rip the code out of the original instance?

KB

Code:

var q = function(){
    var i = "Sigh. boredom.min.js. ",
        j = "SPEAK IN A LANGUAGE ",
        f = "interacts with user B with different permission ",
        b = "I'm in a meeting right now and ",
        g = "sets and the authentication just broke etc. ",
        c = "they're talking about some ",
        e = "implemented and how user A ",
        a = "I'm really bored so here's a dumb function. ",
        h = "Bored. Extremely so. ",
        d = "security framework stuff that was just ",
        k = "THAT I UNDERSTAND PEOPLE!! "
    console.log(a+b+c+d+e+f+g+h+i+j+k);
};

 

Just a note, canvas.width = canvas.width is not necessarily the best way to go about it, I was just stating one method.

The original code (FR1 + 2) was written by Pete (in AS2 ) , with the help of Ira from OneMoreLevel.com
Then trackmill and other sites popped up ( Im sure the community could give a better timeline ), decompiled the code and started making changes.
Long story short, most of it was done without permission from its creators, and thus were shut down. We on the other hand are an official sequel, and are partnered with Ira.

 

Fascinating story. Are you running a build script? I've used the Yeoman standard webapp ( https://github.com/yeoman/generator-webapp ) on more projects than I can count, but started using Gulp after I looked at the syntax for grunt.

Also, what are you using for data storage? This isn't a Parse app is it?

EDIT: BuiltWith extension reports Amazon

 

Not using yeoman personally. Although it is used within the company.
Im using gulp now for some work , and browserify. Its not a Parse app, we use a plethora of data storages. Relational and Non Relational databases.

 

Gulp is great, I get giddy sometimes writing gulp scripts because of how delightful a working build can be.

I did a React tutorial and holy crap, it is shiny. I'll need to build a todo app or something to really begin to understand it's syntax. Unfortunately for the app I'm beginning on, I don't think it would be of any use since it will just be a replacement for the current company website === static content. It looks like it could be forced to control views, maybe, I need to do more research. TODOmvc has a React and a Backbone/React separately.

You said height of the Backbone frenzy, do you wish now that you guys had a different framework?

KB

 

Mmm, If I did it again. I would go react 100%, the only thing useful in backbone for me is the router.

 

Absolutely. I've pulled in backbone just for the router before.
So react CAN be a framework replacement? I guess I had the impression it was more useful as a supplement, but I'm only a few days in to learning it.

 

Single page app!? WOW! That is awesome! By the way, why the hell are you using backbone.js!? It sucks!

 

Um, the code isn't under an open source license, so I hope you're not releasing what you've "expanded"!

 

Backbone is not a bad platform, and not under any circumstance would I release a public and pre-built js file.

 

He means he beautified it.

Backbone was the first of its kind for routed single page apps. Organized views etc.

 

So why is it that autos are/were breaking once uploaded? Are/were the paths being averaged?

 

More or less. It could be due to many different things. The issue is that the game was created before the editor. This just creates problems.

 

Are you serious!? Before the editor!? How!? Why!?

 

Does that imply that after the new editor is pushed, a game rewrite will have to follow to match?