A pattern that is commonly used for game state management is for each game state's Update method to return a pointer to the game state that should be made current. If null is returned instead, continue with the current state. So, for example, when the game is started the main menu state is created and set as current. When the Play Game option is selected, then a new Game state is created and returned during Update, so the state manager knows to discard the current state and set the new state as current. During gameplay, if Esc is pressed, a new state (one which keeps a reference to the game play state internally so that it can continue to render the view even though that state's updating is paused) is created for the in-game options menu. If Return to Game is selected, the stored Game state is returned by Update, causing the in-game menu to be discarded.
Each state implements its own set of Render and Update functions to perform tasks relevant to that state. The outside loop of your game runs the same, regardless of the currently active state; however, when currentstate->Update() is called, different things happen depending on the current state. You shouldn't be updating your game while in Main Menu, for example (since it shouldn't exist yet). You may need to draw the Game state while in Options menu, but if it's single-player you shouldn't be Updating the game state. And so forth.
If the terrain isn't modifiable, you can simply store the random seed used to generate the chunk. If it is modifiable, you can store the seed plus a list of changes. Either way, when a chunk is to be loaded, you check to see if there is a seed stored and if not, create a new seed. If there is a seed, use it to regenerate the chunk then iterate the list of changes and apply them. If a changes list exceeds some arbitrary threshold, it might be more cost-effective to switch over to storing the whole chunk instead.
You may want to check out the game Phantom Brave for PS2 (there are also Wii and PSP ports of it). It's a radically different game than BG or PS:T, but it uses randomly generated terrain on which the player can freely roam (ie, not tile based). It uses 2d sprite assets in a 3D world, therefore the view is restricted to a more or less isometric view (with predefined rotations allowed).
At the very least it might give you more to think about.
Looks tile-based to me. Tile-based doesn't necessarily mean you are restricted to tile-by-tile movement; just that the world is built up from tiles, or building blocks, that are usually aligned on a grid.
You can get pretty complicated with a tile-based scheme. Look at Torchlight 2, for example. It uses the concept of tiles, or chunks, only the tiles are large and can be complex. Play a few levels of TL2 and you can start to see the pieces that repeat.
Looks like a waterfall, running water in the foreground, some leafless trees in the back, and I think I even see some skulls/heads piled on the near bank of the water at the bottom, a guy with a sword on the far bank, and a dude hanging from one of the trees. That, or this is the most fucked up Rorschach inkblot ever.
The picture, on its own, is kind of intriguing. It hints more than anything. If that background were moving/animated, it might make it a whole lot harder to read, but that might also add an element of menace to the feel of the game. If you were toodling along, just barely paying attention, and all of a sudden, "oh, whoa, that dude is hanging there. Are those effing skulls?" it could be kind of fun.
I'd say do a quick and small prototype to nail down the feel and show it to some folks. If it works, run with it. I would give it a play.
This seems dodgy to me. What happens if the distance between player and camera is smaller than the length of (playerPos-camPos)*strength? This would happen if strength>1. You don't show how you calculate strength, so I assume it's tied to elapsed time somehow. If strength>1 then the camera will over-shoot the player's position which can possibly cause camera stutter. You might try clamping strength to 1 to keep it from overshooting.
Yeah sorry, I know it's a really vague question. The problem is I can't post a video of it as the problem doesn't seem to be visible in the video when it's been recorded - even though I can see it clearly with my eyes (on the actual device it's running on)
If you're using third-party video capture (rather than dumping frames yourself from in-game) then it is highly likely that the capture will indeed miss a single-frame glitch in your animation. The awful part, too, is that if you start dumping video yourself, then the increased processing load could throw off timing and cause the problem to disappear; I've had issues like that before.
Clearly it's caused by gamma rays interacting adversely with the silicon of your CPU.
You're right about the question being vague, though. I doubt even John Carmack could answer this one with such little information, and he's pretty good at programming and stuff. This is likely one of those things that you're just going to have to bite the bullet and figure out for yourself, since you are the one with a) knowledge of the context of the program, b) knowledge of the conditions within which the bug occurs and how to reproduce it and c) access to the source code so you can do some debugging and logging.
I'd say, though, that it might be helpful if you could dump a full set of logging info from your animation system on command. Maybe set a hotkey to enable/disable so that you're not generating multiple megabytes of non-helpful data. Enable logging, do a jump and try to repro the bug, then check your logs and see if you can figure out what state changes are occurring that shouldn't be. Try to log as much as you can regarding animation state; the more information you can collect the better.
I tend to believe that it is a mistake to try to deal with biomes as discrete units like this. It leads to weird situations just like you describe, weird situations where you might have desert+cactus right next door to snow or, as you describe, high mountains right next to lowlands with a sharp cliff transition in between.
My personal preference is to approach it from a simulation and modeling point of view. I would first start with the terrain, laying out mountains and hills and lowlands using various combinations of fractals, then use this terrain-type map to inform a simulation process for distributing moisture. Given even a small set factors such as elevation, terrain slope, terrain roughness, latitude and moisture you can infer a lot about what biome a particular area should belong to. Based on this set of data, I can use the type mask to lay down terrain instances and set tiles, then populate the map with appropriate doodads.
JTippetts talked about his island generation process in his journal some time back, and I modeled (stole) my method from his, although in my most recent project the terrain was continuous and infinite rather than on an island. But the idea was pretty much the same, and I even used his noise library to do it.
Grow/shrink the circle using 1D perlin noise? Make the radius a function of the angle, something like this:
// PerlinNoise1D(x) returns a value in [0, 1]
radius = radius * (PerlinNoise1D(angle) + 0.5);
Oh, good idea! I will try it and upload here some results.
Here's some results for you:
Since you are using a 1D function indexed by angle, the pattern ends up as a randomized star-like shape. You can't generate disconnected islands this way. All pixels lying along a given angle will use the same radius.
However, if you use a 2D noise function, indexed by (x,y) to modify the radius, you can get some disconnects:
Pixels lying along a given angle won't use the same radius, so some pixels further out might use a shorter radius than pixels lying nearer in. This means that voids, or holes, open up, providing the necessary turbulence to create disconnects.
Better textures would help immensely. Shaders can only take you so far.
It's very difficult to even tell what the material on those walls is supposed to be. It has very harsh normals, some weird specular that makes it look moist and shiny, etc... I assume it's supposed to be stone, but it just doesn't look like stone.
The first rule of texture creation: work from reference. Try to find a photo or two of the exact type of rock you want represented on your walls, and when creating your texture keep that reference open and handy. Refer to it often; that's why it's called reference. Try to study it to see how the light falls on it, how the crystalline planes and fractures are formed, what the surface coloration and reflectivity do to the lighting and shading.
In your texture I see mistakes that a lot of technical people make, because they approach the aesthetics of a texture or scene from a technical or programmer's perspective, rather than an artist's perspective. Technical people (and I am as guilty of this as anyone) often think that more is better. Do you use normal-mapping? MOAR NORMALS!! Specular? MOAR SPECULAR!!! It sometimes seems like, "I spent all this effort writing the normal-mapping shader, so I need to really enhance those normals so that people notice how awesome and bumpy things look now." The result, of course, being an overly-shaded mess, as demonstrated in your screenshot.
Rather than MOAR NORMALS and MOAR SPECULAR, though, what you need is APPROPRIATE NORMALS and APPROPRIATE SPECULAR. You need to use a light touch with these things, add appropriate detail that subtly enhances rather than overwhelms. You also need to ensure that you generate your normal maps so that the normals are scaled appropriately to the detail and form of the surface, otherwise the lighting just looks off. You can see how off it looks in your screenshot, where you have moderately rough geometry appropriate to a rough-hewn stone block, but the shading is more appropriate for something as rough as a newly-cooled lava flow.
Tone down the specular a bit, unless the rock is intended to look wet. Specular is a scalpel, not a broadsword. Its use, just as with normal mapping, needs to be subtle and precise, and appropriate.
Also, you might want to vary your materials in the wall as well. From what I can see the wall is man-made, with mortal layers in between the rocks. However, the mortar layers have the exact same material as the blocks, so it doesn't look like a man-made wall at all. The mortar would be grayer, smoother, differently-shaded and much less specular. Even wet, mortar tends to have a dull, matte appearance due to the sand in the mix.
It could also result in removing other objects from the list, with no way of knowing it happened.
This line here is the killer. You can safely handle the case of the object under consideration being removed (as previous posters have demonstrated) but if other arbitrary objects in the list can be removed by the same deletion then you're stuck. You'll need to build a more sane object removal traversal. Mark an object for removal, traverse the list to remove it. If that object needs to remove other objects then have the object in turn mark them so that you can remove them in subsequent passes rather than in the same pass.