I'm wondering about this mostly in regards to background tile objects, and sprite objects. I've heard that background tile objects take up more VRAM than sprites. If that's the case, wouldn't it be better to use sprites in place of background tile objects? Instead of stretching out a BG tile object, just copying and pasting a sprite over and over? What's the advantage BG tile objects would have over sprites? Well... I guess if you needed to move a large BG tile object that's been stretched out in the middle of gameplay, that would be easier...

How are they that glitchy? I've never had much of a problem with them with anything else. Just one of two glitches, but they've been fixed. I don't see anything else wrong with them.

I've noticed that your plugin is extremely glitchy with modal layout objects. If someone, like myself, were to use one for game pausing, there would be a few problems in using this plugin.

In my testing, I had set controls in the middle of the actual stage itself, but when pausing, the plugin wouldn't work with the modal layout at all. I coped and pasted the plugin object to the modal layout, I set it to global, but it just wouldn't work. After unpausing, it seemed to work again, obviously.

1. Set controls during stage. These work.

2. Pause game, modal layout pops up. Plugin doesn't work.

3. Unpause game, return to stage. Plugin continues working, of course.

But if I set controls in the modal layout, that is, while the game's paused, it seemed to work. But after unpausing, the plugin wouldn't work at all. Even if I already set controls during the stage.

1. Set controls during stage. These work.

2. Pause game, modal layout pops up. Plugin doesn't work.

3. Set controls during pausing. These work.

4. Unpause game, return to stage. Plugin doesn't work during stage anymore.

The plugin seems really glitchy when it comes to using modal layouts. ^^ I hope this can be fixed somehow. I'd love to be able to use a real PC controller plugin.

If no one's said it yet, I thinking getting Construct to work with general PC controllers, not just the 360 control type, is a must. If you want this to go bigger and more public with a solid release, people are going to be expecting being able to use their generic PC controllers.

If I'm not mistaken, there's two control types, right? XBox 360 has its own type, so it's good that got out of the way, and then there's a universal type for all the rest? 360, and PC? I can't remember what the non-360 control type is called though...

But seriously, if anything, getting Construct to work with general PC controllers should be a top priority for 1.0.

[WARNING: I tend to get long-winded sometimes. I don't think this post is really all that long though, considering I wasn't trying to make it long]

This definitely doesn't fall under "Tech Support" but more "Help". Or rather... "Advice"? "Suggestions"?

In any case, I can't decide what to do about weapons in my game. First, let me introduce you to what I'm doing here. I have four characters, their species name being "Squishies". (Haven't been able to figure out a name for them yet.) Here they are:

<img src="http://i77.photobucket.com/albums/j42/Dreamer_Kisai/Characters.jpg">

A green one, red one, yellow and blue. Each one of these four has an elemental affinity, the green Squishy being wind/lightning, the red Squishy being fire, the yellow Squishy being earth, and the blue Squishy being ice/water.

As you can see, the player is supposed to be able to change which Squishy they're playing as at any time. You might notice a "Weapon" option below them. Here's the weapons:

<img src="http://i77.photobucket.com/albums/j42/Dreamer_Kisai/Weapons.jpg">

There are what's going to be known in the game as the "Elemental Weapons". There's four of them as well: sword, hammer, long-range, and pole-arm. As you can see, the player is going to be able to change the weapon they're using at any time as well. The Elemental Weapon changes its element, its shape, and weapon type depending on what Squishy the player is playing as.

For example, if the wind/lightning Squishy is using the sword, it becomes a rapier. If the fire Squishy is being played with that same weapon, it becomes a broadsword. Likewise, if the wind/lightning Squishy is being played, and the long-range weapon is equipped, it turns into a bow-and-arrow. If the fire Squishy is using that same weapon, it becomes a semi-automatic pistol with explosive rounds, for the fire element, of course (and I couldn't pass up a change to throw in one instance of a normal handgun somewhere in here).

Here's where this long introduction finally gets to the obvious matter of gameplay balance. If you've been paying attention, this comes out to 16 different weapons. 4 Squishies times 4 Elemental Weapons = 16 different weapons to think about and animate.

Let's get down to what I was worrying about. I was just starting so far, and trying to make the green Squishy's sword a rapier, you know, quick jabs, weak attack. The red Squishy would've had a broadsword, and I decided that since the red Squishy should have the highest attack, it should be the slowest, but shorter than the rapier for some balance. But then I thought, "A broadsword, shorter than a rapier? That might be a little silly." And then I was given the suggestion to give the earth Squishy a claymore for its sword-type. "But a claymore is about as long as a broadsword..." I thought to myself.

Would it better to nitpick over all the details of balance, or go ahead and keep the weapons a bit more accurate in size? I suppose I COULD make the rapier shorter than the other weapons... Seems like that could work.

Should I just go ahead and design the weapons and let them be whatever sizes they come out to be? This is the collision box we're talking about of course, how much of an area the player has with attacks. I considered making the broadsword one of the shorter weapons since it would have the highest attack out of all the swords, but maybe it could be one of the biggest ones if it has such slow speed to compensate. I'm not sure...

What do you guys think? I didn't even want to ask for suggestions on weapon attacks and sizes, figuring, "Well, I should be able to figure EVERYTHING out." but, you know, Miyamoto, Kojima, Sakaguchi, Sakurai, Naka and others didn't really work alone either.

...But then again, no one else has come to these forums asking for advice. -_-;

But the point remains. Any suggestions on weapon types? Sizes? Should that not be a worry?

And yes, I asked about weapon types, because I wasn't sure what to make the earth-elemental sword, and my first suggestion was an axe. Then I received a claymore as a suggestion afterwards. Anything you guys think about the weapon sizes, speeds, types?

As a side-note, I figured that wind/lightning Squishy = fast, speedy attacks, but weakest of the four. Fire Squishy = strongest attack, weakest defense. Water/ice Squishy = strongest defense, weakest attack. "Wait, didn't you just say the wind Squishy had the weakest attack?" Well, yes, but its speed should be fast enough to where it can deal more damage in the same amount of time the ice/water Squishy can. Ice/water Squishy would still have weakest attack as a result of not being speedy enough. And earth Squishy = ...I'm not sure. Well, I imagine we'd have to have ONE normal, regular, balanced, average joe fighter in there.

Ugh, and after this, I gotta figure out the combo attacks I wanna implement. I have the imagination, but nowhere near the programming skills for that.

Is this the best way to go about doing this? You know how in games, a message pops up, and it starts writing out text and if you push the confirmation button while it's writing, it instantly displays the whole page?

I wanna do that, but I'm not sure if the way I've done it is the most efficient way. Some copying and pasting is required, and bloating of the event sheet, but the way I've done it like this, it works exactly like that. The text will be writing, and if you push the confirmation button again, it displays the whole thing. Then you can move onto the next page.

But, I'd like it if someone could take a look and tell me if this is absolutely the only way of doing this, or if there could be a cleaner, more programmer-friendly way of doing this.

By the way, ignore line 8, it has nothing to do with this. It's a leftover from previous attempts at getting this to work.

<img src="http://i77.photobucket.com/albums/j42/Dreamer_Kisai/MessageBoxEventSheet.jpg">

Wait. In light of so much new glitchery I'm encountering in my .cap with newer versions of Construct, I take that back.

This... actually makes me feel depressed. I wish SO MUCH I could've thought of this. This is BEAUTIFUL. A WONDERFUL execution. How the combo was done, I wish I could do. The idea of the zoom-in for approaching an enemy, how the "blow" animation looks... ARGH. It's all stuff I'd wanna do in my own game. ;_; I just lack the imagination to realise any of it and the talent. This is awesome. The fluid animation, I want animation that nice... Argh. >< This has made me feel inferior now.

Are you kidding? As far as I was concerned a year ago, it already was. I've been working on my project for over a year now with numerous setbacks by Fate. I plan on it being a full-fledged, overworld-travelling, 4 save slot-having, combo-fighting, puzzle-solving, in-depth chapter-based story-telling, fluidly-animated platformer. I decided this a YEAR ago, and as you can tell, I've already been thinking about this for awhile before discovering Construct. If I thought Construct was ready THEN...

...Well, you know my answer. Seriously, how is this even a question? How can you NOT think Construct could make a major game at first sight?

...Yes. Of course. New COnstruct is glitchy in the sense that it doesn't handle events and such at all like old Construct did.

Also, I should mention here that if anyone wouldn't mind trying to work with me live with the events, that I could pop-up in the IRC chat room, or just do it over AIM. ^^

My current pipe dream project hardly seems to work in the new versions. One of the current hurdles that I've discovered is that certain events for the characters' animations don't seem to work anymore. They functioned just fine in the older versions... But newer Construct does seem to be quite a bit buggier. I'm not sure how to go about asking for help exactly, since there are a lot of events and trying to get things to work right again will probably get pretty complex. I'm thinking trying to get help for this should be done over messanger. It probably would be best to see the file in action. Is there anyone who wouldn't mind wasting some time and accept the file to try and fix what's wrong? I cannot, for the life of me, figure out WHY I'm having problems with the animation. I'm guessing just Construct glitchiness again.

The subject doesn't explain very well, but it's impossible to get what I want said in a simple subject line. I'll show you the picture first:

<img src="http://i77.photobucket.com/albums/j42/Dreamer_Kisai/Abilities.jpg">

Now the intended idea is that... You click on an Ability you want to equip... And one of those points moves down to fill in one of those slots. If you unequip a skill, one of those points moves back to the "Points Remaining" side-bench.

I wanted to do this in an effecient way where I'd only have to use one "Point" object, but it would probably be overly complex. All those "Point" objects you see are the same sprite. The "Point Slot" sprite next to the Abilities' names, however, are not. There's "PointSlot1", "PointSlot2", etc. ..."PointSlot3".

I kinda have it in a way where the farthest Point sprite to the right of "Points Remaining:" is selected to move to a slot. But moving it BACK is another story. How can I have it set where... say... "if Ability is unequipped" (in this case, global variable = 0) to then check for every blank spot at an offset of 32 pixels? The Hotspot of all those "Point' objects are spaced out by 32 pixels, and the objects themselves are 16 pixels. So in this case, I'd want an event that checks for a blank spot next to "Points Remaining:" every 32 pixels, and keeps checking. If a "Point" sprite is there, it moves to the next 32 pixels and checks THAT spot, and so on until there's an empty spot and designates that as its spot.

If that wasn't too difficult to understand what I was trying to do, and if anyone knows exactly how I can do what I want, maybe in a totally different method that what I think would work, however, let me know. ^^

P.S. Holy crap, not only does Construct glitch up, but so does its board. After that giant paragraph, right now, every thing I do in the text field, be it typing a letter like I am right now, or clicking anywhere on the text field with the mouse, is screwing up the scrolling so freaking bad. This text field is having a seizure as I type.