I'd disagree with the accepted answer here.
I'd call this an autotile, and not a 9-slice
"9-Slice" (or 9-patch) is usually used to refer to a system where the content creator slices the image along 4 lines (not necessarily equally-spaced tiles). When rendering a rectangle, the corner slices are displayed at their native size, and the edges/center are ...
A name that will give you actual results in Google is 9-slice.
Another way to call it and ask Google about it is 9-patch.
As per this chat discussion, 9-pane seems to also be used, but the almighty Google will not show you what you need, unless you're into windows or something.
Thanks to Kevin and Josh in chat for that.
There's a solid overview of different popular tile combination patterns put together by Boris the Brave, building on some earlier work by Sean Howard.
I'll briefly summarize the main categories these authors identify in case the links break in future, along with a few additions of my own. I recommend you read the original articles for the full details.
You could use perlin noise, which is normaly used for heightmap generation.
Perlin noise in games
Then you could use the heights as an adviser, how high the chance of grass/dirt occuring in one region of the map is.
Example (Perlin noise values from 0-256):
If the value is over 200 the chance that grass is placed is 80% (dirt 20%).
If the value is between ...
What you could do is randomly generate a Voronoi map like this:
Picking random center points (see the black dots) and randomly decide if they are grass or dirt.
Then for over all tiles, check if it's closest to a center point of dirt or a grass.
If what you did previously is "flip a coin" for each tile (noise), generating a Voronoi diagram will ...
Layers are needed not only the most basic use of a tile map, but also allow more artistic expression and play features. Layers define the draw order of the sprites used in your world. They're simply a way to say, "Draw sprite X after sprite Y, so that sprite X will appear on top of sprite Y". They're typically generalized into layers so you don't need to ...
A simple way to achieve smooth lighting in a tile based game, is to draw a "lightmap" to a render target, and then drawing this render target over top your scene while alpha blending it.
Your light map render target would be the size of your tile map, but in pixels. Each pixel would represent the light color of its corresponding tile. This render texture ...
Most simple (and probably most naive) approach I can think of right now:
Start at your character and mark all surrounding fields as steps - 1.
Iterate over all newly marked fields and once again mark their surrounding fields as steps - 1 where steps would be the current field's step number, unless the new field has an already higher number.
Repeat the last ...
One thing I've done in the past for island shapes is to use perlin noise minus a circular shape. It usually produces one big island and some little things off on the side. You can use flood fill or smoothing to remove any small noise.
Here's a demo (flash) that I wrote for this question.
For each location (x, y) in the noise bitmap, compute the distance ...
Going to try and doodle up what I mean here as soon as I finish typing this, but:
What about merging the two?
Use the second (occlude by base) for everything that isn't a wall and the first (occlude by tops) for lighting the walls?
You actually did this by accident in your second example, with the wall that goes off the bottom of the image. Extending ...
Go to piskelapp.com , then choose 'Create new Piskel'. Click the menu on the right, and choose import your own image; select it, then put the number of size of each tile. After you are done editing, choose Export in separate images. Done!
You can create tiled maps on without using .tmx.
TiledMap map = new TileMap();
MapLayers layers = map.getLayers();
TiledMapTileLayer layer1 = new TiledMapTileLayer(width, height, tile_width, tile_height);
Cell cell = new Cell();
layer1.setCell(x, y, cell);
Each of these ...
here is my version of the cellular automata method
start by filling the grid with random
then run these cullular automata rules on it a couple times
If a living cell has less than two living neighbours, it dies.
If a living cell has two or three ...
Tiles and icons (even in UIs like window systems) are often in a size like 16x16 or 24x24 to make it easier to modify the tiles. Most times the tile size is a multiple of 8 because of the folowing reasons.
It is relatively easy to shrink a tile with the size 32x32 to 16x16 by simply putting 4 pixels together (e.g. create the median/average of the 4 pixels).
This is a basic connected components problem, and can be solved with a single invocation of breadth-first or depth-first search, or any flood-fill algorithm.
bool IsOneSolidShape(TileCollection tiles)
// Clear visited flags on all tiles.
// (This can also be implemented as a temporary set/map or parallel array,
// if you prefer not to clutter ...
I will present a general concept and three solutions using that concept.
Concept is an Influence map: For each location in the map, you are going to store a number that represent the distance to each color point. That way, for each position you can query how far it is from blue, red, green, etc. We call the result is the influence map.
For more detail on the ...
I'd consider a Square-based grid as a "base" type of tiles in any game. Such grid is simple to imagine and moves over this grid are simple to understand. It's also very simple to implement "under the hood". Those are few reasons why even the Chess game uses it :). Additionally, this grid helps you make "regular" levels, because Vertical and Horizontal are ...
Select a point on the map.
Place desired tile type with a base value such as 40.
Keep track of where you placed your newly desired tile.
Add the starting point to a list.
For each point in this list, you visit all neighbours.
While you have enough power left (started at 40) add a desired tile and add it to the list to be visited.
Give the new tile less ...
Sounds like you're after something like a flood fill algorithm.
Basically, something like the following algorithm (you can see other examples on the wikipedia page):
1. Add your castle to the Checklist
2. Get the first item from the Checklist
3. For each surrounding position
4. If not on Complete list
5. If `0` add to Checklist
6. If `1` ...
I start with coordinate systems — the coordinates for grid locations are (x,y) but as Krom mentioned in a different answer, for walls there can be up to two walls for each grid location. That leads to a second coordinate system, for edges between tiles. In this article I used West and South so the edges can be (x,y,West) or (x,y,South), but you can pick two ...
In a case like this, you are going to want to Pool your world tiles. The idea is to pre-load a fixed amount of tiles that you will be re-using during the rendering of your world.
When setting a tile into the world, you would typically set certain properties such as its position and texture. The rest of the object is already ready to go in memory.
Final answer, solved the performance problem! Changed my culling loop to this instead (based on the one used by Dice in BF3)
uint threadCount = WORK_GROUP_SIZE * WORK_GROUP_SIZE;
uint passCount = (numActiveLights + threadCount - 1) /threadCount;
for (uint passIt = 0; passIt < passCount; ++passIt)
uint lightIndex = passIt * threadCount + ...
There are no strict definitions. It's true that the term tiles can apply to both data structure and visual representation. When people say "Tiles", they are just breaking the game into a regular grid, either logically (data structure) or visually (tiled images).
It's probably more appropriate to only refer to tiles as the visual aspect (like real life ...
Have you considered using a 1D Perlin or simplex noise function? There are a number of advantages to this, including:
Infinite (within the realm of floating-point precision), non-repeating terrain
Can be generated real-time (even in a shader, which is fast), or ahead-of-time and stored in textures, as in your example
Borders automatically match up as both ...
Because by default OpenGL can only wrap the entire texture
(GL_REPEAT), and not just part of it, each tile is split off in to a
separate texture. Then regions of the same tile are rendered adjacent
to each other.
Consider the display of an single, ordinary textured quad in OpenGL. Are there any seams, at any scale? No, never. Your goal is to get all ...
Basically, I think what you do is first of all create a tile for each of your terrain types that seamlessly tiles with itself. As you said there are many tutorials available on how to do this.
Once you have those tiles, you can draw variants as well as transitions between different types of terrain by modifying copies of them. The only thing you need to ...
Both of those pieces of code appear to pick a random location (xx,yy in the first example and x,y in the second), then try to change grass to something else near that location.
There are lots of other algorithms, although most are more complicated than the ones you posted. I can't answer whether they're over your head; I don't know what's in your head ;-)
One option would be to load lighting information only as it appears on the screen. You would get one performance hit at the beginning as the full screen lighting is calculated, but from there you could cache the information and (as you mentioned) update it only when a light is flagged as modified. As you move across the world, you could calculate a short ...
You have 3 major options:
1: Implement some kind of sorting or data structure.
For example: Keep monsters in a list/array (Something you are probably already doing) and sort them by x and y. This would enable you to perform a binary search (Which has O(log n) performance) for locating a monster at a given tile. However, this introduces the need to sort ...