Yeah, I did come up with a roadmap, while I was developing the initial pieces right now. I’m thinking the parts that I have now should compile, but I’m not going to test that theory until I have a little bit more to show. I am however about to commit the pieces I have before I head off to sleep. I’ll see what damage there is when I wake up.
Version Convention
Major.Minor.bug/security fixes
I’m not going to bump the minor release version just to fix a couple of bugs. Only when the extension falls behind of the library release.
New Name (Kind of)
I decided to call the extension of the Quantum Game Library the Quantum Game Extension. The old name, Quantum Game Library Extension, which I was using was a little bit too long. I think QGE and QGL would be better than QGLE and QGL as it would seem to some people that QGLE extend the user land library with extra components.
Don’t want that.
Version 0.1
The first version will include all of the working trunk classes and interfaces (interfaces first) in the Quantum name space. The reason for this is that I feel the AI name space is still somewhat unstable with what only the Dijkstra pathfinding algorithm being done. I was thinking of adding the Ai_Pathfinding class, but I think that I’m going to remove it in a later refactoring of the path finding classes.
I like what I currently have and I spent a good 5 hours total now. There are a few questions that I have and need to do more research later on what the solution might be. Basically, I need to know if I add the classes to the function part or just in the INIT_CLASS_ENTRY part. It would be nice to know for sure to fix that bug before it even comes up.
Extension Constants
The PHP extension will have constants for which the user land will be able to check for. The goal is to have the extension completely replace the library and the user would need to check for the extension before including the library.
if(!isset(QGL_VERSION) && QGL_VERSION >= 0.1)
{
// Add autoload or add library_path
}
The usage of the version numbers for the extension is that it would be difficult to keep the extension and library sync since they share the same repository if the repository revision number was used instead. It was an option I had in mind. It should only take a little bit extra work for the developers to look up that this extension version relates to that trunk revision or stable release.
In the future I would want to have the versions relate to stable releases. Only so much can be written for a PHP game library. I think bugs in the extensions and library might also relate to the version changes.
Oh, the whole reason for the version is so that if the extension is too old, then the library should be used instead. It would be slower yes, but it seems that it would be more difficult to keep an extension updated than a library.
Version 0.2
Will include any bug fixes of the library and in the extension. It will also include any new or improved Quantum name space classes that might of been developed between the time of version 0.1 and 0.2.
The major focus will be the inclusion of the AI components. If the path finding classes are complete, then I’m going to add them here and I hope to have the fuzzy logic classes finished so I can also add them.
There might be a couple of reasons why I wouldn’t release this version without the AI classes.
- If the Quantum name space sees major refactoring.
- If there is a surge of new Quantum components.
Summary
Version 0.1: Trunk up to the completion of converting code.
Version 0.2: Anything past the trunk revision of released 0.1 extension version.
Hope that clears things up.
PS
Anyone who wants to checkout (literally) and see how poorly (I suck, I know) a job I did and give suggestions, then please do so. I could really, really (please, I beg of you) use the direction and instruction. I want to stay as far away from asking questions to the internals as possible, unless I really have to.
Oh, I haven’t been testing whether the extension will compile or run, because I’m really not as much excited about fixing all of the bugs that would come up. Better to get the skeleton done before tackling the flood of compile and run time errors. If I can get the MINFO info to come up from the command line, then I think I’m doing okay.
The less people who know I’m building an extension (that is probably beyond my ability) the better. Of course, this is a public blog, but how many people read this that isn’t on planet-php? 4, 5, maybe 6 regularly (and that is probably 2 or 3 too many). So, I’m pretty much safe until that point. Rather not face the ridicule of much better (C/C++/PHP Core) developers.
PSS
As of this writing, I haven’t yet committed the header and source file for which the extension should compile. Also I’m kind of hardcore and didn’t use the PECL_Skel or the PEAR Skel.
Possibly Related Posts:
- Game Engine Development and Open Source
- Plans for Base CMS
- Bullet: E-Book Library Management and Content Server
- Using ZendFramework 2 beta1 For Directory Project
- Project Plans
If you want a stable revision for a specific version (i.e. so someone knows which rev is stable and can checkout or add an external to their own build) check about adding Tags. Of limited use until a useable stable version, but there all the same in Subversion.
I would switch to x.y.z version number – current being 0.0.1. No need to hit v1.0 quickly, since v1′s are “special” in a sense representing a finished product unlikely to substantially change until v2. Unlikely scenario until a full range of QGL components are added – which is a long ways off.
Will grab the ext code tomorrow and try compiling on my lame dev system (recent upgrade, and parts on order, leave me with basics – not bothering with a fuller setup until my PC is fully updated…).