Separating module files
kittykatattack opened this issue · comments
Ga is getting too big!
This is both good, and bad - but mostly great!
I think it's time to take a closer look at modularizing the code base.
Here's a suggestions for the new file structure:
core.js - The current ga.js file, minus the sound module
sound.js - The sound module. (This will be a new port from soundForGames)
utilities.js - Helpful utility functions
tween.js - The tweening module
sprites.js - Specialized sprite types and new sprite creation tools
geometryCollision.js - Geometry collision functions (including boundary collisions)
tileCollision.js - Tile based collision functions
spriteControllers.js - Specialized functions for controlling sprites
tiledEditor.js - Functions for importing and working with Tiled editor files
fullscreen.js - The fullscreen module
ga.min.js - The compiled, minified file containing all these modules
The main thing is that all the modules should be completely stand-alone without dependencies from any of the other modules. The core.js file should also be complete enough (and minify to under 6.5k) so that you can make games without any dependencies on the other modules (And I'm looking forward to using it in this year's js13k competition!.)
I'm going to tinker with some architectural patterns over the next few weeks (yes, including classes!) and see what looks the most promising, Providing I can get the core.js file small enough I'm even considering re-writing the code base in ES6 with Babel. As we're going to need a new compile step anyway to minify the code, it might make sense to go this route.
Great news, however core.js should contain the sound module otherwise the two modules will be inter dependent. I already changed core.js to use classes! and would like you to give it a look. Don't know how and where to upload though?
I'm going to think about this for a bit and try some things experimentally :)
I think ideally it would be good to completely modularize the rendering engine as well.
That way we can choose the display engine: the basic existing canvas renderer, a Pixi-renderer, and a 3D renderer using ThreeJS.
Then they could all share the same basic API and utilities (like collision, tweening, particles, sound etc.)
And then we could offer multiple builds: A micro-build for small-footprint games (like the current version of Ga), a Pixi build for advanced graphics effects, and a 3D build for 3D games.
This will be really tricky to implement, but I think it's worth trying, because it will be really cool if we can get it right! :)
And most importantly it will need to still maintain a simple API and and be as painless as possible for end users pick up and start making games with.
I've been doing a lot of work with ES6 over the past year, and although great to work with the transpiled code might just contain too much overhead... but let's see!
Regarding the timeline for this:
I'm first going to finish working on the current version of Ga.
I need to finish the tutorials, examples, documentation, add the remaining modules, do some testing and debugging.
Then I'll probably release a stable version 1.0.
I think I'll actually create a new repository for the new modularized version of Ga so we can work on from a clean code base.
What I like about Ga is its minimalist and clear structure and would like it to remain as it is. In its current state Ga is quite useable. Certainly modularisation is good but it should not make a system difficult to understand. Many game engines have such a huge structure that they look nightmare to me. In my view a game engine should not take away one freedom to code.
I think I'll actually create a new repository for the new modularized version of Ga so we can work on from a clean code base.
Yes it is a good decision.
@qsrahman I completely agreed :)
That was actually my main reason for starting this project.
Simplicity is the goal :)
Just an update that I'm re-starting work on this feature very soon!
I will keep everyone posted 😄
👍
I've reconsidered!
Ga is so small and so perfect, that reluctant to make any changes to it right now.
I might revisit this later, but, for now, I'm going to close this issue.