The original topic was about getting the computer to create 3d worlds. That was what I was referring to when I said I like minecraft's taken on it. They use a seed to generate the world.
Julian On 17/01/2012, at 3:26 PM, BGB wrote: > On 1/16/2012 8:36 PM, Julian Leviston wrote: >> >> I like minecraft's take on this. >> >> Julian >> > > in which particular way?... > > > well, Minecraft is a fairly interesting game, and allows a lot of room for > people building stuff, ... > > the downside is: > how well does the technology work for considerably different gameplay styles? > (not based on mining and building) > what about world voxel density? > ... > > for example, making voxels 1/2 the size would lead (very likely) to an 8x > memory-requirement increase, and 1/4 (250cm) could require 64x the memory. > > a similarly sized world-space with a 1.5 inch (~ 3.75cm) voxel size would > require around 18963x as much memory. > > > some people have tried "fundamentally different" ways of dealing with voxels > (namely "Sparse Voxel Octtrees" and ray-casting), but these in turn have > different tradeoffs (on current HW there are significant problems regarding > resolution and performance). I suspect it "may be a few years" before this > strategy really becomes practical. > > a big issue though is that it probably still wont make creating of compelling > worlds all that much easier (so, probably a lot more random-generation and > similar, with its inherent pros and cons). > > I guess it may ultimately be a bit of a "wait and see" thing. > > > >> >> On 17/01/2012, at 2:31 PM, BGB wrote: >> >>> On 1/16/2012 6:47 PM, Casey Ransberger wrote: >>>> >>>> Top post. Heightmapping can go a really long way. Probably not news >>>> though:) >>>> >>> >>> I am still not certain, since a lot of this has a lot more to do with my >>> own project than with general issues in computing. >>> >>> >>> I had messed with a few technologies already. >>> >>> height-maps (long ago, not much used since then, generally randomized). >>> >>> the issue was mostly one of being "not terribly interesting", but it makes >>> sense if one wants terrain (and is "fairly cheap" in terms of memory use >>> and performance impact). >>> >>> a more advanced variety would be to combine a height-map with a tile-map, >>> where the terrain generator would also vary the texture-map to give a >>> little more interest. I have considered this as a possibility. >>> >>> also tried randomly generated voxel terrain (similar to Minecraft, using >>> perlin noise). issues were of being difficult to integrate well with my >>> existing technology, and being very expensive in terms of both rendering >>> and memory usage (particularly for storing intermediate meshes). one may >>> need to devote about 500MB-1GB of RAM to the problem to have a moderately >>> sized world with (with similar specifics to those in Minecraft). >>> >>> I suspect that, apart from making something like Minecraft, the technology >>> is a bit too expensive and limited to really be all that "generally useful" >>> at this point in time and on current hardware (I suspect, however, it will >>> probably be much more relevant on future HW). >>> >>> >>> I also tried randomly generated grid-based areas (basically, stuff is built >>> from pre-made parts and randomly-chosen parts are put on a grid). I had >>> also tried combining this with maze-generation algorithms. the results were >>> "functional" but also "nothing to get excited about". the big drawback was >>> that I couldn't really think of any way to make the results of such a grid >>> based generator "particularly interesting" (this is I think more so with a >>> first-person viewpoint: such a structure is far less visually interesting >>> from the inside than with a top-down or isometric view). >>> >>> it could work if one were sufficiently desperate, but I doubt it would be >>> able to hold interest of players for all that long absent "something else >>> of redeeming value". >>> >>> >>> the "main maps" in my case mostly use a Quake/Doom3/... style maps, >>> composed mostly of entities (defined in terms of collections of key/value >>> pairs representing a given object), "brushes" (convex polyhedra), "patches" >>> (Bezier Surfaces), and "meshes" (mostly unstructured polygonal meshes). >>> >>> these would generally be created manually, by placing every object and >>> piece of geometry visible in the world, but this is fairly >>> effort-intensive, and simply running head first into it tends to quickly >>> drain my motivation (resulting in me producing worlds which look like "big >>> boxes with some random crap in them"). >>> >>> sadly, random generation not on a grid of some sort is a much more complex >>> problem (nor random generation directly in terms of unstructured or >>> loosely-structured geometry). >>> >>> fractals exist and work well on things like rocks or trees or terrain, but >>> I haven't found a good way to apply them to "general" map generation >>> problem (such as generating an interesting place to run around in and >>> battle enemies, and get to the exit). >>> >>> the "problem domain" is potentially best suited to some sort of maze >>> algorithm, but in my own tests, this fairly quickly stopped being all that >>> interesting. the "upper end" I think for this sort of thing was likely the >>> .Hack series games (which had a lot of apparently randomly generated >>> dungeons). >>> >>> >>> it is sad that I can't seem to pull off maps even half as interesting as >>> those (generally created by hand) in commercial games from well over a >>> decade ago. I can have a 3D engine which is technically much more advanced >>> (or, at least, runs considerably slower on much faster hardware with >>> moderately more features), but apart from reusing maps made by other people >>> for other games, I can't make it even a small amount nearly as >>> "interesting" or "inspiring". >>> >>> >>> >>>> On Jan 16, 2012, at 8:45 AM, David Barbour <dmbarb...@gmail.com> wrote: >>>> >>>>> Consider offloading some of your creativity burden onto your computer. >>>>> The idea is: >>>>> >>>>> It's easier to recognize and refine something interesting than to >>>>> create it. >>>>> >>>>> So turn it into a search, recognition, and refinement problem, and >>>>> automate creation. There are various techniques, which certainly can be >>>>> combined: >>>>> >>>>> * constraint programming >>>>> * generative grammar programming >>>>> * genetic programming >>>>> * seeded fractals >>>>> >>>>> You might be surprised about how much of a world can be easily written >>>>> with code rather than mapping. A map can be simplified by marking regions >>>>> up with code and using libraries of procedures. Code can sometimes be >>>>> simplified by having it read a simple map or image. >>>>> >>>>> Remember, the basic role of programming is to automate that which bores >>>>> you. >>>>> >>>>> Regards, >>>>> >>>>> Dave >>>>> >>>>> >>>>> On Sun, Jan 15, 2012 at 4:18 PM, BGB <cr88...@gmail.com> wrote: >>>>> I am generally personally stuck on the issue of how to make "interesting" >>>>> 3D worlds for a game-style project while lacking in both personal >>>>> creativity and either artistic skill or a team of artists to do it >>>>> (creating decent-looking 3D worlds generally requires a fair amount of >>>>> effort, and is in-fact I suspect somewhat bigger than the effort required >>>>> to make a "passable" 3D model of an object in a 3D modeling app, since at >>>>> least generally the model is smaller and well-defined). >>>>> >>>>> it seems some that creativity (or what little of it exists) is stifled by >>>>> it requiring a large amount of effort (all at once) for the activity >>>>> needed to express said creativity (vs things which are either easy to do >>>>> all at once, or can be easily decomposed into lots of incremental >>>>> activities spread over a large period of time). >>>>> >>>>> trying to build a non-trivial scene (something which would be "passable" >>>>> in a modern 3D game) at the level of dragging around and >>>>> placing/resizing/... cubes and/or messing with individual polygon-faces >>>>> in a mapper-tool is sort of a motivation killer (one can wish for some >>>>> sort of "higher level" way to express the scene). >>>>> >>>>> meanwhile, writing code, despite (in the grand scale) requiring far more >>>>> time and effort, seems to be a lot more enjoyable (but, one can't really >>>>> build a world in code, as this is more the mapper-tool's domain). >>>>> >>>>> _______________________________________________ >>>>> fonc mailing list >>>>> fonc@vpri.org >>>>> http://vpri.org/mailman/listinfo/fonc >>>> >>>> >>>> _______________________________________________ >>>> fonc mailing list >>>> fonc@vpri.org >>>> http://vpri.org/mailman/listinfo/fonc >>> >>> _______________________________________________ >>> fonc mailing list >>> fonc@vpri.org >>> http://vpri.org/mailman/listinfo/fonc >> >> >> >> _______________________________________________ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
