Wartgamer

One of the most unbelievable things is that NOT having movie play from every single unit (bazooka team/LMG/etc) makes the PBEM aspect easier. The movie detail really is the problem. Its what brings a continuity and situational awareness for the WEGO system. The designer has said as much and everyone needs to accept that. Can we get by without a continuous stream of 'video'? Is it needed for every unit?

PBEM works by saving up a large number of state changes/time refs. Even if the turn is still 60 seconds, why not just save up 5 seconds of it as it is being crunched, and then send that PBEM file 'packet' zipped in some form? You might need 12 emails (or whatever it works out to) but there must be some way to reassemble the total turn and present it to the player. The non-dynamic portions of the map do not need to be sent. Having a state for every 1m^2 tile may be a design booboo. Could the TCP/IP mimic a PBEM in that the host just streams the whole file? So basically, its psuedoPBEM. I get the whole file and then play at my leisure and when its my turn to return a file, I reciprocate? I suppose this means I have to have my computer on and some remote has control of it. I just like the idea of having some place to upload the large file, and another person with a password can get that file. So I upload to a service and even if I have to pay a fee, I can create a password that I can give out to an opponent. If its a good gaem/opponent, he can invite me and we use his service account. 56K modems being the guy out in the cold. [ March 06, 2005, 07:44 AM: Message edited by: Wartgamer ]

Hotseat would not be a problem. I would think that if the game can solo, then hotseat is just a no brainer.

It seems the design approach is literally doing a ground up as they are modeling terrain first and military matters later. But this may actually be the determinant about many file sizes. So if they go for 1m^2 resolution, and find that it even CLOGs TCP/IP, they will just back out to whatever is neded for TCP/IP and leave it at that. I would say no TCP/IP or PBEM is a definite NO so it will be interesting.

Just from a test standpoint, you need some human-human play. Well, actually, if there is no human-human play besides head to head, then playtesting that must be done that way. All other testing would be solo. [ March 06, 2005, 06:53 AM: Message edited by: Wartgamer ]

A mapping method may be to just use overlays. Just like real maps use. So the base map is just non-dynamic information. Things like area, elevation, water, rocky terrain, rubble, roads are in this file and do not change state during the game. This resides on each computer initially. It does not need to be passed but once and does not change during the game. Another file would be a building file. It contains info on all types of houses in the game. They do not change position with time but could change state. Collapse, degradation, etc. Each building has a database of its location, state, room layout perhaps. Collapse/degradation may only be updated every second. It does not need to be 1/10th second. Things like a vehicle position when it is moving describe a database type that needs 1/10th sec update. A vehicle going 20 mph will cover almost a meter in 1/10th sec. And so on for the entrenchments, vegetation, etc. There could be an obscurant file for smoke, dust, etc. The basic thought is that we pass files instead of a very large database. [ March 06, 2005, 06:43 AM: Message edited by: Wartgamer ]

If you had a medium sized map of 1000m by 1000m, thats 1 million square meters. Thats 1 million 1^m2 tiles. If you need to describe that with binary words, thats a 3 byte address. So just bare bones we are looking at 3 Megabyte to describe the map. A three byte address could describe a 4000m by 4000m map tops. But even the simplest map info, elevation, terrain types, roads, buildings, etc all need to be in that map description. The three byte address just tells you where the 1m^2 tiles are. So if each 1^m2 tile has a state AND a time since each state can change during the turn, we start to really CLOG things up. Just an example but lets say we need another two bytes to describe the state of the tile and it is updated 1/10th sec (600 times in a minute). Thats 3 Gigabyte. Thats the maps 'storey' during the turn. You do not want to pass that whole map back and forth during a game in email. Thats something you pump into a hard drive. And there is much more to crunch and do and database and pass. Just loading the scenario/map may be a waiting game. Creating a new large 4km by 4km map in an editor may be a 80 megabyte monster that needs to be served over to someone. Scenario design would take a hit. A better goal is to have a non corruptible map on each end and just flow the state changes and times back and forth. [ March 06, 2005, 05:59 AM: Message edited by: Wartgamer ]

I guess the 'house' idea can be extended to any dynamic terrain feature. So a clump of trees gets a position within a tile. The whole tile does not have a state, just the clump of trees. The trees may get set on fire (state change), blown away and replaced with a smaller clump, etc. Having a map modeled this way just starts CLOGing some more I suppose. But for large maps, having too fine a resolution will also CLOG up the system.

Actually you want to model to the smallest terrain feature I believe. Something like 1 m^2 can make rooms in a building to be modeled with multiple tiles. 8m by 8m is too course. The new terrain model will feature states on the terrain. This means that whatever resolution is used, the state of that terrain is for the whole tile. Houses may actually be modeled like units. Something like the way bunkers are like tanks in the present system. So the house, like a unit, would need a database is my thought. It would need a position within a tile just like a tank or any unit would. So would walls if they are to be modeled as destructible terrain features. Non-dynamic terrain features like the elevation would not be state changed. But even if its a 1m^2 resolution, is there still some subpositioning within the 1m^2? The problem is modeling motion. If the soldier is within one tile, and is moving is it a discrete jump to the next tile? A man laying down would actually extend into two 1m^2 tiles typically. [ March 05, 2005, 11:35 PM: Message edited by: Wartgamer ]

The present system uses a tile of X^2 dimensions (is it X=20m?). Units positions must then be expressed as being in such and such a tile and at X1 and Y1 of that tile. So lets say a byte describes a tile. That means there could be 256 tiles? That isn't right so maybe 2 bytes describe a tile? In any case, if there is 1m^2 terrain resolution and in a 500 by 500 meter game you have 250,000 tiles, you would need 2^18 or so to describe those 'tiles'. Rounded up its a 3 byte 'address'. So any soldier in the game modeled 1:1 will need a 3 byte address to describe his tile position? Will he need a further sub coord also to describe his position within the tile? Or is the soldier going to be centered in that'tile'? Vehicles can actually be in two tiles at once? A king Tiger certainly can. It may actually be quite a few? Can I run over soldiers 1:1? Is there any point in having the resolution smaller than the actually largest physical units in the game? The King Tiger may be the largest lets say. The smallest 'square' tile that captures this unit would be 8m x 8m? [ March 05, 2005, 10:01 PM: Message edited by: Wartgamer ]

If a squad is 1:1 represented, that means each soldier in that squad has to have a position on the map. This changes with respect to time so its another state/time database choker. A running man may actually go 2-3 meters every second. Will 1m^2 resolution really allow speeds to be represented? Will the game need to track each man's speed? Will movement rate be a 1:1 trackable quantity? Each man is supposedly being tracked for ammo, status (pinned, etc), perhaps fitness. Position must be tracked. Posture (prone, kneeling, etc) also? Facing? Which unit or fireteam he is in? Does this mean that there will be 1:1 databases for each soldier?? All these state/time database CLOGGER's are going to add up. [ March 05, 2005, 09:27 PM: Message edited by: Wartgamer ]

3) We (you) code the game as we (you) see fit and, knowing that file size might be a potential problem, actively seek creative ways to reduce the file size throughout the development process. Not wait till the end. With me so far? Great! True. An example is the 1m^2 resolution of the map. In another thread, the designer said that might have to be bumped up if it chokes the cpu. It should also be 'sized' for other considerations beyond gagging the cpu. Its effect on solo play crunch time for starters and other game considerations also. Just loading or saving a game may take considerable time. Its like when you paint or sculpt something. You can't have your face up against the canvas/stone. You have to step back and take in the whole thing as it is being developed.

They don't have to calculate. One side always calculates. It develops several databases and the movie can be assembled from those databases.

I think that the bottom line is that PBEM could be a reality if the designers kept an open eye for it and developed ways to convey situational awareness without all the CLOGGING.

I would like to have mastabatory sex with a pig in a McDonald's bathroom. And use the cupholder from my car without an engine to give that Pig what it really needs.

I remember that project and the guys we called CLOGs (Computer Limited Obnoxious Geeks). These were basically guys that did no programming or low level coordination, but would just come up with more outlandish features that would just CLOG up the code. Yeah, Boss' sons of course. Everytime we tightened things up they wanted to jam up the works. The thing that really saved us was the cheap 66mHz and 100mHz hard drives that started to become available and cheap. We could use the hard drives to flow it all nicely.

So the basic thing is, at what unit SHOULD you get the whole picture? What if you were to 'snapshot' from all HQ units? Do you really need to movieplay from all units? Is it even realistic? My own opinion is that a full 'continuous' movie is only realistically appropriate (and yes I know its my opinion) at the Company HQ level. I believe that the new cmx2 is going to be the best wargame at this level ever. I believe the game should actually be Titled: Combat Mission2:Company Commander! [ March 05, 2005, 02:18 PM: Message edited by: Wartgamer ]

Note the role that having to play the movie has on the database's impact. If you did not need to play any movies, there would be very little problem. You would just send a last 1/10th of a second info flop from the very last 59.9-60 second period. The player has 'jumped' ahead one minute and had his eyes closed, if you will. This is why I brought up the idea of the snapshot instead of a movie. Ever use the >> to jump ahead in the movie mode? I believe its a 5 or 10 second jump? Thats what I mean. What if the game was a 30 second turn? What if you could just have 5 second snapshots? Hit the >> 6 times and thats what you see? Could you get the same amount of battlefield situational awareness without all the eyecandy?

The math does remind me of a project I worked on. Its similar in that each grand database can be locked and encrypted and only the reciept of the new states/timeline can unlock it. So each side locks up its 'game' when it sends out a turn. So the game could send one file, a map update. another file, the units update, perhaps a fire update. And then each side assembles a movie from an events chronology. The events chronology gets info from the databases as needed to reassemble the movie. At 0.1 seconds, it gets all new map updates. it looks for any spotting updates (from unit databases), it looks for any firing updates, and so on. [ March 05, 2005, 01:51 PM: Message edited by: Wartgamer ]

Be nice to set up a webcam of sorts. And have some sorority girls take showers also.

Those are crossdressers. Lets not skirt that issue.

Perhaps the Poll should be.. How do you like to have Sex? A. I masturbate exclusively. (plays the AI) B. I masturbate a little but have some gay partners, and we go LIVE! (TCP/IP) C. I masturbate a little but have all the fine women's at my own leisure (PBEM) D. I only masturbate and PBEM/TCP/IP as needed. I exclusively am consumed with creating Pornography! (scenario designers) Am I leaving anyone out?

You are literally putting words in my mouth. Could you edit your post to reflect that the first paragraph was from BFC and the rest is actually a response? And, no, I am not calling anyone a Rube. So you are really off base.

Its not just the 'new' hole in the ground. Its when the new hole got there. It seems that each 1 meter sq is going to have a state. That means as the turn clicks away, that 1 m^2 is tracked by state and time. If the clock ticks by 1/10 sec for example, that 1 m^2 needs 600 chronological states. And it could be many things like dust/smoke/hole (crater/shellhole/foxhole/trench/etc/etc). But you do bring up a point that does the game need to know every 1/10 sec or just the change and when it occurs. The map size for a 500m by 500m battle would have 250, 000 m^2 for example. Each one of those could have many differet states to depict the terrain and the environment. Lets say its 8 cause thats 2^3 power. Lets say that each state is described by a byte. Thats 2 million bytes to just track a static map. Multiply by 600 (60 seconds at 1/10th sec update) and we need the scientific calculator. 12 with 8 zeroes. 1,200,000,000 bytes. Thats just the map. All the troopies have a similar state/time database. While the number of troopies is not as large as the number of square meters, they might acually have larger databases. Mostly tracking what they see. relatively speaking. And this will be a very dynamic changing database. How often it needs to be updated may not be as fast as 1/10 sec. [ March 05, 2005, 12:09 PM: Message edited by: Wartgamer ]

This is a wish bone thread. Unlike a Bone thread, you must take an already announced Bone and develop it into a wishbone. Perhaps an example may help.. A wishbone I would want is for scenario designers. This wishbone is a development of the 'announced bone' that scenario designers will be able to assign waypoints (perhaps SOPs) and other chahchees to scenarios as part of the design. The wishbone is that they can actually assign many different variations on these elements, and that the player can opt for one of these or have one be assigned randomly. This would allow some new dimension to scenario design and play. It would be interesting if feedback from many players discussing the scenario could agree what is the 'best' AI setting for that scenario. This would also increase replay value against the AI. It would bring scenario design to new levels of creativity. One of the settings could be 'historical' if that information is known. Other settings may be Aggressive, Conservative, Etc. Playtesting for a designer would only need one playtester. he would just fight the AI and report back the difficulty, etc. [ March 05, 2005, 11:14 AM: Message edited by: Wartgamer ]