the official as3isolib blog

actionscript3 isometric library (v1/v2)

Participate in the Development of as3isolib.v2

Past Mistakes

One of the mistakes I made in making the as3isolib.v1 was going at it alone.  I did my research and investigated best practices but I didn’t engage a community like I should.  The result is a great library, but a flawed library with many architectural issues.  While these issues can be circumvented with minimal effort, it’s bothersome to me as the architect of this project that they are present.

Moving Forward

I don’t want to make the same mistake in developing v2.  Since April 2010, I have engaged several prolific flash game developers: in helping me inspect v2 code; discuss architectural ideas; and getting the best performance out of the Flash Player.  Now it’s time to start engaging the community.  I want your input to help drive the as3isolib.v2.

In order to kick this off I want to start taking polls.  Then once the as3isolib.v2.core gets to a testable state, I will engage some of the community in closed testing.  That testing will help me to develop the tools for the as3isolib.v2.builder app.

Without further adieu I present the first poll.

Naming Conventions

Now I am somewhat OCD and can mull over naming something for months.  Rather than wasting precious development time hem-hawing over a good naming convention, I’d much rather get your input on it.  There are 4-5 core classes that are used to create content with the as3isolib.v2: an engine, a camera, a canvas, a scene which contains entities.  While most developers could care less about the verbosity of how something is named (thanks to code-completion technology), there is something to be said about readability.  Parsing hundreds of lines of code is tough enough.  Having to pick out hard-to-read strings of text in that code is tougher.  So here are the naming conventions I am thinking about:

Advertisements

19 responses to “Participate in the Development of as3isolib.v2

  1. Pingback: Tweets that mention Participate in the Development of as3isolib.v2 « the official as3isolib blog -- Topsy.com

  2. Richard February 5, 2011 at 4:06 am

    I believe the naming convention should be short but as unique as possible. Of the 3 proposals with the most votes, the “Iso” prefix satisfies the former but not the latter (‘IsoCanvas’ is not clearly unique).

    I propose something along the lines of “AIL” for (As3 Iso Lib), which would be: AILEngine, AILCanvas, AILCamera, AILScene. It’s clear what each does, and that it’s part of an external framework.

    (One issue however is that the middle ‘I’ may be mistaken for a lowercase ‘L’, but I think it should be clear enough not to be an issue.)

    • Swingpants February 5, 2011 at 5:00 am

      I’m not a pedant about this but IMHO IsoEngine/IsoCanvas/IsoCamera/IsoScene conform to both qualities of short and unique. I can’t imagine a project using more than one Isometric library (I stand to be corrected here). Anyone visually parsing the code will quickly become aware of the used libraries. Any misunderstandings would derive from misinterpretation of a non-prefixed usage: Engine/Canvas/Camera/Scene. The ISO prefix does an adequate job of establishing context.

      There is no sign of an AS4 around the corner – AS2 is thankfully in decline so I don’t think language indicator is necessary.

      • Richard March 28, 2011 at 7:37 am

        Swingpants, you’re right. In retrospect it would be sufficient to use Iso as the prefix, as *which* Iso engine was being used would be evident in the imports. Also, the ‘A’ in my ‘AIL’ suggestion is redundant as, of course, it will be in ActionScript.

        Just something further to note: if I’m not mistaken, Ben mentioned something about developing non-iso engines in future (which would make even AIL an inconvenient name).

        Perhaps the best solution is to simply come up with a 2-letter prefix that is unique/recognizable and use that for this, and all future projects, along the lines of ‘UIKit’, ‘CGRect’, ‘CALayer’ to name but a few.

        My apologies if this comment does not move the discussion forward, at least we may be clearer on where we’ve been.

  3. Jos February 5, 2011 at 1:05 pm

    I agree with Richard. I’m not sure what the best concatenation would be however. AIL is ok. I keep hoping for one of those funky sounds-like-a-word TLA’s. This could be me over thinking it however.

    I wanted add something about your desire to have the community participate in the development of the 2.0 release. This is a great route forward, it is clear that projects can benefit from “the wisdom of the crowd”, and in this case, the great community of AS3 game (and non-game) developers. I’m curious as to why you would then only release it in dribs-and-drabs – ” will engage some of the community in closed testing”.

    What is stopping you from making the current state of the project open for all to help out with?

    I don’t want this to sound whiny or aggressive, as its truly not meant that way. I’m interested in the reasons for not opening it up right now to the whole community. I’m sure there are reasons for this, and i’d be interested in hearing them. Mostly because projects which I have been involved with have been ones which have been fully open – via git-hub or google code. I’m thinking specifically the development of RobotLegs, SwiftSuspernders & Signals.

    Looking forward to hearing more about v2, and the path to it!

    Thanks
    jos

  4. jwopitz February 5, 2011 at 11:05 pm

    I was also thinking of having DefaultIsoCanvas, DefaultIsoEngine, DefaultIsoCamera, etc…

    since eventually I plan to develop non-iso and non-2:1 type render engines. Specifically I had sandboxed a Zelda: Link to the Past style engine that makes use of all the same Core classes and such.

    I would even go so far as to lowercase the whole prepending As3isolib such that you have As3isolibEngine, As3isolibCanvas, blah blah blah….

    • Richard February 11, 2011 at 5:20 am

      If it’s the case that you will develop non iso engines, I would then recommend you come up with a unique name for your framework and use the abbreviated form as the prefix. This can be kept quite simple: why not just call your software “Render Engine”, in which case the prefixes would be as follows:

      REIsoEngine
      REIsoCanvas
      REIsoCamera
      REIsoScene

      Non isometric specific classes could be then named simply RECamera (for example) and other engine types may be named REFooCanvas

      (Bare in mind if you do not like “RE” as a prefix feel free to choose your own, my point remains the same.)

  5. Brian February 5, 2011 at 11:21 pm

    I like Scene, Engine, Canvas, etc… I don’t like when people name their variables by the type like “strName” or “entityArray”. And the “Iso” in front reminds me of that format. The user knows there Scene is Isometric because its in the isometric library. I am sure it will be in a package “com.as3isolib” so i think its redundant.

    The user is likely to extend all of these classes in the end, so it wont really matter.

  6. James February 7, 2011 at 5:52 am

    v2 will be optimized for mobile as well?

    • jwopitz March 27, 2011 at 11:42 pm

      I haven’t targeted mobile at this time, but that is a consideration. It kinda depends on how well things like PBE is optimized for mobile or any other technology I plan to leverage.

  7. Somonak Kao February 7, 2011 at 1:15 pm

    Personally, I think the naming conventions you’re using right now is perfect. For me, it makes perfect sense for Engine being IsoEngine. It’s immediately recognizable to as3isolib. I mean, if you’re importing the library to your project, you should very well know that anything Iso(X) is for the library or an extension of it.

    The other thing too is that it’s short. Everything else is too length or in Richard’s case, it can cause confusion.

    Without “Iso” in front of your modules and elements, it becomes too generic so if we were to reference those pieces anywhere in our own code, we’d have to note it ourselves. Why not kill two birds with one stone and just keep it the way it is now, it gives the library recognition and it’s easy on just about everyone.

  8. Alex Bogartz February 8, 2011 at 12:23 pm

    I think you should opt for the most unique but shortest convention possible.

    scene=new IsoScene();

    is very obvious and easy to remember. It also looks good on the page, unlike As3IsoScene which combines lots of funky characters and will lead to lots of typos.

  9. lennydizzy February 8, 2011 at 7:54 pm

    Any chance v2 will be open source?

  10. jwopitz March 9, 2011 at 12:00 pm

    good feedback guys. Thanks for the input.

    @lennydizzy – most likely no. But I plan on developing a licensing model such that individual developers and hobbyists are not alienated by an obscene price point. Nothing is final and since returning from the FGS in San Francisco this month, I have kinda narrowed my goals with v2.

  11. snick March 26, 2011 at 4:25 am

    Hola jwopitz

    i’m very exciting for the upcoming of v2, i suppose you are also diggin into molehill so this will lead to a faster 2.5d engine!

    I’m also bit scared about the licensing thing, really hope you don’t comes out with something weired like tweenmax licensing, and go for something more “normal”.

  12. as3isolib March 28, 2011 at 9:23 am

    I have debated since the beginning of v2 whether or not to even use the name as3isolib. While it’s great to be able to drive interest off v1’s popularity, the library may try to do something much more.

    Then again, I may just make this a pure isometric rendering engine and be done with it. I always think about the DVD/TV combo. It plays DVDs, and it shows TV, but it doesn’t do either one of them very well. I’d rather v2 be great at a few things than just ok at a whole bunch.

  13. jimtang June 27, 2011 at 7:38 am

    Just leave a simple note here from my own view.
    In v1, the package structure is a little messy, I can find interface definition here and there. For example, the class IsoGroup is under the display package however it implements IIsoScene under the display.scene package.
    Another problem is that Iso looks like IIso in some font style. Strongly recommend to remove all the Iso prefix. So I prefer the 1st choice.

    • jwopitz August 31, 2011 at 12:07 pm

      Thanks for the feeback.. I am on my 3rd rewrite of the v2 core classes. While I would love to just dump it all into an as3isolib.v2.* package, there are many data classes that really just don’t belong out in the open. And as for the “Iso” prefix, that is GONE!!!! I totally agree with you.

  14. jwopitz July 29, 2011 at 10:15 am

    @jimtang.
    I completely agree those packages got WAY out of hand. I am most likely going to set it up in a flat package structure: as3isolib.v2.* or keep the packages flat from that point on such as as3isolib.v2.events, as3isolib.v2.core, no further sub packages.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: