Basically, I'm making an iPhone RPG as a little project for myself, I'm using Cocos2d and thus 2D tiled maps. I had planned to do randomly generate the levels for the map, but have realised it may be harder than I think to randomly generate them and keep collidable tiles working.
Is this possible to do, and has anyone done it?
I'm not familiar with tmx file format you are asking about but usually the way you go about generating a map is to start with the physics of the map not the visual representation. Here is two way to do it
(1) Define materials (water, sand, rock)
(2) Define how much of each you want to use in the map (as percentage)
(3) Place material seeds in your map
(4) Grow the seeds by expanding the material in all directions until the space is full
(5) Now define relation between visual tile and material. If it's transition from one material to another or 100% of one material.
(6) Generate your visual representation using material map and relation between materials and art.
...
(3) Fill your map with the materials you defined using the appropriate amount you defined.
(4) Use clustarization algorithm to swap tiles and form islands. (increasing the number of steps of your clustarization algorithm will make fewer but larger islands)
...
(0) There may be some other rules that the map needs to follow like accesability from one area to another. You can start by placing that in your physics map first and not allowing the other algorithms to break it.
Good luck!
Random map generation is possible and is used in many games. Diablo is one of the first games that come to my mind. Don't forget to set proper boundaries for the generation algorithm, however, because it might create a map with impassable locations.
Related
I'm trying to create an experience where I have a couple of detailed 3D models of buildings on the map with extruded building footprints of neighboring buildings via a vector tile source. The 3D models would be the main focus point and the extruded footprints would be for reference. One challenge I'm running into is that I have a global building footprint layer and it has a footprint for the 3D buildings which doesn't match up perfectly. Additionally, when extruded, it ends up merging/overlapping the nice 3D models.
I'd like to be able to hide the individual footprints that overlap the 3D models. My original thought was to grab the bounding box of the 3D model and then use the new within style expression, but it looks like this will only filter points and lines, not polygons. The building footprint polygons have no unique information in them that I could use to filter on.
I know I could monitor map movements and query the rendered features and manually detect intersecting polygons, but since there is no unique property on the footprint, I can't filter or use feature state.
Any ideas of how to efficiently avoid rendering individual polygons in a specific area that come in from a vector tile source?
It is a common issue that the buildings layer in Mapbox Streets don't contain any unique attributes to allow filtering or rendering differently.
The best solution is usually to source a different buildings layer, and in this case, remove those redundant buildings in pre-processing.
I can think of one rather crazy workaround that might work here, although the performance may be poor.
Add the building layer with very low opacity, of type fill, essentially invisible. (Maybe invisible would work.) Call your main source buildings`.
Create a secondary building source of type geojson, and a secondary fill-extrusion layer. Call this source buildings-copy.
On map move or moveend, use querySourceFeatures to obtain a copy of all buildings.
Process this copy using Turf to remove the buildings you don't want, and call setData to set the copy as the data for buildings-copy.
You may need to do some clever caching to get reasonable performance.
I am currently in High School, and I am in an APCSP (AP Computer Science Principles) class, which in my case is learning in Scratch programming. I am confused and have practically no idea what I'm doing. Scratch is very confusing and I feel like it's pointless to learn.
My question is this: Can anyone help me on how to make a Maze Generator on Scratch, as this is my project and it's giving me struggles.
Thank you.
It's actually possible to build with scratch but depends on what you are looking for. I assume you want to generate a simple maze like in old fashioned 8-bit games like boulder dash.
First decide on the size of your maze: for example 5 x 5 blocks.
If you want to create a maze, imagine drawing it on a grid on paper. Blocks are either "empty" or filled in. Our maze can be represented by numbers. The empty blocks are represented by a 0 and the filled blocks with a 1.
You could visualize that matrix like this if all blocks are empty:
0,0,0,0,0,
0,0,0,0,0,
0,0,0,0,0,
0,0,0,0,0,
0,0,0,0,0
Adding a border wall while keeping the inside empty would look like:
1,1,1,1,1,
1,0,0,0,1,
1,0,0,0,1,
1,0,0,0,1,
1,1,1,1,1
Using a "list" variable to store this information would fit best within the possibilities of MIT Scratch.
In this case, you need to understand that each block in our maze is represented by a position in above matrix. You could draw numbers on a piece of paper in the shape and size of your grid / matrix as a reference to remember the position of each block if that makes it easier.
We also need to look at how our maze will relate to the Stage size. The width and height in pixels of a default scratch project is 480x360.
A 5 x 5 maze is divided in blocks of 480 / 5 = 96 width and 360 / 5 = 72 height. In other words, a block needs to be 96x72 pixels, based on a full screen maze.
Next step, is creating a sprite representing the visualization of the blocks of the maze. I would keep the first "costume" of our block sprite empty, and create a fully filled block to represent the walls of the maze.
After that, we need to programmatically create our maze. I made an example you can explore of random drawing of the blocks of a maze:
https://scratch.mit.edu/projects/278731659/
(You can change the rows & columns value to see it scale up, but remember the limit to the amount of clones the block sprite can have is 300)
This is just to get you started and by no means a complete solution. I just hope this helps you think in the right direction.
You can make this more advanced, by adding a function to explore and correct our randomly drawn grid to generate a walkable path from position x to position y. A rule you can program is for example: Every empty position in the grid should have at least two other empty positions in the spaces above, below, left and right of it.
There are many different ways to do this; whether this is with sprites and stamp or 2D lists and pen. Either way, the main component is the algorithm. This wikipedia page gives details on how maze generation works and few different algorithms. There is also a video series by The Coding Train here where he creates a maze generator with the 2D list method from above (this method is a bit harder on scratch, however). Either way, the best thing to do is to look at examples others have made, figure out how they work, and try to recreate them or make them better. Here's a good place to get started.
Scratch IS truly pointless! A simple maze generator would have you use the pen to draw predefined shapes (Such as a long hallway or intersection). You should also make (invisible) squares to separate everything and have the program draw in the squares.
I will put a link later that leads to a sample project that has the code.
Check out this video by griffpatch
https://www.youtube.com/watch?v=22Dpi5e9uz8
This was one of my projects, and the instructor provided this video for everyone to follow and expand from.
I'm creating my game with dynamicly generated terrain. It is very simple idea. There are always three parts of terrain: segment on which stands a player and two next to it. When the player is moving(always forward) to the next segment new one is generated and the last one is cut off. It works wit flat planes, but i don't know how to do it with more complex terrain. Should I just make it have the same edge from both sides(for creating assets I'm using blender)? Or is there any other option? Please note that I'm starting to make games with unity.
It depends on what you would like your terrain to look like. If you want to create the terrain pieces in something external, like Blender, then yes all those pieces will have to fit together seamlessly. But that is a lot of work as you will have to create a lot of pieces that fit together for the landscape to remain interesting.
I would suggest that you rather generate the terrain dynamically in Unity. You can create your own mesh using code. You start by creating an object (in code), and then generating vertex and triangle arrays to assign to the object, for it to have a visible and sensible mesh. You first create vertices at specific positions and then add triangles that consist of 3 vertices at a time. If you want a smooth look instead of a low poly look, you will reuse some vertices for the next triangle, which is a little trickier.
Once you have created your block's mesh, you can begin to change your code to specify how the height of the vertices could be changed, to give you interesting terrain. As long as the first vertices on your new block are at the same height (say y position) as the last vertices on your current block (assuming they have the same x and z positions), they will line up. That said, you could make it even simpler by not using separate blocks, but by rather updating your object mesh to add new vertices and triangles, so that you are creating a terrain that is just one part that changes, rather than have separate blocks.
There are many ways to create interesting terrain. One of the most often used functions to generate semi-random and interesting terrain, is Perlin Noise. Another is his more recent Simplex noise. Like most random generator functions, it has a seed value, which you can keep track of so that you can create interesting terrain AND get your block edges to line up, should you still want to use separate blocks rather than a single mesh which dynamically expands.
I am sure there are many tutorials online about noise functions for procedural landscape generation. Amit Patel's tutorials are good visual and interactive explanations, here is one of his tutorials about noise-based landscapes. Take a look at his other great tutorials as well. There will be many tutorials on dynamic mesh generation as well, just do a google search -- a quick look tells me that CatLikeCoding's Procedural Grid tutorial will probably be all you need.
This question is (mostly) game engine independent but I have been unable to find a good answer.
I'm creating a turn-based tile game in 3D space using Unity. The levels will have slopes, occasional non-planar geometry, depressions, tunnels, stairs etc. Each level is static/handcrafted so tiles should never move. I need a good way to keep track of tile-specific variables for static levels and i'd like to verify if my approaches make sense.
My ideas are:
Create 2 Meshes - 1 is the complex game world, the second is a reference mesh overlay that will have minimal geometry; it will not be rendered and will only be used for the tiles. I would then Overlay the two and use the 2nd mesh as a grid reference.
Hard-code the tiles for each level. While tedious it will work as a brute force approach. I would, however, like to avoid this since it's not very easy to deal with visually.
Workaround approach - Convert the 3d to 2D textures and only use 1 mesh.
"Project" a plane down onto the level and record height/slope to minimize complexity. Also not ideal.
Create individual tile objects for each tile manually (non-rendered). Easiest solution i could think of.
Now for the Unity3D specific question:
Does unity allow selecting and assigning individual Verts/Triangles/Squares of a mesh and adding componenets, scripts, or variables to those selections; for example, selecting 1 square in the 10x10 unity plane and telling unity the square of that plane now has a new boolean attached to it? This question mostly refers to idea #1 above, where i would use a reference mesh for positional and variable information that were directly assigned to the mesh. I have a feeling that if i do choose to have a reference mesh, i'd need to have the tiles be individual objects, snap them in place using the reference, then attach relevant scripts to those tiles.
I have found a ton of excellent resources (like http://www-cs-students.stanford.edu/~amitp/gameprog.html) on tile generation (mostly procedural), i'm a bit stuck on the basics due to being new to unity and im not looking for procedural design.
I'd like to hear what people think the optimal draw calls are for Open GL ES (on the iphone).
Specifically I've read in many places that it is best to minimise the number of calls to glDrawArrays/glDrawElements - I think Apple say 10 should be the max in their recent WWDC presentation. As I understand it to do this you need to put all the vertices into one array if possible, so you only need to make the drawArrays call once.
But I am confused because this surely means you can't use the translate, rotate, scale functions, because it would apply across the whole geometry. Which is fine except doesn't that mean you need to pre-calculate every vertex position yourself, rather than getting open gl to do it?
Also, doesn't it mean you can't use any of the fan/strip settings unless you just have a continuous shape?
These drawbacks make me think I'm not understanding something correctly, so I guess I'm looking for confirmation that I should:
Be trying to make an uber array of all triangles to draw.
Resign myself to the fact I'll have to work out all the vertex positions myself.
Forget about push'ing and pop'ing each thing to draw into it's desired location
Is that what others do?
Thanks
Vast question, batching is always a matter of compromise.
The ideal structure for performance would be, as you mention, to one single array containing all triangles to draw.
Starting from here, we can start adding constraints :
One additional constraint is that
having vertex indices in 16bits saves
bandwidth and memory, and probably
the fast path for your platform. So
you could consider grouping triangles
in chunks of 65536 vertices.
Then, if you want to switch the
shader/material/glState used to draw
geometry, you have no choice (*) but
to emit one draw call per
shader/material/glState. So grouping
triangles could consider grouping by
shaderID/materialID/glStateID.
Next, if you want to animate things,
you have no choice (*) but to
transmit your transform matrix to GL,
and then issue a draw call. So
grouping triangles could consider
grouping triangles by 'transform
groups', for example, all static
geometry together, animated geometry
that have common transforms can be
grouped too.
In these cases, you'd have to transform the vertices yourself (using CPU) before merging the meshes together.
Regarding triangle strips, you can transform any mesh in strips, even if it has discontinuities in its topology, by introducing degenerate triangles. So this is a technique that always apply.
All in all, reducing draw calls is a game of compromises, some techniques might work well for a 3d model, while others may be more suited for other 3d models. IMHO, the key is to be creative and to carefully benchmark your application to see if your changes actually improve performance on your target platform.
HTH, cheers,
(*) actually there are techniques that allow to reduce the number of draw calls in these cases, such as :
texture atlases to group different textures in a single one, to prevent
switching textures in GL, thus
allowing to limit draw calls
(pseudo) hardware instancing that allow shaders to fetch transforms
from various sources to transform
mesh instances in different ways.
...