1

I had a project setup like this in Adobe Flash Builder: (tried to illustrate it the best I could)

enter image description here

Basically, GameProj and TitleProj are compiled down to their own SWFs. They each have their own specific source-folder (src-nameofproject), as well as link to a common one used by the LoaderProj.

In addition, GameProj also refers to some classes in TitleProj, so it also links a source-path to Title's own source-folder (src-title, in this case).

Then, the LoaderProj is setup so that it "embeds" the gameproj.swf and titleproj.swf as ByteArrays, which it loads at runtime (with Loader.loadBytes())

But now I'm wondering how can I setup this complex multi-project scenario in IntelliJ IDEA?

I tried importing the Flash Builder workspace into IntelliJ, but when I try to configure the Project Structures settings, it keeps telling me there's conflicts of source folders between the modules.

How can I get around that? How can I compile it the same way?

chamberlainpi
  • 4,854
  • 8
  • 32
  • 63
  • did you read this: http://www.jetbrains.com/idea/webhelp/configuring-dependencies-for-modular-applications.html ? – snowdragon Jun 30 '14 at 23:33
  • I also had a similar problem when I switched from Flash Builder to IntelliJ, solved by adding multiple modules to the same project (File->New Module, Import Module) or just add multiple build configurations. – Alex Jul 02 '14 at 10:03

1 Answers1

0

Sorry, this is not an actual answer to your question, but rather a reformulation of your problem: I actually don't see a reason for compiling two different swfs, and embed them in a third one, if LoaderProj.swf is indeed the only swf you are using in the end ?

By including the same source folders src, src-title in several swfs, you are recompiling 2 or 3 times the same classes. It costs you more compilation time, more compilations (3 calls) and more complex project, more size in the final swf, several definitions of the same classes that might not be in-sync if you ever happen to embed old version of the sub-swfs, and that may or not override the root swf definitions depending on the ApplicationDomain in which you are loading the sub swfs.

Additionally you are adding runtime swf decoding overhead when loading the embedded swf from bytearrays and memory occupation for the duplicated definitions of shared classes.

I'd rather keep it simple and directly compile LoaderProj.swf with all the source folders, and replace the Loader.loadBytes() by simple instantiations. new GameProjMainClass; or new TitleProjMainClass; (replace by the actual current main classes of your subprojects)

multi swf setup could be relevant if they were not embedded in the same final swf, and loaded on-demand, but here it's like you're getting the worst of both world (single swf embedding everything you need VS dynamic swf loading)

jauboux
  • 888
  • 6
  • 12
  • 1
    Yeah I agree 100% with your suggestions. It's just that I cannot start changing the way the projects are setup (even if that means sticking to a crappy one, at that). I think the reason behind the individually compiled SWFs and the redundant source-path bytecode compiled in them is so that each SWFs can be tested individually (and faster), instead of having to launch the game from the title screen every time. – chamberlainpi Jul 02 '14 at 14:32
  • I realize that this could be dealt with some sort of static variable or a quick replacement before launching the game to say "currentGameState = new InGame", and once that's all tested, reset it back to "new TitleScreen". But, we're not so lucky in our setup! :( – chamberlainpi Jul 02 '14 at 14:35