Dalal's Forum Posts

  • Yeah if you find any web functionality that is missing, you can always write a plugin yourself. Construct 2 is very simple to extend. As far as image export goes, you are just taking the contents of the canvas and using the 'toDataURL' and putting that in an image tag, so it should be a breeze to implement. You could even export your game through Construct first, and then add the needed Javascript afterwards.

  • While you're waiting for a better solution from a more experienced user, here's two solutions I can think of:

    1. Define a new family called 'SolidObject', and add all your solids to this family. Test for a collision with 'SolidObject'. The down side to this is that every time you create a new solid you need to add it to the 'SolidObject' family.

    2. This is more hack-ish, but add a Platform Movement behavior to your bullet and set all the attributes to 0, and the 'Default Controls' to no. Now Platform Movement doesn't really do much except give you a new condition to test for. In your events test for 'Is by wall' for left and for right. Use an OR to test for both sides, and destroy it in the action. The benefit of this is that you don't have to worry about classifying all your solids.

  • Out of curiosity, why do you need to be able to access your variables using a string? That can get messy - especially when you decide to change a variable name. Perhaps there is a more elegant solution that we could figure out, if you don't mind mentioning the specific problem.

  • Now that sounds like a great option. I will look into it. Thanks Kyatric!

  • Yes, it looks like for my animation I can paste the images frame by frame using the Canvas plugin. My two questions:

    1. On export to AppMobi using DirectCanvas, will Rojo's Canvas plugin use DirectCanvas, because I may need it to be hardware accelerated?

    2. What would be a good way to store these frames?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • The way I'm doing it, it won't be too performance-intensive. I'm specifically targeting iOS devices for the first version, and a web prototype I did with Javascript and Canvas ran perfectly on an iPhone 4. It works well because I'm not calculating every single frame of the morph. I'm calculating about 30 frames spaced equally apart, and fading between them to produce the animation. That's all I need for my app.

    In the web prototype, however, I was able to store the images using Javascript and 'new Image()'. I would calculate a frame by dumping the image in the canvas, doing my processing, and then converting from canvas back to image, and storing the result in an array of images. Then I would later make continuous draw calls to the canvas, drawing images from the array to display the animation.

    If I were to write a plugin for Construct 2 that does the same thing (using the Javascript image type), what are the guarantees that it will convert gracefully to AppMobi for use with DirectCanvas? Otherwise, are there any other approaches anyone can suggest to achieving what I want.

    Thanks!

  • In the properties for the 8Direction behavior, set 'Set Angle' to 'no'. Also make sure 'Set Angle' is 'no' in all other behaviors that have this property.

  • I haven't played that game, but I think you might be able to get started by using Sprite Effects. There is an example in the Construct 2\examples folder called 'Sprite effects.capx' that you could look at to get an idea of how these effects work, if you don't know already.

    I was thinking that you could create a small circle sprite (or square) called "Ground" and set its effect to 'Destination In'. On the same layer, add your ground graphic to a sprite and call it "Ground Image". Make sure "Ground" is on TOP of "Ground Image".

    Now, if you set it up correctly, the "Ground Image" will only display where you have "Ground" objects. What you can do to start is have "Ground Image" fill up the whole screen, then place "Ground" objects all over it. Have an event that destroys "Ground" objects if they are clicked on.

    Now, when you run the game, it'll look like there's ground everywhere and as you click on different parts of the ground, they disappear. You can work up from there to get the effect you want. I think this is a good approach, because you can use the "Ground" objects to interact with your environment (such as by giving them a 'Solid' attribute), which will give the illusion of a real, dynamic surface.

    Alternatively, you can use the Canvas object to draw the ground dynamically as rfisher suggested. This will give you better results, but will be harder to code.

  • Oh, thanks Yann! I didn't realize arrays had instance variables. I'll probably go with that. Too bad I already used a sprite :P

  • Thanks for your responses guys. An array would make it unmanageable by making make the code even harder to read. I don't want to use global variables because by the time I'm done with my game I could potentially end up with like a hundred globals and that just seems wrong to me since I'm not using them globally. I guess it doesn't seem like there is much of an alternative then.

    Alright, I'll go with the Variable Holder sprite! It actually makes workflow pretty efficient. I could name it something like 'Vars', nice and short. Then I can refer to my variables like 'Vars.Distortion = 3' and the best part is that when I type Vars in the expression editor I'll get a list of all the variables I could use. So I really don't mind. It's actually faster than trying to remember the name of your global, or having to click System and select a global from a list. It just sucks that these have to be instance variables and not Event Sheet Specific variables. Perhaps if Ashley sees this as a useful feature, he'll go ahead and implement it. Til then, this is what I'll go with.

  • I want to create several variables that I can modify and access from my event sheet. Global variables would be overkill since other event sheets can access them. Local variables don't work because they reset themselves every tick. The only way I've found is to use a variable holder sprite with several instance variables, which feels like a hack and makes the code look weird. Is there some functionality of Construct 2 that I've overlooked, or is this the only way to do it?

  • Mulkaccino, oops, I actually misunderstood the question. I thought you wanted 'on A do B ONLY', and for all subsequent continuous occurrences of A 'do C ONLY'. In addition, I somehow thought you wanted separate actions for each condition. Sorry for the misunderstanding!

    Ashley, I'm curious to know why Else does not make sense after 'Trigger Once'? I thought that Else fires if the previous condition did not. Trigger Once will only fire once in a row, and Else will fire every OTHER time, right? So if you wanted something totally different to happened the first time in a series of repeated actions, this seems to me a viable solution. But perhaps there's logic better suited for this circumstance that I overlooked.

  • A variable-less option might be to have a 'Trigger Once' 'Else' structure as sub-events for each condition. Still a bit repetitive, but now you only have one event block, have to define the conditions only once, and use no variables.

    <font face="Courier New, Courier, mono">

    -------------------------------

    |[Condition A ]:              |

    |    [Trigger-Once]:[Action A]|

    |    [Else]        :[Action B]|

    |[Condition B ]:              |

    |    [Trigger-Once]:          |

    |    [Else]        :[Action C]|

    |[Condition C ]:              |

    |    [Trigger-Once]:          |

    |    [Else]        :[Action D]|

    |[Condition D ]:              |

    |    [Trigger-Once]:          |

    |    [Else]        :[Action E]|

    |[Condition E ]:              |

    |    [Trigger-Once]:          |

    |    [Else]        :[Action F]|

    -------------------------------

    </font>

    How's that?

  • The smoothing of the scrolling algorithm is very simple as far as I can tell. Let's say you have two positions A (X = 0) and B (X = 360). To smoothly move from position A to position B, start at position A and then add a fraction of the difference between A and B. The number you divide by determines the speed of the scroll. It provides a nice smooth scrolling effect without the need for any fancy calculations. Something like:

    Scroll.X = A.X + (B.X - A.X)/30 (experiment with that number 30, the higher it is, the slower the scroll). In this example, on the first frame, Scroll.X will be 0. On the last frame of this algorithm, it will be 360. The only thing that changes based on the '30' is the speed at which the scroll takes place. The starting and ending points will remain the same (which is one of the things Mulkaccino was talking about when he mentioned stick-to points). So this (the 30) is the number that should be tweaked based on the flick velocity. We can call this number the 'smoothing ratio'.

    To determine the smoothing ratio (which is what I'm calling the number to divide by i.e 30 in the example), take the flick velocity into account. Whenever they let go, get the difference between the initial touch point X and the release point X and divide by the time it took for them to perform this action (which will get you the velocity = distance/time). So you'll need to record the time the initial touch occurs, and then find the difference when they release, and then calculate your speed. The greater the speed, the lower your smoothing ratio should be, creating a faster scroll.

    A simple way to determine the smoothing ratio might be something like 30/speed. So now when you have really high speeds, you'll get a really low smoothing ratio. Experiment with numbers until you get something that looks natural based on the velocity of the flick. I chose 30 randomly. The best part about this technique is that no matter the speed of the flick, it will always scroll to the same position, and smoothly too. All the flick will determine is how fast this scroll will take place.

    Alternatively, you could do what Mulkaccino was talking about, which is a great way to do it that offers the user control over HOW much they scroll based on velocity. Calculate the velocity using what I said above and then apply that velocity to the scroll as follows:

    Scroll.X = Scroll.X + Velocity * dt.

    Every frame, keep decreasing the Velocity (by a multiple of dt I guess) until it equals zero.

    The only problem with my version of this approach is that you won't have a defined end point for the scroll. They could potentially flick too fast, causing the scroll to go on for way longer than expected. You could limit the speed of the scroll, but then it may feel unnatural because the speed did not initially correspond to the flick. Mulkaccino may be able to offer more insight in this area.

  • If I'm understanding this right, the first event block handles the first occurrence of those conditions, and the second block handles all subsequent occurrences of those conditions. Is that correct?

    If so, could you get by with setting a Boolean from ON to OFF when these conditions are run, and include Action A in a sub-event of Condition A that only runs when this Boolean is ON? Likewise, include Action B in another sub-event for Condition A that only runs when the Boolean is OFF. Alternatively, use the new 'else' logic so you only have to test for the Boolean once. Does that work? And let me know if I need to elaborate.