A simple wargame

You could implement rudimentary boundary box collision detection. In which case, you could set the units a minimum distance apart from the point of the collision, but I can imagine this cascading into many other collisions. I think it would be kinda neat to see them sort themselves out, but I don't know how resource intensive you're allowed to be with this. It shouldn't be too bad with a simple AABB, though.

This post is so far beyond funny to me :)

I am currently working on a turn-based strategy game where the entire point of the design was to eliminate the nasty hex grid and take advantage of the additional gameplay it can create.

I'm not far enough in it to give alot of implementation advice, but I've gone far enough to know that the math isn't nearly as bad as you think. One of the biggest difficulties that you mentioned is the crowding, and I'm handling it by allowing units to intersect while moving but not be able to stop until they are a certain distance from other units. That way, they will intersect a bit, but they can't just all stand on top of each other. Also, since a unit can't move past a wall of units, it gives the strategy of marching down the field in a line or surrounding an enemy.

I think the bigger difficulties are in making it appeal to non-gamers. You'll have to consider your combat system to make sure that it isn't too complex, but has enough strategy to be fun. Try the Sega Genesis series Shining Force for a great combat system (and one of the inspirations for my current game).

Good luck, and if you want to talk more about it feel free to email me: jbourrie@gmail.com

I suggest that you actually use hexes, but hide it from the audience. Instead of making it blatantly obvious that there are hexes(see: most hex-games), simply not show any hexes, but actually just 'round' any mouse clicks to the nearest hex. Provide any lighting in a circle, not based on the number of hexes away. Anything that would show that it is obviously a hex-based system, try to avoid.

Best of both worlds, IMO.

Many games do this for isometric tiles, too, but it should work with hexes.

Good luck!

Thanks JBourrie, that sounds like pretty elegant solution to the crowding problem. I was leaning toward applying a movement penalty to each unit depending on how many other units they're intersecting. So hey, if the player wants to cram five divisions through a narrow pass at the same time the game will let them, but it'll take five times longer than normal. :)

How are you defining your terrain characteristics? A simple array?


Ezbez, unfortunately I really can't use hexes. The scale is such that they don't provide sufficiently fine control over movement and positioning. I'm talking literally a 10x10 grid.

Quote:

How are you defining your terrain characteristics? A simple array?

My terrain is currently just a set of line segments that represent walls, though I plan later to allow certain areas to have movement penalties (most likely as polygon sections). I didn't want a tile system, because I'm really trying to eliminate the grid feel altogether. The character bounding objects are circles, and they just do a simple swept-collision with the line segments.

One thing I like about doing turn-based is that super-fast code is not as much of an issue. So instead of worrying about having an optimized collision system and complex structures to manage everything, I can instead focus on what's really important: making the game shine. If you do need to optimize for speed, those line segments can be sectioned off into a grid, and each character will only need to collide with segments that are within the surrounding sectors of the grid.

A tile array would work as well, though it's actually more memory intensive (important if the system you're working on is mobile or something) and IMO just doesn't feel as good.

Target platform is Flash in a web browser, but resolution-fixed due to it being embedded in some distance-learning content.

Agreed that a grid isn't ideal for this sort of thing, but vector intersections are way outside my experience zone (nevermind the overhead of creating an editor). Maybe next time. For now I'm toying with the idea of using a little interpolation to smooth things out and make the griddiness not so apparent.

Sure, I could blow a megabyte on a high-res terrain data array and modern PCs wouldn't even flinch, but my inner child (who learned programming on a 48K Atari 800) would kill me on general principle.

Quote:

Sure, I could blow a megabyte on a high-res terrain data array and modern PCs wouldn't even flinch, but my inner child (who learned programming on a 48K Atari 800) would kill me on general principle.

I think the dial-up users would kill you first ;)

Quote:

No more than ~30 units total.

you could get away with just 3 units in a scissors/paper/rock relationship. These could be:
Tank: Tanks are tough against infantry because of their speed and firepower, but as artillery has a far greater range and damage, thanks are not very effective against them.
Artillery: These are slower than infantry to move and only have a slow rate of fire. Also they have a minimum distance that they can shoot at, which makes them ineffective against infantry as they can move within the artillery's min range adn the artillery can't escape. However becaue they can destroy a tank easily they are most effective against tanks.
Infantry: Infantry can move faster than artillery, but are slower than a tank. Thy can move within artillery's minimum range and attack without the risk of being attacked back. However because they are lightly armoured, they are not effective against tanks.

this simple system should be able to be oicked up quickly by non/casual gamers, but you can expand this quite easily to 9 units by having 3 unit types for each category. Each of the 3 unit in the category would specialise in killing one of the categories.

For instance:
Infantry
Machine Gunenrs: Machine gunners are infantry units that are effective at killing other infantry units. The weak firepower of the machine gun against armoured targets means they are ineffective against tanks, and although still able to take out artillery, they are less effective than other infantry units.
Rocket Launcher: These infantyr use a rockit launcher that is effective at destroying tanks. The longer range of the rock means that the unit can attack the tank from out side it's own attack range. However the missile launcher has a minimum range that is greater than a standard artillery's minimum range, this menas that these units are not effective against artillery and the slow rate of fire means that they are not effective against infantry.
Grenade Launcher: Grenade launchers use a short range morter launcher to fire explosive shells. These can be used fairly close, and can do a lot of damage so are effective against artillery, the slow fire rate means that they are ineffective against infantry and the short range means that the are also not effective against tanks.

This could also be applied to the artillery and the tanks so that you end up with 9 units total. This would be harder for a non/casual gamer to learn but have much larger strategic deapth.

If you haven't played many wargames, and are targeting non-gamers, you'll probably want to pickup a copy of Advanced Wars (either of the ones for the GBA, or the one for the DS) for "research". It has pretty much defined how to make a turn based game "fun" for the masses, making Nintendo and Intelligent Systems a mint in the process.

Quote:

Original post by Edtharan Quote: No more than ~30 units total. you could get away with just 3 units in a scissors/paper/rock relationship.

Whoops-- what I meant there was no more than 30-ish actual units in play. There are around eight unique unit types. Unfortunately I can't abstract any more than that-- the people playing this will be military-savvy, just not necessarily game-savvy. This part will be relatively easy anyway. Just throw on some movement/attack/defense stats and twiddle the numbers until it produces sensible results.

Ironically, I'm expecting the toughest part to be the UI. Good, intuitive interface design for anything non-trivial is fracking hard.

Quote:

Just throw on some movement/attack/defense stats and twiddle the numbers until it produces sensible results.

That quote makes me sad :(

What? Hey, it's my first wargame. I'm certainly not going to bite off doing windage, angle of impacts, formations, veterancy, morale, supply lines, et al.

The number-twiddling is going to be supervised by people who have some real-world experience with what's being simulated, so my comment isn't really as bad as you may have perceived it. :)

Quote:

Original post by ZylonBane What? Hey, it's my first wargame. I'm certainly not going to bite off doing windage, angle of impacts, formations, veterancy, morale, supply lines, et al. The number-twiddling is going to be supervised by people who have some real-world experience with what's being simulated, so my comment isn't really as bad as you may have perceived it. :)

It was a joke, I tend to talk as if people know my crazed ranting "innovate whenever possible" views... which only works if somebody knows me ;)

Truthfully, I wouldn't want to do wind, angle of impact, etc either (overkill and only for the nerdy... I apoligize to any nerds I just offended)

In my game, I'm working with a less realistic setting (which I know isn't an option for you) so that I can do knock-back attacks, area effects, and some very unique monster types (plus more "secrets" that I can't give away yet) in order to take full advantage of the gridless approach.

But please don't think I'm harassing you about it, it was a comment from the crazed game designer in me :)

Ahhh, I see where you're coming from. Yeah, I'd love to be doing this in a more imaginative setting, but alas. Getting things to play out "correctly" is going to be a whole separate fount of pain on this project. Yay!

What kind of warfare are you looking at?
A single land type? rolling hills? Just desert?
Or different lands? Going from forests to open areas to town/city areas?

If you want different land types I suggest doing something a little more complex with the units. You have 2 main unit types: tanks, tanks are the key to holding the open spaces, rolling hills, flat lands and that sort of thing. Then you have your infantry, those are needed in forests and cities. Infantry in the open has nearly 0 protection, and you would need your tanks to provide cover for your infantry units to advance. In closed in areas, you need the infantry to move forward to find and engage the hostiles.

How can this work in a simple game? Tanks get -75% movement and sight in forests, meaning they become slow and blind. Tanks then give +100% defence to infantry near them.

You can then throw larger guns in. Artilleries. Set them up, and rain hell down on infantry. Have infantry dig foxholes/trenches to get even more defence bonus, dig-in in forests for something that is nearly impossible to dislodge.

If you can't use a constrained movement area like a hex/square grid, you could use a method similar to that used on tabletop gaming. This simply involves the models being able to move a certain number of inches in any direction. On a computer you would just calculate a circle around a particular unit using a radius that was equal to that units movement stat. The unit would then be allowed to move anywere with in that circle.

To get more of idea on how tabletop gaming works, I recommend reading through the warmachine rulebook called 'Prime'. I'm using it an a basis for my next game.

Also, if you think creating an GUI is difficult, wait until you get to write the A.I - he he!!

Quote:

Original post by 6 If you can't use a constrained movement area like a hex/square grid, you could use a method similar to that used on tabletop gaming. This simply involves the models being able to move a certain number of inches in any direction. On a computer you would just calculate a circle around a particular unit using a radius that was equal to that units movement stat. The unit would then be allowed to move anywere with in that circle.

Exactly what I'm doing :) The next step for me is to instead calculate a "blob" of movement based on the terrain it is on, so that walking into a forest slows the character down but walking across a plain is full speed. This is much harder to do without a grid, but it will really add to the experience.

Quote:

Original post by JBourrie Quote: Original post by 6 If you can't use a constrained movement area like a hex/square grid, you could use a method similar to that used on tabletop gaming. This simply involves the models being able to move a certain number of inches in any direction. On a computer you would just calculate a circle around a particular unit using a radius that was equal to that units movement stat. The unit would then be allowed to move anywere with in that circle. Exactly what I'm doing :) The next step for me is to instead calculate a "blob" of movement based on the terrain it is on, so that walking into a forest slows the character down but walking across a plain is full speed. This is much harder to do without a grid, but it will really add to the experience.

Well, what are you basing your map on? You are still going to have some sort of grid for the land itself aren't you? Just have it run along each 'section' in the direction of travel, and pick what sort of tile that is on, apply the math as needed. However that does give how to deal with sudden changes.

Quote:

Well, what are you basing your map on? You are still going to have some sort of grid for the land itself aren't you? Just have it run along each 'section' in the direction of travel, and pick what sort of tile that is on, apply the math as needed. However that does give how to deal with sudden changes.

Actually I'm not using a standard tile grid for my land (because I'm trying to remove the grid-feel from every aspect of the game). Technically, it is using multiple tile grids that can be placed on the land, but rotated at different angles to avoid the world from being "square".

And yes, calculating the blob isn't going to be that difficult, but it is more of a challenge since it's not on a grid or tilemap :)