Battletech virtual board

A project I've thought about for a while...

A virtual board to play Battletech over the Internet, able to support large battles and take care of the dice rolling bookkeeping.

EDIT: Webplayer available at www.electricrune.com.


Alpha at his stage, the game only works up to the end of the Move Phase.









Youtube link:

I'm really loving the way it's turning out so far, five different terrains so far (Clear, Rough, Light Woods, Dense Woods, Cement), three depths of water, and up to 15 levels above 'sea level'.

Images are of a 40x40 map, but this is by no means the limit.

Next in development, Pew, Pew, Bang! Weapons!

 

yay, isometrics!

 

Um, no...

Not Isometric, it's fully 3D, rotatable and zoomable...

 

New video, showing weapons!

Best in high res...

 

Web player available now, but it is only a game up until the end of the Move Phase.

www.electricrune.com

Still, you can get your hands on the virtual table, and see how it works and feels.

 

This is really cool.
Can I ask how you accomplished the hex game board? I've been toying around with a turn-based hex-board game and I'd love to see how you got yours to work.

 

Awesome Tasarran, go man go! I loved these games as a kid, this was one of the first things I tried making later on, my inspiration came from a game called MechForce (http://www.scharmers.info/2010/08/forgotten-amiga-classics-1-mechforce.html or for a quick youtube of gameplay, some dude with Amiga and floppy ftw here : http://www.youtube.com/watch?v=vz3e2hpbo50 ). Ralph Reed was THE MAN for my $ as a kid, between MechForce, Ultima, BardsTale and Wastelands - there went a lot of youth .

A buddy and I helped out a bit (nothing significant just the menu at the time iirc), on the Titans of Steel project which was essentially a remake of MechForce, good job but I've always thought it could have went a lot further in usability.

Something that would be really cool is making this a F2P style game with online store - would be pretty balanced as you'd just sell credits then hook up a centralized AH for buying/selling gear from arena matches, have auto-ransoming, etc...

Very exciting stuff, will love watching this one come to fruition!

 

I kicked it around a bit..not much to do, as you noted.

There is alot of potential for coolness though.

Looking forward to more upDates!

 

I would also be interested to hear how you made the board.

 

Nice job!

Like Welby said, the idea has a lot of potencial.

Keep the good work up!

 

How I made the board...

I made a model of one tile, it consists of a hexagonal cylinder, with extra faces on the top.

Then I made four different copies of this in Unity, and modified them for Rough, Woods, Forest, and Clear.
I added rocks and trees to each tile, then added a script that only runs once that randomly displaces the trees and rocks, and for some of the tiles (like Clear), I randomly destroy most of them, leaving a few randomly placed and chosen features on the tile. There is a custom version of this script on each Prefab.

I have a couple of arrays that store two points about the map. The first stores the type of each hex, and the other stores the height.
The script reads these two arrays, and Instantiates the tiles, one by one, assigning variables for X, Y, Z coordinates to a script called HTMod that is also on each tile. (These are the grid coordinates, not the actual coordinates in Unity, so the first tile would have 0,height,0)
On Update, HTMod moves the tile to which it is attached to the proper actual coordinates.
It also assigns variables that point to each of the hex's six neighbors, and the height difference between the two.

As I Instantiate each tile, I add it to a Unity Array, and also assign the number in the array to a value in HtMod called Index. This way, I can refer to tiles by the number in the array, or by actually referring to the GameObject.

Then the magic happens. HTMod looks at each tile, and if the neighbors are not zero height difference, it modifies the vertices to make a smooth slope.
Actually, it only moves the verts halfway, the other tile goes the rest of the way, so the slope is spread over the two tiles.

The water planes are at a set height, any terrain that dips low enough will end up below the water.

 

That's impressive. The terrain generation you have seems very solid. Another question: Is your movement based on a per-tile basis? For example, does the mech move from the center of one tile to the center of an adjacent tile? Along these lines, are the directions locked as well to the 6 angles of the hex? (i.e. Mech can only move in a straight line along these angles.)

Thanks for sharing. This is very interesting stuff. Good work.

 

Yes, the placement and movement are from tile center to tile center. The handle of the tile is at the center of the top.
Each move is broken up into three segments, the middle one distorted up or down based on elevation change.

Even the facing isn't set to 60 degree intervals, but rather, the mechs face the center of the adjacent tile (minus the Y component)

 

So you broke each tile into 6 triangles to calculate the grid, right? I remember being told by a CMU computer science professor that hexagonal grids are impossible to code on a computer, turns out it takes a lot of certificates to prove you're a moron.

 

I guess that's the benefit of being self-educated...

I didn't have anyone to tell me something was impossible.

 

Each tile is distinct, and has an array of six integers, that contain the index numbers of the tiles that connect to it.
As to how I calculate the grid, I cheated...

Let me see if I can draw this out a bit...

Code (csharp):

1.  
2. HEX 0           HEX 1             HEX 2
3.  0, 0            2, 0              4, 0
4.         HEX 3            HEX 4            HEX 5
5.          1, 1             3, 1             5, 1
6. HEX 6           HEX 7             HEX 8
7.  0, 2            2, 2             4, 2
8.  

This way, X represents lines of longitude, and Y is latitude.
If I was making an array this way, it would be 50% empty and wasted, but I'm not, so no worries.
I can check to see if any set of coordinates is valid by making sure the sum of the two coordinates is even.

So when I find the tile, for example, NE of Hex 4, its at X+1, Y-1. I have an equation to find the index from the X,Y coordinates, and vice versa.

It is essentially a node list, but there's no need for an array of structs to define it, there's just the tiles themselves, and variables set on scripts attached to the tiles.

(By the way, don't be confused by my X and Y above, those are just the Hex Coords. X axis is the same, but the Y Hex Axis is actually inverse of Z in the unity editor)

 

I discovered long ago that an education doesn't make you smart. Obviously the creators of Bookworm didn't listen to this guy either.

 

Thats even simpler than I had imagined, nice work.

 

It seems there are cliffs, not only slopes. How do you decide if there is a cliff or slope?

Neat.
Have you thought how to do rivers? They can start on a height far above the water plane.

 

How to program hex grid stuff:

http://playtechs.blogspot.com/2007/04/hex-grids.html

 

The cliffs are there because in BattleTech, a mech can only change elevation by one or two levels. (each level is half the height of a 'mech, six meters)
I decided that the best visual feedback to the player what was moveable and what wasn't, was to have a cliff where you couldn't move.
Early on, I had HTMod smooth every juncture; it made for a totally smooth map, looked pretty good.
If I had a slope sensitive shader/material, that would make the tris that were above a certain steepness a different color, I would have gone with that.
It was actually pretty tricky to write code that didn't smooth a height difference of more than two.

As to rivers, I've thought of a few things, the front runner in my mind is having them on top of the tile, like I plan to do roads in the future.
In this case, I'll have some sort of waterfall for when the river goes over a cliff.

 

Those links aren't really that useful in this environment.
I found at first that I was overthinking this problem, and getting way too into the math.

When you are doing a tile-based game, you only have to move from tile to tile.
In Unity, this is easy, you just get the HEX.transform.position.
You can easily construct a vector that represents a line from one hex to another, and tween movement along this line.
You don't have to worry about the actual coordinates, or figure out how to find all those points, you just go from this tile, to that neighbor tile in this direction (whose name just happened to be stored here in this array in Start).
The most complicated piece of math I had to figure out was the algorithm that finds the index number from the hex coordinates, and its reverse.

Think this way, and it won't matter if you're doing hexes or squares or any other sort of weird board that you could think of.
Think of it as one of the old adventure games...
You are Here. Exits lead: Up, Down, Left, Right, North, East, Northwest, and Out
Doesn't matter how many connections you have, or how few, you just move from one space to a connecting space.

 

Update! Added background music loop, targeting, weapons fire.

Coming next, Arcs of Fire, Line of Sight, Range, and actual to-hit dice rolling, damage effects, and Heat tracking.

 

Awesome! Brings back childhood memories of spending hours and hours on end doing anything and everything Battletech! 3025 TR with drawings by Loose were the best!! I loved those little cardboard mech figures on the paper maps. The Ral Partha miniatures were never as much fun as the carboard ones in the little black plastic foot. I guess it was a good way of sharpening basic arithmetic calculating all those to hits. Tactics as well, though that probably won't come in handy until I become a dictator.

Nice work! I'll be on the lookout for your progress.

Death from above!

 

Tasarran, I love the work you've done here. I also think that a lot of what you've done could really be helpful to our team on our upcoming project. If you'd be interested in lending a hand, send me a PM. Keep up the great work!

 

I'm thinking of posting the map generator on the Asset Store; somewhere between $50 and $100...

 

Will it include rivers and roads? I'll buy it immediately

 

Well done. Looking forward to full release.

 

Any idea when you might be doing that?

 

You know I'm interested.

 

Well, I think I'm going to make that my top priority; I'd be a fool not to take the opportunity to get a little seed cash to fund the development of my actual game.

I need to polish it up and maybe add a few more minor features, but I can't imagine it would take me more than two or three weeks to get it into a presentable package...

I've got a request from Plebe for roads and rivers, any other suggestions/requests?
(BTW, Plebe, roads are for sure, rivers are 50/50)

 

Cool. If you could make rivers to be placed in the sides of the hexes we could use your system for nearly 100% of board wargames.

 

I think I am probably going to do two versions...

One is the Tactical level, which is the one that has been being referenced in this post.
This will have elevations and roads, but no rivers. At this scale, rivers will be lines of water hexes.

The other will be the Strategic level, which will be mostly flat, but there will be 3D tiles.
This one will have rivers and roads.
If you want to see a rough demo of this style of map, look at this video on YouTube.
http://www.youtube.com/watch?v=DAzZuxWzeH0

I'm thinking about selling each for $75, and a combo pack for $100...

 

Hey nice work on this! Shows a lot of promise, and the more hex games the better I reckon

I recently started doing something similar, and approached it in pretty much the same way, except I build the map directly in the Unity editor and let the code find the game objects and fill the data structure with them.

Rather than use a 1d array for the map structure, I used a Dictionary with a Vector2 Key that holds the hex co-ords in the manner that you described, and the Value is the hex game object at that location.

Anyway, I hadn't considered changing vertices on the mesh to smooth the hexes out, but after seeing yours I think I have to...if I may ask - how are you determining the vertices that are to be moved? Is there an algorithm or have you just determined the vertex numbers by hand?

 

The vertex numbers don't seem to follow any pattern, so I wrote a modified version of the script that modifies the verts.

This script just looped through all the vertexes one at a time and move them up one unit, as I hit the spacebar, and Debug.Log the vert numbers as it does them.

I ran through this script and wrote down the verts manually.

If you have an object with hard edges, you can split the surface if you're not careful.
At a soft edge, you can move one vert and you move the verts of any triangles that share that point.
At a hard edge, you have to move the very on each side of the edge.

I realize this might be confusing, I don't quite know how to describe it...

 

Very cool!

 

I second this suggestion. If you have the Roads go through the hexes and the rivers follow the hex edges your package will be very attractive to boardgamers.

 

Why not rivers on the tactical level? A river is a road with other texture, isn't it?

I already have the strategic level done (lacking roads and rivers now), but having to pay only $25 more for both I will buy them!

 

Well, its because I'm not doing the roads or the rivers as textures, it's actual geometry.
In other words, my roads are actual slabs on top of the tile, and I want the rivers to be another level of vertex modification, revealing water below the surface of the tile, the same way the water is done in the rest of the map, but smaller scale.
This way, there can be bridges, roads going over rivers or full hexes of water (or open air, eventually)

But the rivers... I keep running into problems about having rivers running along the edge of a cliff.
And waterfalls complicate things, and add particles to slow down the engine.
I think it might take me some time to figure out an elegant solution with the 3D terrain model.
I don't want to hold up the whole project on that one thing, though...

Maybe I should just be OK that there is no perfect solution, and leave it up to the map designer to not make rivers that are all wonky...
There's no way to prevent the user from drawing a river that runs downhill then goes back uphill, anyway, so I guess I should just get over it.

Making rivers work in a 2.5D large-scale map model is easy. Rivers can run all around any old hex side you want, double back, no problem.

 

Awesome. Awesome.

 

For me it's ok having rivers with limitations. If I want to do something different for my game then I'll change whatever is needed, and having a base to do that is perfect. Please, add rivers at least as a basic feature.

 

Had a burst of activity tonight, and roads and rivers are in!

Peek the webplayer at www.electricrune.com

Also, check out the contour lines and z-level shading.

Almost ready for publication!

 

Wow!!!! Sold!

I like a lot the contour lines, give a nice effect for wargames, and the rivers are a great addition.

 

Very Nicely Done

 

Very cool!

 

Nice

 

Thanks!

You can see a hint of what I was speaking about with the complications of rivers with height if you look at the river that goes in a ring around that hill.

On the sides of the hill, you can see that the river is higher on the upslope side of the hill.
On the north side of the hill, you can see one segment that goes up and down on the same hex side.

But it works well for a basic implementation; if you bear in mind the limitations, it should work fine.
And if you switch to the full smooth option, where there are no cliffs, you don't have to worry about potential waterfalls, you'll just have some potentially steep rivers.
Just try to keep the terrain close to the same elevation on each side of the river.
A river with more than 1 difference on each bank will make for a weird river, one that would spill over the lower bank in the real world, and find a new course downhill.

Whoever gets the package from the asset store will be able to extend it in any way they want, if rivers are important at the tactical level in their game.

Same thing for the roads: they are very basic.
The way they are implemented right now, it is essentially a sixth type of terrain, that modifies itself based on the neighbors.
This is because I realized when I ran roads through the forest, I needed to do one of two things:

1) Modify the script that moves the vegetation to the proper slope and 'jiggles' them so that it monitored road placement and removed trees in the road.

2) Treat terrain with roads as a separate tile type, with different patterns of foliage that won't interfere with the road too much.

I decided to do #2; to be honest, it's because it was easier.

Then, to be ultra-super-lazy, I only did Clear With Roads. :razz:

This would probably be the first thing I change if I update the package in the future.
I know I could develop better ones given time, but this is sufficient for a starting point.

But the best thing about my system is that I built it to be extensible.
Six terrain types now, but there's really no limit to the tiles you could have.

If you wanted to get really fancy, you could have a different forest tile, depending on altitude. Palm trees by the coast, broadleaf trees one or two levels up, shading into all pine trees at the top.

Desert would be easy to add, new texture, rocks and cactus 'trees'. I've been thinking of adding it to the basic set.
Although I think a better implementation of a desert would be to simply make Clear look like a desert, and altering Woods and Forest to look more desert-y, with more cedar-like trees, rocks, and cactus-y plants mixed in.

The addition of the underlying water plane in each tile makes it possible to have a terrain type like Swamp, where there can be a few vertices on the tile that dip down into the 'river' water slightly and make puddles of shallow water.
You could have a Marsh that had grasses and bushes, and a full-on Swamp that had trees (cypress and mangrove trees?)

 

That sounds fantastic. It would show off the flexability and power of your system. You should make a single Marsh or Swamp tile to showcase your system.

 

Another nice addition, and it would serve as a basis.

 

Let it be so!

Swamp (terrain type 7), and Marsh (type 8) are in.
Added another river coming off the big hill, and made swamp on the north side near the lake shore, and Marsh on the south of the old river.

Used the trees from Woods and the texture from Forest for Swamp.
Used the texture from Woods and the ground clutter from Clear (with greater frequency) for Marsh.
Added a simple script that bumps the center verts down a few units, knocking them into the water below.
Future users might want to put custom trees and grasses/bushes in these tiles.

Note that these are random deviations, each tile will be unique, but each tile will also be modified differently each run of the map.