Proto1

Create all objects on the field

When the room starts
Create a ds_stack with the instance id of all the objects.
Pick a random number between 0 and the maximum stack number (0-19, i think for the first, 0-18, etc)

If number of instances in room <= 5, exit.
else destroy instance(grab the id from the random stack number)


This should randomly delete all the objects until only 5 are remaining, just run in a loop.

Add some show_message() statements right before the variable is stored, showing the variable. That might help trouble shoot.

Could playhelf be defaulting to 0 when you are trying to read?




Im kinda wondering if this is even being activated, as

ini_write_real("stats","hmlwin","1") // supposed to write that the item has been taken, so it can not be taken again

Is a pretty independent statement. Nothing should really be able to go wrong with that, yet it is still showing 0, even though its clearly stored as 1. That makes me think the problem is your problem lies in the

if complete{} statement is testing as 1, not 0, so the code isn't edited at all. Make sure the complete variable is actually testing as 0 so the script runs.



Post back with details, let us know if its still not working.

In the creation event, do you have a variable can_shoot = 1?

If so, is it spelled correctly?

So:

creation event:
can_shoot = 1

space event:
if can_shoot = 1
{
//shooting code
}

First off, I forgot to mention I quite like the art for the game. Very retro, but stylish.

2nd, As to the random chest spawns, I want to first ask how you are getting the enemies to spawn. I assume they are not spawning all about the entire room, but only within a certain proximity to the player. I would use this same philosophy to create chests. Create a global timer that clicks, say, every minute. At that minute mark, it rolls a 0-3. If 0, it will spawn a chest close to the player, just out of screen. That way you will encounter a chest around every 4 minutes (less if you want), and they will always be near the player, not across the room. Infinite chests would then be possible, and it would still feel like you are just stumbling upon them as you walk. To spawn the chest, you could do something as simple as rand(0-360), for the degrees, then just spawn it a set distance in that direction from the player.

Edit: Once a chest is looted, I would set a timer for around 10 seconds. Once timer = 0, destroy_instance(). Just to remove old chests, which would make the world seem smaller if you keep bumping into them.

@Kupo

I think your ideas about using XX and YY to select class and subclass would probably work better than what I had going. I usually prefer to have everything in one array, as I feel it leaves more options open if everything has its own id, but this is definitely a good idea for his current setup.

Also, how would the rarity range work if the items aren't sorted by rarity? I guess you could use ds_structures to actually sort by rarity, but that seems a bit advanced.

I must admit I'm far better with data structures than with images, so my idea naturally leans away from images, just adding them in once the data structures are all said and done.

@Kortuga

Unfortunately im still restoring my PC from a nasty crash (currently using my bro's macbook). However i'll try to find time to look at the coding once its up and running.

First steps though, I would think about beginning the painful process of redoing your item id layout. These will inevitably get messy, although the beginning is always somewhat clean (just look at minecraft id's, blocks and items are scattered everywhere). Like I said above, Kupo's method definitely works with what you have, and you could definitely still use it, but I fear it might potentially limit your game. This is seriously just a matter of figuring out what your game will be, and if you need the kind of freedom that a mast array would allow. If not, then definitely don't re-sort the entire thing. The way it works right now is actually easier when using Kupo's XX and YY system.

Going back to what Kupo said, I think 2d arrays are kinda the way to go here. You can have the item id (say main[0,0] = id 0), then the images, stats, everything stored in [0,1], [0,2], etc. I think the sub_images kupo suggests are definitely a good idea, as you can sort the images easier. That way you use one sprite for all your weapons, and the image itself is just set to the subimage.

You pretty much have two tasks here:

1) Update your array into a 2d array, complete with sprite_index, image_index (this is what we meant by sub_image, I guess we should have been using correct terminology), item type (just a numerical variable. 0 = weapon, 1 = ring, etc...) and stats for that type. The core of your game will all lie in this one array.

2) Go back to my original post, and use that (along with Kupo's xx and yy idea) to help generate the array inside each chest. Then, simply display that array in your gui when you collide with the chest.

Edit: I realized you already made a separate sprite for every object, rather than sub_images. Although Kupo's plan is a good one, it might take longer to rework the framework just to make them into image_indexes.)