R0J0hound's Forum Posts

  • I don't think any of those are an application of the genetic algorithm. Mercuryus's example tweaks the jump as it goes but it's not following the algorithm. Radulepy's are more like ai examples.

    I tried my hand at the algorithm and came up with this:

    https://dl.dropboxusercontent.com/u/542 ... netic.capx

    It does this:

    1. simulates 100 objects moving with 5 seconds worth of random input

    2. scores them

    3. kills the lower 50

    4. creates 50 new objects by combining two of the survivors and adding some random mutation

    5. and finally repeat.

    It doesn't converge very fast but given enough time it will converge on the objects moving as far along the path as possible. I imagine the scoring could be improved to help it converge faster but I'm probably done with this.

  • It doesn't use a behavior at all. Here's a working example of the idea:

    https://dl.dropboxusercontent.com/u/542 ... ette2.capx

  • You could use the math here:

  • The algorithm itself looks pretty simple. The hard part would be coming up with how to design the creature so it can do something interesting. One way that seems useful to me is to make one creature and make it player controlled. If you can get it to kind of do what you want you can then take that and come up with a way to automate it.

    With the physics one it looks like torque is being applied at the joints. I'm guessing its properties are when to apply the torque and the amount of torque to apply. That is probably per joint.

    The initial values for the properties would be some reasonable random value. Like if it takes 1 second before the ball hits the creature then for the time to apply torque a value of random(0, 2) could be reasonable.

    There are probably more complex ways to model the creature. Some ideas that comes to mind could be to only start the timer when the obstacle gets close, or somehow take into account the orientation of the creature. Giving the creature some sensory cues could be useful too.

    I think it basically amounts to a bunch of tinkering and creativity.

  • Nothing is impossible. There isn't a built in way to change the collision shape at runtime though so that may be another issue to tackle. Even that isn't impossible. You could look at yann's polygon plugin or deal with a physics engine directly with JavaScript through the browser plugin. Although I admit the latter is hard to do.

  • Maybe give the loot some velocity too when it's spawned. To make an explosion just give an impulse in a random direction. Probably more satisfying would be to make the loot launch away from the player.

    I don't have access to C2 currently but probably something like this:

    Create loot

    Loot: apply impulse -3 toward position (player.x, player.y)

  • Here's one way. Give your spinner Sprite a variable and call it 'speed'.

    Then add this event:

    Speed>0

    --- add -50*dt to speed

    --- rotate self.speed*dt degrees clockwise

    That makes the spinner Sprite slow down. Now all that's left is to change the initial speed so it stops at a certain spot. The equation for that is:

    Speed=sqrt(2*decceleration*distance)

    In the event above deceleration is 50. So if you wanted the spinner to spin twice and land on 90 degrees you'd do this:

    Start of layout

    --- set speed to sqrt(2*50*(360*2+90))

    Or in the case of always landing on one of six positions you could do:

    On space pressed

    Speed <= 0

    --- set speed to sqrt(2*50*(360+int(random(6))*60))

  • You could run the contents of the editbox as JavaScript using the browser object's execjs action. That is the simplest but the feedback would basically just be a return value. I suppose you could add some functions that call c2 functions to provide more feedback. But arbitrarily running js is an issue since absolutely any js can be run, which can be an issue.

    You can look at the browser and function objects in the manual to see what I talk about above.

    A more advanced thing you could do is make your own parser that reads the editbox a character at a time to do your own coding language. This gives much more control or what can and can't be done by the user. This can be as complex or as simple as you like. Probably not easy if it's not something you've done before.

    I've done some expression parsers before that you can find on the forum, but reading outside sources may be more useful.

    I guess it depends on what you actually want the code to do specifically and look like specifically.

  • I got it working here. I set a global from one instance and was able to access it from another. Not sure if I can do anything too useful yet beyond that.

    Uou can only run js you include in your edittime or common.js. It's basically just plain js and anything the editor provides.

  • Either of those could be a spot to put a global value, but you may be better off making your own global variable. I think the edittime.js is put inside a closure so vars there aren't global as you say.

    I fount this snippet online as a way to get the global namespace.

    var global=Function("return this")();

    After getting that you can add a global variable with:

    global.myvar=1337;

    Then using something like:

    alert(myvar);

    Should work in any other edittime.js after that.

  • No, it's pretty limited. Instances can only access themselves.

    Here's all I've found to be available at edittime:

    I suppose you could make a global js variable and store references there. I think I've tried it one time, but I forget why it didn't work out.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Here's my current test for the adjusting of the normal for bouncing:

    https://dl.dropboxusercontent.com/u/542 ... oTest.capx

    You can drag everything around, and the red line is the visual normal and the blue line is the the corrected normal.

    The issue as you describe is when the angle the balls travel are perpendicular to the blue normal. Which would mean it's there is no perpendicular motion to reflect so it doesn't bounce.

    Mid typing this I re-uploaded the file with an idea that seems to work. It takes both the surface angle and the angle of the ball and doubles the y component before calculating the bounce. Then it halves the y component of the resulting angle.

    So if you end up using the normal from the ray caster plugin just add or subtract 90 (it doesn't affect the math) from that the get the surface angle.

  • Just halve to y component to do it:

    angle(0,0,cos(ang_surface), sin(ang_surface)/2)

  • That good it worked. The surface angle in my formula is 90 degrees from the normal angle so that explains why you needed that tweak.

  • The wait shouldn't be needed in this case. Wait is only needed when you create a physics object with events and you want to add joints to it. Why? because the behavior needs a tick to update the positions in the physics world. It's a quirk and when I made the chipmunk behavior you don't have to worry about such things.

    Anyways with your capx you just need to disable collisions between your physics objects. The collision polygon means they are overlapping so they will move out of each other and the joints will try pulling them into each other so it turns into a fight.