Particle-based hex map & editor (PHex)

Hi everyone, I'm making a large-but-casual hex-based strategy game, and after sinking my teeth into making the map editor, I've decided to place said editor on the asset store once complete. Possibly with a level of the game for demonstration as a full package. This thread will serve as a mighty vessel for updates on both the game itself and the arguably cooler map editor. I've decided to call it PHex as a working title (PBHM&E is not a great acronym), and it's kind of grown on me so we'll see if I get the chance to hold onto that one.

Here's a youtube video of the editor in action as it stands now (painting terrain data onto drawn map art)

it shows camera control, painting data (currently representing "terrain type" enum values with dual mouse button painting), displaying that painted "terrain" data, and paint-bucket-filling hexes and also lack of undo

Memory & scale​

The hex visualizations are particle based and the data is stored as a long[] so there can be a lot of them (100000 in the demo). The actual data of the hex, here representing 7 values in a mixture of enums and integers, is stored in a scriptable object, and only converted to useful values through a struct when required.

The editor runs in play-mode. I was considering moving it to unity's editor but I actually prefer having it run fully functional in application play mode for a couple reasons: So I can see how it looks in the style of the game (which is the main reason I left the graphic effects in the youtube video, complimented slightly by laziness); So I can include it for players to use in level editors; and so I can make edits mid-play in maximized view without editor shenanigans. And only the tiniest bit supported by the fact that I don't like writing editor code.

UI​

The toggles in the editor UI are generated on start according to how the enums and color palettes are set up, so UI management isn't necessary if enums or colors change. They're sorta kinda ugly, but they're functional. I'll make them pretty in the polish phase.

Mystery UI elements: That currently recycle-themed button resets the map, so all the hexes become "none" again in terrain. That text field allows you to type a Key for the database (basically a map name), and the lock icon next to it lets you use that key to lock the database.

Database​

The hex database is just a scripto with a long[] (soon to be ulong[] I think) and some fancy utility features for accessing it, like automatically converting it to useable values in and out, and set methods for those individual values, and locking and unlocking.

Locking a database is optional, and it is NOT a security feature. It is not intended to protect from terrain-stealing world-thieves. It is intended to protect you and mostly me from accidentally placing a river of lava in Candyland when it was meant for Mordor, because the data is persistent and dynamic (you may have swapped databases at some point and forgotten, and knowing what you're editing is handy). As such you can technically break the lock or work around it at any time, anywhere, universally, it just takes deliberate action to do so.

Generation​

The map base is generated automatically given a number of rows, a number of columns, and the size of the hex (point-to-point). The rest (height (edge-to-edge), edge size, column offset, and row offset) are then calculated, the database filled, and the map is born. The particle visualization is optional, and can fade out at the edges. If the assigned database is already initialized, it will load that instead of initializing a new one.

A quad with a tiled hex texture is also automatically scaled and its texture tiled to align with the particles, so a hex map overlay will be available even if the particles are not active.

The utility is at its core a data structure of layers of information of hex positions, combined with utilities to get those positions and visualize / retrieve the data. It does not alter any actual terrain mesh (maybe one day, if it's a popular demand). It does not even have to store any "terrain" value, you can paint any data you want, I am simply using it to paint self-defined "Terrain" values to suit a purpose in my game. I'm thinking about at some point adding the ability to overlay the hexes onto an existing 3D mesh including a terrain mesh, in addition to explicitly painting height.

Visualization​

Outside of edit mode, my plans are to have the hexes show only player and enemy ownership (the loyalty data of a hex), so it won't visualize the terrain unless the player commands it to, maybe by holding a modifier key or something simple (I'd like the game to be mostly played with the mouse). Landmark will be a 3D object loaded onto the hex, and claim will affect the size of the visualized hex particle. But that's game-specific, really. The particles generated don't even have to be hex-textured. You can have an array of dots with a half-step offset. And when you visualize them is up to you.

In edit mode, right now there's just terrain painting, but I plan on having a toggle group for the layer to paint on, wherein the palette currently showing the terrain will change to whatever that is; resource type, ownership, claim, etc.

What I am hoping to accomplish is a generic scripto or prefab, or other inspector-based option for you to edit A) what you want each layer to represent and be called, and B) How you want each layer to be visualized. Right now this is sort of hard coded, but as it becomes more of a salable asset I'm going to want it to be user friendly and quick.​

Utility / Calculation​

There are 3 main classes at work here not counting the UI: the database storing the raw hex data for a map, the editor sending commands to set hexes and refresh visuals, and the hex manager. The manager is the one that builds the map, refreshes the particles, calculates clusters, and tracks the mouse's positional index.
The data transferred between the classes is almost exclusively int[] values as indices, with a command of what to do with those hex indices. The exception is the database, there the enums are sent to store that data.

the manager has a number of static utilities like quantizing a world vector to hex centers, getting the hex index closest to a vector3, building an int[] index cluster around a central index, and changing visualization state (show terrain / show loyalty, etc)

I'll add a gameplay section later, once the editor is a little more ironed in or out and I get a more decent fantasy map to use. Also, once I add gameplay.

Edit: Forgot to add utilization.
It's prefab based. You'd drop the PHex prefab to generate and use a map, assigning a database to it in the inspector. Accessing the instance of hex manager will let you handle all the hex stuff through that prefab.

Dropping the PHexEditor into the scene or making it active would enable the editor UI and edit capabilities. It's safe to destroy it or deactivate it as needed, as changes are saved to the scripto immediately.


EDIT: Clarified that this does not directly affect terrain, and intentions of future visualization utility.​

 

Here's the map I'm currently using for the editor / game demo. I made this in photoshop over a few hours, I don't really like how it turned out but I don't have the patience it takes to make a really good fantasy map, so it'll have to do for editor and game demo purposes.

It's pretty quick and basic. If you would like to make use of it, feel free, I'm not attached to it, so consider it creative commons. The only external elements used were the mountains as a photoshop brush by Morraey:
http://www.deviantart.com/art/Map-Brushes-449750567 who has declared them open to public use.

This is a downsampled 2048x version, let me know if you'd like the 4096 psd / jpg.

 

Awesome... competitive price? as there is a few similar solutions @ the asset store.

 

Thanks, runner!
Yeah I definitely plan to release it at a competitive price. I've bought enough plugins to have run into my own pricing vs value frustrations. And I plan to include source.

I didn't run into anything on the asset store that was as simple and quick as I needed it to be, and it doesn't hurt that by making my own I can tailor the data to my game.

I hope to make the system generic enough that it can easily be applied to a number of game settings.

 

This looks very interesting,some more screenshots of what you can do with this tool would be cool.

 

Thanks Rick, I'm going to try to add layer swapping soon (paint to a different data layer than terrain), I'll add a video of using the tool in an empty project to demonstrate the plop-and-play prefab nature, hopefully by the end of the weekend.

 

Is it possible to paint various 'heights' in the terrain too?I think it would make the terrain more interesting.

 

Hi Rick, I'll add height visualization back in; I had experimented with height before and it's easy to implement but didn't suit what I was going for personally, so at the moment the visualizations are all flat. I used height to visualize particles in a different Y position and found it a little distracting; but I was probably just setting the Y adjustments too high (I didn't give it much of a chance since my game isn't utilizing height). How data is interpreted in visualization is a pretty simple task, though, so I'll add a height layer to the data and keep the height magnitude adjustable, and include that in the next screencast.

I'm also going to convert the long[] data to ulong[] so it can store just a little more. That will allow right off the bat 9 layers of data with up to 100 forms each (up to 100 terrain types to choose from in the terrain layer, etc), and later I can add a means of automatically condensing it to allow dozens of data layers depending on the size needed for each.

Just in case there's any confusion, I want to clarify this utility doesn't currently connect with Unity Terrain information. That is, no textures are splatted onto a terrain, nor is height information translated to a terrain object; the "terrain" is an enum stored in the database that the end developer uses as they see fit. It's just an assigned name of a data type.

That being said, linking height to a terrain modification would be a neat addition down the road. I think what i'd do first instead, however, is cast the hex map down onto an already existing terrain, so it uses a terrain mesh for the actual height of each mesh. That would be more useful and creatively efficient I think.

 

Here's a small update showing the drag-and-drop or plop-and-play nature of the prefabs. A bit plucky, I apologize in advance, sort of.

Later this week I'll put up another cast with more layers and height

 

Hello! I am very interested of yours asset! Is there any updates about release date?

 

Hi Ivan! Haven't been able to set a date for sure yet, My computers tanked recently (one had a GPU die and the other had a drive die at the same time! conspiracy!) and I just finished getting back up and running.

Looking forward to making some more progress and getting a sense of timeline, though. Thanks for your interest! I'll post here once I have an idea

 

Nice work. Definitely interested. Can this also be used for space themed stuff (planets, nebula etc) or is it bound to terrain?

Unrelated question: Whats the music used in the first video?

Hint: It seems you are drawing the terrain after an image/map. I think it wouldbe easier to pick the color at the hex and assign a terrain automatically and then just finetune it.

 

Thanks!
It's definitely not bound to terrain; It stores layers of numeric data that you can interpret how you like, in this case I am converting the ints back into a terrain enum (and other layers into faction, loyalty, influence, resource, and landmark enums) I'm hoping to provide easy ways of giving the user customization over the data, maybe using scriptable objects instead of enums to avoid making them code if they don't want to.

As for the music, I took a look and I am not actually certain. It was one of youtube's builtin free options that I liked but surprisingly it doesn't keep track even in the studio what the music applied was. I should have made a note of it in the description. I'll keep looking passively and if I come across it again I'll let you know and also note it in the video.

Regarding color-picking, if you're talking about getting pixels from an image, I would definitely like to add that option later, but since it would require different logic to have the user define multiple maps for different layers and different colors for different data for each map, I figured it would be best to start with manual in-editor "drawing" of the data and add automation later. Now that my machines are working again, I'm able to resume this project but only in my free time from client gamedev work, so I want to make sure I don't make the scope bigger than it needs to be for the first release. After all, if I added everything I wanted to add, this would never get done! You're right, though, that map importing is quite valuable.

 

No worries regarding that automapping. It just seemed tedious to me to draw all hexes by hand when you have an existing map you want to transfer it to hexes. Thats not a feature request from my side, just a hint to make it easier for you.
Anyway, just give hint when its released in some form. I'm always interested in Hex-Stuff .