• Advertisement
Sign in to follow this  

A simple wargame

This topic is 4278 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all! This is my first post, hopefully it's in the right place. Here's my situation-- I've been tasked by my boss with writing a simple tactical-level modern-era wargame. Now, I've never written any wargames before... heck, I've barely even played any wargames. But no matter, he doesn't want anything complex. Just something that produces reasonable results from the player's actions. Almost a mini-game, really. No more than ~30 units total. But here's where it gets messy-- The target audience is non-gamers, so I'm not allowed to use a hex grid. A square grid would be okay, but the boss isn't satisfied with the map placement resolution that provides. I can't significantly increase the grid resolution, because that would make the unit icons too small (project is running at a fixed, relatively low res). So this leaves me with one option-- non-constrained free placement of units. Ugh. At this early point in the project I "don't know what I don't know", but I have a feeling it's going to be painful and involve a lot of math. All movement will be completely player-controlled so at least I don't have to worry about pathfinding, but I am concerned how to sanely handle multiple units crowding into the same space. Or how to allow easy manipulation of overlapping icons. Any advice? Recommended reading? Sympathies?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ;)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by templewulf
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.



Could use some of the methods employed by the 'flocking' mechanisms. Having the units check their nearest neighbors (test the ones inside a box of a certain size) and have a sum of repulsion forces along the center to center line (higher repulsion the closer the neighbor...). Scale the repulsion to some small steps and add as a position adjustment each turn cycle. Emergent motion would slowly spread units (that are in too close proxomity) apart.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by ZylonBane
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.



You need to get over that (I date from when we only had 4k of memory to make use of, so I have that tendency also). Its ok to use memory if its available (within obvious target machine limits etc...) Many problems can be simplified (and even have faster solutions) often. I recently ditched a complex file caching scheme for a client on a simulation with dynamic terrain (zone areas being saved locally on the client...) and substituted a much simpler in-memory zone cache (starting at 64meg and expandable depending on available computer memory...)

Being tight on memory in the main program is still a useful trait can actually increase code speed (ie- packing data in structures can remove many cache misses, when the data set is larger than the CPU caches...)

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by JBourrie
I think the dial-up user would kill you first ;)
*fixed

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Just throw on some movement/attack/defense stats and twiddle the numbers until it produces sensible results.


That quote makes me sad :(

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Talroth
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?

The test map is a mix of plains, woods, hills, and water. I'm trying to keep the terrain attributes as basic as possible-- I'm currently hoping elevation, concealment, and roughness will cover all my bases. "Roughness" is currently envisioned as a loose abstraction of how easily the terrain can be passed through. A building, for example, would have really, really high roughness. So would water, oddly enough.

Available unit types have been defined for me-- it's a decent mix of armor, infantry, mechanized infantry, combat engineers, yadda yadda.

Share this post


Link to post
Share on other sites
Quote:
Whoops-- what I meant there was no more than 30-ish actual units in play.

Ahh. Ok, so you will be looking at small unit tactis for the game play.

Quote:
There are around eight unique unit types. Unfortunately I can't abstract any more than that

An odd number of units is easier to balance than an even number. So if you want you could reduce that to just 7 units.

Scince 3 unit types can be used as a minimum, you should ask yourself if having more unit types are nessesary. If you have been told that you have to use those 7 unit types then you don't have much of an option. If, however you are designing the unit types then you will need to justify any extra unit types above the minimum (as you are trying to make a simple game).

Once you have a justifaction for a unit then you need to make sure that justifcation will not unbalance the game (dominated or dominating units) and make sure that the role is different enough that the players can easily distinguish why that unit is needed.

Quote:
the people playing this will be military-savvy, just not necessarily game-savvy.

If they are military savvy then it would be a good idea to create units that conform to combined arms theory. This is simialr to the Scissor/Paper/Stone type of unit designs I proposed.

Another concept to help design the types of units (and balance them) is to look at Lancaster's Laws ( At wikipedia: http://en.wikipedia.org/wiki/Lancaster%27s_Law). Although these don't give extremely accurate predictions for real life, they are good for games as they cover the ideal situation (things like terrain, fatigue, weather, etc ruin the predictive advantage for these in real life). So in real life they don't give an accurate prediction. If you are making a simple game for military savvy p0layers then they would have learnt about these laws and the Combined Arms theory and these would form part of their expectations.

You can keep the actual design of the units simple, but if you use these to help you end up with a better product in the end.

Quote:
This part will be relatively easy anyway. Just throw on some movement/attack/defense stats and twiddle the numbers until it produces sensible results.

This is the path to a very bad implimentation. If you just "twiddle the numbers" without any overall plan for the unit balance, then you will find it hard to avoid dominated or dominating units (dominated units are units that are not worth using and dominating units are units that are only worth using).

In real a military, you would never spend yime on training and equiping troops that would not be useful, simmilarly if there was a troop that could beat any other troop then no other troop types would ever be trained and equiped.

Twiddeling the numbers means that you will have to explore the entire phase space for the unit stats (or if you are luck you will hit it quickly). If you take this as an example:

Each unit has 4 Stats: Health, Speed, Attack Range, Damage. Each stat has a value between 1 and 10 (these don't nessesarily precicely represent the exact spec in the game but references a table for that stat).

For each unit that means that there are 10,000 posable stat combinations for this unit alloe. Now you have 8 posable units and that is an extrtemely big number. A proverbial needle in a haystack.

If you have an idea of the role that all the units have this gives you a rough map to what will be requiered for each unit, reducing the number of posable places that you need to test. However if this is all you have then you still have to decide what units and their rough abilities that they will have. Which still leaves a lot of area where you will not have a balanced or fun game.

If you create a framework that will guide you to what units and abilities would make a balanced game then you will be able to zero in on the stats for each unit. This can be done with the right maths to the point where you will have the requiered stats calculated and no searching is nessesary (although you will most likely come up with several posable solutions and some testing will be requiered).

Quote:
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. :)

If they know about combined arms theory and game theory then they will be able to help, but even then they will most likely use som oif the mathematical techniques to get the right numbers as I described above. The problem is, though, they will not be game designers and not understand the concept of "game play". Just making the game fit to known statistics and experence will not nessesarily make a fun or interesting game.

Game play is more than just reproduceing reality. For instance in the real world a unit type might be know to be effective, but because your game is a simplified reality, that unit might not be effective, or might be too effective. This means that you would either have to change the implimentation of the unit so that it is not conforming to the "experts" experence, or drop it altogether (which might unbalance other units, etc).

So it might not be as bad as initially though, it might be even worse in that they experence, when translated into a simplified system, can compleatly destroy your gameply (or at least will defintaly cause conflicts that will have knock on effects).

Quote:
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.

I agree that for a simple game to appeal to non-gamers, a simple/abstract system is needed. If you use a little bit of randomness (eg the damage done to a target has a random range rather than a set value) you can abstract all the situational effects (windage, angle of impact, morale, etc). As you seem to be doing a small unit tactical game then you don't need suply lines, etc (these are a strategic level).

It would help if you let me know what unit types and the role that they are to perform and I will help you create a balance for them.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement