FP use of Stage vs Root Issue & Solution

(Playvue Games) #1

Hey “Punks”!

Admittedly, FlashPunk is still an engine I have yet to dive into myself, however, I am heavy into AS3 game dev.

As such, we recently ran into a significant issue w FlashPunk when loading FP games into our Flash-based game platform (so child SWF into parent SWF). One of the restrictions of this situation is strict adherence to Flash best practices regarding the use of stage vs root. Normally, this difference between these two is nil when loading your game from a standard HTML web page. However, when loading your game into a parent SWF, the differences are serious and tragic.

The issue is every SWF has it’s own local root object, but there is only ONE common stage. This means, that if you were load your game’s SWF in a parent SWF, say our platform, which just happens to be full browser window sized, and, for example, we center your game smack in the middle all nice and tidy, if you add a display object at (0,0) to the stage, instead of being added to the upper left corner of your game, it’s added to the upper left corner of the whole bloody browser window (i.e. the 0,0 position of the parent).

If you were to add that same display object to the root of your game’s swf, it will appear exactly where it should. This is because each SWF has a root, but they all share a stage. So, best practice (defined by Adobe, not us), is to always use root, as stage will vary from situation to situation but root will always be appropriate.

Unfortunately, it turns out that FlashPunk exclusively uses the stage. For everything. From the get go. Thus, every game made using FlashPunk (and, as an extension, HaxePunk, because it’s directly ported from FP), breaks when it’s loaded into a parent SWF.

Thankfully, we enlisted some help and have found a solution, which can be found here: http://github.com/playvue/DOFlashPunk.

This approach has been tested and confirmed to work in the situation described above, but I thought I’d open it up to the FP Pros for some honest testing, review, confirmation and feedback.

Please let us know what you think!

Keith @ Playvue

(Ultima2876) #2

Hmm, I’m not sure that I fully understand the problem here. As explained on the github site, there’s some problem that stops FlashPunk/HaxePunk games working with sites like Kong/Newgrounds… but I’ve never experienced or heard of this before. In fact, this is the first I’ve heard of any incompatibility with sponsor code shrugs. I do have a lot of experience with the engine also (both working with sponsors for primary licenses/sitelocks and from other perspectives).

I don’t see much harm in changing the Stage reference to a DisplayObject one, but could you explain the problem in a little more depth, perhaps with some examples? Why can’t the developer just center the game themselves in their code?

I’m sorry if I sound suspicious or whatever, it’s just that normally when a game is licensed properly that kind of customisation on the developer’s part would be trivial (literally, it’d take a minute or two for them to get it working correctly) :slight_smile:

I’m maybe just a little worried that this might potentially facilitate theft of games by some malicious people (not necessarily you), or is perhaps solving a problem that isn’t really a big deal and might lead to further problems down the road…

Perhaps some of the bigwigs around here can chime in and offer their opinions.

(Playvue Games) #3

Ultima2876, first, thanks for your (thorough) consideration. You clearly took some time to look at this, and I appreciate that.

But, I have to say it’s interesting that your first reaction was to question the premise that the problem even exists.

Regardless, Erik was a little zealous when (on github) he included Kong and NG in the list. The issue at hand is loading a SWF into a parent SWF (as I’ve outlined above). NG & Kong, to date, use HTML and thus, do not run into this issue. Loading a SWF into another SWF introduces security sandboxing at a base level in the Flash technology and purposely so by Adobe. The fact that you have not run into this issue previously does not surprise me, yet, the “issue” is quite widespread in the Adobe Flash community.

Regarding examples, I’m sorry. I was trying not to advertise our service in the process of seeking input/feedback, but our platform, which should provide clarification as to the specific problem at hand is available at http://www.playvue.com. This is an earlier version than the one currently under development, but still will clearly display the situation. And, should alleviate any concerns of ‘game theft’.

Actually, to that point of ‘game theft’, this is exactly why the issue exists: the parent CAN NOT access the child SWF, and vice versa. So, the developer actually can not coordinate proper compatibility except in allowing the parent to handle it without getting in the way.

Again, regardless, that is not the problem at hand. The problem at hand is that FlashPunk exclusively uses the stage, which presents conflicts when loaded into a parent swf.

More so, we are presenting a solution to this issue and seeking feedback on it. If you are able to comment on this, I would greatly appreciate your contributions. Otherwise, I’d prefer to keep this thread on-topic.

Thanks!

(Ultima2876) #4

That’s a good enough answer for me :slight_smile:

I’ll be honest, the main thing that raised a red flag was the inclusion of Kongregate as I have myself published FlashPunk games there before and not had any problems - so when that was included it made me a little (perhaps unjustifiably so) suspicious.

(Zachary Lewis) #5

I wish this were a simple fork of Draknek/FlashPunk so I could easily see the changes made (and so you could submit a pull-request to the repository).

I’d love to roll this into FlashPunk; however, this change would require a major version change (since the inclusion of a new constructor at the front end of Engine). I believe this issue could be skirted by changing the constructor to something like:

public function Engine(width:uint, height:uint, frameRate:Number = 60, fixed:Boolean = false, gameStage:DisplayObject = null)

This way, users looking to migrate to a new version of FlashPunk won’t have to muck with the constructor (unless they wish). Now, should this automatically wrap FlashPunk into a DisplayObject if none is provided, or will it default to stage (as it currently works)? Will changing the size of the DisplayObject stretch the game, or will it continue to function as-is (the game will render at the specified size and scale set by the user)?

(Playvue Games) #6

Hey zachwlewis, thanks so much for your suggestion.

Erik (@CaffeineViking, and the FP dev that worked up the solution) is, as-yet, “not so familiar” with github, so I’ll work with him to isolate his changes and add them into a new fork/pull request, as soon as we’re able, so you can better assess the changes involved.

Your fix for maintaining compatibility seems perfect. (In fact, it’s exactly what I would have suggested.)

Regarding changing the default behavior, I think you might consider the overall methodology and goals of FlashPunk.

If one of your goals is to stay in-line with the methodology of Adobe Flash/Actionscript, then a migration to avoid automatic assignment of the stage as the base class should be a priority. As a general rule, Flash reassigns the document class (or root) on it’s own given the current load situation, so root will always be the most appropriate base class, whereas stage is only the appropriate base class when there is only one SWF being used (although, that is the case in 90% of situations).

However, if you prioritize backwards compatibility with previous versions of FlashPunk higher, then, in that case, simply allowing for the reassignment away from usage of the stage as the base class seems appropriate, since this is only an issue in “fringe situations.”

Regardless, I agree that either permanent change should take place in the next major version and that adding the optional param to the Engine constructor is appropriate to support the change until then.

Thanks guys!

(Zachary Lewis) #7

FlashPunk focuses on being extremely simple. The fewer steps to getting something playable, the better. That said, having the power to make something more is also very important — FlashPunk should be just as much a professional tool as a beginner tool.

Here’s some helpful links to getting started with GitHub.

The majority of this can be completed with the desktop application as well, in case you’re afraid of the command line (or on Windows :tongue:).

(Playvue Games) #8

[COMPLETELY UNRELATED] OMG, I absolutely HATE Github’s Windows GUI interface. It somehow successfully manages to make a command line tool more confusing.

Thanks for the fork/pull info, though. I have yet to need to dive that deep into github, myself. So, expect me to make a mistake or several.

(Abel Toy) #9

Check out SmartGit or something, I guess. They are fully fledged GUI solutions for Git.

(Zachary Lewis) #10

Windows GitHub tool is actually really great once you know how git works. :tongue:

If it’s not your thing, I’d recommend SourceTree. Open source, full power, all GUI.