Small Bone

[Scipio]

Originally posted by Lars:

... Perhaps throw in the horse**** random map generator. Better than nuthin if you can just dust off some old code.

I'm pretty sure it ain't that easy.

Maybe it's a good idea to use a basically standardize & exchangeable CM2 map format, so it finally doesn't matter if the map was created in CM2:SF or in CM2:WWIIwhatever. So the pool of available maps would get bigger and bigger with & for each future title.

[Lars]

That would work too.

But, since Battlefront is relying on others to make all these maps, it would be nice if they set up a server host.

Remember when the Scenario Depot crashed?

[MikeyD]

About replayability and the random map generator.

Remember guys, BFC isn't planning an everlasting game this time around. The CMx1 games had such looong development times that something pretty close to 'everlasting play' had to be designed-in to keep people interested & around from one title to the next! Theoretically with the modular x2 game engine, by the time we start to get bored with the initial release of CMSF a cool new module will show up, and when we start to get bored with that a new title will show up, etc., etc. That way we keep enjoying new aspects of the game engine and they keep collecting money from us.

From the perspective of BFC's bottom line, perhaps built-in eventual boredom is a good thing. if the first game released is all things to all people what's their incentive for anyone to buy the second game?

[ October 03, 2006, 10:35 AM: Message edited by: MikeyD ]

[Ace Pilot]

Originally posted by Lars:

Dunno, we've never seen the sales figures.

True, but Steve gave a pretty strong indication in this post that sales have declined from CMBO to CMBB to CMAK, despite your, my and aka_tom_w's efforts to the contrary.

[Lars]

Originally posted by MikeyD:

if the first game released is all things to all people what's their incentive for anyone to buy the second game?

That's a no brainer.

Given BFC's track record, it's pretty obvious you might just be missing out on a great game.

[dalem]

Originally posted by Kineas:

The problem IMO is that random map generation is applicable for 'tile-based' games, and the CMx2 maps will be rather FPS style maps. Like what you can see in the Battlefield series. Writing a random map generator for those is quite challenging, and the quality gap between the human made maps and the generated maps will be far wider.

I'm ignorant of the different styles of map you refer to above. I thought the CMx2 maps were just going to be roughly the same idea but with smaller tiles and therefore finer resolution. Are FPS style maps different than that?

-dale

[aka_tom_w]

Originally posted by dalem:

</font><blockquote>quote:</font><hr />Originally posted by Kineas:

The problem IMO is that random map generation is applicable for 'tile-based' games, and the CMx2 maps will be rather FPS style maps. Like what you can see in the Battlefield series. Writing a random map generator for those is quite challenging, and the quality gap between the human made maps and the generated maps will be far wider.

I'm ignorant of the different styles of map you refer to above. I thought the CMx2 maps were just going to be roughly the same idea but with smaller tiles and therefore finer resolution. Are FPS style maps different than that?

-dale </font>

[dalem]

Thanks, Tom.

-dale

[Sergei]

Uhm..? I thought Steve said at one point specifically that there WOULD be tiles (of something like 8 metre size). Tom, where did Steve say to the contrary?

Well, never mind, it was easy to find what Steve said. Here:

1. The grid size is now 8m x 8m vs. CMx1's 20x20m.

2. Now even an 8x8 item can be put at a 45 deg angle, unlike CMx2 where 45 deg angles were only possible if they were smaller than 20x20m. This allows you to have, for example, a row of adjacent "row houses" running at a 45 deg angle to another row. This was not possible in CMx1 because diagonal lines never allowed things to be truly adjacent.

3. Terrain is in layers, allowing you to mix and match stuff within the 8x8 areas. This was only possible in CMx1 if we had hand coded the 20x20m tiles ahead of time. We still have to limit how much stuff you can pile up in one spot for code reasons, but it is possible to do more combos than was possible before.

4. Because the grid is now 8x8m, you can pack a lot more terrain features into a smaller space. For example, in CMx1 you could have a house on grass as one of the 20x20m tiles. Now you can have a 8x8m house with trees around it, or a wall running right up to it on one side and a road right along on the other.

5. Problems inherent to the 20x20m terrain mesh are most likely all solved. Things like not being able to have a house in the side of a hill... no problem now. I'm sure there will be some limitations here and there, but not the routine ones experienced by map makers in CMx1.

6. Buildings are so different from CMx1 that I'll have to start up another discussion about them. Suffice to say that we designed buildings with urban warfare in mind. Yes, that means you can have dense, multi-story structures with roof access, basements, specific entry/exit points, and a host of other features. Graphically buildings will look a lot better than CMx1, though they won't match the sort of fine details seen in games like BF2. That's the trade off one gets for flexibility... function over form

[ October 03, 2006, 10:01 AM: Message edited by: Sergei ]

[YankeeDog]

Ya, there's an 8x8 grid, but as some of the stuff you just quoted implies, and if you read Steve's other posts on the matter, it sounds like terrain modeling is considerably more complex, beyond just using a smaller grid resolution, especially WRT how the engine handles objects and elevations within the 8x8 grid.

Kinda like comparing a Horse-drawn wagon and a Ferrari. Yeah, they both got 4 wheels, but the similarities pretty much end there. . .

[aka_tom_w]

"In CMx2 things are very different. The CMx2 concept of tiles is gone. However, there is still an underlying grid and a separate terrain mesh. Unlike CMx1, the two can contain different sized blocks. This allows us to independently control the volume of data for the game engine and the graphics engine."

this is what I was talking about, and I may have been mistaken, there are still tiles, but the are superimposed on top of a 1m x 1m mesh.

correct?

from the same Post by Steve:

Battlefront.com

Administrator

Member # 42

posted August 25, 2005 04:17 PM

Since I've seen a lot of questions about terrain, I figure a quick compare/contrast with CMx1 is in order.

In CMx1 we had a fixed grid of 20m x 20m. This grid determined both the terrain data as well as the graphical appearance. We called these 20x20 spaces "tiles". CMx1 resolved the location of a unit down to fractions of a meter within a tile, however all units within that tile were treated as being in the same terrain regardless of position. Well, except for a few hybrid tile types, such as roads and small houses (i.e. things that were not 20x20, but instead contained within a 20x20 tile). The relative position mattered for LOS/LOF, explosions, movement etc. and therefore it did matter what your relative position was.

In CMx2 things are very different. The CMx2 concept of tiles is gone. However, there is still an underlying grid and a separate terrain mesh. Unlike CMx1, the two can contain different sized blocks. This allows us to independently control the volume of data for the game engine and the graphics engine. Say for example we find that the game data is a real pig in terms of RAM and CPU usage, but the latest graphics hardware can handle the graphics just fine. Well... we can tweak the fidelity of the terrain mesh without increasing the size of the blocks for the underlying game grid. Or perhaps it is the other way around... the CPU and RAM can handle more game data, but the graphics bottlenecks require a lower resolution of the graphical terrain mesh, so we increase the fidelity of the underlying game data. Whatever the case is, the sizes of these blocks can be adjusted by us, quite easily, as hardware becomes more powerful in years to come. That means we're not locked into one way of doing things for the next x number of years.

Why not just resolve everything down to individual pixels and be done with meshes and blocks of terrain? Hardware limitations. Unless we employ pathetically small maps with simplistic units this is just not possible. That means a certain amount of "grid" behavior will continue to exist for some time to come. Good news is that over time the grids will be smaller and smaller.

web page Steve's post and entire thread about terrain it is a long thread

The 2D Editor UI will be a lot easier to use than in CMx1. Even if Charles winds up refusing to code 90% of the stuff I came up with, I can assure you it will still be better

No, you will not be able to cut and paste parts of one map into another, no matter how the mechanics work. All you can do is download someone else's map, bring it into the Editor, and work on it as you would do in CMx1. In order to do more than that we'd have to support the concept of placing "assembled" stuff instead of just creating it. It's not going to happen simply because it isn't necessary (it is also a time sink we ain't touching). If someone makes the Reichstag, then why wouldn't they also put the neighboring terrain around it? And if the person doesn't do that, why can't you just import the map, increase the size, and then work on it yourself? Piece of cake.

Steve

Battlefront.com

Administrator

Member # 42

posted August 26, 2005 09:33 PM

Oh yeah... I keep forgetting to mention that the terrain mesh is 1m x 1m. So even though the terrain itself is measured in 8x8 pieces, the underlying shape is significantly more flexible. This is why you guys don't need to worry about houses in sides of hills and whatnot

Steve

AND

Battlefront.com

Administrator

Member # 42

posted September 04, 2005 06:49 PM

Correct about the TacAI. It can figure out "I am here, the enemy is there. I need to find some cover. That trench looks good". It is the StratAI that needs to say "I don't know where the enemy is, but I suppose he is over there. Ah... a trench runs in just the right spot for defensive line. Let's see... the enemy's approach path is level so the trench actually will provide some cover. I think I'll put 2 platoons along this trench and my heavy wepaons behind it." Two different concepts. The TacAI is the easier of the two to do in this case.

Terrain grid is 1m x 1m, but every 1m a height can be assigned of between 1 and 100mm. This means that you can have a 100m long slope with the high point being 1m.

For every one tile you had in CMx1 you can have roughly 4 tiles. So even if there were no mixing of terrain within a CMx2 8m x 8m tile, you will still get (roughly) 4 times the varried terrain as you could get in CMx1. In reality, over a larger space of map, you get a little more than 6 tiles for every 1 of CMx1. That's a pretty huge jump in variety all on its own. However, we will allow some mixed tiles in CMx2. Some of the mixing will be dynamic, but some of it will have to be hand coded by us. In the latter cases we'll have to go easy on the variations simply because there is only so much time in the day

Steve

[ October 03, 2006, 10:14 AM: Message edited by: aka_tom_w ]

[Battlefront.com]

It's been too long since a car analogy...

Trying to take the CMx1 map generator and putting it into CMx2 would be like taking a truck engine and putting it in a BMW. Not only would one be stumpped as to how to physically connect it, but the performance of the BMW would suck even if one could get it running.

There is nothing similar between the CMx1 terrain system and the new CMx2 system, therefore there is no possibility of code sharing. Period.

The added complexity and refinement of the CMx2 terrain system is the reason why we are not doing a random map generator (remember, not a random BATTLE generator.... that we still have). It would take a ton of time and effort and likely produce a result that pretty much nobody would be pleased with. It just isn't worth it. We realized this probably 2 years ago, and nothing today makes us regret the decision from a development standpoint. From a game standpoint, I've already said that in theory we would want it in there. It's just not practical.

BTW, it is true that Longevity does not equal Sales. "When the novelty wears off" is not a concern since it will wear off AFTER the purchase. Most games are playable only for a few weeks, tops. For $45 that is a pretty good deal when compared to other forms of entertainment. The fact that you guys have been getting YEARS off of a $45 or less purchase is nothing short of highway robbery Sure, our egos are nice and stroked by the fact that we have broken pretty much all records in the wargaming niche, and a few game wide, but that's about it. So arguments for us to slave away to give you things for, basically, free don't go over too well

Steve

[kgsan]

Originally posted by MikeyD:

About replayability and the random map generator.

Remember guys, BFC isn't planning an everlasting game this time around. The CMx1 games had such looong development times that something pretty close to 'everlasting play' had to be designed-in to keep people interested & around from one title to the next! Theoretically with the modular x2 game engine, by the time we start to get bored with the initial release of CMSF a cool new module will show up, and when we start to get bord with that a new title will show up, etc., etc. That way we keep enjoying new aspects of the game engine and they keep collecting money from us.

From the perspective of BFC's bottom line, perhaps built-in eventual boredom is a good thing. if the first game released is all things to all people what's their incentive for anyone to buy the second game?

OK, so let me understand; having a much narrower focus for their games and much more limited replayability, without random maps, is going to increase sales?

[Sergei]

Of course, what with new separately sold modules coming out every week, and so forth. Start digging your wallet!

[Lars]

Originally posted by Battlefront.com:

So arguments for us to slave away to give you things for, basically, free don't go over too well

Back to work you!

Btw, my point on longevity was that latecomers to the party buy on word of mouth. You're still selling a few of the CM series, aren't you?

[Battlefront.com]

As for the issuing of orders when PAUSED in RealTime... as I said, we do not want to blur the lines between it and WeGo. If you want to slow things down and plot deliberately, then play WeGo. If you don't, then play RealTime. If you re schizophrenic, seek medical help

One practical issue is that there are no Command Delays in RealTime Mode. So a Pause would allow you a completely unimaginable amount of precision control over what happens, even more so than WeGo. So if we are going to allow Commands during a Pause in RT we are also going to have to put Command Delays in place for the entire RT environment. We don't think that is a wise idea.

I'll head off this likely response..."WHAT? No Command Delays in RealTime Mode? Are you insane?" Nope, logical. Think about it... in WeGo we have Command Delays in there so that there is some simulation of the difficulty of getting Commands issued exactly when you want them whever you want them executed. RealTime has this built in as an inherent part of the system. The fact that the game continues as you move around checking on things and what not means that there is already plenty of delay happening. So adding MORE delays would be a bad thing as would unlimited ability to plot without any delays.

As I said, in theory we can change things to allow Comamands to be issued during Pause, but at the moment we see this as highly detrimental to the game. Therefore, for now, it is completely out of the question. When we get major testing under way we will reevaluate our options to make sure we're going forward with the best system.

Steve

[Battlefront.com]

kgsan,

OK, so let me understand; having a much narrower focus for their games and much more limited replayability, without random maps, is going to increase sales?

No, having a lot more depth, far more detailed game experience, and a lot of brand new features will increase sales. Adding more features to something that people will already happily buy and enjoy far longer than other games is not going to increas sales at all.

Lars,

Btw, my point on longevity was that latecomers to the party buy on word of mouth. You're still selling a few of the CM series, aren't you?

Sure, but if we were able to put out a new Module every 6 months and a new game every year we wouldn't need the extremely small number of highly discounted sales we get of aging products just to keep the lights on, now would we?

Remember folks... this is all part of a much larger strategy. In order to do some things we can't do others. On balance we know, for sure, that everybody will be a lot happier with the new strategy we have. However, that doesn't mean that it's got a perfect mix of things for everybody. Just know that there are practical limitations, therefore we expect some sighs and curses along the way. Doesn't bother us because we know the cheers will drown them out.

Steve

[Lee]

Steve: Would it be possible to take advantage of the We-Go game mode to let CMII calculate all the complex math under the hood of the actual combat resolution all at one time for the whole one minute of game time, and then play back the 3D visual combat results afterwards, like it works in CM now?

This would allow for much larger numbers of units in a battle without the frame-rate going down because the computer could devote all it's processing power to calculating the combat results (the PC could use 30 seconds or a minute or whatever amount of time it needed to process the math) before watching the video of what happened. And then devote all it's processing power to rendering the 3D battlefield results at a good frame-rate.

[Battlefront.com]

Lee,

In theory we could simply have the first pass of the turn hidden and then you would see the replay, so to speak. This would mean always having to wait 1 minute to see a new turn executed. If there was some major benefit to this it might be worth it, but I don't see that being the case. Under your scenario, any possible speed increase you might see would be more than offset by the extra weight of polygons. Calculations don't kill framerate, polygons do. Hey, sounds like something that could go on a bumpersticker

Steve

[Lars]

Originally posted by Battlefront.com:

Sure, but if we were able to put out a new Module every 6 months and a new game every year we wouldn't need the extremely small number of highly discounted sales we get of aging products just to keep the lights on, now would we?

Hear they're doing great things with LED's and fluorescents these days.

Ok, good enough. Back to the realtime/wego debate.

[dalem]

Thanks Steve.

-dale

[Lee]

Well, if the math of the combat calculations takes up so little processing power that it's not even worth worrying about as it relates to frame-rate, then I guess it's no big deal. But I'm surprised to hear that. Charles is always talking about the incredible amount of processing power it takes to calculate this or that realistic combat resolution feature. So I thought that even on the faster PC's we have now, it would take up a major slice of the computer chip's processing time just to figure that combat stuff out while still having to render the great looking 3D graphics that CMII has in real-time.

Kinds of makes you wonder what kind of math-intensive realistic combat calculation features Charles had to leave out due to frame-rate considerations in a real-time game, as opposed to We-Go, knowing the PC could spend all the time it needs calculating the combat results, and then could focus on just the 3D graphics separately. Hmm...

As far as the bumper sticker, let's no get that started again. hehe

[MikeyD]

I'm happily playing my CMx1 games at home on a semi-ancient 300 mhz G3 mac (a system that'll definitely need to be upgraded to play CMx2). By way of contrast, my current computer at work is a 1.8 GHz dual processor G5. Now THAT's the kind of exponentially faster speed available these days to handle realtime combat calculations!

As to what Dan had to leave out of the game to keep the frame rate up, I think he already mentioned the days of vast Russian steppe maps are over, we're going to be playing 'up close & personal' on more reasonable size CMBO-scale maps, at least until the next generation of super CPUs come out. I can't help but notice everybody's still making assumptions and suggestions largely based on a CMx1 mental picture of the game. I suspect all our jaws will drop when we finally get to see the new engine in action.

[Salkin]

Originally posted by Sergei:

</font><blockquote>quote:</font><hr />Originally posted by Salkin:

I'm really dissapointed that you took out the random maps. I only played random maps.

Sure you did, you good-for-nothing Swedish asswipe! :mad: </font>

[Battlefront.com]

Lee,

But I'm surprised to hear that. Charles is always talking about the incredible amount of processing power it takes to calculate this or that realistic combat resolution feature.

Charles was talking about this 4-8 years ago... a lot has changed since then When we first released CMBO people were using Pentium I systems running around 166 MHz, or 604s in the same range for you Mac guys. RAM was 64MB to 128MB. Graphics cards had 8MB of VRAM, maybe 16MB if they had shelled out some serious dough.

All of that has changed dramatically, but CPU power is where things really increased. With the sort of CPU and RAM available to us these days lots and lots of things are now possible and possible a lot quicker. Graphics are still the bottleneck.

Think about it... the basic needs of CM are the same now as they were 8 years ago. That means a great amount of the stuff that CMx1 struggled to crunch are over and done with without the hardware even noticing something happened. This has allowed us to add more stuff, like higher terrain resolution, more detailed LOS/LOF, Relative Spotting, etc. and still have CPU power to spare. Not so for graphics. We still have to watch what we do VERY carefully. Of course, this is after we bumped the polygon counts up by a factor of 10 or more

My point is that right now we find it difficult to bring the system to a standstill to get the game itself to work, but we could crush framerate with about 5 minutes work. All Charles would have to do is compile the current code without certain graphics optimizations on and you'd probably experience FPS in the single digits no matter how high end your system is.

Steve