In addition to switching the whole chunk to stored rather than procedural, you could always store changes as a set of diffs that are applied to the chunk after generation. Either store every atomic change (change this block from dirt to open, etc) you could compress it by storing the events that occurred to create the change, and apply those events in order when recreating the chunk. (ie, apply an explosion radius 6 at (X,Y), dig at (X,Y), etc...) Once the diff starts to affect a certain arbitrary threshold percentage of the chunk, then you could switch to just storing the entire chunk as is, discarding the diff table. This way, you would see some memory savings on slightly-modified chunks, without incurring the bloat of a heavily modified chunk.
Banner advertising on our site currently available from just $5!
FLeBlancMember Since 10 Sep 2011
Offline Last Active Mar 21 2014 04:56 PM
- Group Crossbones+
- Active Posts 566
- Profile Views 7,756
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Posted by FLeBlanc on 28 August 2013 - 12:34 PM
Posted by FLeBlanc on 27 August 2013 - 04:35 PM
Well, the problem is that they're just too different. Marrying them just isn't really a straightforward job.
If you want overhangs, then cube-to-sphere suffers from the same limitations that a standard planar heightmap does. The structure just isn't there to do overhangs. Marching cubes can do overhangs just fine, but the difficulty there is doing the adaptive level of detail. LoD on a marching cubes implementation is fairly straightforward; the difficulty comes in fixing the cracks between chunks of different resolutions. You might take a look at http://www.terathon.com/lengyel/Lengyel-VoxelTerrain.pdf by Eric Lengyel. I haven't really researched this topic that much, nor have I read that whole thing, but I understand that he had a method for accomplishing the transitions.
swiftcoder has some links up at http://swiftcoder.wordpress.com/planets/isosurface-extraction/ that you might want to browse through, seems like some of the enhancements to marching cubes such as dual contouring might offer solutions.
At any rate, it's a pretty complex problem. Best of luck.
Posted by FLeBlanc on 27 August 2013 - 10:05 AM
Even for sprite work I'd rather use Blender. I just don't see this "deal" as anything at all to get excited about, and I doubt it's seriously going to make any kind of significant impact.
Posted by FLeBlanc on 20 August 2013 - 10:46 AM
Forgive me if this comes across like being an ass but, if I find myself bored one day and without a project to work on, I really think I might give this a shot. I genuinely am not trying to be sarcastic with my words but considering creating a satirical project.
I think I'm inspired. At some point I will have to write a program that will generate a series of files each with some random but completely useless line of code. Just simple lines and pointless lines like:
int Abcd = 3;
int abce = 6;
Maybe throw in the occasional if statement or switch. All of it will do absolutely nothing. I will have at least 1000 files and each with 1000 randomly generated lines of code and I will take these files and put them all into a project, compile and execute it. And then when I'm asked I can say with honesty that I have worked on a project with 1 million lines of code. But the best part will be when that person asks me what the project did. I will say with a smile, "Absolutely nothing."
And I think I would take pride in the absolute uselessness of the resulting program. I have a feeling there might be a small challenge to ensure that is indeed bug free.
Im quite alright with that , that may be even usefull, (for ex. to test the compilers, measure compilation speeds and things like that)
Sure, it might be useful. Except for the fact that would be completely useless for measuring compilation speeds by any useful metric.
Posted by FLeBlanc on 20 August 2013 - 09:01 AM
@JTippetts here at gd.net has done some stuff like this before. If you're interested, you might check out these journal links of his:
To me, 20 minutes for a 1280x1280 map seems quite excessive. Even given time spent doing an erosion and water-flow simulation of some sort to determine rivers, I'd think that three or four minutes should be expected, and if it was more than about 5 I'd want to take it apart and see where it is sticking. 20 minutes is just way too long.
Posted by FLeBlanc on 19 August 2013 - 08:39 AM
I consider myself as a moderately experienced, newer shipped a full game but got five years of coding on my back and so..
I read a questions how to start a game programming, what language/ framework to use and I began to think how to mention/enumerate possible ways I do know about. So let me begin this what do I know and maybe someone wil expand that
(sorry for weak english)
1) there is a low level way, you could start by using such things like a opengl + c or directx + c++ or even assembly on some empty machine but be aware that it can take you at least 5 or maybe 10 years to do something this way
Contrary to popular belief, OpenGL and D3D are not low level. Assembly is, but GL and D3D are mature mid-level APIs that abstract away the low-level details of the underlying hardware. Given the API docs, you can get a basic pipeline in place in a couple of days. And no, using basic GL or D3D isn't going to expand your development time out to 5 or 10 years. If your dev schedule is that extended, it's likely due to over-design and feature-creep of the game itself or a crippling lack of experience or motivation on the team.
2) there is a big engine way (something like ue3 or unity) I newer was doing such thing so I can say much about this - I suppose howewer that learning such engine can take long time to (but I do not know if this is even the main problem with that )
4) there are clicks /gamemakers - newer saw one (totally nothing to say, but it seem to be not a programming way)
6) there are also more esoteric frameworks suitable for programming games, for example a couple of basics (I saw some freebasic or what it was called, demos and it was running quite fckng good) There are also many less known languages where you can try write games too - it seem to me
quite interesting option for the open-minded begginer to learn some language that will stay unknown for most more advanced programmers - it could be like exotic adventure maybe
7,8,9,10 there may be other ways, If you can expand this, please contribute thanx
There sure are a whole lot of "I never did this" in your list. You never used an engine like Unity. You only looked at the docs for Allegro/SFML/SDL. You never used something like GameMaker. So, really, what is the point of this list?
It seems to me that instead of trying to teach other beginners, you ought to spend a few more years to tighten up your own personal skills and get a whole lot more experience so that you can talk about these things from a position of authority. There are a lot of sources out there to help beginners get started, and the last thing that we really need is yet another poorly-thought-out and poorly-written one. At some point, you'll become experience enough to understand that rough-overview enumerations like this are just a waste of time and effort if you don't really know what you are talking about and can't give an honest, experience-based assessment of the pros and cons of each.
Posted by FLeBlanc on 07 August 2013 - 09:31 AM
Yeah, it's a bit dark.
On what basis are we being asked to critique this? Is it the overall aesthetic? If that's the case, it needs more stuff. Real terrain isn't that bare and slick, barring empty and bare terrain like rolling dunes.
Are we being asked to critique it on technical merits? If that's the case, we really can't see the detail on the terrain so we don't know if there are problems with your texture splatting and detail mapping.
Posted by FLeBlanc on 05 August 2013 - 09:12 AM
Can't really see the terrain, to be honest, so it's impossible to make a good judgement. Folks got distracted by the rain (which does look good) but if you want an honest assessment of the terrain itself we'd need to actually see it.
Posted by FLeBlanc on 30 July 2013 - 11:41 AM
An isometric perspective is simply a camera set to orthogonal projection, oriented at an angle above the horizon (commonly 30 degrees, for the famed 2:1 ratio, or ~35 for true isometric; other common perspectives exist) and 45 degrees around the vertical. That is all there is to it, these days. In the old 2D days you had to do some weird tricks, but there is just no point in them anymore.
Posted by FLeBlanc on 23 July 2013 - 12:30 PM
Sounds like you are asking about the difference between procedurally generating a level (as Minecraft does) vs building a level by hand. Each method has advantages and disadvantages.
Procedural generation allows you to specify a relatively simple set of rules for the generation in order to produce a large amount of data. And we are talking large here. I saw something somewhere that estimated the size of a Minecraft world as several million times larger than the surface area of Earth. That's pretty large, way larger than you would ever be able to build by hand. If a large open world is your goal, procedural is the way to go. No team in the world could pre-build a world the size of Minecraft without heavy use of procedural tools.
Additionally, procedural can help to amplify replay value, assuming the gameplay is built to support it. With pre-built levels, once a player has run through them and learned all their secrets and surprises, that bit of content is essentially "used up". It holds no more surprises for the player. With properly built procedural gen, you can always present the player with new places they haven't yet seen and new challenges, emergent from a set of simple rules, for them to overcome.
The drawback of procedural gen is that it is superficially easy but essentially somewhat difficult. The concepts and broad ideas are fairly simple, and you can get simple results quickly, but to achieve production results you're going to have to spend quite a bit of time and thought. You can pour a lot of time into getting the generator just right, time that in some cases might be better spent pre-building a world and polishing it to a shine.
Posted by FLeBlanc on 22 July 2013 - 11:56 AM
Seems like you are allowing things to see the rigid bodies that shouldn't be. Seems like the explosion management system should instead gather up objects within the radius, and pass them damage and force events instead, and let the objects physics components worry about translating a force event to an actual force impulse on the physics bodies. Anything outside of the physics component system shouldn't even know what a btRigidBody is.
Posted by FLeBlanc on 22 July 2013 - 11:22 AM
Something to remember is that failing to code against the requirements in favor of a quick solution is also a form of pre-mature optimization (optimizing for development time rather than execution time) and can cause you serious problems down the road. The OP indicated a sample gameplay scenario (5 Ghosts, Death, Alien, Win condition) for which it would be appropriate to load everything in at game start and keep it memory resident. But then he asked about an RPG 20 hrs long, for which it definitely would not be appropriate to keep all assets loaded at all times. A 20 hr long RPG is not really the sort of thing you want to keep everything loaded all at once. So telling the OP to "just go ahead and load everything and don't worry about it until you have to" is leading him astray.
To build a 20 hr RPG, if that is your goal, you have to design smart asset management from the start. You don't want to get deep into the project by hard-coding and pre-loading everything, only to realize that you are running out of resources and now you have to retro-actively modify complex systems to support loading and streaming instead.
So, yes, pre-mature optimization is to be avoided, but that also includes hacks done in the name of "faster" development.
Posted by FLeBlanc on 20 July 2013 - 08:44 AM
Why would you come here for good examples of that stuff? This site tends to be hobbyist and indie oriented, not enterprisey or AAA. I wonder why you even need all of those documents. Seems like a lot of excess bullshit if you're not running a large team.
Posted by FLeBlanc on 19 July 2013 - 12:00 PM
They talk about combining various fractal noise functions to create complex terrain. Essentially, he uses a linear gradient function and a step function to create a sort of membrane with solid below a certain value and open above, then uses the noise function to distort that membrane. The noise function itself is a composite of many simpler functions.
You can also check out libnoise's tutorials to see more of how noise functions can be hooked together.
Posted by FLeBlanc on 01 July 2013 - 11:55 AM
On a featureless terrain like that, it's pretty difficult to even say how big a character should be in relation. Throw some more objects in there for point of reference, then adjust your scales.