Forum adverts like this one are shown to any user who is not logged in. Join us by filling out a tiny 3 field form and you will get your own, free, dakka user account which gives a good range of benefits to you: No adverts like this in the forums anymore. Times and dates in your local timezone. Full tracking of what you have read so you can skip to your first unread post, easily see what has changed since you last logged in, and easily see what is new at a glance. Email notifications for threads you want to watch closely. Being a part of the oldest wargaming community on the net. If you are already a member then feel free to login now.

Lets just say you were going to play a Necromunda board game or a map-based campaign. A territory takes up one or more hexes - a drinking hole or friendly doc only fills one hex, while a settlement or collapsed dome might be much larger. The map would be made up of blocks of hexes as domes, with tunnels - some small, some large - running between them.

Given this, how wide do you think a Dome should be? Five hexes across (19 hexes)? Seven (37 hexes)? Nine (61 hexes)?

My reason for asking is that I'm going to be experimenting with file I/O in Java, and am planning on making a couple of programs that could generate a map of part of the Underhive.

Go for a variety of sizes, from all the fluff I've read I don't think they were very consistent.

Any of those options would work. Maybe do one big dome (Nine across) with a handful of smaller ones (Five maybe?).

I'd like to see what you come up with actually. I've wanted to run a map-based campaign for ages...

Tibbsy wrote:
Go for a variety of sizes, from all the fluff I've read I don't think they were very consistent.

Any of those options would work. Maybe do one big dome (Nine across) with a handful of smaller ones (Five maybe?).

The difficulty with making them inconsistent is getting them to mesh together nicely. With physical tiles you could just sort of mash them together until they fit, but that's not really an option for procedural generation. What might be the easiest way is to start off with a standard size and give each dome a chance to expand by one hex in all directions, shrinking all adjacent domes by one to fit. So you'd have some sevens, some nines and some fives.

I'd like to see what you come up with actually. I've wanted to run a map-based campaign for ages...

I've been thinking about that too:

For one campaign we ran with a physical board we used the Plantery Empires set (The guy running it was nice enough to let the campaign use his) which uses hexagonal tiles so a Hive could be a cluster of three or centred on one tile with each adjoining tile being included (For a total of 7 tiles)
Like Tibbsy said fluff-wise the size of individual hives can vary greatly so feel free to go nuts with it if you want to

Progress report!

I've got the core of the Map Output half of the program working. Below you can see an uninitialised 7x5 grid, as displayed by the program.

My next step should be to create a test input file and some more tile images, then give the program the ability to read that input file and swap out images accordingly.

Really interested in this - eager to see what you come up with!

More progress:
I've got the test input file and a couple more test hex icons done, and have successfully got the program to read the CSV file and render the appropriate tiles.

More progress:
I've swapped the black tiles out for transparent tiles and started using a black background. This allows me to show the domes as circles and not hexagons. Domes of different sizes will be positioned the same way as hexes, just on a larger scale.

This is the CSV file that currently produces this image - 0s are transparent hexes, 1s are floor hexes, 7s are the four 7-hex domes. I'll be adding another line or two for error-checking, to make sure the program doesn't try to render domes as hexes or vice versa.
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 0,1,1,1,1,0,0,0,0,1,1,1,1,0,0,0,0 0,1,1,1,1,1,0,0,0,1,1,1,1,1,0,0,0 0,1,1,1,1,1,1,0,0,1,1,1,1,1,1,0,0 0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0 0,0,1,1,1,1,1,1,0,0,1,1,1,1,1,1,0 0,0,0,1,1,1,1,1,0,0,0,1,1,1,1,1,0 0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,1,0 0,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,0 0,1,1,1,1,0,0,0,0,1,1,1,1,0,0,0,0 0,1,1,1,1,1,0,0,0,1,1,1,1,1,0,0,0 0,1,1,1,1,1,1,0,0,1,1,1,1,1,1,0,0 0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0 0,0,1,1,1,1,1,1,0,0,1,1,1,1,1,1,0 0,0,0,1,1,1,1,1,0,0,0,1,1,1,1,1,0 0,0,0,0,1,1,1,1,0,0,0,0,1,1,1,1,0 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 7,7 7,7

More progress:

I've written the core of the program that generates the map files. If you'd like to try it, I've uploaded both the generation and display programs. Just save both to the same folder, run Necromunda_Map_In first to create the map file, then Necromunda_Map_Out to display it.

There is only a small amount of error-checking at the moment, so if you manually modify the map file there's a good chance it won't work.

I'm really impressed with your progress so far. Do you have a roadmap in your mind of where you plan to take the program?

 Flamekebab wrote:
I'm really impressed with your progress so far. Do you have a roadmap in your mind of where you plan to take the program?

Hi, Flamekebab. I do have some ideas on where I'm headed with this, but it's possible I'll take it beyond that - possibly ending up with some sort of digital board game slash Necromunda campaign "overworld" support.

On the output side I want to make the map easier to use - probably by letting the user export to an image, adding mouseover text and enabling scrolling, for the obvious reason that usefully large icons take up a lot of screen space so you can only view a couple of domes at a time.

On the input side I want to procedurally generate various sorts of domes, and fill them with appropriate territories. At the moment I'm thinking the edge cases - "Uninhabitable" and Prosperous domes - will only have a ~5% chance of showing up, but raise or lower all adjacent territories by a tier. So Uninhabitable domes are more likely to be surrounded by Badlands or Outlaw Settlement domes, while Prosperous domes are more likely to be surrounded by Civilised or Civilised Settlement domes. The level of access would also vary depending on the quality of the dome - the best domes are more likely to have intact accessways that permit the transit of light vehicles and not just people, while the worst might be cut off from some of their neighbours entirely.

 AlexHolker wrote:
Hi, Flamekebab. I do have some ideas on where I'm headed with this, but it's possible I'll take it beyond that - possibly ending up with some sort of digital board game slash Necromunda campaign "overworld" support.

Lots of potential there

 AlexHolker wrote:
On the output side I want to make the map easier to use - probably by letting the user export to an image, adding mouseover text and enabling scrolling, for the obvious reason that usefully large icons take up a lot of screen space so you can only view a couple of domes at a time.

Sounds good. It might be worth figuring out a good way to create some output built to be printed too. I'm not sure how hard that is to do in Java - outputting a 300 DPI A4/US Letter PDF or similar would be handy. I say that because lots of campaigns seem to like printed handbooks with the specific rules and setting that are to be used. Having an easy way to add a map to that would be useful, I reckon.

 AlexHolker wrote:
On the input side I want to procedurally generate various sorts of domes, and fill them with appropriate territories. At the moment I'm thinking the edge cases - "Uninhabitable" and Prosperous domes - will only have a ~5% chance of showing up, but raise or lower all adjacent territories by a tier. So Uninhabitable domes are more likely to be surrounded by Badlands or Outlaw Settlement domes, while Prosperous domes are more likely to be surrounded by Civilised or Civilised Settlement domes. The level of access would also vary depending on the quality of the dome - the best domes are more likely to have intact accessways that permit the transit of light vehicles and not just people, while the worst might be cut off from some of their neighbours entirely.

That sounds fantastic!

Personally I'm thinking about what one could do further down the line in terms of porting it to my favourite game, Gorkamorka. I'm not entirely sure how the concept would translate (not that I couldn't give it some thought!) - I figured I'd think about that only if you were planning on continuing this project. If it was just a learning exercise for you then circumstances would of course be different.

 Flamekebab wrote:
Personally I'm thinking about what one could do further down the line in terms of porting it to my favourite game, Gorkamorka. I'm not entirely sure how the concept would translate (not that I couldn't give it some thought!) - I figured I'd think about that only if you were planning on continuing this project. If it was just a learning exercise for you then circumstances would of course be different.

The main problem I see with extending this project to cover Gorkamorka is that that territory is a more fleeting concept on Angelus. You have Mektown and you have your fort and its mine workings, but the game is mostly about random encounters - you head out into the desert, find some scrap, have a fight, dig up the scrap and leave.

I do want to extend this to cover the Ash Wastes, so there's certainly the opportunity to modify it for Gorkamorka once that happens, I just don't know how interesting it would be in a setting without journeyman convoys, neutral shanty towns and hive wall breaches.

 AlexHolker wrote:
The main problem I see with extending this project to cover Gorkamorka is that that territory is a more fleeting concept on Angelus. You have Mektown and you have your fort and its mine workings, but the game is mostly about random encounters - you head out into the desert, find some scrap, have a fight, dig up the scrap and leave.

You're definitely right in terms of the vanilla game. One of the things that is on the tUGS to do list is to create a good way to run a campaign. It'd detail how scenarios would fit together, a few tips on how to create a narrative thread, that sort of thing. Under those circumstances having territory maps seems pretty sensible.

 AlexHolker wrote:
I do want to extend this to cover the Ash Wastes, so there's certainly the opportunity to modify it for Gorkamorka once that happens, I just don't know how interesting it would be in a setting without journeyman convoys, neutral shanty towns and hive wall breaches.

Depending how you set it up it could be up to others to put the engine to use. I'm not sure what your plans are for generating the look of the map (tileable textures, procedurally generated, or whatever) but depending on how you go about it generating suitable art assets shouldn't be too hard. The contents and info for the map shouldn't be too hard for me and a few of the other tUGS guys to put together. Sometimes getting Ross to stop coming up with ideas is the hard bit!

Some examples - tar pits, fungus grove, caves, salt mine, critters, 'uge critters, cliffs, abandoned fort, 'ulk chunk, rad zone, Mutie turf, Dust Rat supply route, geysers

The graphics are generated from images for each hex tile - A '0' in the data file corresponds to Hex0.png, a '1' corresponds to Hex1.png, and so on. If you want to make your own tileset compatible with the program, you could use the template I just attached, rename it, and edit it to look how you want. I personally use GIMP but there are plenty of other programs that support transparency you could use.

A couple of things, though:
- At least for the foreseeable future, the hex textures are "baked in" to the executable and not retained as individual files. This means that until I work out a way to do it differently, the only way to add new tiles is to recompile the program.
- If you do this, please use the filenames Hex100.png to Hex199.png. That way, I don't have to worry about your tiles overwriting mine or vice versa.

Nifty! I hear you on the baked-in aspect. We can worry about more convenient ways to import assets later. I was more just wondering for further down the line. I may have a bash at creating some textures today. Have you created any so far (other than the basic textured tile) ? I'd like to at least attempt to match your art style

 Flamekebab wrote:
Have you created any so far (other than the basic textured tile) ? I'd like to at least attempt to match your art style

I've created a few but nothing you could call an "art style" yet, just a few basic shapes for the inter-dome accessways.

 AlexHolker wrote:
I've created a few but nothing you could call an "art style" yet, just a few basic shapes for the inter-dome accessways.

You do yourself a disservice! A clear style is emerging even if you don't see it. It could be just lines and text but instead you chose to texture them. It's one of the reasons I got excited about the project. Very stylish

I threw together a few possible tiles for Gorkamorka:

Desert, dunes, tar pits, and a canyon

I've got textures at ten times higher resolution too in order to future proof for printing requirements.

Looks like you're making a good start. Do you think you would you want to recolour the edges too? Maybe something like this:

What's the stipulation on the edges of the hexagons? Single colour, or?

 Flamekebab wrote:
What's the stipulation on the edges of the hexagons? Single colour, or?

Whatever you like. The only important thing is that the transparent parts remain transparent, or else they'll overlap.

I've added some support for other tilesets *cough*Gorkamorka*cough* and started playing around with it as a way that people who play Dreadball Xtreme could make their own boards. I've also added some basic support for the varying access levels depending on dome quality, and plan to do the same for light levels.

 AlexHolker wrote:
I've added some support for other tilesets *cough*Gorkamorka*cough*[

Thanks!

 AlexHolker wrote:
I've also added some basic support for the varying access levels depending on dome quality, and plan to do the same for light levels.

Noice. I'm looking forward to seeing how it turns out. I should probably create some more tiles too.

While I haven't ported it into the main program yet, I have now worked out how to get the scrolling working. Once I make up a set of placeholder icons for a Player Character and add in the new code, I'll upload the new version, with the ability to travel around the Underhive.

While I still need to do some work on it to support larger displays*, the program now works, complete with movement.

To use the program:
Put both the CSV file and the JAR file in the same folder.
Run the JAR file.

Click on the little person to activate the controls.
Use the numpad to move, as follows:
.7 9 \ / 4--X--6 / \ .1 3

*Please do not try to move really quickly, as the problem seems to occur if one keypress interrupts the process being done for the previous keypress.

More update:

I've improved the error-checking, so the next version will be able to accept any valid map file without the need to recompile. Previous versions had the map size hard-coded, while the new version uses the values in the header of the map file.

I've also added the initial support for border maps consisting of both the Underhive and the Ash Wastes. Now I have to add the two types of access - proper access tunnels controlled by the Guilders, and breaches in the hive wall that might be uncontrolled or turned into toll gates by gangs.

Has anyone tried using the program I uploaded last time?

It launched for me but I can't move. As far as I know MacBook Pros don't have numpads (even as FN key combos) so those controls are a no-go for me :(

 Flamekebab wrote:
It launched for me but I can't move. As far as I know MacBook Pros don't have numpads (even as FN key combos) so those controls are a no-go for me :(

I did not know that. What would be more suitable? Something like this?

.W E \ / A--X--D / \ .Z X

I hadn't given it any thought before this came up either, to be honest. That key combo should work just fine, although I'm not sure how it would be affected by other keyboard layouts like QWERTZ and AZERTY. I'm on a QWERTY keyboard though so worry ye not, but it just crossed my mind

It would be easy to modify that to support QWERTZ - all I need to do is permit three keys for SW instead of two. The French will have to make do with the numpad.