Mort's Forum Posts

  • Good work getting in PCG!

    You could probably fix the collision detection problems you mentioned earlier - if you set minimum FPS to 60, it'll slow down instead of skipping a frame.

  • Hey, Construct has events and conditions. Right click on something like 'always' or 'on collision with x', and see what comes up.

  • Ohhh, right! I get it now.

    Sounds useful, actually.

  • If I'm understanding it correctly, that sounds like a feature Construct already has. If you want a sprite to have different opacity in different areas, can't you just change the alpha values of those areas in the image editor? (Or import a PNG file with the correct transparency.)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • It was on JayIsGames as well. Nice one!

    http://jayisgames.com/archives/2009/06/ ... oad_90.php

  • This might be simplifying it, but:

    You can't really combine the Physics Behaviour with other movement behaviours. This is because the physics behaviour is expecting to see the object physically move around (because you applied force to it, or something ran into it, or whatever.) If you don't move it using force, then it's acting really weirdly from the viewpoint of the physics model - kind of warping around the place without actually moving - and you'll get really weird results.

    So just apply force to the character to make him move around, and remove the 8 direction behaviour completely. Here:

    http://files.getdropbox.com/u/906550/Co ... hysics.cap

  • It's fun to fire across such a long distance. You should post it again when there's something to shoot at.

    There is definitely a less tedious way to make the events for it, though - instead of creating a sub-event for each state it could be in (anim frame = 2 then set speed 60, anim frame = 3 then set speed 70, etc), you can just create one event that takes the animation frame into account (set speed to 50 + anim frame * 4).

    Similar for the charge-up bar - instead of using an animation you could use a sprite, then resize it to the right width depending on how charged up it is.

    Here's how it would work:

    http://files.getdropbox.com/u/906550/Co ... stions.cap

    I wouldn't recommend using Python unless you're already really skilled with it. As I understand it, Python's kind of an afterthought for Construct - you can definitely do everything without it (and probably should).

    You can do a lot with loops and families once you get to know them them. Here's a fairly amazing example one of the developers posted a while back:

    http://files.getdropbox.com/u/906550/Co ... locks2.cap

  • ...or if by scripting, you meant using Python: yes, you can do all of that without Python.

  • I think the 'heap of mini-games' idea could work really well. Just imagine the insane stuff this community would come up with!

    It'd be a great way to show off the features of Construct, since different games could showcase different areas. Also, it'd avoid a lot of the problems associated with collaborative projects: different artistic directions, the need for coordination of different project areas, project bloat leading to collapse, etc.

  • Well... I made a little iso engine that seemed to deal with the Z order problem okay.

    You just have a layer for each depth, and then order objects within each layer by their Y position. It's really limiting if you want to have completely variable heights (like how X and Y coordinates are continuous), but if you just want simple floors, it seems to work reasonably okay.

    (I think there are probably at least six better ways to do it, but if you want to look at the engine, you can. This one only solves the problem for the character, but I was able to make one that updated all the terrain as needed, using a similar method.

    http://dl.getdropbox.com/u/906550/iso%20demo.cap

    I hated this engine so much that I scrapped it and started over, hoping to make something based on a built-in map editor. But nothing to show for that yet.)

  • I'm pretty sure there's no way to tell what individual particles are doing, so you can't tell when one leaves the layout.

    But changing the timescale can be done based on how long you'd expect it to take to fill the screen, so you can just set timescale to 20 at the start of the layout, then to 1 when timer = 15 seconds, or something like that.

    Regarding the effects - yeah, I see what you mean! I'd never noticed that before. It only seems to happen with some effects: "Outline" or "Greyscale" apply correctly, but "Soften" works for one instance of the particle object and breaks the others.

  • Looks good, runs fast, and I think it'd make great snow, also! But it takes such a long time to get established.

    Tried making a situation where the timescale was really high for the first few seconds (to quickly set up the starfield at the start). That sort of worked, but the particle object seems to act strangely at very high timescales.

    (I guess I'll submit to tracker, if it's not a known issue or a side effect of the way particles are handled.)

  • Thanks for posting this! I wouldn't have thought of rolling my own Windows-style windows. Looks modern.

  • Thanks! Now I can stop using appalling hotspot based orbits.

  • Like Max said - you could create a bullet sprite the same width as your beam, facing in the same direction, and just make it, say, 200 pixels long. Then you could give it the Bullet behaviour, make it Instant Hit, and set the speed to 200.

    Instant Hit just keeps looping in the same tick until it hits something, so it'd strike the target immediately. If it traveled 10,000 pixels at the size and speed I said above, I guess that'd be, what, 50 loops? Should be no problem for the CPU.