• Content Count

  • Joined

  • Last visited

  1. valid point about the community size. But let's imagine that we have a modular approach. So instead of 45k lines of JS, we will have 15 separate github repositories, each with 1k-5k lines of code. I am sure you'll see a lot of forks and many developers will be able to contribute since the complexity is reduced and more devs will be able to wrap their heads around the code. Right now the barrier to entry is pretty high due to the monolith design and the tight coupling between components.
  2. but it's not my modules. it's everyones. the community will create many small modules. they will fork my modules and create different ones. just like in nature - the fittest survives. it require more 'plumbing' from the developers' side but that's the way to be innovative, fast and flexible. When I use node.js, everytime I start a new project I uses similar modules but many of them are a bit different than my previous project, different ones or upgraded version. The same goes with levelDB. leveDB is the DB that is used by the chrome browser. it's an embedded DB. if i want to be able to access it from another process, i'll expose it over http using another module (multilevel). If I want to have replication I'll use it with level-replicate module etc. Here is a nice diagram of levelDB echo-system. That way you, Rich, don't need to work so hard on every release. the community will take a lot of the burden.
  3. Great insights. thanks. The problem i see with frameworks is they are short-lived. New framework is created, with cleaner codebase that is a better fit for the new shiny technology and developers will jump to the new thing. By using small modules that works together we create an eco-system that is more flexible and adapt to changes. Just my 2 cents.
  4. I am new to Phaser and really excited about the posibilities it opens to game developers. There is one issue I like to talk about - modularity. Phaser is 45,000 lines of JS. the code seems to be well written and domuented but it's still a lot of code to reason with and to maintain. I am coming from a Node.js mindset and in the Node world everything is modular. The idea is to constract your app using small NPM modules. This modular approach is one of the reason for the popularity of the Node echosystem. Node itself has small core and the community adds more functionality by publishing their libraries to NPM. How cool it would be if we could have something like this; var gameLoop = require('game-loop'); var keyboard = require('keyboard'); var entity = require('entity'); var physiqueEngine = require('engine'); etc.. Now if something new comes up, we don't need to wait for anyone to add this new hotness into our framework since there is no big framework. we just replace whatever we want. In addition it will be easier to contribute to the different libraries since each of them is small and is doing only 1 thing (the unix philosophy). In the 3d game development there is a good example to this approach - http://voxeljs.com/ In the DB world there is levelDB which also based on this - https://github.com/rvagg/node-levelup/wiki/Modules There is an interesting project for 2d games that is trying this approach - http://crtrdg.com/ And here is a recent blog post by Seth, the developer of this project - http://learnjs.io/blog/2014/03/04/gameloop-load-images-sprite-2d/ I don't know what is the effort and viability for breaking up Phaser into small modules, but at least let's have a discussion about it!
  5. I am new to phaser and would like to jump on 1.2. I switched git to the 1.2 branch and use the build of 1.2 on my little hello world sample game. I get the following errors: Uncaught TypeError: Cannot read property 'gravity' of null this.bird.body.gravity.y = 400; Uncaught TypeError: Object #<Object> has no method 'overlap' this.game.physics.overlap(this.bird, this.pipes, this.hit_pipe, null, this); I know that it's due to major changes in the codebase. since the examples are also broken on this branch it's a bit hard to figure out what should I change. grepping the codebase was not very helpful but I am sure i'll get better at understanding the codebase as i spend more time with this project. if there is a good post that can help understand the codebase better, please link it away! Thanks in advance!