I'm developing the game server. I want data structure for storing 3d-coordinates (x, y, z) of the objects on the map. This objects can dynamically change their position (move, teleport, be destroyed etc). I want to store this coordinates in specific order according to their visual position on the map. So, I think using graph for this purpose is good choice. But I'm not sure.
Please, notice, I need to store real-time coordinates for many objects (about 4-5 thousands). Does it exists library or algorithm to implement what I need ?
You want a spatial structure like an Octree (for 3D spaces) or Quadtree (for 2D spaces).
They partition their contents into buckets that group neighboring coordinates together. This makes doing checks surrounding a coordinate quick because only one bucket of coords (or, only buckets immediately surrounding the coord's bucket for larger checks) need to be checked. This can greatly limit the number of objects that need to be checked.
These structures arr commonly used for collision detection in games.
Related
I have a problem in which I have an irregular polygon shaped container which needs to be sub-divided such that it contains certain smaller rectangles of specific dimensions. I have previously tried addressing this problem using a bin packing approach which seems to be too time consuming. As a result I wanted to try out sub-division based approaches where the algorithm ensures that the sub-division contains certain smaller rectangles of specific dimensions while the remaining space can be considered as empty space. Any suggestions on fast algorithms for the generation of these sub-divisions preferably using the shapely library?
The irregular polygon container would look some thing like the diagram below. The edges of the container will always be right angles and it is known that items to be packed can all fit in to the given container with additional remaining free space. The constraints are the same as regular bing packing where the items should not overlap and all items should be completely within the container. The items can be rotated (preferably at right angles).
I'm making a 2D platformer using my own engine in Python/Pygame and have made a good start. I've also made a level designer that exports the level tile map and the game imports it, but I need to associate different things, like switches that open specific doors (or to be more precise, pressure plates that hold a specific door open) but my tile map array currently only holds the tile image index number. What's the best way to include associated tiles (like which switch opens which door etc)?
Do I make an extra file with that data? Or do I have 2 values for each tile? I've tried Googling, but it's not really covered anywhere. I'm sure there's someone with this kind of experience out there... I don't really want to hard-code it in as I want the game to be as versatile as possible.
I would change your file format from storing one tile index per 2D cell to storing some more complex data object. My first thought would be a dictionary per cell for maximum flexibility moving forward, but serializing that and storing it will be quite large. There's a trade-off here between flexibility and storage size.
Another option would be using NamedTuples to store a fixed number of parameters per cell, while preserving a concise serialization. NamedTuples are nice because they let you very concisely represent a data object in a way that both serializes well and can be queried into using named fields.
The questions you need to ask yourself are "what metadata do I need to know about each cell on the map" and "how much do I care about concise file size to represent them".
The answer to my question was posted by #BowlingHawk95 as using NamedTuples for the data object which enabled me to add multiple fields for each cell. I wanted to post a sample to show the resulting code, and a snap shot of how I've implemented it to help anybody else looking for the same thing.
# Initialise the level data array with NamedTuples;
# 'linked_point' is a tuple (x, y) for an associated cell - e.g. switch associated with a door:
Cell = namedtuple('Cell', ['image_id', 'linked_point'])
level_data = [[Cell(image_id=0, linked_point=(0, 0)) for _ in range(grid_width)] for _ in range(grid_height)]
And now that I am able to add coordinates (as the linked_point) I can now reference another cell from the one I'm on. The following image shows a shot of my level designer, with the coords in the title bar, and also showing the image_id name and coords of the linked cell.
Massive thanks to #BowlingHawk95 for the assistance!
I have given a large binary image (every pixel is either 1 or 0).
I know that in that image there are multiple regions (a region is defined as a set of neighboring 1s which are enclosed by 0s).
The goal is to find the largest (in terms of pixel-count or enclosed area, both would work out for me for now)
My current planned approach is to:
start an array of array of coordinates of the 1s (or 0s, whatever represents a 'hit')
until no more steps can be made:
for the current region (which is a set of coordinates) do:
see if any region interfaces with the current region, if yes add them togther, if no continue with the next iteration
My question is: is there a more efficient way of doing this, and are there already tested (bonus points for parallel or GPU-accelerated) implementations out there (in any of the big libraries) ?
You could Flood Fill every region with an unique ID, mapping the ID to the size of the region.
You want to use connected component analysis (a.k.a. labeling). It is more or less what you suggest to do, but there are extremely efficient algorithms out there. Answers to this question explain some of the algorithms. See also connected-components.
This library collects different efficient algorithms and compares them.
From within Python, you probably want to use OpenCV. cv.connectedComponentsWithStats does connected component analysis and outputs statistics, among other things the area for each connected component.
With regards to your suggestion: using coordinates of pixels rather than the original image matrix directly is highly inefficient: looking for neighbor pixels in an image is trivial, looking for the same in a list of coordinates requires expensive searchers.
Given a scenario where there are millions of potentially overlapping bounding boxes of variable sizes less the 5km in width.
Create a fast function with the arguments findIntersections(Longitude,Latitude,Radius) and the output is a list of those bounding boxes ids where each bounding box origin is inside the perimeter of the function argument dimensions.
How do I solve this problem elegantly?
This is normally done using an R-tree data structure
dbs like mysql or postgresql have GIS modules that use an r-tree under the hood to quickly retrieve locations within a certain proximity to a point on a map.
From http://en.wikipedia.org/wiki/R-tree:
R-trees are tree data structures that
are similar to B-trees, but are used
for spatial access methods, i.e., for
indexing multi-dimensional
information; for example, the (X, Y)
coordinates of geographical data. A
common real-world usage for an R-tree
might be: "Find all museums within 2
kilometres (1.2 mi) of my current
location".
The data structure splits space with
hierarchically nested, and possibly
overlapping, minimum bounding
rectangles (MBRs, otherwise known as
bounding boxes, i.e. "rectangle", what
the "R" in R-tree stands for).
The Priority R-Tree (PR-tree) is a variant that has a maximum running time of:
"O((N/B)^(1-1/d)+T/B) I/Os, where N is the number of d-dimensional (hyper-)
rectangles stored in the R-tree, B is the disk block size, and T is the output
size."
In practice most real-world queries will have a much quicker average case run time.
fyi, in addition to the other great code posted, there's some cool stuff like SpatiaLite and SQLite R-tree module
PostGIS is an open-source GIS extention for postgresql.
They have ST_Intersects and ST_Intersection functions available.
If your interested you can dig around and see how it's implemented there:
http://svn.osgeo.org/postgis/trunk/postgis/
This seems like a better more general approach GiST
http://en.wikipedia.org/wiki/GiST
It's a long one so you might want to get that cup of tea/coffee you've been holding off on ;)
I run a game called World of Arl, it's a turn based strategy game akin to Risk or Diplomacy. Each player has a set of cities, armies and whatnot. The question revolves around the display of these things. Currently the map is created using a background image with CSS positioning of team icons on top of that to represent cities. You can see how it looks here: WoA Map
The background image for the map is located here: Map background and created in Omnigraffle. It's not designed to draw maps but I'm hopelessly incompetent with photoshop and this works for my purposes just fine.
The problem comes that I want to perform such fun things as pathfinding and for that I need to have the map somehow stored in code. I have tried using PIL, I have looked at incorporating it with Blender, I tried going "old school" and creating tiles as from many older games and finally I tried to use SVG. I say this so you can see clearly that it's not through lack of trying that I have this problem ;)
I want to be able to store the map layout in code and both create an image from it and use it for things such as pathfinding. I'm using Python but I suspect that most answers will be generic. The cities other such things are stored already and easily drawn on, I want to store the layout of the landmass and features on the landmass.
As for pathfinding, each type of terrain has a movement cost and when the map is stored as just an image I can't access the terrain of a given area. In addition to pathfinding I wish to be able to know the terrain for various things related to the game, cities in mountains produce stone for example.
Is there a good way to do this and what terms should I have used in Google because the terms I tried all came up with unrelated stuff (mapping being something completely different most of the time).
Edit 2:
Armies can be placed anywhere on the map as can cities, well, anywhere but in the water where they'd sink, drown and probably complain (in that order).
After chatting to somebody on MSN who made me go over the really minute details and who has a better understanding of the game (owing to the fact that he's played it) it's occurring to me that tiles are the way to go but not the way I had initially thought. I put the bitmap down as it is now but also have a data layer of tiles, each tile has a given terrain type and thus pathfinding and suchlike can be done on it yet at the same time I still render using Omnigraffle which works pretty well.
I will be making an editor for this as suggested by Adam Smith. I don't know that graphs will be relevant Xynth but I've not had a chance to look into them fully yet.
I really appreciate all those that answered my question, thanks.
I'd store a game map in code as a graph.
Each node would represent a country/city and each edge would represent adjacency. Once you have a map like that, I'm sure you can find many resources on AI (pathfinding, strategy, etc.) online.
If you want to be able to build an image of the map programattically, consider adding an (x, y) coordinate and an image for each node. That way you can display all of the images at the given coordinates to build up a map view.
The key thing to realize here is that you don't have to use just one map. You can use two maps:
The one you already have which is drawn on screen
A hidden map which isn't drawn but which is used for path finding, collision detection etc.
The natural next question then is where does this second map come from? Easy, you create your own tool which can load your first map, and display it. Your tool will then let you draw boundaries around you islands and place markers at your cities. These markers and boundaries (simple polygons e.g.) are stored as your second map and is used in your code to do path finding etc.
In fact you can have your tool emit python code which creates the graphs and polygons so that you don't have to load any data yourself.
I am just basically telling you to make a level editor. It isn't very hard to do. You just need some buttons to click on to define what you are adding. e.g. if you are adding a polygon. Then you can just add each mouse coordinate to an array each time you click on your mouse if you have toggled your add polygon button. You can have another button for adding cities so that each time you click on the map you will record that coordinate for the city and possibly a corresponding name that you can provide in a text box.
You're going to have to translate your map into an abstract representation of some kind. Either a grid (hex or square) or a graph as xynth suggests. That's the only way you're going to be able to apply things like pathfinding algorithms to it.
IMO, the map should be rendered in the first place instead of being a bitmap. What you should be doing is to have separate objects each knowing its dimensions clearly such as a generic Area class and classes like City, Town etc derived from this class. Your objects should have all the information about their location, their terrain etc and should be rendered/painted etc. This way you will have exact knowledge of where everything lies.
Another option is to keep the bitmap as it is and keep this information in your objects as their data. By doing this the objects won't have a draw function but they will have precise information of their placement etc. This is sort of duplicating the data but if you want to go with the bitmap option, I can't think of any other way.
If you just want to do e.g. 2D hit-testing on the map, then storing it yourself is fine. There are a few possibilities for how you can store the information:
A polygon per island
Representing each island as union of a list rectangles (commonly used by windowing systems)
Creating a special (maybe greyscale) bitmap of the map which uses a unique solid colour for each island
Something more complex (perhaps whatever Omnigiraffe's internal representation is)
Asuming the map is fixed (not created on the fly) its "correct" to use a bitmap as graphical representation - you want to make it as pretty as possible.
For any game related features such as pathfinding or whatever fancy stuff you want to add you should add adequate data structures, even if that means some data is redundant.
E.g. describe the boundaries of the isles as polygon splines (either manually or automatically created from the bitmap, thats up to you and how much effort you want to spend and is needed to get the functionality you want).
To sum it up: create data structures matching the problems you have to solve, the bitmap is fine for looks but avoid doing pathfining or other stuff on it.