A simple wargame

Game Design and Theory Game Design

Started by ZylonBane May 31, 2006 12:55 PM

24 comments, last by LorenzoGatti 17 years, 10 months ago

May 31, 2006 09:36 PM

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.

Anonymous

May 31, 2006 09:50 PM

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

Anonymous

May 31, 2006 11:46 PM

Quote:Original post by JBourrie
I think the dial-up user would kill you first ;)

*fixed

ZylonBane

122

Author

June 01, 2006 08:39 AM

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.

JBourrie

1,204

June 01, 2006 12:28 PM

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

That quote makes me sad :(

Check out my new game Smash and Dash at:

http://www.smashanddashgame.com/

ZylonBane

122

Author

June 01, 2006 12:36 PM

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

JBourrie

1,204

June 01, 2006 12:49 PM

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

Check out my new game Smash and Dash at:

http://www.smashanddashgame.com/

ZylonBane

122

Author

June 01, 2006 12:58 PM

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!

Luckless

3,283

June 01, 2006 03:43 PM

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.

Old Username: Talroth
If your signature on a web forum takes up more space than your average post, then you are doing things wrong.

138

June 01, 2006 04:04 PM

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!!

----------------------------------------------------
Check out my casual TBS game blog
----------------------------------------------------

A simple wargame

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

A simple wargame

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines