I'm currently creating a tile based game, where elements of the games are placed in four different vectors (since there are multiple game objects with different properties, hence stored in different vectors).
These game elements themselves contain x and y coordinates similar to how they are stored in a two dimensional array. i was wondering if there was a way to access these vector elements similar to two dimensional array access (currently i am implementing an for loop to cycle the elements while comparing its coordinates).
This kinda sucks when i need to refresh my display at every game cycle (since the large number of comparisons and loops).
I'm implementing this in java btw.
My recommendation would be to think "object-oriented": create a class named Board or Grid or whatever fits that encapsulates that implementation detail of choosing between 2D array or Vector of Vectors. Add a method that lets you return a board token for a given (i, j) index into the board.
Don't use Vector, use ArrayList.
If you have very large datas, see perhaps buffers, for instance IntBuffer.
Three Ideas:
You could use a HashMap with the coordinates as key and your elements as value. This is faster than cycling through the vector and lightweight for memory.
You could store null instead of elements at empty coordinates. This way you can access each stored memory by its coordinates.Fastest but memory intensive way.
A speed up for what you currently do: Sort your elements by their coordinates once and then use binary search to find them in the vector.
Related
I'm coding a Q-Learning implementation for a game and the Q-Learning state requires a 7-dimensional array because I have everything about the game on it (player x, player y, monsters, treasures, possible moves, etc...)
Everything adds up to more than 1 billion states and the memory can't handle a static matrix of this size, I'm pretty sure the algorithm won't need a lot of these states, so how can I do that using a dynamic structure?
My first thought was to use something like:
ArrayList<ArrayList<ArrayList<ArrayList<ArrayList<ArrayList<ArrayList<Double>>>>>>> qList;
But I'm not sure this is a reasonable solution and I'm not sure how to allocate all of these ArrayLists.
What would be the best way to create a dynamic data structure to store a 7 dimensional matrix?
I want to distribute a huge two dimensional array Object[][]. Mostly holding primitives but also String, Date and Color objects. I want to allow different machines to modify data in this matrix. My problem is that I need some help with the modelling.
As far as I can see there are only distributed maps available like hazelcalst or openhft. But maps are not fitting my needs exactly. So what I can do is store all rows (or all columns) of my array in a map. But when I act on a whole row/column it is blocked for all other threads even if they operate on another index. When I store every "cell" in a distibuted map the row/column index for the map key might me bigger than the whole array itself. Are there better tools or modelling approaches for this scenario? I would need a matrix where I could distribute data and lock just one single cell.
So I'm making a game similar to Age of Empires 2. So far, what I've been doing is using an Applet and making an array of tiles (grid) to contain units and buildings. I feel that in the long run this is going to be inefficient. I'm sure there is a better way to do this, perhaps using GUI, but I'm not a very experienced programmer yet so I've resorted to this more primitive method. Is there a better, more efficient way to have tiles that contain characters and buildings on the map?
Thanks.
This is pretty much how I want it to look like:
An array of tiles should be fine - this is what is usually used to represent the map in a 2D game.
Note that you will probably want to distinguish between:
Map terrain tiles, where each square contains just one tile
Units / buildings / other game objects, where each square might contain multiple objects
For the terrain a single array is fine, with one tile in each position.
For the other objects, you need a way to store multiple objects in each square. An array with an ArrayList in each square can work - though you will probably want to leave nulls in all the squares that don't have any contents to avoid creating a lot of empty ArrayLists.
It's also useful to create a global collection of game objects so that you can iterate over all game objects and/or find a speciifc object quickly without searching the whole map. I typically use something like a HashMap for this, where the integer key is a unique ID for each game object.
It depends on what you consider to be the 'inefficient' part. If most of the array elements are going to be containing data, and you need to be able to look up that data quickly and easily, than arrays are certainly the best way to go. They're easy to understand, and the logic mikera described for storing data is a very good way to get started.
There are data structures that very big tile based games use for storing data. Most of those are optimized for 'sparse' graphs at the like. A sparse graph is one where most of the locations are empty, but a few of them have content. Very big world maps often have this qualit. If you're curious about these scenarios, then you should google "quad tree tiling".
But in general, if you're still learning development, stick to the array. Premature optimization is the root of all evil. :)
I am making a game for Android. I am kind of trying to keep the game a secret so I cannot reveal too much about it, so bear with me. Basically it runs in real-time (so I will be implementing a thread to update objects' coordinates) and its style is kind of like Duck Hunt; you have to hit objects that move around on the screen.However, the game has been lagging slightly from time to time (running on a Samsung Galaxy S, which is one of the higher-end devices) so I believe I need to use a better data structure.
Basically I am storing these objects in a doubly linked list instead of in an array because I wanted the maximum number of objects on the screen to be dynamic. In other words, I have a reference to the head and tail objects and all the game objects are connected just as a typical linked list would. This provides the following problems:
Searching if an object intersects with a given coordinate (by touching the screen) takes O(n) time (worst case scenario) because I have to traverse from head to tail and check the hitbox of each object.
Collision checking between two objects takes O(n^2) time (again, worst case scenario) because for every object I have to check if its hitbox intersects with that of all other objects in the linked list.
Another reason why I chose linked list is because I basically have two linked lists: one for active objects (i.e. objects that are on the screen) and one for inactive objects. So let's say that there will be at most 8 objects on the game screen, if the active linked lists would have 5 objects, the inactive list will have 3 objects. Using two linked list makes it so that whenever an object becomes inactive, I can simply append it to the inactive linked list instead of dereferencing it and waiting for the garbage collector to reclaim memory. Also, if I need a new object, I can simply take an object from the inactive linked list and use it in the active linked list instead of having to allocate more memory to create a new object.
I have considered using a multi-dimensional array. This method involves dividing up the screen into "cells" in which an object can lie. For example, on a 480x800 screen, if the object's height and width are both 80 pixels, I would divide the screens into a 6x10 grid, or in the context of Java code, I would make GameObject[6][10]. I could simply divide the coordinates (on the screen) of an object by 80 to get its index (on the grid), which could also provide an O(1) insertion. This could also make searching by coordinate O(1) as I could do the same thing with the touch coordinates to check the appropriate index.
Collision checking might still take O(n^2) time because I still have to go through every cell in the grid (although this way I only have to compare with at most 8 cells that are adjacent to the cell I am examining currently).
However, the grid idea poses its own problems:
What if the screen has a resolution other than 480x800? Also, what if the grid cannot be evenly divided into 6x10? This might make the program more error prone.
Is using a grid of game objects expensive in terms of memory? Considering that I am developing for a mobile device, I need to take this into consideration.
So the ultimate question is: should I use linked list, multi-dimensional array, or something else that I haven't considered?
Below is an idea of how I am implementing collision:
private void checkForAllCollisions() {
GameObject obj1 = mHead;
while (obj1 != null) {
GameObject obj2 = obj1.getNext();
while (obj2 != null) {
//getHitBox() returns a Rect object that encompasses the object
Rect.intersects(obj1.getHitBox(), obj2.getHitBox());
//Some collision logic
}
obj1 = obj1.getNext();
}
}
Common data structures for better collision-detection performance are quadtrees (in 2 dimensions) and octrees (3 dimensions).
If you want to stick with a list - is there a reason you're using LinkedList and not ArrayList? I hope you are currently using the built-in linked list implementation...
A Samsung Galaxy S has 512 MB of RAM - don't worry about taking up too much memory with a single data structure (yet). You'd have to have a relatively high number of relatively heavy objects before this data structure starts sucking significant amounts of RAM. Even if you have 1000 GameObject instances, and each instance in the data structure (including the associated weight of storing an instance in said data structure) was 10,000 bytes (which is pretty honking big) that's still only 9.5 megabytes of memory.
So I definitely think that there's something we need to firstly consider.
1.) LL vs. Array
You said that you used a LL instead of an array because of the dynamic property the LL gives you. However, I would like to say that you can make using an array dynamic enough by doubling the size of it after it has filled up, which will give you O(1) runtime of insert amortized (given that the array is being unkept/unsorted). However, there will be a scenario where every now and then an insert can take O(n) since you must copy the data appropriately. So, for live games such as this, I believe the LL was a good choice.
2.) Your consideration of memory in terms of game objects.
This depends heavily on the structure of each GameObject, which you have not provided enough detailed information about. If each GameObject only contains a couple of ints or primitive types, chances are that you can afford the memory. If each GameObject is very memory costly and you are using a very large grid, then it will definitely cost tons of memory, but it will depend on both the memory usage of each GameObject as well as the size of the grid.
3.) If the resolution is different than 480x800, don't worry. If you are using a 6x10 grid for everything, consider using a density multiplier like so:
float scale = getContext().getResources().getDisplayMetrics().density;
and then getWidth() and getHeight() should be multiplied by this scale to get the exact width and height of the device that's using your app. You can then divide these numbers by the 6 and 10. However, note that some grids may look ugly on some devices, even if they are scaled correctly this way.
4.) Collision Handling
You mentioned that you were doing collision handling. Although I cannot say which is the best way to handle this in your situation (I'm still kind of confused how you're actually doing this based on your question), please keep in mind these alternatives:
a.) Linear Probing
b.) Separate Chaining
c.) Double Hashing
which are all admittedly hash collision handling strategies, but may be implementable given your game (which, again, you would know more about since you have kept some info back). However, I will say that if you use a grid, you may want to do something along the lines of linear probing or create 2 hash tables all together (if appropriate, but this seems to take away the grid-layout you're trying to achieve, so, again, your discretion). Also note that you may use a tree of some sort (like a quadtree) to get faster collision detection. If you don't know about quadtrees, check them out here. A good way to think of one is dividing a square picture into separate pixels at the leaves and storing the average colors at the parent nodes for pruning. Just a way to help you think of quadtrees meaningfully.
Hoped that helped. Again, maybe I'm misunderstanding something because of the vague nature of your question, so let me know. I'd be happy to help.
I'm working on a simple modelling program concept for Android, and I've come into a bit of a problem.
Basically, I keep Vertex and Polygon info in Java Vectors (I need this info for manipulating them, not drawing them).
For drawing I'm using VBO's.
Each polygon currently has a list of vertices that it is made of. That means that when the indice array is populated, I need to find out what index each vertex has, and those indexes can change if vertices are created or deleted.
I quickly coded this using the indexOf(Vertex v) method of the Java Vector, but obviously this is very slow and I'm wondering what is the best way of managing this so that it doesn't take too much processing?
Thank you in advance.
First off, a quick fix that will improve performance a tiny bit: Use ArrayList instead of Vector - you probably don't require the synchronisation overhead.
The main issue is that you are recalculating the whole index array on every vertex array change. Currently you need to do this because if you delete a vertex, the index of every vertex after the deleted one in the list changes. Thus the key is to minimise changes to vertex indices, allowing you to easily maintain the index array rather than completely recalculating it.
So: instead of using list.remove() to remove a vertex, replace it with the vertex at the end of the list. This way there is only one index that has changed, and so it'll be super-quick to iterate through your index array and substitute the new value.