• Content count

  • Joined

  • Last visited

  • Days Won


JTippetts last won the day on December 2

JTippetts had the most liked content!

Community Reputation

13023 Excellent


About JTippetts

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

55682 profile views
  1. Mostly just a lot of googling. I 'got started' by playing various roguelikes back in the day, then at some point I purchased the book Texturing and Modeling: A Procedural Approach and that got me started on using noise functions. After that, it was all just various experimentation and some internet googling.
  2. Never underestimate the power of erosion. Also, spend some time looking at actual terrain on Google maps satellite view. One thing you will see is that terrain varies across different scales. In your sample shot, you have two types of terrain: flat and bumpy. All the bumps are the same scale, across the entire terrain, indicating that you are probably just using a simple fractal of some sort. Fractals can be useful as a building block tool, but not really as an end in themselves. Look at throwing other building blocks into your arsenal, such as Worley's cellular functions, domain turbulence, etc... (Here is an example using a cellular F2-F1 function with fractal domain turbulence: clicky). You can also look into using fractals that incorporate the previous layer's derivative, to give a sort of eroded look without an explicit erosion pass. Íñigo Quílez talks about this some, and it is in fact the technique used by the Shadertoy shader in @piluve's post. This article by Giliam de Carpentier presents a couple different variants of derivative noise. As far as the detail goes, if you are going to use a lower resolution terrain as you are, you can use a normal map that covers the entire terrain to 'fake' the smaller details. Those details wouldn't have any effect on gameplay (ie, they wouldn't affect the geometry that the player walks on) they just affect the visual result, adding shading detail to make it look like the terrain is higher resolution than it really is.
  3. Are you asking only about procedural content used IN the game, or do you include procedural generation as a part of the game creation process? Because even games that have static (ie, not generated at run-time) worlds frequently make use of procedural stuff during the creation phases. For example, using algorithms to generate a large chunk of terrain, then using editing tools to make modifications such as building placement, spawn locations, etc.... The procedurals allow the designer to quickly rough-in large areas, rather than forcing them to hand-create every mountain and ridge and valley. Algorithms also allow for more advanced realism, ie an erosion pass on a generated terrain, then using splines to locate roads and rivers and trails. Stuff like that (realistic terrain) is quite difficult to hand-model, but quite easy to model using algorithms as a starting point. I've got a terrain editor in the works that allows to do just that kind of thing. Rapidly generate a terrain from various functions, erode and perform various editing and texturing tasks, place some roads or rivers using splines, then export height and texture blend maps. You can very quickly (ie, in just a few minutes) rough-out a large map. (An example.) As far generation techniques go, I've experimented a bit with some of it and have written about various things over the years in my blog, including generating rock and dirt textures using particle system scattering in Blender, generating a side-scroller level using 3D blocks, generating Minecraft-like block worlds, generating mountain tiles for a 2D game, creating textures from noise functions (more), procedural islands, and so on, and so on. Some of the stuff I've played with have been in-game techniques, but most of it has been for offline content creation stuff. Other techniques I've used include noise functions (quite extensive), tile-based stuff, Wang tiles, architectural grammars, space colonization for procedural trees, meta-tiles (where the 'tile' is a large piece, such as an entire dungeon room, complete with contents), drunkard's walk, labyrinth generation, and many more. Personally, I see procedural generation as a critical part of the game design process, even if only during content creation. With a comprehensive set of rules, you can generate levels for simple puzzle games all the way up to entire open worlds populated with fleshed-out NPCs and monsters.
  4. The Poor Man's 3D Camera

    This was an interesting read. I love to read about other people solving their problems. It always sorta nudges my own thinking around about my own stuff.
  5. Following along from the previous post about the node graphs, I have lately pulled the node graph stuff out and have started work also on a standalone editor for noise functions. https://github.com/JTippetts/ANLEditor The editor uses the node graph functionality, along with an output node that provides various functions, to allow one to create graphs of noise that can be used to create textures. The output node allows you to map either a Grayscale or RGBA image output (the Volume button currently does nothing, for now). It can analyze a connected grayscale function to give you a histogram graph of how the function output is distributed, and calculates a set of scale/add factors that could be used to remap the output of the function to the 0,1 range. It allows you to specify seamless mapping settings, and to export images to file. It's all still fairly rudimentary and I still haven't settled on a final save/load format, but all that is in progress. I have also started creating an editor of sorts for Goblinson Crusoe, using some of this editor functionality. It's still in its infancy, but eventually it will allow me to create areas and area pieces for use in randomly generating maps. Lately, I've been doing some thinking about what I want to do with Goblinson Crusoe. It has become clear to me that it will probably never be a commercial release. It will probably never be on Steam or anything like that. I just don't have the time. I wasted a LOT of my early years spinning my wheels and going nowhere, and now I have so many other things that have to come first (family, full-time job, home-ownership, etc...) that I just don't think I'd ever realistically finish this thing. If I could work on it full-time, perhaps, but mortgage, bills, and the necessity of providing insurance and safety nets for my wife and kids means that isn't feasible. However, I do enjoy working on it, and don't want to just abandon it. Nor do I want it to never see some kind of release. And I would like to see some kind of return on my huge time investment over the years. So I've been thinking of making GC a free and open-source project, linked with a Patreon and/or PayPal for goodwill donations. At least that way, if I die or life gets in the way of further development, at the very least it wouldn't disappear completely. Plus, I might get at least a few dollars from appreciative people along the way. What do you all think? Any advice on how to structure such a thing? Good idea/bad idea?
  6. How to learn from Quake source code

    ModeX and 13h were pretty nice. As you say, standardization makes a difference. Before the ModeX days, in the days of the weird transition from Hercules/monochrome stuff, through CGA and EGA to VGA, it was kind of messy. To make your game work on as large a range of hardware as possible, you had to write a LOT of custom code paths. And 13h didn't do anything for the equally shitty sound card business.
  7. How to learn from Quake source code

    Man, this brings back some memories. While it was interesting in its way, it was kind of horrible and it's the reason I don't miss developing on DOS at all.
  8. The million monkeys approach.

    I would guess that throwing that many non-experienced people at the project would guarantee it never got finished. The Mythical Man-Month is still kind of a thing, after all.
  9. Noise derivatives

    You might take a look at this article by Giliam de Carpentier about some modifications of Quilez's original derivative noise for an idea of how you can use the derivative. The derivative basically says 'this function is changing at such-and-such rate, in so-and-so direction, at this given location'. So, essentially, it's good to use anytime you want to do something that depends on how rapidly a function is changing value. When a function is used directly as a heightmap, this derivative corresponds to the 'steepness' of the terrain at a given location. However, there isn't always necessarily a one-to-one correspondence between the derivative and the terrain steepness; for instance, if the derivative is used in a function that is used to apply a domain transformation. Pretty much, this. If you do enough googling, you'll run across some specific tips or ideas, maybe, but a lot of it really depends on context and even personal preference. In my experience, the three most useful tips for making decent terrains are 1) Use domain distortion/perturbation 2) Use simulated or physically-based processes such as erosion 3) Use smoothstep functions to choose between different archetypes to create a more heterogenous result.
  10. Is Phil Fish a Jerk?

    Money is literally why these companies are in business. If a company can't make money and pay its employees based off a small cadre of vocal hardcore players, and their research indicates that they'd have a better chance of growing their business by expanding their audience to so-called 'casuals', then it would be a breach of trust and a betrayal of their shareholders to NOT do what they have to do. Regardless of how it makes the (usually small, in my experience, if vocal) group of hardcore players angry. Now, I have a mostly negative opinion of pay-to-win. like a lot of people. However... the people in charge of a company do not have a duty to avoid pissing off the 'hardcore contingent' by not offering things that cost money. They have a duty to increase shareholder value, keep the company solvent, and pay the employees on time. Sometimes, the latter comes at the expense of the former. A company that isn't attracting new players is a company that isn't growing.
  11. Octagon-Square tiling for world map

    You misunderstand the purpose of such a tool. It's not for creating randomly generated terrain in-game; it's to give you, the level designer, a place to start. Rather than having to grab a brush and start painting mountains and plains and what-have-you, you construct a function that can rapidly fill the space, tweak the parameters, then when you have something you like you can start doing custom tweaks and modifications to it with brushes and filters to make it into what you need it to be. It's a quite common technique for rapidly filling out the base of an area. Much easier to let a specially constructed routine build the mountains and plateaus, rather than try to build them by hand. If you need finer control of placement, in my tool I have masks for that purpose; you can paint in a mask, then apply the generation routine only to masked or unmasked areas. Lets you place mountains where you need mountains, without having to sculpt the mountains yourself. A common trick with heightmaps is to use a facade object, modeled as a cliff, to mask the region of sloped terrain where the cliff should be. The cliff object is constructed to fit the terrain, and blend smoothly in with it, and create the appearance of a vertical cliff. Cave entrances are more difficult, if you want it to be an actual hole in the terrain, then often a premade Terrain object has difficulty with these. However, if your in-game perspective is limited to a top-down-ish third person view, like in Zelda, etc..., and doesn't allow the player to freely rotate the in-game camera to look off into the distance, then there is no need to actually use a Terrain object. Terrain objects are usually built to allow this kind of free-viewing, and they include functionality for level-of-detail that is unnecessary in a top-down. Just use simple meshes, and cut whatever holes in them you like. In this way, you could construct the heightmap as a rough base, then bring it into Blender by using the heightmap to displace a subdivided plane. After that, you can push/pull vertices of cliffs to make them truly vertical, cut out holes for caves, etc... You can also construct the cliff and cave entrance facade meshes, modeling them around the cliffs and holes, although it is also possible to build a tool that can generate such things procedurally, building a volume mesh of some sort and mapping it with a texture. There is also a different use for a texture as a heightmap. Standard heightmaps use a grayscale texture to provide vertical displacement of a point on a plane. However, you can use all three color channels, red green and blue, as displacements to the X,Y and Z coordinates of the point, to provide truly vertical cliff faces and other varied terrain. Building such maps is usually trickier than a simple heightmap, but the results can be nice. You can do this on a heightmap. In my editor, the spline curve is used to alter the terrain height along the length of the spline and to set a texture layer for the road surface. However, instead of setting a texture, you could instead have the spline build a quadstrip mapped with the road texture applied. It's all a matter of having the right tooling: In this case, I use the spline to raise the elevation to roadbed height, then construct a long quadstrip with the road texture mapped to it. The quadstrip is raised just slightly above the level of the terrain, to avoid Z-fighting. I've never used Unity, but in Urho3D you can attach script objects to objects. You could certainly put whatever functionality you require in the script object, to do what it needs to do. I'm sure Unity offers similar functionality.
  12. Octagon-Square tiling for world map

    A lot of this really depends on exactly what you want to achieve, how you want your game to look and feel, and the kinds of actions the player can perform. A lot of this discussion has been, for my part, just throwing ideas out there without really knowing what you are trying to achieve in any detail. We've done a lot of talking about tiles, but I haven't nailed down exactly whether or not a pure, rigid tile-based representation is what you really want. Your earlier posts indicate you are pursuing tile-based methods as a way of reducing the manual labor involved in creating a level, and not as any sort of aesthetic choice. But given that you are not opposed to 3D, there are other potential methods, other than tile-based ones, that could help. But some questions do need to be asked first. One big question is, how to handle elevation and height? We've talked about displacing ground to make rivers, so it seems elevation will play a part in your game. True varying elevation, however, has always been a complicating factor for tile-based systems. Creating a tile or tile object for a flat piece of ground is a lot simpler than creating one that can fit on ground of arbitrary elevations. Also, if the player can modify elevation during the game, that complicates things even further, since now you need to proceduralize everything, whereas if the elevation is laid down during level creation and made static, then you can resolve a lot of things during creation time that would be difficult to resolve during run-time. Autotiling algorithms, which automatically pick and choose tiles and tile objects based on the pattern of neighbors, and which update these choices in real-time as edits are made, vastly simplify the process of laying down terrain and roads, but they can get complicated when it comes time to deal with some edge cases or with large sets of tile objects. But if the terrain is to be very interactive during gameplay, then these algorithms need to be perfected. If not, then you can often get by with manual kludges in many of the special cases. If you are not tied to tiles from any design or aesthetic standpoint, you just want to get a level together quickly and with minimal effort, there are other things you can do. For example, I am currently working on a terrain editor. (Forgive the self-promotion here.) It's still in its infancy, but it does offer a couple things that can help get a level up and going fairly quickly: 1) procedurally generate a chunk of terrain and 2) use splines to modify the terrain for rivers and roads. The procedural terrain generator uses a visual node-based UI system for chaining functions together to modify the elevation or the ground cover. I made an image to show a sample of the workflow. I'll just link it, rather than embed it, since it is kinda big. Linky. Essentially, it uses a workflow of procedurally generating a terrain to start with, applying procedural filters such as erosion, cavity fill, etc... to modify the terrain, and using spline curves to modify the terrain for rivers and roads. In all, the area created in the sample image took me about 15 minutes to put together, although of course more time would need to be spent to make a 'real' level. And ultimately, it would require some tools that are not yet implemented. With such a tool, you can brainstorm other kinds of things that can help the process. Like drawing a closed spline loop around an area and filling the center to flatten an area for buildings. Or providing a menu of structures and prefabs to place with a click of the mouse at a location. A tool to measure between points, to help with sizing a prefab as needed. Using procedural functions to scatter props such as rocks and bushes and trees. Using a spline tool to create the geometry for flowing water. Stuff like that. Building a level editing tool can be quite time-consuming, but if your game is large-enough scale then it can be worth it. Of course, if you really want to go with a tiled approach, you still have quite a few technical hurdles to jump. And how you jump them really depends on a lot of your game design, and your choice of engine/tools. For an example, I use the Urho3D engine, which comes with a pre-built editor with which you can make prefabs, such as the tile objects we've been talking about. Between the editor and Blender, you should be able to build your set of tiles and metatiles fairly easily (though, of course, it will take some time.) Blender can create the geometry, and the Urho3D editor can be used to combine it together into a prefab that can be loaded by the game. Similar workflows exist for other engines such as Unity, Unreal, Godot, Atomic, etc... They can vastly reduce the amount of time you spend building custom tooling, whether for a tile-based framework or not.
  13. Octagon-Square tiling for world map

    If I were doing it, I'd forgo the subtile method that I suggested earlier. Since this is 3D, you'll likely have access to a decent set of mesh->mesh collision test routines, so instead I would represent a tile or a tile object as 2 bits of data: 1) the actual mesh geometry(ies) to draw and 2) a simplified collision box-out shape that would be used to test collisions against other tile objects that want to occupy the same tile. Here is how that would work. Here is a road tile object, and its associated box-out: Now, another highway comes along and wants to cross the tile going another direction. So you try to place another road tile: Uh oh. When you check the intersection between the two tile objects' collision box-outs, it shows there is an intersection. That means you need to resolve that issue somehow. One alternative is to force the second tile object to a different pattern, such as a bridge: The bridge has a raised section in the center that allows the road to pass over the existing road. Another alternative would be to swap in a 4-way intersection tile that depicts an intersection and has a corresponding box-out. That would need to be left up to the creator's discretion and choice. Every tile or tile object would have an associated box out. A base, bare ground tile would have no box-out collision geometry. A river would have a raised box similar to what a road has, enabling it to be crossed by a bridge. A beach would have a very tall box-out structure occupying the areas of tile that are underwater, prohibiting any sort of bridging or building-over that area. And so forth. At that point, it becomes a job of assembling the tile objects, boxing-out the collision geometry, and feeding that data to an autotiling algorithm of some sort. When collisions happen, the autotiler would bail-out to some sort of conflict resolution mode, where the creator can swap out individual tile pieces to resolve the issue.
  14. Octagon-Square tiling for world map

    Well, the good thing about 3D is that you can use as much geometry as you need to. In this case, to add a river you could simply subdivide the ground tile mesh to a proper detail level, then displace the 'river' parts downward. Then add a water tile for the water surface: You can even scatter a few doodad meshes as in the above, to 'dress up' the water's edge. Again, that tile is drawn in 3 passes: ground, then water, then rocks. (Although, in a 3D engine, if the water material is partially transparent it would typically be drawn in an alpha pass after the solids.) No complicated stitching required, just 3 meshes. (Or, 3 batches, anyway; the clutter could be built as a batch using instanced meshes.)
  15. Octagon-Square tiling for world map

    On modern hardware, some overdraw is acceptable. In this case, you would simply draw the tile in several passes. In a simple 2D top-down, that would look like: Step 1, draw the ground. Step 2, draw the road. Step 3, draw the rock. The tile itself isn't drawn as just one image; it's drawn as a composite of layers, using sprite alpha blending. In 3D, it would be similar: 1) Draw the ground. 2) Draw the road tile mesh. 3) Draw the rock mesh. That's how you can have tiles of arbitrary complexity: by layering them up in-game from simpler pieces. The tile starts as a bare piece of ground, then you build a road. Eventually, you build a bridge over that road and lay a train track. No need to try to create a single tile graphic to represent that; just structure your map so that it can render in layers (if 2D), or just instance multiple separate objects (if 3D). That small amount of overdraw will make no difference, compared to the effort of trying to stitch and snip things together as in your diagram.