next »

[Soulliard]

I have to disagree with Boris. Unless your game features teleportation or destructible terrain, all those walls will do is slow the game down.

[BorisTheBrave]

I have to disagree with Boris. Unless your game features teleportation or destructible terrain, all those walls will do is slow the game down.

Premature optimization is the root of all evil. I know GameMaker is slower than treacle, but I stand by my point. You can remove the walls later when you have decided you need the speed up, but are feeling confident that you've already got the game running and bug free.
To be honest, extra tiles shouldn't slow down games, I'm surprised that it does. As you store the tiles in some 2d array, and to check collisions you only iterate over the tile spaces that your game objects are actually in, so what difference does one which is never checked make?

[Soulliard]

GM does some things automatically for each object each step, like reassigning its position based on its speed. This means that adding enough objects will slow GM down, even if they don't do anything.

[BorisTheBrave]

GM does some things automatically for each object each step, like reassigning its position based on its speed. This means that adding enough objects will slow GM down, even if they don't do anything.

I thought tiles couldn't move?

[ஒழுக்கின்மை (Paul Eres)]

In GM you can move them. They can't have speed or direction or anything, but you can move them around using a function. They aren't in a grid either, they are placed arbitrarily, and can be of any size, which has advantages and disadvantages.

But also, walls are not tiles. You can't just call a tile 'impassable', you need to create an invisible object on top of the tile, which is a pretty bad complication, but necessary due to how GM works. I'd prefer if tiles themselves could be designated solid or passable, rather than having to use separate, invisible objects on top of the tiles for that.

[GregWS]

I'm not sure if this would slow down GM a lot rinku, but couldn't you just check what tile is being shown (I'm very sure there's a function for that) and if it's a "solid" tile, the game treats it as such?

[BorisTheBrave]

In GM you can move them. They can't have speed or direction or anything, but you can move them around using a function. They aren't in a grid either, they are placed arbitrarily, and can be of any size, which has advantages and disadvantages.

So they're more "things you can design in a tile-based layout" than anything massively different from normal objects.

[ஒழுக்கின்மை (Paul Eres)]

You can't treat tiles as solid, no, if by solid you mean GM's special solid definition that is used in all its collision checking functions. You could code your own collision checking and check for tile locations, yes, but that'd probably be even slower than just using objects instead of tiles.

Normal objects have a bunch of extra parameters that slow them down. Tiles are slightly faster, but still will slow down a game if you have too many of them. I'd say 1 object is worth about 3 tiles in terms of slowdown (assuming equal sizes or assuming they are undrawn).

My recommendation is this: do not use tiles, and instead use large backgrounds the size of the entire room. For walls, use large, invisible objects of many shapes and sizes and lengths and widths, and piece them together so that there are the absolute minimum of invisible wall objects. This is what I did in Alphasix. The source code to that game is in the GMC open-source subforum (under Game Creations) so feel free to download it and see how I did it (although don't judge my GM coding from the code in that game since it was my first GM game).

[Xion]

My recommendation is this: do not use tiles, and instead use large backgrounds the size of the entire room. For walls, use large, invisible objects of many shapes and sizes and lengths and widths, and piece them together so that there are the absolute minimum of invisible wall objects.

Really? I'd wondered about/tried this before but discontinued because I thought it would somehow be slower (and also making those huge backgrounds was a pain).

[ஒழுக்கின்மை (Paul Eres)]

No, it's much faster. On my old 566 mhz computer with 32 mb of RAM and no video card, Alphasix went from 40 fps to 70 fps when I made this change.

Making the huge backgrounds is fairly simple: just build it with tiles in Game Maker, then take a screenshot, save that screenshot as a background, and replace the tiles with that background.

The key is to make the invisible walls *large* and to have a wide variety of shapes and sizes of them, so that you can minimize how many you have to use.

[ஒழுக்கின்மை (Paul Eres)]

Of course, on modern computers the difference is more negligible; now that I have a core 2 duo 3.0 mhz, 2gb of ram, and a 512mb video card, the fps is likely to be over 100 no matter which method I used. Still, optimization is a good idea since some people still are using old computers.

[Xion]

I stole this script from someone else's thing that, in the room creation code, combined all wall objects into larger rectangular wall objects, turning many small objects into a few large ones while in-game, but while in the editor the pieces were still separate. So I've been using that.

Also I've got an shitty comp. Most things I make run fine for other people but slow as hell for myself, so I'm obviously trying to cater to the lowest specced folk, myself being one.

[ஒழுக்கின்மை (Paul Eres)]

I've seen scripts that do that in the GMC forums, yes. They were posted after I had use of them though, so I never tried them. Typically what they do is take the tileset, use surfaces to put them in larger 'blocks' (like 256x256 squares), and then display those instead of the tiles. Those are useful.

Also, *even if* you use tiles, it's a good idea to make your invisible wall objects as large as possible and in a variety of shapes and sizes, so that you can minimize the number of wall objects you need. For instance, if your tile size is 20x20, you should have invisible wall objects with sizes like:

20x20
20x40
40x20
40x40
60x20
20x60
60x60
80x20
20x80

And so on. And then just arrange them such that you use as few as possible.

[Pencerkoff]

Hello this is Pencerkoff

Since your second tutorial I guess I learned most of the view stuff, however the tile part was informative.

Does anyone have some tips on data-structures?  I'd really like to use them more but putting numbers into them is really annoying, unless there's something I'm missing.  Like, is there a faster way than defining each separate cell of a grid?  I had this problem in MMF too.  I want spreadsheets.

-PENCERKOFF

[Xion]

I've seen scripts that do that in the GMC forums, yes. They were posted after I had use of them though, so I never tried them. Typically what they do is take the tileset, use surfaces to put them in larger 'blocks' (like 256x256 squares), and then display those instead of the tiles. Those are useful.

I don't mean with tiles I mean with actual objects. It runs a loop or whatever through the objects you use for solids and combines them into larger blocks, like as in the sizes you mentioned, but without the need for so many sizes actually being present in the objects list (which I already find can quickly become cumbersome in making levels.)

Though with tiles sounds useful, too.

[partymetroid]

Is there a way to make the view move slowly according to the character's viewpoint, like in Cave Story?  Maybe make an object that follows the character when he moves, and moves left or right when the character looks left or right, respectively?  Are those the so-called "controllers" I hear so much about?

[edit]And have the view follow that object, of course, instead of the character object.

[Derek]

I don't think you'd need a new object for the view to follow.  Just make the view borders around the player more flexible.

You could create variables that represented the acceleration and velocity of the view.  Then, at each step, add the acceleration to the velocity and the velocity to view_xview[0].  Change those values depending on what direction the player is facing.  Put them in a controller object.

That's how I'd try to do it, at least.

[partymetroid]

I don't think you'd need a new object for the view to follow.  Just make the view borders around the player more flexible.

You could create variables that represented the acceleration and velocity of the view.  Then, at each step, add the acceleration to the velocity and the velocity to view_xview[0].  Change those values depending on what direction the player is facing.  Put them in a controller object.

That's how I'd try to do it, at least.

=O.  Nice, Derek!

[sandcrab]

Hey these tutorials are great, I just wish the next one was done right now!  I haven't done programming of any sort in years, and that was extremely rudimentary (even for QBasic!) but even with this brief bit of training I can see all sorts of potential already.

I found a little flaw though!

Although enemies positioned off the screen are deactivated until they appear on screen (obvious, but I confirmed it anyway by making enemies that move forward), they can still be shot by the bullets that go off-screen.  My enemies take 2 hits a pop, so I was seeing them seemingly self-destruct as soon as they appeared (at 1 hit I wouldn't have seen them appear at all!).  It looks as if the bullets are deactivating and then reactivating as the viewport catches back up with them. 

I realized how to fix it as soon as I typed "how can we fix this?", but probably the tutorial should mention it!

Code:

// for complete noobs like me, to limit range to the viewport only:
if (x > view_xview[0]+320) instance_destroy();

[sandcrab]

Also, I was able to get a little Grace Period going after I spawn the ship back in, but there's no visual indicator.  I suppose that (pardon my non-code language):

Code:

if grace exists, create a blinking ship on top of regular ship's current location;

and I can certainly manage that, provided "blinking" means it is flashing to a visible color--if I make it go transparent, you'll still see the solid ship underneath and the effect would be invisible!  It might be cooler to do it as a visible color, but then I won't have learned anything!  I want to make it blink the traditional way, with the ship flashing transparent briefly.  How can we accomplish this? 

I suspect once we know how to do that, it wouldn't be hard to modify it to add animations for other events, like tilting the ship as it moves up and down?