GMG's Forum Posts

  • I have made these two caps to illustrate an issue I'm having with the Ball behaviour.

    The BB cap uses the ball behaviour. The ball has no randomness, so it should bounce at a steady 45 degree multiple. However, if you use the debugger, you can see that the bouncing has a very obvious variance to it.

    The CMB cap uses the custom movement behaviour. The angles for speed, angle and collision response are basically the same, but in this case the ball bounces exactly as I expect it to.

    Why is this? I don't have a problem using CMB for these things, but it would be so much more logical to use a ball. As far as teaching goes, I don't want to have to tell my students "don't use the ball behaviour for the ball".

    On a side note - I could display the angle of movement for the CMB in the text object using the expression "Ball[CustomMovement].Angle", but I couldn't do the same thing with the Ball behaviour. Is there a way to do this?

  • Device name: Intel(R) 82945G Express Chipset Family

    Pixel shader: 2

    Estimated VRAM: 195 MB

    Motion blur: No

    My office PC - Yikes!

  • Ashley,

    I've always thought it would be a good idea to have some way of attaching event sheets to objects, so that if you include an object in a layout it automatically includes the necessary events. Also, I was just thinking the other day how it would be awesome to have compound objects, or some form of grouping that goes beyond simple containers. What you describe sound like exactly that, and I really hope you develop this idea.

  • I wrote a GDD for a concept very similar to this, with an astronaut who is trapped outside of his spaceship in an iron-rich asteroid belt. The ship is moving up and the asteroids are moving down, and the only control you have is the direction you run around asteroids and switching your magnetic boots on and off.

    Once the magnetic boots are off, you drift with whatever momentum you were able to build up (linear velocity on a tangent from angular velocity at moment of release), until you reactive the boots and are pulled towards whichever rock is closest. You die if you go off the bottom of the screen or get squished between two asteroids, and you win if you get to your spaceship.

    I had a few extra mechanics, like collecting minerals from the surface of the rocks, but the core concept was very similar to yours. Great minds think alike, eh?

    One thing I would suggest, based on my own experiments, is that you don't necessarily need to model realistic gravitation between the various objects in the game. Sometimes realism goes too far, to the point that it isn't actually fun. Sometimes, it is more fun to have something that only vaguely approximates the laws of physics. Weigh the benefits of realistic physics versus the extra complexity, runtime overheads, player expectations, etc., you might find a better solution is far less complex but doesn't detract much from the actual gameplay.

  • As I understand it, Construct needs some things that are DX9 but not in DX10. You can have both installed at the same time, as far as I can recall.

    When you install Construct it should prompt you to install a DX9 package from Microsoft - just agree to it and follow the process.

  • What about linked lists? Does construct include these?

    Linked lists are very efficient data structures for handling large amounts of objects, as each element in the list knows the previous and next objects in the list. If an object is removed you simple update the links for the previous and next objects, not the entire list.

    Lots of info about data structures here:

    http://lab.polygonal.de/ds/

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • How about a "Post Your Ghost Shooter" thread in Creations. Anyone, not just beginners, could use it. Any new GS threads that people create can be merged with the main thread. If people want to demonstrate some technique that takes the tutorial further, they can do so in that thread.

  • Sounds like he's trying to make a stretchable 9-patch image, for making pretty boxes.

    I was thinking about this just the other day - the four corners would be regular sprites (aligned TL, TR, BL, BR corners), the top and bottom would be a tiled background running left-right, the sides would be tiled backgrounds top-bottom, and the middle would be a regular tiled bg in all directions.

    Then you could resize it at run-time and have all the parts snap to where they should be and have nice looking boxes for buttons, UI, etc. And I think he wants a way to automate this process.

    Of course, I could be wrong

    Edit: and it appears I was wrong. And slow.

  • I see two ways to do this (untested, as usual):

    Method 1: make them all part of a container, then move the container object.

    • sprite1 - underspikey-moving-platform: visible, with movement events
    • sprite2 - solid platform: invisible, solid, platform
    • sprite3 - spikey bit: invisible, kills player on contact

    If you make a container on sprite 1 with sprite 2 & 3 inside it, moving sprite 1 should move the others automatically.

    Method 2: different sub-events for different conditions

    For example:

    + Player collides with platform
    ++ Player moving down
    ++ Player.y > platform.y
    --> land on platform, standing animation, etc.
    ++ Player moving up
    ++ Player.y < platform.y + platform.height
    --> kill player, lives-1, death sound, reset layout, etc.[/code:2ap95zkr]
    
    Let me know if either of these work.
  • Just wondering, where does the in development tilemap plugin/object fall in this plan?

    You said that v1 is now feature complete, with only bug-fixes remaining.

    Is it going to be a v2 feature, or a plugin that can be dropped in post-1.0?

  • I was just about to make a post of my own, until I saw this. I have a small, relevant request:

    Is there any way you could make it so that the arrow keys can move the selected ACEs around on the event sheet, for quick reordering? So, anything could be moved up or down, events/subevents could be moved left or right. If you moved this first subevent up or the last subevent down it would become a sub of the next event. There are probably a few other scenarios, but you should be able to get what I mean.

    So many times I've been frustrated by the drag and drop reordering system - unless I'm doing something wrong, sometime it just doesn't want to put them where I want them. With a complex event sheet, sometimes it will just refuse to put events in certain locations.

  • re: #48 - I have an unfinished KonamiCode.cap on my PC, which I stopped working on for exactly this reason. I could get the combo to work - just about - but it didn't handle failures very well, and the events required became so complicated that it would have utterly failed as the educational example I wanted it to be.

    I definitely support having more control over timers. In GameMaker you can set, reset and disable timers (alarms) at any time simply by setting it to a value - e.g. writing 'Alarm[n] = 30' (to set it to 30 steps), set to 0 to finish early, set to -1 to cancel it.

    Some things you should be able to do with timers:

    • activate (set to a value and begin counting down)
    • reset (start again from new value)
    • pause & resume (self explanatory)
    • finish early (timer = 0 >> perform event)
    • cancel (finish without performing events)

    It's been a while since I worked on that example, so I can't quite remember what timers can and can't do right now, but I remember thinking at the time that they could benefit from a few additions / tweaks.

  • It's been in the documentation for a while!

    Bizarrely, my workplace blocks access to sourceforge on the basis of it being a software download site, so I often cannot check things before posting. Sometimes all I can do it a quick test in the software.

    Anyway, yeah you can set it to the sides/corners/middle just as you described with numlock on. I'd still like to see the option to not align the image by hotspot though...

    Well, I didn't know about that one, so we have both learnt from each other symbiotically

  • OK, i see - they currently function by nudging pixel by pixel. I was referring to instantly setting it to edges, corners, or the centre. In that case, forget about hotkeys (no point in changing the current functionality), however I think the buttons would be a good idea. GameMaker has a button to set the origin to the centre of the sprite and I use this feature constantly.

  • Also, would be cool to have buttons or hotkeys for compass points.

    I.E. buttons arranged like so to quickset the hotspot...

    NW N NE
    W  C  E
    SW S SE
    [/code:1k2zenyh]
    or shortcuts on the number pad:
    [code:1k2zenyh]
    NW   N   NE
      7  8  9
    W 4  5  6 E
      1  2  3
    SW   S   SE
    (press 5 to centre)
    [/code:1k2zenyh]
    Make sense?