Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Angle]

I'm trying to make a simple text adventure game in C++ using the codeblocks IDE with the g++ compiler. I've been getting a syntax error located on line 1 of gamefiles.h, which I think is connected to me misusing the IDE and multiple files or something.

Spoiler: My Project (click to show/hide)

Code: (main.cpp) [Select]

#include <iostream>


int main()
{
    using namespace std;
    cout << "Welcome to Blargia!" << endl;
    return 0;
}



Code: (dialogue.cpp) [Select]

#include "gamefiles.h"
#include <stdlib.h>

using namespace std;
void processCommand(string command)
{
    switch(command[0])
    {
        case 'b':
        case 'B':
            //begin
            startGame();
            break;
        case 'e':
        case 'E':
            //exit
            exit(0);
            break;
        case 'p':
        case 'P':
            //play
            startGame();
            break;
        case 's':
        case 'S':
            //start
            startGame();
            break;
    }
}


Code: (gamefiles.cpp) [Select]



void startGame()
{

return;

}



Code: (gamefile.h) [Select]

#ifndef GAMEFILES_H
#define GAMEFILES_H

void startGame();

#endif



can anyone help?

edit- nevermind, I figured it out. I had been messing with some file info earlier trying to solve a problem and changed something important. my mistake.

[alway]

This question is a bit more complex than most in this thread, and is somewhere between programming and mathematics... I'm hoping someone knows the answer.

I'm thinking of creating a minecraft-esque game, but with a larger ability to scale up. It would break up the massive number of objects into chunks, with there being a hierarchy of larger and larger chunks, all told, over half a dozen layers deep. Naturally, storing the 2^65 individual blocks which would make up a planet is entirely impossible, as is generating all blocks on the fly whenever any generalized data about block types and such within a large chunk are needed. While data about player built/modified blocks would be able to be stored, information about the 'natural' blocks created by a terrain generation algorithm could be neither stored nor calculated.

I think what I need is the ability to quickly calculate what is basically an integral on a terrain generation algorithm whose parameters are the x, y, and z coordinates of the blocks. This integral would then be able to tell me things like 'according to the part of terrain generation responsible for placing x blocks, there are a total of y instances of block x within this 3 dimensional volume of blocks.' This would need to be able to scale to any given volume of space, so as to accommodate chunks ranging in size from a few cubic meters to over one hundred cubic kilometers. Which leads me to my question:

Does anyone know what sort of terrain generation algorithms I should be looking at to allow for such calculations to be as simple as possible while still generating interesting terrain?

[Max White]

With any luck Virex will show up and help you out. It sounds like you need a structure similar to a three dimensional quad tree, and I only know the name of that structure thanks to our friend Virex, so he might be able to help you make one. Although IIRC minecraft works using an array broken into chunks, rather then the quadtree, so if you are making something similar then we know it is possible with a simple three dimensional array.

[Nadaka]

You CAN dynamically generate terrain like that quickly enough if you use the right algorithm. The process to determine a specific altitude using a diamond square algorithm is at about O(n) where n is the power of the width of the world (a world 2^n+1 tiles in about n time). Generating continuous areas is more efficient because they mostly use the same parent sequence of tiles.

A traditional use of diamond square creates the whole world at once, but if you know what you are doing, you can render a world in arbitrary detail in pieces arbitrarily small with relatively little additional cost. I was rewriting a diamond square algorithm to be exactly this, before I got side tracked with that project. I'll see if I can dust it off and finish it for you, at least see about providing a starting point. But it will probably be at least a week before I can make time for that.

To get exactly the kind of terrain you are looking for, especially if you want things like rivers or caverns will probably require modifying the algorithm.

Edit: I may have misremembered the exact complexity... It could have had a Big O in  a low polynomial time but an expected cost at or close to n.

[alway]

Na, that's not what I need. I'm looking for something capable of capturing the aggregate data of the sub-nodes without generating said sub-nodes. It's a similar concept to finding the area under a curve using the equation alone, rather than adding up the area of every individual slice described by the equation between the values.

Some form of integral should do the trick, I'm just not entirely sure how to create a decent terrain generation algorithm whose integrals can be easily found. Diamond-square won't work in this case, as the number of cubes in the largest usable chunks is around 10^16, or something on the order of 10 petabytes of storage if each one is 1 byte. In this case, anything much over O(1) won't work; both in regards to speed and memory use. Hence the reason for needing to engineer a terrain generation system around this issue.

An example of how this would be used: Imagine you were viewing a given planet; you look down at the surface and select one of the planet's 400 or so sub-regions. This then pulls up data about the materials, ores, and other various things within this vast area, hundreds of cubic kilometers in size. However, if you were to do the equivalent of an integral calculation on the algorithms used to generate the terrain, it would have a storage and run time of O(1), with any size of chunk getting the results in the same amount of time.

[Siquo]

Na, that's not what I need. I'm looking for something capable of capturing the aggregate data of the sub-nodes without generating said sub-nodes. It's a similar concept to finding the area under a curve using the equation alone, rather than adding up the area of every individual slice described by the equation between the values.

I went there, and ran out of memory pretty quickly

If you have an equation that describes your terrain, you can do this, but it won't work easily for modified terrain. What you can try is use something like perlin noise, where each "level" increases the detail. I tried to do that dynamically, before I abandoned the whole idea of voxels:
http://nam.siquo.net/2010/12/29/small-update/

[Virex]

What you're looking for is a form of Lazy evaluation applied to an Octree. Each level of the tree could be generated on the fly by taking the parent node and applying for example the diamond square algorithm to it, or any other subdivision algorithm that can be applied an infinite number of times. This way you can generate arbitrary detail without having to generate all the information at once. To generate m nodes at level n, in a naive implementation one would need to generate m nodes and their parents, meaning the algorithm can run in O(m log n) times the time complexity of the subdivision algorithm itself (and luckely, in the given example, log n is only 64. If you'd use the fact that you can often generate most of the desired nodes from the same parent, you could drop it to a value quite close to O(m) times the complexity of your algorithm.

[MaximumZero]

Even though I have no idea what was just said in any of the last dozen or so posts, I am so glad I made this thread.

[Nadaka]

Na, that's not what I need. I'm looking for something capable of capturing the aggregate data of the sub-nodes without generating said sub-nodes. It's a similar concept to finding the area under a curve using the equation alone, rather than adding up the area of every individual slice described by the equation between the values.

Some form of integral should do the trick, I'm just not entirely sure how to create a decent terrain generation algorithm whose integrals can be easily found. Diamond-square won't work in this case, as the number of cubes in the largest usable chunks is around 10^16, or something on the order of 10 petabytes of storage if each one is 1 byte. In this case, anything much over O(1) won't work; both in regards to speed and memory use. Hence the reason for needing to engineer a terrain generation system around this issue.

An example of how this would be used: Imagine you were viewing a given planet; you look down at the surface and select one of the planet's 400 or so sub-regions. This then pulls up data about the materials, ores, and other various things within this vast area, hundreds of cubic kilometers in size. However, if you were to do the equivalent of an integral calculation on the algorithms used to generate the terrain, it would have a storage and run time of O(1), with any size of chunk getting the results in the same amount of time.

you misunderstand my statement.

The n I am referring to is not 10^16. If you are mapping an area of 2^over9000+1 by 2^over9000+1, you can find the height of any point in about over9000 units of time (if I am remembering the complexity correctly). you also do not need to store the entire map, only the points you want to reference and a temporary list of parent points needed to generate those points. And because continuous areas of points use mostly same parent points, the temporary memory usage even for a fairly large continuous segment is relatively small.

Quad-trees and Oct-trees are a method of storing information with subdivision going into increased detail. Diamond Square is an algorithm for generating data using subdivision going into increased detail. They can work very well together with only minimal adjustment (applied to a quad tree, you would probably actually use a tri-tree where the parent nodes height value "trickles down" as one of the corners).

Edit: had a brain error caused by how I was creating the seed values for any given tile in my own algorithm, you would still need a full quad tree.

[alway]

Ah, I think I get it now! Thanks everyone.

[Starver]

Just looked up the concept of the DSA, and I find it interesting, because for a while I've been using a triangular method[1][2] for various unpublished projects I've played around with.  I've made it a bit more complicated, with the likes of the tri-corner height values (derived from the layer above, or the original seed when at the top layer) being accompanied by both variance[4] and sub-seeding[5] values, and thus deriving equivalents for each of the mid-points used to create each the subdivision triangle (all three for the central quarter-area triangle, each possible pair and their adjacent corner for the three point-corners).  Continuing iteratively for every section for which the increasingly precise LOD is not yet satisfied (i.e. still does not have enough resolution) while still wholly or partly within the desired viewport or needed to work out other localised information.

Obviously, in the triangular version (with only mildly more compex maths than one that works with orthagonals), the central child triangle could not be of the same orientation as the parent one, being either 180 degrees out or plus or minus 60 rotated, so I had long ago decided that the corner-children should also rotated.  The original base of the parent triangle is a guide as to which order the sub-triangles get dealt with, on top of which I add a prescribed rotation sequence to them all.  This closely mirrors the Diamond-Square's 45 degree rotation schema, although as I'd never considered doing otherwise I'd never actually observed the polygonal (square for DS, presumably triangular but perhaps hexagonal for my scheme) artefacts the DS's rotation is there to avoid.

The usual Wiki mentions that there was an analysis that described DSA as being flawed, but appears to have no details.  Anyone know what this entailed?  It might apply to my triangular method, although I've noticed no real issues with it.



[1] Useful because I can drill down a sphere-friendly heightmap without obvious polar effects simply by starting with a dodecahedral division of the original, as well as use a single- and double-axis wrap-around Euclidean surface.

[2] A couple of decades ago I was using a far more inefficient and easily irrepeatable method.  Randomly (or pseudo-randomly) assigning utterly random values to each pixel (or voxel), then for a given (arbitrary, and thus unjustifiable) number of iterations progressively making a new copy of each pixel(/voxel) a weighted average of it and its neighbours (immediate, or even unto to a given distance) then normalising the values back to maintain the desired max/min.  For a colour-map, this gave a Plasma-like output (especially interesting if R, G and B components are dealt with independently, giving an overlay of three 'gels') but is very processor-intensive.

(Just had a browse on one of my old backup disks, that is within reach, and I've actually got some images I recorded from that very experiment!)

Spoiler: Images (click to show/hide)

A screenshot (converted from bitmap to the now-available PNG format, just for you) that I'd taken of the App itself.  (Rough around the edges.  Now, where did I put my Delphi installation disks, I could improve on that interface, these days.)


A GIF export I'd made.  Notice how the 256 colour limit makes it step in interesting ways that the 24bit version doesn't.

Note that the above result is a result of a 100-iteration 'averaging and normalising' process.  The more iterations, the bigger the blobs are (with wrap-around across both axial boundaries, in the above example).  Also note the near-complete lack of 'square' artefacts.  I'm pretty sure that I made the above using Pythagorean weighting when averaging the eight neighbours.  That way it doesn't need anything like the Square-Diamond rotational fudge.

((Bear in mind that the above doesn't exactly relate to landscape generation... but it could do!  e.g. heightmap related to one colour component, flora concentration related to another and moisture levels to the third, so that #FFFFFF might be a high, swampy forest, #000000 a barren desert slump, #FF8000 a dry-grass hilltop, #00FF80 a normally damp low-level forest, #8000FF is a mid-level marsh.  Look, that's just examples, it's the underlying values that are important. Anyway, it's far less efficient than the methods being described, just thought it worth bringing up as what can be done, but why to not do it this way!))

[3] <Original text for this footnote now edited out>

[4] This way, there's a chance of plain-like, mountain-like and even (with a nod to Slartibartfast) Fjord-like areas, with a localised intensity and consistency.  Without this, I've found it's either very badly developed (e.g. long, thin plains that don't look right) or globally so self-similar that it doesn't look credible.

[5] Sometimes I've just summed or XOR together all the relevant existing values to create the sub-seed, but if instead of that I make sure that the first values I derive from the master-seed are the four sub-seeds that I will need, I can then mess about with the later PRNG outputs that follow it at that level[6] without disturbing the sub-seed chain that will apply to all lower levels.

[6] e.g. if I derive from the seeded PRNG the four sub-seeds, then use the next four PRNG outputs to dictate the local height variance and thus the mid-point deviations, then I can also at a later time take another four PRNG outputs to dictate the local variances of some sort of resource availability without it affecting the already observed PRNG chain (similarly appended with it's own demand for resource variances) at all levels lower, meaning I can layer additional demands upon the system and yet maintain the same world-state.  Not that I'm doing this (yet, at least), but it would mean that I could generate (or allow a client to generate) a given landscape for all end users and then if I later on want to add something esoteric like Spookiness as an overlay to the environment, the upgraded environment would not suddenly have completely different terrain (now possibly inconsistent, in game-space) and yet would now have a new (probably hidden) variable over each square mile/furlong/foot/inch/whatever of the ground with which I could enhance the gameplay.  As long as I didn't try to insert new demands (like a new Sleaziness measurement) within the generating list, only at the end, I also wouldn't end up with the new Spookiness (or whatever) intensities suddenly shifting and producing different environmental effects.  IYSWIM.

[edit: some footnote numbers became misaligned by bad editing... hopefully corrected]

[alway]

The usual Wiki mentions that there was an analysis that described DSA as being flawed, but appears to have no details.  Anyone know what this entailed?  It might apply to my triangular method, although I've noticed no real issues with it.

Miller's complaints with the diamond-square algorithm stem from his attempt to force the algorithm into creating a mountain, that is, with a peak, by artificially increasing the height of the grid center-point. He lets all other points in the array generate randomly. If Miller had simply generated the center-point randomly, then even he would've had to admit that the algorithm works pretty decently as a terrain generator. The Diamond-Square algorithm can be used to force a mountain with a peak, by "seeding" the array with values. More than just the center point of the array must be seeded to achieve acceptable results. He complains of some inherent creasing problems as well. But you judge for yourself. The algorithm is originally described by Fournier, Fussell, and Carpenter 4.

From: http://www.gameprogrammer.com/fractal.html

By the looks of that page, it seems to be a complaint about the relative lack of control over the end result; the inability to tell it make a mountain here and a valley here without manually modifying several layers deep.

[Starver]

Not something I need to worry about then.  There's only ever been one situation where I wanted actual features in an actual location (the thing I personally call "Outcrop") and the way I dealt with that is find an actual feature (always produced from the default seed I was using for that map) that was what I wanted, but not necessarily in the right place, and used a transformation routine applied directly to the whole render to move the whole map around so it was where I wanted it after all, and in the right orientation.

BTW, cheers for at least reading through to the top of the fetenete section.  I wrote far, far too much!  Which is so unlike me, I'm sure you'll agree!!!

[Angle]

alright, I got another problem. There's this variable, see? it should get changed. it's not changing. I'm not getting any errors or warnings or anything. It just won't change, and I don't know why.

heres my project.

Spoiler (click to show/hide)

Code: (main.cpp) [Select]


#include <iostream>
#include "Ship.h"

using namespace std;

int main()
{
    cout << "Welcome to Spatial!" << endl;
    Ship player("Player", 20, 4, 4, 0, 4);
    Ship enemy("Enemy", 5);
    player.attack(enemy);
    enemy.attack(player);
    cout << enemy.getHealth() << endl;
    cout << player.getHealth() << endl;
    return 0;
}



Code: (Attack.cpp) [Select]


#include "Attack.h"

Attack::Attack(int damage, int accuracy)
{
     Attack::damage = damage;
     Attack::accuracy = accuracy;
 };



Code: (Attack.h) [Select]


#ifndef ATTACK_H
#define ATTACK_H

using namespace std;
class Attack
{

 private:

 int damage;
 int accuracy;

 public:

 Attack(int damage = 0, int accuracy = 0);
 int getAccuracy() {return accuracy;}
 int getDamage() { return damage;}
};

#endif



Code: (Ship.cpp) [Select]


#include "Ship.h"
#include <iostream>

using namespace std;

 Ship::Ship(string name, int hitPoints, int weapons, int damage, int armor, int targeting, int manuevering)
  {
     Ship::name = name;
     Ship::hitPoints = hitPoints;
     Ship::weapons = weapons;
     Ship::damage = damage;
     Ship::armor = armor;
     Ship::targeting = targeting;
     Ship::manuevering = manuevering;
 }


 void Ship::attack(Ship target)
  {
      for (int i = 0; i < weapons; i++)
      {
          target.defend(new Attack(damage, targeting));
      }
  }

  void Ship::defend(Attack* incoming)
  {
      if (manuevering < incoming->getAccuracy() && incoming->getDamage() > armor)
      {
          this->setHealth(0); //Ship::hitPoints - (incoming->getDamage() - Ship::armor);
          cout << name << " was hit for " << (incoming->getDamage() - Ship::armor) << " damage!" << endl;
      }

      else
      cout << name << " dodged!" << endl;

      delete incoming;
      return;
  }


Code: (Ship.h) [Select]


#ifndef SHIP_H
#define SHIP_H

#include <string>
#include "Attack.h"

using namespace std;
class Ship
{

  private:

  string name;
  int weapons;
  int armor;
  int damage;
  int targeting;
  int manuevering;
  int hitPoints;

  public:

  Ship(string name = "Ship", int hitPoints = 10, int weapons = 1, int damage = 1, int armor = 0, int targeting = 1, int manuevering = 1);
  void attack(Ship target);
  void defend(Attack* incoming);
  int getHealth() {return hitPoints;}
  void setHealth(int health) {hitPoints = health;}

};

#endif


the problem variable is enemy.hitPoints; It should be set to 0, but its staying at five. I'm thinking that the function that should be modifying it, Ship.attack, is not being allowed to or something.

edit - nevermind, I found it, I forgot to make the attack function use a reference. derp.

Here, since I found the solution to my problem, how about just a general critique of my coding style? Did i do things right, what should I do differently, etc.

[Siquo]

Looks okay. You can do constructors like this, "they" say it's just a bit faster:

Code: [Select]

Attack::Attack(int d, int a) : damage(d), accuracy(a) {

}