Yes I know what you mean about those crashes, I don't know how exactely but for me by a mixture of doing editing steps in a different particular order and letting construct the time to process (not clicking around too much, which is hard) it seems to digest sprite edition a little better. it's still ctrl+s land tho.

For the full screen issue I found a great work around is to play in windowed mode without caption and by sizing the window 1920 x 1080 in the event sheet. WHen I really need to test full screen I export a little build and exit construct, then run the build. Much faster! Construct boots quickly.

Glory and success friend!

Edit: just to say you need to create a "window" ogject in the layout to have access to the window resizing actions. Took me a while to figure that out.

Personally I only use the collision mask for gameplay ingredients and environment. After A LOT of experimentation I found the quickest method to update, sadly, is to delete and recreate the object. After a few manipulations the collision mask just won't answer anymore. THis is also where I had the most editor crashes with construct so I put biohazard gloves whenever I start fiddling with this.

For the main character I can't imagine how I would use collision masks. I got a lot of script running for the collision and a lot more just for the visual of the character so they need to be independant. It must be very complicated to manage the two with the same sprite no doubt. For you it might be a change for the better, especially once you begin to have a lot of animations to manage.

CHeers!

oops sorry about that XD well if you need feedback on anything else just let me know. I like your game!

I think I've been blessed so far, biggest project I've ever created and construct doesn't let me down, knock on wood. I should post content (finally!) this month.

Funny anecdote, sounds like you're working closely with your muse. :)

So yeah, if it ain't broke don't worry about these details.

CHeers!

Very nice game! I like the concept very much and I think it can appeal to a lot of people, especially Nintendads. XD

I design a few boss fights and damn they are the most complicated feature of any games I worked on, eating up months of developpement. If I can give a few advices; boss fight is in great part the art of good attack anticipation, the longer the anticipation the stroger the attack, etc, and so the player can learn patterns. THe crabs claws could brust out of the water after a small splash signal, or the big balls could fall directly on the player's last position after a short "drop shadow" signal, etc...

Try to avoid exploits and force the player to almost constantly move. Nothing sucks more that seeing all your beautiful attack patterns totally useless when the player hangs in a particular corner of the map and keeps shooting till the boss dies.

Your crab is big and impressive, I think it should be somehow occupying the center of the screen more often.

KUTGW!

Wow very nice demo man! great potential. You have a nice variety of gameplay ingredients, tho I had to be very attentive to notice everything, they were not showcased like they deserve to be.

I'd turn the bunny hop off personnally.

Make sure you have a clear OCR feedback loop going on (objective, challenge, reward) this can be done by giving attack anticipation delay to your enemies so that they telegraph their intention to the player an give the player a chance to succeed the challenge, avoid being hit.

also give clear feedback when the character is being hit, like metroid. you'll see the potential OCR much more clearly once your game can transmit the feeling of pain to the player. :D

again, great job KUTGW!

oh damn there was actually a newer version of construct! sorry about that, I shouldn't stick to the update button. It's always a little stressing to overwrite your game engine ain't it? But the release looks solid.

wow I'll be having dreams about containers and objects pairer. So in the end all the functions of a "game object" module is actually handled by all these different little modules.

Ok, I should be able to find a way to make it work, you brought a lot of fresh ideas, thank you so much for your generosity.

Hmm I can't seem to be able to open your .cap with r1.2? Strange... there's a more up to date version available?

Well it's all about parenting, to put it simply I'm looking for the method to make "game objects" in construct.

Components, modules, ingredients, groups, classes... names vary between editors I worked with but in all cases the basic principle is having various objects parented to one entity, which is the entity I refer to when scripting, in order not to have to manage every single object individually.

That's why I used the "Enemy" family, which looked to me like the closest thing to a class in construct.

So not only do the enemy spawns with its visual, FX, collision box, triggers, etc, but when one enemy is activated, the game is able to identify which game object/group/module is alerted and activate only the right one, not all existing enemies in the world.

Right now I found a way is to check if the trigger box is simultaneously overlapping the main character, and the enemy to which it belongs to. But this looks like a hack and there must be a better, more bug-proof way to do it.

Well I hope that's clearer! :) Thanks a lot for all your help R0J0!

that's a neat trick!

I'm still searching how to express a group of objects into a string... I tried many ways, (sprite1, sprite2) {sprite1; sprite2}

But, correct me if I'm wrong, this would not "parent" the objects to one group. Like for instance, if my character steps into one enemy line of sight, all enemies would activate at once, and not just the one that saw my character.

infinite thanks!

sorry, don't mean to spam but this is still giving me a lot of troubles, can't find my way around it...

Posting new cap with the details mentionned above;

http://dl.dropbox.com/u/38319441/TestGrouping2.cap

oh niiice now I got independant look at, thanks!

but the spawning of object groups belonging to the "enemy" family still doesn't work properly. Each spawners seem to spawn at random one of the two objects the family includes, or neither. changes every time I restart the build.

what would be the correct way to spawn many groups of objects and affect these groups individually in that same independant way?

just that missing part and I can place my enemies in the levels. :D

Hello esteemed possessors of teh knowledge,

I've been trying for months to demystify the notion of object parenting in classic, I've tried containers, object pairer, families and FOR loops with just no success at all.

I've made a .cap quickly illustrating all those failed attempts and I thought maybe one of you guys could shed a light once and for all on this simple but complexe issue.

Object parenting test

Basically I want to spawn mobs with their own collision, visual, trigger box, etc... but this would be useful for any game objects!

Sincerely, thank you so much!

I'm glad it turned out to be a valid question after all! :D I'm gaining a little of my sanity back.

I never thought collisions were also based on overlapping. I thought that if I'm hitting a wall it was because it detected a collision.

Cool then, I'll investigate this overlap at offset action, it looks like a simpler way to compare positions. Also it's surely more reliable than my "sensor above the head" solution.

Thanks for the detailed help folks!