Where to next with worldmap and new dungeon locations

No apologies for the double post, but I feel that I have cracked the problem at the eleventh hour (or the twelfth, it's 12am here).
I woke up today with a feeling like I shouldn't have been rooting around in script.cpp after all, so I rolled back those changes, and focused on making the world terrains resemble level terrains.
I had a patch where it wasn't compiling beyond database.cpp, but I figured out to add "wterra.h" to "dataset.cpp" and I was away and racing. Suddenly it was a clear path to compiling, but then opening the application and starting a new game resulted in a crash. I blocked out changes to wterras.cpp and wterras.h and I was able to load the world map! But then entering a dungeon suddenly caused a crash! Loaded up again and tried to see what I could do using the command system while in the world map... not much it turns out... until I tried to save the game. Another seg fault! But a healthy clue. Two problems, one of not being able to save, and the earlier problem of the game picking up the BitmapPos of the owterrain, but seemingly unwilling to place it on the worldmap without crashing...
Hours of searching and messing around, until something subtle catches my eye: Every level terrain has a function which initializes some of the data. I decided to chuck it into wterra.cpp, just for the gwterrains and owterrains, and for completeness. What do you know? To my complete surprise it stops crashing when I save, enter a new area, leave it again, and load. What's more, the BitmapPos is being picked up from either owterra.dat or gwterra.dat!
Happy day.

So, reasons this is getting us where we want to go:
Contributers will want to create their own dungeons. Unfortunately, a world map location is not always where the start point of a dungeon is located. Think of the underwater tunnel exit.
Contributers will want to create their own graphics for their new world map locations; and so on. Therefore we need to represent the owterrains in data files. Plus I want to add climate data to each gwterrain, and I feel the best way to test it out would be using a data file, where I don't have to compile each time.

So this step is done: https://github.com/Attnam/ivan/pull/125

Having done this necessary ground work (haha!), only a few things remain:
1. Pulling biome data like longitude, temperature and elevation into each ground-world terrain in the gwterra datafile - this would enable parameters to be varied to create worlds with a different look and feel
2. Causing the worldmap generator to populate the map with ground terrains in a new way
3. Re-working worldmap.cpp in a way that ensures it doesn't explode when adding more locations
4. Making the empty slots for new worldmap locations

How would people feel about having a world map that wraps on itself in the horizontal direction?

The edges of the world map would line up, and the player could circumnavigate the world. Or at least access landmasses that were on the other side of the map. It would help make it easier to reach far away places.

I wouldn't suggest it if id didn't have a way of doing this (see attached)

So the Wise would know the world to be a square crêpe wrapped around Valpurus's body? Might be popular in France.
When it comes to imitating a sphere with a flat map, I tend to favour using the fundamental polygon:
Though that needs 90-degree shifts in player perspective, and some fov trickery.

World wrapping unto itself? That souds great!

It would be awsome to then add some towns (Mondedr and such) rather far apart, as to allow and promote actual exploration of the overworld.

This reference on Poisson disk sampling might be a good way of planting locations with a minimum/maximum distance.


This looks cool Is it something you have implemented in a game already?

I've implemented an @-on-a-map demo with spherical geometry (along with a torus, a projective plane, a hall of mirrors - anything whose fundamental polygon is a square), but none of those have made it into an actual game yet.
The case of the sphere is quite weird because if the window is much larger than the map, it makes a square tiling like a torus map - but each "tile" is actually made up of four copies of the world, each with a different rotation. Copies of the player avatar dance around the centre of each tile.

Kinda like this:

That's interesting. Do the attached images show how the character is reflected in the mirrors?


I have been plugging away today and I have used python to do some poisson disc sampling to create model for IVAN to place worldmap locations randomly but evenly spaced out. The first attached image shows the sampled field (red dots) overlayed on the world map. The second attached image shows where the red dots coincide with land, which become yellow dots. The yellow dots represent possible valid locations to put a dungeon entry point.

Yes and no - the animations show the rotated copies of the character (since the sphere is built from rotations).
The Poisson disc sampling looks good. I wonder how it would affect the average distance from UT4 to Attnam?

I was wondering when that question would come up. I'm pretty sure Attnam is placed first, then the game searches for the shoreline with an open area of water nearby and then puts an island there with under water tunnels in between. I have historically been critical of this method, but looking harder at the world map generator has caused me to be humbled by the wisdom of the original devs. It is a simple and practical way of making sure that the core locations show up.

There's a list of candidate locations (yellow dots). I imagine what will happen is that we retain the old placement method for the original locations, with Attnam as one of the yellow dots. If the original locations (say UT exit) are in the same place as the candidates, then those candidate locations are eliminated from the list.
We would need to re-order the list with a nearest neighbor routine with Attnam at the centre, so subsequent locations are situated in a cluster about Attnam town.

This weekend I was busy porting the poisson disk sampling algorithm from a python model to c++. I learnt that the std::vector type is a good proxy for a python list, because you can use push_back() and pop_back() to add or remove things from the vector in much the same way as you would use append() in python, and much more besides. I was also reminded that the ^ operator is the logical XOR in c++, and not raising to the power (stupid matlabthink).

We're getting closer to making it possible to contribute dungeons, just check out the attached file! I committed the code for posterity, but it is quite scrappy so I will tidy it up as I come up with a way to integrate the sampler with actual user-defined dungeons (the easy part).

This is exciting!

Indeed it is!

I have been doing more; this weekend I built some machinery for collecting data into vectors of structs (not sure if this is efficient). I transplanted some code normally used for the prototype system, and it rather unexpectedly worked "right out of the box". Not exactly "flow", but a pleasing experience nonetheless.
I very nearly have something ready to deploy to the main line of development. I think it will be another weekend before I can do this. My current problem is to find the best way of filling the available spaces with locations according to a combination of terrain type, proximity to Attnam and what continent. I figure I will find a way of filling up all the available spaces on the main Attnam continent first. Then once it is full, then move to the next nearest available spaces, even if they are on another continent. It's a real pain because you can get underflow and overflow if the number of terrain types differ greatly between available types and the types to be placed on the world map. I may just have to be expedient and make some stern simplifications. The next adventure is how to use c++'s Erase-remove idiom to remove those vector elements of locations that have already been placed.

After all this I'll need to make a how-to guide for adding new dungeons without compiling.

I am toying with the idea of adding a new swamp terrain type called "morass". Does anyone want to draw a picture of it?
For that matter, would anyone object to new drawings of the world terrains? There's no deadline... Azba? blob?

Well, after some work, here it is: https://github.com/Attnam/ivan/pull/130

I finally figured out how to populate the worldmap in the right way. You start with the main continent and work through the available locations you sampled. Then you join up the terrain type of the available location with the dungeon you need to place, by iterating through the entire list of dungeons. Then you eliminate those locations which are occupied, and those dungeons which have been placed. Then move on to the next nearest continent until you run out of continents.

Below is a screenie showing the diversity of terrains on which you can place the locations (they all look like New Attnam in this example).

Ok, so what does this all mean?

This means in IVAN 0.50.6, you will be able to add your own dungeons on the worldmap, using the script files alone!!!

Love it! Great work!

I know right? I'm working on a guide on the wiki right now

That's awesome. Good work!

Awsome! So awsome!

So, will the new dungeons be incorporated into official releases, or will they work as a plug-in? As in, we post our dungeons here and everyone can pick what they like and add it into their game, or we post and playtest, then put it into new release for everyone?

The intention is to incorporate the dungeons into official releases. This will attract players, and perhaps some developers. This means you can create full-length dungeons and be confident that they will continue to appear in continuing development.

I would say, the most direct/guru way would be to fork the git repository and you can work on your own dungeon in your own fork, commit, push changes to your remote, and then pull request the changes into attnam/master. However, as I write this I can see that with the status quo there might be long times between releases. I feel that there will be more frequent releases as dungeons reach the cut-and-polish stage.

You will want players to play test your dungeons as soon as you make changes. The players don't use github, that much is obvious. But I would recommend you use github as the vehicle of ultimate authorship, because it will enable you to show the work was yours, and help you track changes etc. It also means I can see it if you get stuck, or if there is a bug. When you feel the code is ready you can make a pull request, I can merge this into the main line and do a release. In this way it will be released to the general public.

For all github's technical usefulness, it will not get you the rapid feedback you require. The forum here is a good development nucleus with plenty of the game's legendary power players who drop in on us from time to time. When I did CLIVAN I found lots of people coming out of the woodwork to push my dungeons to their limits and the feedback was awesome! They smashed through everything and found all the loopholes, which was embarrassing, but humbling that people took the time out to review my work.

I expect if you get a thread going on the forum here you will get some eager followers. As you develop, attach your dungeon data files here and explain where they go so people can test it out. If you don't want to use git (the learning curve can seem steep, I'll admit) and you start out in this way, then that is fine too. You can even jump into github right at the end and push all the changes in one go. I know you already have a fork though...
The first part will be to flesh the thing out using your imagination, and writing the dungeon script (or copy-pasting a lot and changing things). It will be a lot of solitary hours, keep a notebook handy, graph paper is good too.

I've been toying around a bit with making Bazaria (tourist dialogue) into a new quest hub for a branch I've had in mind. Is there a way to set ambient lightning via script such as the core settlements have? I did notice IsOnGround prevents earthquakes, but it does nothing about light. Currently the place is dark as a cave.

Try

AutoReveal = true;

It's used in the New Attnam script file as well. Might be missing from the wiki page...

Awesome that you are considering doing this, by the way

AutoReveal doesn't affect lightning, so only areas with lanterns and such are visible. Unlit tiles just get a slightly bluish black of "you know it's dark in here".

The passive lighting is apparently set inside the source code rather than by script.
I'd argue that needs to be changed to reading from say, a couple of lines in the dungeon's script file rather than set manually otherwise we need to update the source every time someone makes a map.

Relevant sections are in level.cpp:

Night time lighting is on line 276

if((Index == 0 && GetDungeon()->GetIndex() == NEW_ATTNAM)
     || (Index == 0 && GetDungeon()->GetIndex() == ATTNAM))
    NightAmbientLuminance = MakeRGB24(95, 95, 95);

Daytime is checked with checkSunLight() line 2337 onward:

void level::CheckSunLight()
{
  if(Index == 0 && GetDungeon()->GetIndex() == NEW_ATTNAM)
  {
    double Cos = cos(FPI * (game::GetTick() % 48000) / 24000.);

    if(Cos > 0.01)
    {
      int E = int(100 + Cos * 30);
      SunLightEmitation = MakeRGB24(E, E, E);
      AmbientLuminance = MakeRGB24(E - 6, E - 6, E - 6);
    }
    else
    {
      SunLightEmitation = 0;
      AmbientLuminance = NightAmbientLuminance;
    }
  }
  else if(Index == 0 && GetDungeon()->GetIndex() == ATTNAM)
  {
    double Cos = cos(FPI * (game::GetTick() % 48000) / 24000.);

    if(Cos > 0.41)
    {
      int E = int(100 + (Cos - 0.40) * 40);
      SunLightEmitation = MakeRGB24(E, E, E);
      AmbientLuminance = MakeRGB24(E - 8, E - 8, E - 8);
    }
    else
    {
      SunLightEmitation = 0;
      AmbientLuminance = NightAmbientLuminance;
    }
  }
  else
    return;

  SunLightDirection = game::GetSunLightDirectionVector();
  ChangeSunLight();
}

I'm well aware that changing this to read the appropriate sunlight colours from each individual dungeon script file is going to be a huge pain in the ass but it will need to be done sooner or later.