GMG's Forum Posts

  • I just made this little example, showing how to do simple tank movement that leaves tracks behind.

    I used image points to place the track sprites.

    Hope someone finds it useful.

  • Device name: NVIDIA GeForce 6150 LE

    Pixel shader: 3

    Estimated VRAM: 793 MB

    Motion blur: Yes

    This is my home PC. We have something significantly different in college. I'll check when I get the chance.

  • I mentioned this in a help thread, thought it wise to move the discussion here. Original link:

    Currently, if you want collisions based on anything other than pixel perfect or full bounding box, you have to create another sprite to do the job and link the two together with an always event.

    I propose two possible solutions to this problem:

    Firstly, the ability to define custom bounding boxes that would be calculated relative to the hotspot. You would need variables for width, height, x-offset and y-offset, which could be added somewhere in the properties panel. For example, if the hotspot was in the centre of a 32*32 sprite, the bounding box could be defined as W:16, H:32, XO:-8, YO: -16, in order to place a tall, thin bounding box in the middle of the sprite.

    Secondly, for more complex collisions, you could offer the ability to define a custom collision mask, editable in the image editor. This could function in the same way as the multiple animations found on a single sprite. If present, this mask would be used for collisions instead of the currently displayed sprite.

    Any thoughts?

  • And honestly I don't think it's that hacky of a practice

    Hack or not, you can't deny that setting up events and actions for games would be a heck of a lot easier if you had only one sprite to deal with per distinct in-game object. As it stands right now, you need two sprites for each object, with events and actions distributed between them.

    I just feel it would be great if you could say "the bounding box for this sprite is W*H pixels in size, offset from the hotspot by XY pixels". Or better yet, the way there are several animations per sprite, it could be possible to have a special image called collision mask, which would override the pixel collisions of the animation frames.

    Anyway, I didn't mean to hijack the thread. I'm going to open up a topic on this in the feature requests forum to continue discussing this.

  • Things like this would be much simpler if Construct allowed you to define custom bounding boxes for sprites, relative to the hotspot. Then there wouldn't be any need for linking animated sprites to hidden interactive hitbox objects.

    In GameMaker, with sprites you can define precise collision detection (pixel perfect), custom bounding boxes, or you can even make a mask sprite that can be explicitly linked to the object for collision detection. It's a lot more flexible and robust in that regard. This invisible hitbox and visible sprite method just seems like a hack.

  • I've found that using the unfinished themes results in UI glitches with the Layout/Event Sheet areas. I did like the look of the Office 2007 themes, but those glitches just got annoying, so I've switched back.

    Basically, every time I alternated between Layout and Event Sheet, or did any other changed that cause the area to rerender, the scrollbars would flash in a fixed position about 50% the size of the sub-window. Going back to the regular theme fixed it.

  • Very nice tutorial, but may I suggest using Vimeo instead of YouTube, for video quality reasons?

    Your AVI was perfect, apart from the audio sync when you tested the jumping (which I guess is a video capture issue more than anything else). However the YouTube version is barely watchable, since the fine text on the event sheet was just a smudge of pixels.

    Can't wait to see more.

    I have access to camtasia through work, maybe I'll try my hand at some as well.

  • Ah, that makes sense now. I hadn't used tileable backgrounds in mine, just sprites (not very efficient). I didn't look at yours so closely, and I hadn't really registered the full scale of the differences between sprites and tiles until now. It doesn't actually say anywhere in the interface - "Sprite" - when you select a sprite, or whatever. Looking closely I can see how much difference there is between the two.

  • I have a little question:

    Why do you set you ground sprites to invisible in the start of layout event, but use the 'invisible on start' attribute for your player sprite?

  • My first turret in GM worked like yours - only firing when the player was in it's field of fire, so it would sometimes only fire two shots, then fire the last one the next time the player came in range.

    The code above was a fix for that problem. By using the 'firing' variable, and toggling the variable when the shots were depleted, I ensured that the entire salvo was fired in one continuous burst. This gave me the more realistic anti-aircraft style firing. When you attach a sound to that action the effect is really nice: boo-boo-boom!

    I'm now positive that such behaviour could be done using events, but is it the sort of thing that would be better implemented in the behaviour?

  • This is the code I used in to make this work in GameMaker, after hacking away at it for an entire night:

    if(firing==true) {
    if(shots>0) {
        if(reload==5){
            s=instance_create(x, y, obj_enemyShot);
            s.direction=direction;
            s.speed=4;
            shots-=1;
            reload=0;
            if (shots==0) alarm[0]=30;
        }
    } else {
        firing=false
    }
}
if(reload<5) reload+=1;[/code:3kwc4jy7]

Prior to this is code that makes it rotate and decide whether or not to fire (firing=true). This code is executed every step, using GM's fixed time step (30fps).  So, first check if the cannon is firing, then if it has ammo (shots > 0). Then check if the cannon is loaded (reload==5), and if so, fire a bullet in the direction the cannon is facing, reduce the shots available and start the reload cycle. When you run out of shots, start the timer (alarm[0]) to do a full reload. The alarm event has code to set shots back to 3.

Horrible code, I know. But the end result was a really nice turret that tracked the player and fired off a salvo of 3 bullets, 1/6seconds apart, with a 1 second gap between salvoes. Much nicer that an endless stream of bullets. This is the sort of thing I was trying to describe.

As I said, I'm sure something like this could be done using events. It's a question of whether it is significant enough to warrant adding to the behaviour. It doesn't look like it would be used enough to make adding it worthwhile. Case closed.

  • Thanks for the encouragement and the kind welcome.

    Naturally, the fact that it is free is one of the greatest plusses for this software. I can't use a product that the students can't continue to use in their own time. The restrictions placed on GameMaker 7 Lite meant that I had to jump through all sorts of hoops (for example: pre-rendering rotated sprites and writing code to compensate for it (image_index=direction/360%image_number)!!!). Ultimately, I want to be teaching broad concepts using clean examples, not granualar, one-time-use solutions to platform specific problems.

    Working with GameMaker, within the first few lessons I needed to start working with GML code, which alienates those students coming from an art/design perspective. Since then, I have been mixing DnD with GML in the most inelegant ways. The system used in construct seems ideal for my needs, with no restrictions and everything done using either ACE or behaviours.

    Hopefully I'll be able to help you with the documentation, as I will be converting my lessons and examples to Construct. I have a range of lessons teaching different concepts such as hazards, objectives, rewards, powerups, all demonstrated in actual game play examples. It will simply be a case of making Construct examples to replace my current GM7 ones. Different people learn in different ways, some by watching/reading, some by doing/experimenting, others by following instructions. The more and varied material that is available for study, the better.

    Anyway, I only joined yesterday, I don't want to get a reputation posting long rambling rants.

    I'll be back when I have something to ask or something to share.

    GMG

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I see. I didn't realise image points could be used in that way.

    I'll give this a go next chance I get.

    I assume the same techniques could be used to create spray and other bullet arrangements?

    Thanks.

  • Just a small suggestion.

    I'm sure this can be done using events, but it would be great if the turret behaviour could fire in salvos, i.e. three quick shots, then reload. This is quite a common behaviour in games with turrets.

    I implemented something like this in a game maker game, but it required several variables and nested if statements to make it work properly.

    It could be implemented using two variables - salvoSize and salvoInterval (or similar). These could work in tandem with the other variables and properties of the turret. So if the onShoot event fires, the turret would automatically shoot {salvoSize} bullets with {salvoInterval} milliseconds between them, then wait for it's standard reload time before firing again.

    Any thoughts?

  • Hi,

    I just want to introduce myself.

    I'm a lecturer in IT from South Wales, teaching mostly media subjects at college level. Since September I've been teaching an evening class in game design, using GameMaker. However, very early on in the process I realised that GM, great though it is, was not going to be suitable for the class. Too much of my time is spent solving issues specific to GM and teaching workarounds, rather than teaching concepts of game design and simple implementations as I would like to.

    I've stuck with it out of necessity, but since October I've been casting around for alternatives, so that I can develop the class and deliver an improved version from September. My criteria were quite specific:

    • free for education/non-commercial use
    • accessible to beginners (drag and drop style or similar)
    • offer advanced options for stronger students
    • deep enough to teach complex topics such as AI
    • able to create a variety of game types (platform, shooter, top-down, etc.)
    • a full range of features- sprites, controls, collisions, text, sounds, particles, etc.
    • well documented, with plenty of public examples
    • give the students skills and portfolio opportunities that could help them get on a degree course

    I found Construct completely by chance last week (despite being around for over a year, you have made a very small impression on the web), and I am so far very impressed with the software and community. It ticks most of the boxes, just the documentation is a bit sparse at the moment.

    If all goes well, I plan to use Construct for my class starting from September '09. In doing so, I will be producing a collection of teaching resources such as tutorials, examples, and exercises, that I will hopefully be able to share with the community. This will of course depend on how Construct develops in the intervening time, i.e. a 1.0 release, more documentation, etc. I really hope things continue to develop well.

    Anyway, that's all I really need to say right now. I look forward to working with you all, and getting my students to share some of their creations with you.

    Thanks.

    GMG