Strategic Primer: Encounter Model Mark II: Initial thoughts

I’ve started running the ninth turn of the current campaign of Strategic Primer, my strategy game. This means that I am finally putting the new encounter model into practice; here are my thoughts after using it.

First, once the tools are in place, this is a far superior model … but that’s not saying much. The previous model was far too limited, with at most only one thing per tile (each tile being a quarter of a square mile) and only a hundred or so possibilities, very few of which were what the players were looking for. The new model addresses those problems quite well, and—unlike the old model—can be extended to cover new categories that I didn’t think of.

Second, on the other hand, it still suffers from the other major problem of the old system: the results are essentially random, unrelated to anything around (except, now, the “terrain type” of the tile). And it adds another: it doesn’t take into account what previous explorers have found there.

Third, the signal-to-noise ratio ratio is now far too low. Under the previous model, on those rare occasions when an explorer found something, it was always something worth investigating. Now, I have to go over the generated results myself to make sure that what it produces is reasonable, and even then there’s quite a bit that players may want me to omit entirely. (What kind of grass when the explorer is going through a meadow or plains, for example.)

I think that the real solution is to increase the detail level of the map significantly, at least for some sorts of “details.” (A previous attempt to do this got bogged down in generating elevation and water table statistics based on the “terrain types”; I do still want to add data for those, but that should be a separate project.) For each sub-tile, I’d generate or otherwise determine (once!) information in several categories, and then determine how the explorer moves through the tile and what he or she encounters or notices based on those lists.

But the viewer is already running into performance problems, with maps only about 70 tiles by 90 tiles. Increasing the size of the map by an order of magnitude or more is likely to worsen that. And then there’s the problem that kept me from implementing this in the first place: having to produce the lists for every sub-tile. But after seeing what happened with what has now become the current model, I now think it’s necessary.

What do you think?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s