Quote from: EngineAnd I think that probably deserves mention in the rules, and is one solution to the conundrum Flyingmice mentions. When combat doesn't need to be tactical - because the situation doesn't require it, or the group doesn't tend to it, or whatever - maybe the big map isn't necessary.* But when the time comes, it's absolutely irreplaceable as a means of visualizing large, tactical combat.

Even small scale combat as far as I'm concerned.   There is the thief sliding down the corridor towards the corner around which he wishes to quietly peer, leaving the party 30' behind, when suddenly two doors on the opposite walls open and out pour six kobolds, three goblins and an ogre!   Map, please!  

QuoteOne point: I think it's important not to limit the scale of the map to some specific value. We did that for quite a while - standard 5ft squares - and the problem becomes that the battle tends not to range outside the confines of the map! Even the players just don't ask, "What's eight feet over there?" This is okay if your combats can take place in that sized area, but when we first got the map, I was a Ranger and could shoot things from hundreds of yards away, but because of the scale issue, I never engaged anyone further than 120 feet or so. Something to keep in mind.

Good point!   I think I'll have to experiment with how to handle that, but my guess is that GM adjudication is the solution.   Statement to the players would be:  "Dudes, remember, that while we are playing on tactical maps with scales at 5' per hex, remember that you may always ask about and react to terrain and/or foes who may be off the current map.  Archers with ranges that extend off the map - do take note!"   Might that suffice?

Quote*But just think: there's a giant-ass thing to write on in the center of the table. If you don't need a map, use it to do something else: draw a picture of the scene, rather than a birds-eye-view; write down the names of the important NPCs in the enormous political arena; and so on. Even when it's not a map, it's an excellent tool: we use it to track initiative [large enough for everyone to see!] on the end of the map that's not gridded [there's a six-inch leader at the end for this purpose] and often, the players will make notes, to themselves or each other, right on the map, right on the table.

We're going to move over the next year to a multi-touch 3' x 5' display that'll be the center of the table and will be connected to a PC running XP Tablet, which will make some of this easier - for instance, no marathon erasing sessions - but for now, I think the big map's an incredible tool, which like any other, only needs to be used properly, and taken into account throughout the game.

Now THIS is really interesting!   I am very curious about the multi-touch 3' x 5' display and how you intend to use it!   Can you give some more specifics of the techical setup?   I have some software here that I created that I might be able to put to excellent use on such a system.    Manufacturer's and model numbers, and any other technical details would be awesome.   Thanks!

Quote from: VBWyrdeI think I'll have to experiment with how to handle that, but my guess is that GM adjudication is the solution.   Statement to the players would be:  "Dudes, remember, that while we are playing on tactical maps with scales at 5' per hex, remember that you may always ask about and react to terrain and/or foes who may be off the current map.  Archers with ranges that extend off the map - do take note!"   Might that suffice?

Also, let's say you really need to draw a map that's 400 feet across: you're not going to do that on one inch squares at five foot a square! So then you mark scale: outline a square and write "10ft" next to it or whatever. That's generally all we end up needing to do, although you do have to remember, in a wargaming system like D&D, that all your engagement rules aren't going to apply per square, but per quarter-square, for instance. It can be tough.

Quote from: VBWyrdeCan you give some more specifics of the techical setup?   I have some software here that I created that I might be able to put to excellent use on such a system.    Manufacturer's and model numbers, and any other technical details would be awesome.   Thanks!

The manufacturer will be "Engine Corp," and the model number will be "3278." No, seriously, I'm building it, rather than buying one [which we couldn't afford!] Originally, I'd intended to use an array of old LCDs and a side-mounted imaging system more like Microsoft's Surface, but it looks like we'll probably use a projector and a Wiimote, inspired by Johnny Chung Lee's whiteboard and airtouch controllers. We predict much awesomeness. And, building it ourselves means we can put in cupholders and room for character sheets and space to roll on, etc.

Someday, I'd love to have a system that can read the bottom of the die, figure out the top value, and figure out your roll for you, but really, if we get to that point, we're just showing off.

Quote from: EngineAlso, let's say you really need to draw a map that's 400 feet across: you're not going to do that on one inch squares at five foot a square! So then you mark scale: outline a square and write "10ft" next to it or whatever. That's generally all we end up needing to do, although you do have to remember, in a wargaming system like D&D, that all your engagement rules aren't going to apply per square, but per quarter-square, for instance. It can be tough.

Yeah, well that's the same scaling issue I was talking about a little earlier in essense (or at least related).  My problem has been keep track of what scales on zoom in maps are what so that my scaling makes sense between maps.  Kinda tricky, but I'm working on it.   I think the key for me may be to standardize my scales so that I'm always sure what scale belongs to what Map Levels.  I've done this effectively in my software, but I have yet to apply the principal to my poor old analog brain.  

QuoteThe manufacturer will be "Engine Corp," and the model number will be "3278." No, seriously, I'm building it, rather than buying one [which we couldn't afford!] Originally, I'd intended to use an array of old LCDs and a side-mounted imaging system more like Microsoft's Surface, but it looks like we'll probably use a projector and a Wiimote, inspired by Johnny Chung Lee's whiteboard and airtouch controllers. We predict much awesomeness. And, building it ourselves means we can put in cupholders and room for character sheets and space to roll on, etc.

Someday, I'd love to have a system that can read the bottom of the die, figure out the top value, and figure out your roll for you, but really, if we get to that point, we're just showing off.

Holy macrel - built it yourselves?  Geektastic!  I hope you'll show off with some screenshots and specs diagrams and stuff when you're done!   I was hoping there'd be something on the market like this because I do have software that would be pretty useful for this kind of setup that I designed a while back.   Anyway, thanks for the leads.   While I don't think I'll be manufacturing this myself, I sure will be interested to hear about your progress.

When I orginally wrote my Nucleus game I used hex grids a lot, the rules were formulated around moving around on such a grid, and there were rules for how and when this movement should be performed.  At that the time the game was a fanasty game so all the action was fairly close together (as a rule) so it tended to work well.  

It all kind of fell apart however when I wanted to use the same rule system in a Scifi game were invariably the action occured across a wide area (shooting and vhiecle combat for example), while still having localised melee fights at the same time.  At this point you ethier needed very big hex grids, or just stopped caring what specific hex combatants were in, and instead just worring about how big the hxes were for roughly managing movement and working out how far apart things were.  Once you kind of took this decision it no longer mattered whether you were using hexes or squares.

The decision about whether two comabants get in the way of each other becomes a little more subjective once you accept that the hexes / squares are not occupied / unoccupied but instead just a unit of measure, but in my experience common sense prevalies and players and GM almost always agree on whether something is possible in this regard.  I.E. its often not required to plan out movement in a board game like way.

The order in which movement occurs is also an interesting subject, but is of course only significant really when two or more combatants have competeing goals with respect to movement (I.E. what to get through the same door) or block the move of another and so on.  IMO good systems only get down to a fine level of detail once this beocmes an issue, while keeping it quick and easy when not significant.  Or allowing faster combatants to call the shots in such an oppossed situation

Quote from: HawkyWhen I orginally wrote my Nucleus game I used hex grids a lot, the rules were formulated around moving around on such a grid, and there were rules for how and when this movement should be performed.  At that the time the game was a fanasty game so all the action was fairly close together (as a rule) so it tended to work well.  

It all kind of fell apart however when I wanted to use the same rule system in a Scifi game were invariably the action occured across a wide area (shooting and vhiecle combat for example), while still having localised melee fights at the same time.  At this point you ethier needed very big hex grids, or just stopped caring what specific hex combatants were in, and instead just worring about how big the hxes were for roughly managing movement and working out how far apart things were.  Once you kind of took this decision it no longer mattered whether you were using hexes or squares.

The decision about whether two comabants get in the way of each other becomes a little more subjective once you accept that the hexes / squares are not occupied / unoccupied but instead just a unit of measure, but in my experience common sense prevalies and players and GM almost always agree on whether something is possible in this regard.  I.E. its often not required to plan out movement in a board game like way.

The order in which movement occurs is also an interesting subject, but is of course only significant really when two or more combatants have competeing goals with respect to movement (I.E. what to get through the same door) or block the move of another and so on.  IMO good systems only get down to a fine level of detail once this beocmes an issue, while keeping it quick and easy when not significant.  Or allowing faster combatants to call the shots in such an oppossed situation

Good points.  The problem with the TableTop game for this kind of thing, I find, is that maps are not easily drawn, so that scaling when you need to change the scale can be a drag for the GM.  Computer enhanced play would include a scalable map feature for this purpose, but I don't have that tool ready for distrubution to the public.

As for the order of movement, yup.  I think I'd go with your suggestion - don't hassle with it unless it is an actual issue - such as getting to the open door first.   In that case, if the number of movement points are equal, then I'd compare the dexterity of the two characters and let them roll against that to determine who won the race.   Seems like that would be fair and work well enough.  Yah?

I'd love a Microsoft surface to play on, so yes, I'm with you on a computer aids. In my experience most movement is not oppossed ist rarely worth getting to detailed about it until it matters, even then its fair to say that an opposed role modified in what ever way is appropriate solve the issue, so yep we seem to agree there to :-)

Quote from: HawkyI'd love a Microsoft surface to play on, so yes, I'm with you on a computer aids.

Only costs about US$100 plus projector if you make it the easy way.

Harder to use at the pub though, but its a fine idea ;-)

Quote from: EngineOnly costs about US$100 plus projector if you make it the easy way.

I have the code that would work for this, but not the expertise to bring it forward.  The code is in VB6 and would handle quite a bit of what we're discussing in terms of mapping.   Functions:

1. Create maps (grid and hex)
2. Assign Terrains that have movement values
3. Create pieces and place them on the map board
4. Move pieces by mouse drag
5. Show movement paths of all pieces or selected piece.
6. Reverse movement using backspace key
7. Calc Movement Range and show on screen for all or selected piece.

Etc.
Etc.

It does a lot of stuff.  But I am currently stymied by the fact that the code is in vb6 and needs a good solid code review and polishing up (improved and/or reviewed error handling, etc).   This code would, however, work very well on Microsoft Surface, I'm pretty sure.   Only question is - where to go from here with it?   That's where I'm stymied, actually.