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.
