Suggestion: Combining Construct Projects

I seem to get a little frustrated when doing a large test project. It is because only 1 person can work on a project at a time and it cant be done by several people at once. Can the future Construct be able to allow users to like uhh work on separate parts of a project and just combine them or something? This way, it would be much more faster to make games in construct.

I'm thinking it could be done through layouts, like copy pasting a layout into another construct project and everything in that layout is transferred and etc.. you get the picture.

I second this. Sometimes I wish there was a way to collaborate on a project... importing stuff, etc.

What in code would be copying functions and classes, or libraries.

Or outsourcing. Example: If I have an event sheet full of not object related functions, I would like to export them, so I can import them in another project as needed. Would speedup the workflow as well as letting you build up a library.

Yeah, this issue could be one reason why its takes a bit too long for a project to finish, since you'd expect only one person is and can do the project at a time.

Uhm, you can just use DropBox.. I mean, DropBox offers the possibility to have an online directory, and you can access it everytime you want. I'm doing my project between 2-3 computers, syncing changes by DropBox.

Anyway, not a bad idea..

One way to implement this is to make .cap files text-based. This has several benefits:

• it's easier to debug it if something goes wrong
• it's possible to do simple editing outside Construct IDE
• with good organization of text-based document, collaboration comes "for free" when you some source-control tools (for example SVN)

There are also downsides:

• .cap files would become bigger (in the range 3-5 times, maybe even more); not a big issue, since text based files are compressed well
• time is need to implement it; but time is needed to implement <anything>, it's just about choice what to do
• Construct will need to support both binary and text .cap files; on the other hand, since there is already support for versioning of .cap files, this would only mean enhaced support for it
• problem of binary files (like images); not sure what's better - just to store them in binary form, or store them as hex numbers (meaning two bytes in cap file for each byte of binary data)

Some overloading of << and >> operators on CArchive in StdAfx.h (which seems to be included in all files), as well as updating READXXXFROM macros in CapReader should give results pretty soon. Anyway, I'll try to play around with this idea and report if I can make out something of it.

One way to implement this is to make .cap files text-based etc.

In C2 .cap files will be pure XML. Or so the story goes...

> One way to implement this is to make .cap files text-based etc.

>

In C2 .cap files will be pure XML. Or so the story goes...

What will XML feature compared to what Construct have now? Will this even change Construct in some way's?

Well yeah, for one you could edit your game file with any text editor, which means that you make events by writing code if you wanted. Importing/exporting bits of your game would be easier too, meaning you could have a team work on a project much easier than you can now.

Theoretically, that is.

Sounds like it will become scripting obligatory, I hope that in Construct 2 you aren't obliged to use text editing, sound's kind of hard, I presume it is optional, I can't say about being easier for team editing since I never worked in a team tough.

Just to clarify it - my idea was only to change format of .cap files. Nothing in workflow of Construct itself would be changed, only .cap files would change.

I work in game development team, and we were thinking of using Construct, but since it has binary file formats, it (still) doesn't work for us.

If Construct is indeed moving towards XML, that's even better news, but I understand that's huge task which needs lot of time o accomplish.

Sounds like it will become scripting obligatory

Why would you say that?

Anyway Ash has said that the event system will still be there, it's just that events will create an .xml file. Think Dreamweaver... you are using a GUI to make an .html file... which you could also code by hand if you wanted to. Same thing. It shouldn't be obligatory at all.

If Construct is indeed moving towards XML, that's even better news, but I understand that's huge task which needs lot of time o accomplish.

Just to clarify, this is something planned for Construct 2.

> Sounds like it will become scripting obligatory

>

Why would you say that?

Anyway Ash has said that the event system will still be there, it's just that events will create an .xml file. Think Dreamweaver... you are using a GUI to make an .html file... which you could also code by hand if you wanted to. Same thing. It shouldn't be obligatory at all.

> If Construct is indeed moving towards XML, that's even better news, but I understand that's huge task which needs lot of time o accomplish.

>

Just to clarify, this is something planned for Construct 2.

Which very likely wont be ready in a real, usable form for quite a long time. So anyone thinking of waiting until then might just wanna get used to the current version and find workarounds.

Well if you say so, I'm fine with it

>

>

> > If Construct is indeed moving towards XML, that's even better news, but I understand that's huge task which needs lot of time o accomplish.

> >

> Just to clarify, this is something planned for Construct 2.

>

Which very likely wont be ready in a real, usable form for quite a long time. So anyone thinking of waiting until then might just wanna get used to the current version and find workarounds.

In that case I should get my hands dirty with my ideas soon