Is it possible to do it in Construct?

New releases and general discussions.

Post » Sun Jan 04, 2009 1:01 am

Hello.

I'm new to Construct, so after a bit of tinkering I've decided to ask some questions, since I couldn't figure them out by myself.

First and foremost, is it possible to manipulate parameters of a behavior some object has at runtime? Say, I spawn a bunch of objects with platform behavior, and I want them to have slightly different parameters, for example one has jump strength of 800, another has 790, some of them have jump sustain enabled, some don't, etc.

Another question: is there an 'Object created' event condition? Say, I take Ghost Shooter tutorial and add some way for ghosts to respawn. I need to set the direction of every new ghost to random. Of course, I could add that action right after the one that creates a new ghost, but imagine there are ten different events that spawn ghosts. I'll need to add that action to each of them, and change it in all those 10 places every time I decide that the way to spawn them need to be changed (say, they need to have different colors, or different sizes with their starting health proportional to the size, etc.). Of course it's doable, and I could probably store all that custom initialization code in a function and call it from all those 10 places, but having an event that fires when the object is created seems easier.

Is it possible to make a tiled background cover the whole layout regardless of the layout's size? It should be pretty easy to do with events, but what about something like, I don't know, setting background's width to be something like CurrentLayout.Width? Or, for that matter, is it possible to stretch a background, or do I need a Sprite object if I want to stretch it?

Is it possible to make 'camera zoom in/out', so that the area of the layout that is seen is smaller/larger than the window's size? In Game Maker I could do it by setting view's 'View in room' and 'Port on screen' to be different from each other and that was it.

Is it possible to make split-screen games? Or' for that matter, anything that has several 'cameras'? For example, to make a sniper scope that shows a zoomed-in portion of the layout in addition to what is normally visible.

When I give an object platform behavior, it behaves in an unexpected way. I expect it to be completely 'transparent' (that is, the player can move through it freely), except when the player is jumping on it (that's when the object acts as a platform and allows the player to stand on it). In practice there's a situation, when the player is trying to walk through the platform. In that case the platform acts as a solid. Imagine the player standing on the ground, and a large block in his way, which is an object with platform behavior. The player won't be able to walk through it, but jumping through it works fine. Is that an intended behavior? The inconsistency (I can't walk through it, but I can jump through it) makes me think it's a bug.

Anyway, even if it's not currently possible to do the things I ask about, please tell me if it'll be possible later, or with some kind of addon. Say, if there's no 'object created' condition, but there is a way to add it - I'll gladly have a shot at implementing it (I do have some experience with C++), hoping to make Construct even more impressive and convenient than it already is.
B
4
G
4
Posts: 65
Reputation: 1,305

Post » Sun Jan 04, 2009 1:46 am

First off, welcome to the forums. :) Now to answer your questions.

1. You can manipulate pretty much all behavior parameters at runtime, and that includes the two you mentioned.

2. There's no condition like that, but here's how you could do it: every enemy has a value called "spawned". For the sake of the example, this should have a default value of 1 so it's that value when the object is created. Now check if a ghost has a "spawn" value of 1. If it does, then you can set the angle, position, whatever. Then simply set the spawn value to 0 so the event won't trigger for that enemy anymore.

3. It is rather simple to do with events. At the start of the layout, have the width of the background set to LayoutWidth and the height set to LayoutHeight. For this to fill the whole area the background needs to be flush with the top left corner of the layout.

4. Do you just mean zooming in? Or where the layout is seen but with borders around it? If you're just talking about zoom, it's a simple as going to the event editor and setting the zoom through the System/Set Zoom action. Or you have it zoomed in out on startup using the layer properties.

5. Split screen games aren't currently supported, unfortunately, and as far as I know there's no way to do what you want with multiple views. I think the devs have plans to implement them at some point, although it might not be until after 1.0.

6. I think that's the way it's intended, actually. I don't really know if there's a way around that.

Anyways, I hope that answers all of your questions well enough, and I hope it helps :)
Moderator
B
98
S
37
G
19
Posts: 1,584
Reputation: 17,817

Post » Sun Jan 04, 2009 8:00 am

[quote="Shviller":1glcubjw]When I give an object platform behavior, it behaves in an unexpected way. I expect it to be completely 'transparent' (that is, the player can move through it freely), except when the player is jumping on it (that's when the object acts as a platform and allows the player to stand on it). In practice there's a situation, when the player is trying to walk through the platform. In that case the platform acts as a solid. Imagine the player standing on the ground, and a large block in his way, which is an object with platform behavior. The player won't be able to walk through it, but jumping through it works fine. Is that an intended behavior? The inconsistency (I can't walk through it, but I can jump through it) makes me think it's a bug.[/quote:1glcubjw]

Are you talking about the Platform checkbox under Attributes? If so, yes the solid sides have been discussed and I've been informed that they'll be fixed in an upcoming build. So the way they'll work is they're only solid on top, but you can pass through on either side or from underneath.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Sun Jan 04, 2009 1:44 pm

Just to add a bit more info to what others have already said:

1. Most behaviors have their own actions, conditions and expressions. You can access these through the tabs that appear when the object is picked in the event wizard dialog.

2. I think the best solution for now is to use the function object. You could use a function like "SpawnEnemy" which spawns the enemy and does the startup actions on it. I thought about adding 'On created', but didn't think it'd be useful since it's identical to following the create object action with other actions. Maybe you're right though - I'll see if I can add it.

3. I think in the latest builds the Tiled Background can scale the texture inside, but only if it's a power-of-two sized texture (eg. 128x128, 256x256...)
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Sun Jan 04, 2009 5:33 pm

Thank you for your replies!

1. [quote="linkman2004":340vdx84]You can manipulate pretty much all behavior parameters at runtime[/quote:340vdx84]
[quote="Ashley":340vdx84]You can access these through the tabs that appear when the object is picked in the event wizard dialog.[/quote:340vdx84]
Thanks, Ashley and Linkman!I feel stupid for not clicking on that 'Platform' tab I saw in the event wizard.

2. [quote="linkman2004":340vdx84]There's no condition like that, but here's how you could do it: every enemy has a value called "spawned".[/quote:340vdx84]
A very nice trick, Linkman! I'll stick to it, since there's less places in event sheets to keep track of. If I notice performance issues (which seems unlikely) I'll switch to function objects, like Ashley recommended. Well, I'll probably have a whole lot of questions about how Construct works on the inside (for example is 'Compare private variable' condition evaluated for every object of the required type every cycle, or only when the variable actually changes, etc), but that'll be much later - only when I'm able to make those questions comprehensible.

3. [quote="linkman2004":340vdx84]At the start of the layout, have the width of the background set to LayoutWidth and the height set to LayoutHeight.[/quote:340vdx84]
Yeah, that's pretty much what I thought.
[quote="Ashley":340vdx84]I think in the latest builds the Tiled Background can scale the texture inside, but only if it's a power-of-two sized texture[/quote:340vdx84]
Good to know, thanks! By the way, I've encountered a small quirk that may be considered a bug. When the 'Set image scale' action is displayed in the event sheet, it only shows one argument, (X Scale), not two. Probably a legacy from the times when you couldn't set X and Y scaling separately.

4. [quote="linkman2004":340vdx84]it's a simple as going to the event editor and setting the zoom through the System/Set Zoom action[/quote:340vdx84]
Thanks for pointing that system action out, Linkman! I think I should read about all existing actions and conditions before I ask another stupid question like that.

However, I've noticed that the zoom is apparently applied [u:340vdx84]after[/u:340vdx84] the scrolling (both 'scroll to...' actions and 'center view on me' attribute), so if you have unbounded scrolling disabled it's quite possible to have the object the view centers on off-screen. The easiest way to see this behavior is to create a layout that can scroll only horizontally, place an object with 'center view on me' attribute somewhere at the bottom of it and use a System/Display/Set Zoom action to zoom to, say, 200%.

Another interesting thing with unbounded scrolling is related to System/Display/Set display angle. If Construct can't display the view without showing areas that are outside of the layout (because of the rotation), it simply displays it as if display angle is set to 0. If you move the view so that it can be displayed properly - it will be displayed properly. It's easy to see if you make a large (taller than the window) layout and an object with platform behavior at the bottom of it, set display angle to, say, 5 in the 'Start of layout' event. When you start jumping, the view will tilt when you're in the air, and go back to horizontal when you're on the ground - all without touching the Set display angle action.

It's particularly interesting to set the display angle to 180 - sometimes it will work properly (everything is drawn upside-down), and sometimes not (switching back and forth between normal and upside-down as you jump). I don't think it's a bug - after all, the user have disabled the unbounded scrolling property - but that 180 degrees thing seems just weird. Anyway, this quirk should probably be documented.

On the other hand, this "scroll first, zoom later" thing seems a bit counterintuitive, so it may be considered a bug. Even if that's the intended behavior, I'd really love to see it documented. I could add it to the wiki, if you like, just tell me where such info is appropriate. Well, if Ashley and others are ok with allowing mostly-strangers like me to edit the wiki, that is. :)

5. [quote="linkman2004":340vdx84]Split screen games aren't currently supported, unfortunately, and as far as I know there's no way to do what you want with multiple views.[/quote:340vdx84]
Aw, it's a pity. Well, Rome wasn't built in a day... By the way, is it possible to implement it as a plugin via SDK? If so, I'm willing to help. I have pretty much no idea about what's possible and what's impossible to do with it, though...

6. [quote="deadeye":340vdx84]Are you talking about the Platform checkbox under Attributes?[/quote:340vdx84]
Yes, Platform attribute is what I meant. Sorry for the garbled explanations. Good to know it's going to be fixed. By the way, thanks a lot for your great Platform School!
B
4
G
4
Posts: 65
Reputation: 1,305

Post » Mon Jan 05, 2009 12:11 am

[quote="Shviller":xuxvomh8]for example is 'Compare private variable' condition evaluated for every object of the required type every cycle, or only when the variable actually changes[/quote:xuxvomh8]
All events except triggers are evaluated every cycle for each instance. It still performs very well. Also, often events don't impact performance anyway.

[quote:xuxvomh8]On the other hand, this "scroll first, zoom later" thing seems a bit counterintuitive[/quote:xuxvomh8]
Huh? What do you mean? As far as I know, zoom works relative to the scrolled position, so at any zoom level with unbounded scrolling, the object you are scrolling to should always be in the centre. Maybe there's a bug stopping that from working normally. Upload a .cap perhaps?

[quote:xuxvomh8][quote="linkman2004":xuxvomh8]Split screen games aren't currently supported, unfortunately, and as far as I know there's no way to do what you want with multiple views.[/quote:xuxvomh8]
Aw, it's a pity. Well, Rome wasn't built in a day... By the way, is it possible to implement it as a plugin via SDK?[/quote:xuxvomh8]
It could probably be done, but the runtime would need a few changes. I was hoping the Layout object (which can display a different but not the same layout) could be upgraded to do this soon.

[quote:xuxvomh8]I could add it to the wiki, if you like[/quote:xuxvomh8]
Please, feel free to edit the wiki. The more people add to the wiki the more time I can spend coding instead of documenting. You'll need a SourceForge account to edit (and I need to pre-approve you so let me know your SF username).
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Mon Jan 05, 2009 12:51 pm

[quote="Ashley":3pn722ah]I was hoping the Layout object (which can display a different but not the same layout) could be upgraded to do this soon.[/quote:3pn722ah]
Okay, I gather that's a bit too serious for me right now, so I'd rather not mess with it, and leave it to the professionals. :)

[quote="Ashley":3pn722ah]As far as I know, zoom works relative to the scrolled position, so at any zoom level with unbounded scrolling, the object you are scrolling to should always be in the centre. Maybe there's a bug stopping that from working normally. Upload a .cap perhaps?[/quote:3pn722ah]
Everything is fine with unbounded scrolling, as far as I can tell. I messed the explanation with that double negative, sorry. "Disable unbounded scrolling". Ouch.

The deal is that when the scrolling is bounded, Construct apparently first resolves those bounds and then zooms. So, for example, if you have a layout that is just exactly as big as the screen, but you still set up all what's needed for scrolling. Zooming in won't enable scrolling like you'd expect (or, rather, like I expected), since it first scrolls to the needed point (in this case it stays in place, since the scrolling is set to bounded, and there's nowhere to scroll to), and then zooms - to the center of the layout, not to the object with 'center view on me' property.

It might be better to apply zoom first (so it changes camera viewport size before scrolling), and then scroll to the desired object. Hope this makes sense, I suck at explanations...

By the way, what do you think about that 180 degrees quirk? This one:
[quote="Shviller":3pn722ah]It's particularly interesting to set the display angle to 180 - sometimes it will work properly (everything is drawn upside-down), and sometimes not (switching back and forth between normal and upside-down as you jump).[/quote:3pn722ah]
Maybe it happens because of rounding errors? Those can be hard to fix...
B
4
G
4
Posts: 65
Reputation: 1,305

Post » Mon Jan 05, 2009 3:32 pm

You know, the more I think about bounded scrolling... rotating and zooming seem to be implemented with unbounded scrolling in mind (Ashley, please correct me if I'm wrong, after all, chances are it's your mind I'm talking about :)).

It is, of course, possible to circumvent those limitations of zooming and rotating I mentioned by enabling unbounded scrolling and manually create events that will keep it in check. However, it somewhat beats the purpose of bounded scrolling's existence, since it's purpose, as I see it, is mainly convenience.

Well, it's really up to you - whether to leave it as it is and therefore provide a simple sensible behavior that has to be manually reproduced when the user needs to make small modifications to it, or to spend more of the valuable time to make it more fool-proof. After all, fool-proofing is a fairly thankless job, since there's always some contrived situation you didn't think about (I can name one right off the top of my mind).

There are various levels of 'foolproofness', however, and I still think it might be a good idea to change the way System/Set Zoom action works, so that it can work better with bounded scrolling.
B
4
G
4
Posts: 65
Reputation: 1,305

Post » Mon Jan 05, 2009 5:31 pm

[quote:ylkky4wy]You know, the more I think about bounded scrolling... rotating and zooming seem to be implemented with unbounded scrolling in mind[/quote:ylkky4wy]
You're right, really - there are some relatively tricky problems with bounding and zooming/rotating. Firstly the maths becomes a bit of a headache with bounding limits. Secondly, you have to think about layers, which is the cause of the bounded zoom not working as you want. It's a known problem - it works fine in the middle of a large layout even with bounded scrolling, it's only when you come to the edge of the layout. Since you can zoom layers independently, then zoom the entire display, if you zoom in to 200% the display could be zoomed to 50% which means you still have to have the usual bounds. When bounded scrolling is on, it should never display anything outside the layout boundaries. It's possible to detect this situation though, so I can probably fix it (it's just a bit boring, heh).

The 180-degree quirk is a rounding error, yes. I thought I fixed it, but I guess not - when you rotate the screen 180 degrees the math sometimes has rounding errors like being 0.00001 of a pixel outside of the layout, which counts as outside the layout, which means go back to 0 degrees. Again annoying to fix. Of course the easiest workaround for all in the mean time is to use unbounded scrolling, and add your own scroll boundaries (possibly just as solid objects or something the player can't move past).
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,580

Post » Mon Jan 05, 2009 9:12 pm

The workaround you suggest is great, especially if you use a separate invisible rectangular 'camera' object (with 'Always scroll to object' event), since it will give the extra convenience of generating events on collision between this object and 'borders'. This way there'll be no need to make the borders solid, or otherwise make them interact with something - they will only interact with the camera object. It will also solve that 'scroll first and zoom later' issue, since you can change the size of camera object's rectangle. This setup can facilitate such complicated scenarios as "don't scroll outside of layout's bounds, except for the screen shake effect". Or even restrict the camera to some complexly shaped area in the layout. Or make the camera move 'on rails'. Not to mention that I always ended up using this 'camera' object anyway - every time I wanted non-trivial camera behavior, i.e. scroll a bit more in the direction the character is looking in.

The only problem with it is that you need to manually reproduce it in every game. One could move all the necessary objects and events to a template, but what if there is need to use another template?

All in all, what do you think that about adding a special Camera object? Or, better yet, it could be implemented as a Camera behavior and replace (or simply add to) the 'center view on me' attribute. This way, it can be implemented via the SDK by someone else (like myself), so that you can stay focused on more important things.
B
4
G
4
Posts: 65
Reputation: 1,305

Next

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 3 guests