I recommend taking a look at the ECS (Entity Component System) architecture/design pattern which lends itself well to games or in general any software which deals with lots of relatively independent but highly heterogenous components. It really simplifies things in the long run (and even in the short term). In my opinion it is far superior to the brute force "this is a X which is a Y which is a Z which is also A, B, D, and E - but it isn't C" inheritance approach that is often taught but which doesn't map well to game development (though it can, and is often a good solution when you are dealing with homogenous object types).

JavaScript and Object Oriented is a strange beast. JavaScript isn't actually an object (class) based language, although that doesn't stop people from using it like one.

JavaScript instead is a Prototype based language. In a nutshell, this means in JavaScript you describe something ( say... an NPC ), then clone and possibly extend it. "Objects" in JavaScript are mutable to the extreme. This is handy in that creating adhoc objects is laughably simple, but dangerous in that... well, clobbering an existing object is laughably simple.

JavaScript have some major shortcomings though. It's far too easy to create globals ( it's the default... ) and globals are bad, m'kay. It's also far too difficult to hide data. There is no concept of private or protected variables for example. This makes using JavaScript on large scale multi developer projects... tricky. As does the lack of a good module system built in. There are solutions out there to try and solve these problems... from closures ( which are an overly complicated hack to accomplish something that should be simple ), to higher level languages like CoffeeScript and TypeScript that compile to JavaScript. Of course, there is also the next version of JavaScript that hopes to fix all of these problems but is a product for the future.

So frankly, JavaScript is great at creating in the small projects. But for larger solutions, you really want to use a framework. Building your game over an existing library like Backbone would impose structure and a certain about of cleanness on your code. Or use TypeScript or a similar higher level language. One of the nicest things about JavaScript is also it's mutability, so its almost staggering what a framework is able to accomplish when it comes extending JavaScript or hiding it's various flaws.

Also, pick up the book JavaScript:The Good Parts.

It's also far too difficult to hide data. There is no concept of private or protected variables for example.

You can still annotate a block of declarations as public, and treat everything else as private.

People typically settle on some convention.

I faced this problem myself and the best thing I done was learning how to use UML and (way harder) learning to always use UML; I usually was too lazy to model everything beforehand and ended up in those "what do I code now? what do I need now? how do I do this?" obstacles.

Today, I use a software called ArgoUML for my modeling and then, and only then, I start to code. The software can even generate code structure for us.

As I'm learning JavaScript myself, I cannot avoid noting how JS documentation is really dependent on data types being there.

This separation between data types as something that just exists in our mind to understand against data types as something understood by the language is JS main problem in my opinion. Code readability, as well documentation is seriously hampered.

So sadly, in the long run, I consider static, traditional languages to be far superior.

I made a tutorial called Dynamic and Clean Programming about a week or so ago:

http://forum.maratis3d.com/viewtopic.php?id=793

It seems a lot of people on this site need some help just like I did, I will try to make an article on it here (sorta new, just browsing for now)