firebelly Like I said, most of my problems are due to me not knowing the proper workflow for Git. I didn't know that a baseless merge existed up til now, but it makes perfect sense. For clarification though can I ask, we should both be working on the same 'development' branch, comitting directly to that branch?

msv0001 Thanks for letting me know, it seems that link I've been using was telling me the completely wrong way of going about things.

I'm determined to get it working, so we can all have a good working example of how to use Git for Construct 2.

msv0001 For now I have 3 types added to my .gitignore:

*.uistate.xml

*.capx.backup

*.capx.backup1

This has reduced almost all of the conflicts; the last one is the main .caproj file.

It's not much, but take a look anyway!

Thanks for replies, I'm going to have a little poke around and see what I can find with this. I'll post a follow-up about it later.

Edit:

Ashley

The last conflict I'm getting is in the main .caproj itself, I take it I'll have to manually sort out conflicts with this?

Okay, I'm new to version control, and have been using Git as my preferred method. Everything worked perfectly when it was just me making commits (I assume because there would never be any conflicting files), but as soon my friend tried making commits the problems started. Conflicting files and Detached-HEADs galore.

In short, I don't know what I'm doing and I need some help, specific to Construct 2 and in general with Git. I know I need to add files to the .gitignore file, but I'm not sure what ones to add. A specific conflict we are having is with a layout.uistate.xml file; can I add this to the .gitignore, or is it vital for Construct 2?

Can anyone help me out with this, because it is absolutely vital that we use some form of version control, as Dropbox isn't a suitable alternative.

I've been having a lot of issues with GitHub for Windows and Construct 2. I'm guessing that a lot of it is down to me not knowing how to properly use it, but I'll explain what issues I'm having:

This is the method I've been following, along with the other guy in my team. We've got our main development branch, and both have our own branches for stuff we're working on. When we try and merge a branch into the main Development branch, it complains about conflicting files and refuses to merge.

Are we supposed to avoid working on say, the same layout, at the same time? It just doesn't seem to ring true to what I expected Git to work like.

Okay, a bit of a longer and more insightful post.

I recently picked up a temporary position at a toy shop so I've had precious little free time lately. Just before I got this job I made the decision to scrap most of the systems I had in place for Dungeon Buster as they were hopelessly convoluted and the more I added to them the more they came apart at the seams. I took a much more methodical and modular orientated approach to how I designed and implemented things. As a result I now have a fantastic dialogue system that I'm quite proud of, amongst other things.

Whew, this isn't dead! I've been busy lately. I started from scratch with Dungeon Buster, as far as mechanics go anyway.

<img src="http://i.imgur.com/9HlQs.png" border="0" />

<img src="http://i.imgur.com/ywLg4.png" border="0" />

-Snip-

My browser was being retarded.

Hey —, I was running it with CocoonJS, I haven't tried it in PhoneGap or Appmobi, but I'm assuming they'll perform even worse than CocoonJS.

Hi all, the trouble I'm having is the procedural dungeon generation event sheet reduces my iPhone 4S to ~3 frames per second, yet it runs fine on PC.

I've been testing and testing trying to isolate the issue and I can't seem to pin it down. I have debug text to show if the generator is constantly on (which indicates that it isn't). I also tested if it was the sheer number of sprites being generated that was the culprit; in short, it wasn't, it lags constantly regardless of the layout size it is working with. The last test I conducted was to manually paste in a large number of the tile sprites, rather than spawn them through the generator. The game runs perfectly fine with this, but it isn't really the solution I was looking for, confirming to me that the number of sprites isn't the issue.

Here is the capx

If you're testing this out on iOS, its a 3 finger touch to generate a dungeon.

I'm banging my head against a wall with procedural dungeon generation and iOS, the two just won't play well together.