Hey there... been a while, eh? I've been away for a while, both for work and because I've been pretty sick. But lately I've been feeling better and had some time so I fired up the engine and got the Sprite Demo working with the new namespace. In doing so, I also got a renewed interest in the Level Editor for 2D platformer style games. I spent a fair amount of time getting things reorganized and cleaned up.
Sunday, January 16, 2011
Friday, January 7, 2011
Almost Done!
The refactoring is almost complete (I still need to do physics, demos, tutorials, and tests) but the Asteroids demo is working with the new namespace, as is Tutorial 1 in both Chrome and Firefox. Everything appears to be working as expected. There's a shiny new "R" object on the DOMWindow which contains all of the engine classes. Yay!
Thursday, January 6, 2011
Refactored Again
I just committed the v2.0 updates (as they stand so far) which has taken me the better part of a week to do. I still haven't touched the physics package. I was able to get the vector demo (Asteroids Evolved) running on Firefox, but not in Chrome. Tutorial 1 is also converted and running in Firefox. So, for the time being, v2.0 is very sick but is getting better all the time.
Everything is different. Yep, I introduced the "R" namespace, renamed some of the classes, renamed all of the components (removed "Component" from the end of the class name), moved some files around, and did other things to make my life very difficult. Trust me, it's taking a lot for me to get used to it. I've been working with this engine since 2008 and it's a huge change to do what I've done. I'm still making mistakes when I write class names.
Anyways, if you're curious you can look at the code in the v2.0 repo. There's still time that something might change, but I'm thinking that this is how the final layout will look.
Oh yeah, biggest change was the namespace but it also allowed me to change the Linker. Yep, now Linker is a very simple class which uses the predefined class dependencies to determine what needs to be loaded. It doesn't do any parsing or symbol table checking. It's a lot faster and it's a lot simpler. You can write your code in more ways than you used to be able to (however, I suggest keeping it clean).
Feedback is appreciated.
Everything is different. Yep, I introduced the "R" namespace, renamed some of the classes, renamed all of the components (removed "Component" from the end of the class name), moved some files around, and did other things to make my life very difficult. Trust me, it's taking a lot for me to get used to it. I've been working with this engine since 2008 and it's a huge change to do what I've done. I'm still making mistakes when I write class names.
Anyways, if you're curious you can look at the code in the v2.0 repo. There's still time that something might change, but I'm thinking that this is how the final layout will look.
Oh yeah, biggest change was the namespace but it also allowed me to change the Linker. Yep, now Linker is a very simple class which uses the predefined class dependencies to determine what needs to be loaded. It doesn't do any parsing or symbol table checking. It's a lot faster and it's a lot simpler. You can write your code in more ways than you used to be able to (however, I suggest keeping it clean).
Feedback is appreciated.
Tuesday, January 4, 2011
v1.5.4 Cancelled
I hate to do this for anyone who was waiting for v1.5.4, but I've decided to cancel it. v2.0 is such a big priority to me that unless some major bug shows up in the current release (v1.5.3) I probably won't be touching that code branch anymore.
Again, apologies to anyone who was waiting on it.
Again, apologies to anyone who was waiting on it.
Monday, January 3, 2011
Namespace, Part Deux...
Okay, well, that didn't exactly go as planned. While setting up the namespace, I have also been trying to clean up the Linker. I have been removing the calls to Engine.initObject(), but I just realized (after completing 95% of the refactoring) that it was going to blow chunks the first time I tried it. It comes down to the fact that I'm using Base.js by Dean Edwards to set up my OO model. As such, a class definition looks like:
var ClassB = ClassA.extend({
...
});
Due to this, ClassA must exist, otherwise calling the extend() method will fail with an exception. There has to be some sort of delay before it checks to see if ClassA exists! Well, after some hemmin' and hawin' I think I've settled on an acceptable alternative. Now each class will look like this:
var ClassB = function() {
return ClassA.extend({
...
});
}
Not as pretty as before, but I can eliminate the need for the Linker to do as much work as it has been doing. This will cause a lot less hair pulling when trying to get your game running. Plus, instead of R.Engine.requires(), I'm changing it (so soon?) to something like the following:
R.Engine.define({
"class": "R.collision.OBBHull",
"requires": [
"R.collision.ConvexHull",
"R.math.Point2D"
]
});
This goes at the top of each class file. What this does is it allows the engine to know that R.collision.OBBHull has two dependencies. It can wait until those two dependencies are initialized (loaded and their dependencies are resolved) before initializing. For those who wish to know, when it's time to initialize:
R.collision.OBBHull = R.collision.OBBHull();
Tada!! Thoughts?
var ClassB = ClassA.extend({
...
});
Due to this, ClassA must exist, otherwise calling the extend() method will fail with an exception. There has to be some sort of delay before it checks to see if ClassA exists! Well, after some hemmin' and hawin' I think I've settled on an acceptable alternative. Now each class will look like this:
var ClassB = function() {
return ClassA.extend({
...
});
}
Not as pretty as before, but I can eliminate the need for the Linker to do as much work as it has been doing. This will cause a lot less hair pulling when trying to get your game running. Plus, instead of R.Engine.requires(), I'm changing it (so soon?) to something like the following:
R.Engine.define({
"class": "R.collision.OBBHull",
"requires": [
"R.collision.ConvexHull",
"R.math.Point2D"
]
});
This goes at the top of each class file. What this does is it allows the engine to know that R.collision.OBBHull has two dependencies. It can wait until those two dependencies are initialized (loaded and their dependencies are resolved) before initializing. For those who wish to know, when it's time to initialize:
R.collision.OBBHull = R.collision.OBBHull();
Tada!! Thoughts?
Sunday, January 2, 2011
Namespace for The Render Engine
I'm in the process of giving The Render Engine a namespace, and reorganizing the way that objects are included so that the Linker isn't a thorn in developers' sides. The new namespace (for the time being) will be "R". I know, not very inventive but it's short (and being a developer, I hate typing). Additionally, files are getting renamed left and right. For example, now the components are like the following:
Transform2DComponent => R.components.Transform2D
Also, when you want to use the component, it's gone from:
Engine.include("/components/component.transform2d.js")
to:
R.engine.Engine.requires("R.components.Transform2D");
And the filename is now:
"/engine/components/transform2d.js"
Originally, I had figured that a namespace wasn't necessary since a game should really be the only thing running in the browser (along with the engine). If people wanted to have 5 to 10 libraries loaded, and the game, and the engine, and things conflicted... well, that wasn't my fault. But, as one user pointed out, even if I accounted for naming conflicts with browser objects, there may be naming collisions with a game's objects and the engine's objects. So, here I am doing a huge refactoring. It's going to be as big of a change to me as it will to you. Eventually, this will help me to fix up some of the drawbacks of having the Linker do excessive checks. This will all affect v2.0 of the engine, which I feel will be a major improvement over v1.x.
Now that I'm looking at it, I think I'll also move R.engine.Engine => R.Engine. No reason to put it into the "engine" package... That will simplify some things as well.
Transform2DComponent => R.components.Transform2D
Also, when you want to use the component, it's gone from:
Engine.include("/components/component.transform2d.js")
to:
R.engine.Engine.requires("R.components.Transform2D");
And the filename is now:
"/engine/components/transform2d.js"
Originally, I had figured that a namespace wasn't necessary since a game should really be the only thing running in the browser (along with the engine). If people wanted to have 5 to 10 libraries loaded, and the game, and the engine, and things conflicted... well, that wasn't my fault. But, as one user pointed out, even if I accounted for naming conflicts with browser objects, there may be naming collisions with a game's objects and the engine's objects. So, here I am doing a huge refactoring. It's going to be as big of a change to me as it will to you. Eventually, this will help me to fix up some of the drawbacks of having the Linker do excessive checks. This will all affect v2.0 of the engine, which I feel will be a major improvement over v1.x.
Now that I'm looking at it, I think I'll also move R.engine.Engine => R.Engine. No reason to put it into the "engine" package... That will simplify some things as well.
Saturday, January 1, 2011
Browser Storage Objects
The website is back up and running.
Today I finished the implementation of PersistentStorage and TransientStorage which use browser-based localStorage and sessionStorage objects. On top of this, I found the TrimQuery API which supports a nice SQL-like syntax for querying and modifying the data. PersistentStorage is used to maintain data between browser sessions, whereas TransientStorage exists to provide a place where current session data can be stored. TransientStorage provides a mechanism which would allow a developer to store data and retrieve it with SQL, rather than simply storing it in many JavaScript objects.
TrimQuery supports a wide range of SQL-like syntax so a developer can put data into multiple tables and perform simple joins to get aggregated data. I can see a developer using this to store data for their MMO, or to store configuration information about keyboard setups and other things. I've updated the Asteroids Evolution demo to store and retrieve the high score using PersistentStorage.
You can try it here.
Today I finished the implementation of PersistentStorage and TransientStorage which use browser-based localStorage and sessionStorage objects. On top of this, I found the TrimQuery API which supports a nice SQL-like syntax for querying and modifying the data. PersistentStorage is used to maintain data between browser sessions, whereas TransientStorage exists to provide a place where current session data can be stored. TransientStorage provides a mechanism which would allow a developer to store data and retrieve it with SQL, rather than simply storing it in many JavaScript objects.
TrimQuery supports a wide range of SQL-like syntax so a developer can put data into multiple tables and perform simple joins to get aggregated data. I can see a developer using this to store data for their MMO, or to store configuration information about keyboard setups and other things. I've updated the Asteroids Evolution demo to store and retrieve the high score using PersistentStorage.
You can try it here.
Subscribe to:
Posts (Atom)