Queue-like datastructure that is readable from anywhere

Question

I'm working on a game in Yoyo Game Maker where I have items moving along conveyor belts. As the items only move in one direction, I thought it would make most sense to use a queue or queue-like data structure to store the items. However, to be able to render the items, I need to be able to read all of them at any point in the queue, not just the head or tail.

     [[a] [b] [c] [d]]
             |
             V

a <- [[ ] [b] [c] [d]] <- e
             |
             V

     [[b] [c] [d] [e]]
       |   |   |   |
       V   V   V   V

       b   c   d   e

I could simply use an array that manually moves all its values forward by one slot every turn (using a for loop), but somehow that seems inefficient, laggy, or at the very least, bad form. My programming instincts recoil at the thought of using such a system, anyway.

Is this a correct assumption to make? Is an array really the best way of implementing a structure like this? Should I even be worried about efficiency, or are the differences in this case negligible?

Some advice or examples (in any programming language) would be greatly appreciated.

Answer 1

It might "seem" inefficient to use an array, but it most likely won't be. Take into consideration how many items will actually be on the conveyor belt at any single time. If you want quick random access to any index in a data structure, you must use an array, a DS List or a DS Grid(wouldn't make sense here, tough).

Using a DS List, you can use ds_list_delete(your_list, 0) to 'dequeue', much like a DS Queue, and ds_list_insert(your_list, 0, value) to 'enqueue' an item.

Iterating through the list is then very simple:

for ( var i = 0; i < ds_list_size( your_list ); i++ ) {
   var item = your_list[|i];
}

It might also be relevant to add, that, in a game I'm working on, objects are build using components, which basically means that all of the enemies, the player, and such have a for-loop in their Step events to iterate through and update all components if need be. At most I have about 80 such objects in the game at any time and performance hasn't been a problem yet.

You should always first try to get a working solution, then testing it in conditions specific to your game: eg. if you are going to need a 100 items in the structure, try that, and if the performance is not satisfactory, only then optimize.