Is it possible to do it in Construct?

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.

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

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.

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.

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...)

Thank you for your replies!

1.

You can manipulate pretty much all behavior parameters at runtime

You can access these through the tabs that appear when the object is picked in the event wizard dialog.

Thanks, Ashley and Linkman!I feel stupid for not clicking on that 'Platform' tab I saw in the event wizard.

2.

There's no condition like that, but here's how you could do it: every enemy has a value called "spawned".

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.

At the start of the layout, have the width of the background set to LayoutWidth and the height set to LayoutHeight.

Yeah, that's pretty much what I thought.

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

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.

it's a simple as going to the event editor and setting the zoom through the System/Set Zoom action

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 after 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.

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.

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.

Are you talking about the Platform checkbox under Attributes?

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!

for example is 'Compare private variable' condition evaluated for every object of the required type every cycle, or only when the variable actually changes

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

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]

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.

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?

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

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).

I was hoping the Layout object (which can display a different but not the same layout) could be upgraded to do this soon.

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.

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?

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:

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).

Maybe it happens because of rounding errors? Those can be hard to fix...

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.

[quote:ylkky4wy]You know, the more I think about bounded scrolling... rotating and zooming seem to be implemented with unbounded scrolling in mind

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).

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.

What specific actions, conditions and expressions would you have in the camera object/behavior? It sounds like an interesting idea, but I'd need to see a full spec to fully appreciate what it could do.

A Camera behavior might be useful. It could make zooming/panning easier, especially during cutscenes.

Actions:

Set View - set the current camera as the one to be looked through (if there is more than one camera)

Pan to object/point [speed|slowin|slowout]- move to and stop at a certain object over time with slow start/stop for natural movement.

Cut to object/point - jump instantly to an object

Follow focused object - would work pretty much like Center View On Me but you could set different objects to follow by using Pan or Cut to set the focus

Zoom [speed (in percent per second)|target amount] - zoom in/out over time until target zoom amount is reached

Tilt [speed (in angles per second)|target angle] - uh, yeah

Shake [amount|duration] - Maybe? I dunno, might be too much (you could use the Shake behavior)

Wobble [amount|duration] - Maybe? I dunno, might be too much

Fade [duration|in/out|color] - Maybe? I dunno, might be too much (you could use a Tiled BG with Fade behavior)

Conditions:

Object has focus - test if a specific object is the focus of the camera

Is focused - Test if the camera is positioned directly over the object currently in focus

Is active - test if the selected camera is the one being looked through

Is panning

Is zooming

Is Tilting

...uh, I don't know what all conditions you'd need. Depends on how complex you'd want the behavior to be I guess. Same goes for expressions.

I know all of these things can be done with actions, but maybe it's useful enough to make into a behavior

Wow, love that idea deadeye. Hope it will be considered after the 1.0 release.

After some thinking I've arrived at the idea that the hypothetical camera behavior we're discussing can (and possibly should) be fairly minimal. You see, there's a lot of contrived situations, and it's a good idea to minimally restrict the user. So here's what I suggest.

Add a 'Camera' behavior (and possibly ditch the 'Center view on me' attribute, I'm not sure there'll be a use for it with this Camera behavior) and a 'Camera boundary' attribute. Objects with Camera behavior won't be able to pass through Camera boundary objects (those are effectively camera-specific solids). Give the Camera behavior a bunch of parameters:

• Rotate camera - equivalent to the event Always set display angle to Self.Angle
• Scale camera - similar, only links zoom to object's size
• Make 1:1 - on layout start makes the view show only the area covered by the sprite. Probably redundant, but it eliminates the need to change both the camera object size and the initial zoom factor when you decide to change the size of the viewport during development. Likewise, eliminates the need to change the initial zoom factor when you decide to change the window's size.
• Create default boundaries - on object creation creates four rectangular objects with the 'Camera boundary' attribute framing the layout, so that the user doesn't have to do it manually.
• Invisible on start - on by default (I see no reason to leave this object visible, but someone might want to...). Sprite object already was this in 'Appearance' , but it might be a good idea to duplicate it in the Camera behavior, so that all relevant things are grouped in one section. However, that could probably cause untold problems with resolving two identical properties. By the way, why don't, say, Tiled Background objects have this property? Also, why there's a way to edit the image associated with a Tiled Background object (Properties/Properties/Image), but no way to do the same with a Sprite object?

This will hopefully take care of the basic things. Now about 'Pan to object' and 'Follow object' Deadeye mentioned. Those should probably be separate behaviors, or one behavior with a lot of parameters. So that the object has 'Camera' behavior to actually control the viewport, and another behavior to follow the character or whatever object is 'in focus' right now. After all, there seems to be no 'Chase another object' behaviors right now, and having one would be very useful. There's a lot of useful features that can be crammed into such behavior, I'm not ready to say anything useful about it right now.

Why bother and split it into two behaviors? Well, 'Chase' behavior is useful on its own, and besides there are always times when canned behavior doesn't cut it, and user will want to have a different way of moving the camera - using events and/or other behaviors.

Now about tilting, wobbling and shaking. Well, there already are some utility behaviors for that, but I have a different idea. What if someone wants to use Sine behavior, only applied to object's angle, not it's position? Or a cycloid instead of a sine wave?

A while ago I tinkered a bit with Ogre3D (and in the end decided that it's way to early for me to dig into full-blown C++ programming and 3D), and stumbled upon a great feature: controllers.

The basic idea is that you attach a function to a variable, so that the variable changes on its own without the need to explicitly change it's value each step (or, in Construct's case, no need to clutter event sheets with technical calculations). So a controller has a value it changes, probably some values it takes as input (TimeDelta is the first that comes to mind), and a function that calculates the new value based on the input values (and possibly the old value). The function can be programmed to be anything, of course.

I have no idea if it's at all possible to implement it in Construct, but that would be a very cool feature. Anyway, it can be emulated with events, but not all that easily. The way I'm seeing controllers, they attach to the specific variables of the specific objects, so when you try to simulate them with events you need to pick the exact object you need.

So all in all there'll be up to three different aspects to implement a good camera: Camera behaviour to attach the camera to the object, Chase behavior to make this object follow the player, and some controllers to shake this object (and the camera with it), if it is needed.

There are two things I haven't thought about: multiple cameras (Imagine that we want to have different boundaries for each camera in the layout. A single 'camera boundary' attribute is insufficient for that. Now if it stored an object ID...) and camera-specific effects. That is, effects that 'live' in the local coordinate space of the camera, and not in the global coordinate space of the layout. Say, horizontal waves on the screen representing dizziness. Now those should stay horizontal (respective to the camera) no matter how the camera is rotated. UI overlays also fall in the same category. So, there's the need to rotate some of the layers together with the camera objects. Now that I think of it, controllers could help with that, linking the required layers' angles to the camera object's angle via the trivial 'output=input' function. That might be a bit counterintuitive, however...