Arcane: Doesn’t work that simple. When you load the API in via loader, you’ve basically stripped it of all its class definitions, and you can’t strongly type them into a variable and work with it.
Proverbial pain in the butt.
|
|
Arcane: Doesn’t work that simple. When you load the API in via loader, you’ve basically stripped it of all its class definitions, and you can’t strongly type them into a variable and work with it. Proverbial pain in the butt. |
|
|
Its not stripped of its class definitions, its stripped of the interfaces that provide the compile time error checking that strong typing allows – compared with the component, that is. It does actually work that simple, since those who use manual loading can easily store references using untyped variables. Typing them is not necessary. The reason an alternate ‘shadow services’ file was provided is to allow runtime errors when testing locally to accommodate those who wanted to avoid the component. The component is nothing more than a loader itself and a collection of interfaces to allow strong typing, probably along the lines of what you did for yourself. It does not contain the actual API, nor does it have compile time access to the API class definitions themselves, only the interfaces. We could easily distribute the interfaces to allow strong typing, but we’ve chosen to avoid doing this in code form as it allows more room for error on the developers part – and possibly more questions that we have to answer as a result. The point is to focus as little attention on the API as possible. We could distribute more and more files for every situation, but then there is more to track for us, more for people to have possible problems with and more clutter in the documentation. It is complicated enough as is really, and more files are being distributed than preferred. |
|
|
This is probably out of scope for this thread. I’m not saying I totally understand/agree with what you’re saying. lol We can discuss this elsewhere and you can elaborate to me in more detail ^^ |
|
|
I don’t think thats really necessary, unless there’s a specific problem that needs to be addressed or integration help is needed. There should be sufficient info here to give the typical AS3 programmer what he needs; and as you know we’ve discussed this previously anyhow. If you have specific methods of handling the API when you are manually loading, thats great; thats what was hoped for and expected of developers should they choose that route. |
|
|
Maybe I can mail you what I have done so far and you can have a look and maybe give me some advice? that would be great :) |
|
|
This is great! I didn’t expect so much documentation and attention to detail in the API. Awesome work. |
|
|
@TastyLamp: Thanks :) @Dazzer: I did some double checking right now and the component works perfectly in FlashDevelop. It worked as expected when testing locally and connected to the API fine when I uploaded it. The newer versions of FD support swc usage, so a developer can add the swc to his project’s compiler options and integrate the API the same as in the Flash IDE – with strong typing, compile time errors and shadow services. If a developer wants all those features, he should use the swc file. Just make sure you have the Flex 2.0.1 patch for Adobe Flash CS3 Professional compatibility. |
|
|
Maybe that’s what I was missing. ^^ Thanks. edit: Ah I see what I did wrong now… lol I went a whole round circle ^^ |
|
|
I’ve written an article with source code about how I load the Kongregate AS3 API into my games at runtime. I’ve used this code in my two games that are on Kongregate. Cubical and Tetrical. |
|
|
Cool article, glad to see the API is being used! Only thing with the source code is, you’ve pretty much re-written much of the code in the component. The component is basically a compiled version of a loading class ( like yours ), put together so everyone wouldn’t have to write that stuff if they didnt want to. The main difference being, the component also includes interfaces for better error feedback and encapsulates helper methods like custom events – as you also wrote. Good job though ;) |
|
|
My motivation for writing it in this way was for developers that post their games on multiple sites that might have different APIs. This way the API is simply loaded at runtime if it needs to be based on the domain. I haven’t looked at how many bytes the Kongregate API adds to a compiled swf. I doubt it’s very much, but for some people it might make a difference. Anyways, thanks for finally getting the AS3 version out. I was waiting for it for awhile, and I will definitely be using it more heavily in my next game. |
|
|
You can do the same thing with the component. The component wont load the API until it is added to the stage, so whatever code logic is being used to decide whether or not to load the Kong API can be applied just the same to the component, swapping out whatever APIs you want to use. Again, the component doesnt actually contain the API, it loads it. It only adds around 3k to your file. I dont think that makes much of a difference for most people :) Of course, its great to see you fooling with this stuff because thats what we want ;)
|
|
|
How can i read the stats information? i can use the method ( submit(name:String, value:Number):void) to write the stats information, why i cant read it for more uses |
|
|
DigitalMachina — thanks for your API loader classes, I was having some issues with the component version and your code worked great. |
|
|
The AS3 component doesn’t appear to work for FLEX apps… I get the error: |
|
|
I figured it out, you need to add it like: this.rawChildren.addChild(kongregate); |
|
|
I am trying to get the AS3 API to work in haXe: ….but running it locally I get a security error. If I force my way around that by getting a local copy, running it local-with-filesystem, it fails at kongregate.services.connect(); with the services field not found. |
|
|
In case someone runs into the same problem I did… If your game loads in a swf from another server, the API can not be loaded into that swf. It used to work, but apparently it doesn’t anymore. The API has to be loaded into the file that gets served from kongregate’s domain. I just spent all day figuring that one out. :P My game loads the main file from a remote server, so the file on kongregate is mostly just a preloader. I had to add the API component to the preloader, and then pass a reference of the component to the main game once it loaded. |
|
|
Is it okay to contact Kongregate and request for badges to be made (and to suggest some) for your game or do they have certain internal criteria for choosing what Flash games get badges (popularity / statistic quality / etc)? If a request is allowed, who do you contact about this? |
|
|
Nice to know |
|
|
Has anybody had any joy or fail trying to use the stats API using mxmlc directly? I use TextMate to build my AS3 projects using Flex3.1 and I’m currently loading the API externally, which is not ideal. I’d much rather use the .SWC component but it’s not clear about how I should do that and how to integrate it properly with my flex distribution. I think what it needs is the intrinsic classes to work with, so that I could drop them into my library path and build the project without the compiler errors. Are these available anywhere? |
|
|
Can
work for the API? |
|
|
Why do you need a progress event listener for the API? |
|
|
What is the point in having both stats and scores, cant both be used for badges, also scores bit of the API seems much more capable than stats with the set mode that stats doesn’t have. |
|
|
can anybody help me here? |