« | Main | COUNTER-INSURGENCY AXIOMATIC »

January 23, 2005

decaplex development

To be updated as decisions on axiomatic are made...
---

DECAPLEX

The game is played on a grid of numbers arranged like so:



n+9n+10n+11
n-1nn+1
n-11n-10n-9

Every number has two sets of gates - '[[Planar]]' leading horizontally through n from n-1 to n+1 and '[[Abyssal]]' leading through n from n-10 to n+10.

Every participating player occupies a number. (Even when they're not 'present'.)

No two players can occupy the same number.


Each number has a 'polarity' meaning players can travel only vertically (to n+10 or n-10) or horizontally (to n+1 or n-1) from it. The polarity of a number depends on how it was 'spun' by the last player to occupy it.

The object of the game (tentative) is to control as many numbers as possible and stop other players retaking them.

When a player fully controls a number, he also controls all numbers that decimally reduce to it - hence, the lower numbers are most valuable.

A player may have some or all of the following powers of movement within the number grid.

-- creep : move + / - along the number line (the only 'basic' power)

-- plumb : move up by 10 (quite easy to get this power)

-- decadance (decaplex?) : digitally reduce (a much coveted power :)

-- spin : change the orientation of a number (abyssal or planar, vertical/horizontal) (this power means you can stop less powerful players getting to certain places)

... other possible powers:

-- ability to enter negative territory <0 (not sure what advantage this would be...maybe energy is stored in the lower territories (oily theme?))

-- move diagonally (to n+9, n+11, n-9,n-11)

some questions:

---> A player stops other players getting into a number by
(a) occupying it
(b) ??? planting some sort of occupation-token / weaponry - this would have to be linked to a limited supply of 'energy' (which would be renewed but subject to realtime, so you would have to wait until tomorrow to get more energy. Or perhaps it could be hidden somewhere in the grid?)

---> (how is it possible for a number to be retaken by another player?? some rules of combat needed - also linked to this 'energy supply')

---> possible/necessary to tie in the glossolalary somehow?

Posted by undercurrent at January 23, 2005 10:45 AM

Comments

1) Assuming experimentalism as an approach, definitely ready to try Decaplex v1.0 as soon as possible (just to say, this isn't a bid for vacillation).
2) The analysis of 'game space' (contemporary ludology) is - i suspect - hugely underdeveloped so far. Sticking to those ludological regions relevant to this project, my expectation is that the distance between 'Go' model (close to cellular automata and comparable decoded dynamic multiplicities) and RPG-type narrative games is really vast. Abstract Machines Corp. was going to head into the latter zone, where Reza obviously has a lot of libido too - but there's no point pretending that a crucial decision has not already been made when choosing between these approaches (almost worth - at least nominally - running the two simultaneously, just to stop them destructively interfering with each other). IMHO, the original u/c project was much closer to the former ('Go') model, which is also much 'cleaner' theoretically. RPG's are a medium, or vehicle for conveying stuff, of huge hyperstitional interest, but their game mechanics are so baroque and their latent bandwidth appetite so humungous that they are of far less interest as abstract engineering programmes.
3) The u/c principle concerning escape from 'real time' is of utterly crucial significance and extremely demanding. We need to be very clear about how this criterion is to be met. To resolve this issue in an elegant way will commit us to quite a lot viz the ultimate character of the 'game.' - worth spending serious time/thought getting this right.
4) Setting an extrinsic objective (viz "The object of the game (tentative) is to control as many numbers as possible and stop other players retaking them") is probably very helpful as a provisional device on an experimental path, but the only goal that will suffice to lift this game to a long-term libidinally self-sustaining level is the auto-emergence of the game itself - immanent 'teleology' and even 'a-life.'
5) Where do the rules come from? As quasi-arbitrary axioms a set of (pragmatically consistent) rules constitute a hyothesis or experiment. What are our meta-criteria here? -
a) Playability - certainly, but modest in ambition. Definitely worth making a game that works regardless of other desires, but we might not want to stop there. [Also, a lot here: e.g. time issues mentioned above].
b) Vehicle criteria - for RPG-type game-media creations, functioning to promote 'content' of some kind. Highly interesting (see above) but really feel this should be rigorously separated from 'ludochemical' approach (viz 'Go').
c) Immanence - a game functioning as a rule-writing (auto-construction) machine obviously complies with a high-intensity ludic ambition, sucking in libido from adjacent fields. Demands of this will (again obviously) be extremely high - IMHO not to be dismissed however.

OK, won't get carried away to the point of psychotic monologue.
My recommendations - start practising with Decaplex v1.0 as soon as feasible, but also try to avoid shutting down alternative pathways and analyze the entire project along with its practical environs as intensely as possible (aiming to formulate an informative ludological science - geared to abstract engineering questions - alongside the experimentation)

[follow ups will engage decaplex schema more concretely]

Posted by: nick at January 23, 2005 12:03 PM

Apologies for blithering on - just have to say the machine created so far is absolutely delicious - we need to define it as neatly as possible so as to grasp as much as we can of its pragmatic potential (let's not rush to lock abstract mnachinery into telelogical schemes (overall game-designs), which isn't to say we should delay experimenting with it - copy, variagate, and polyperversely invest ...)

Posted by: nick at January 23, 2005 12:15 PM

hypnotically creeping, plumbing and spinning - Soooo cool!

Posted by: nick at January 23, 2005 12:19 PM

>1) Assuming experimentalism as an approach,
>definitely ready to try Decaplex v1.0 as soon as

just a few technical things to work out first...but yes

>my expectation is that the distance between 'Go'
>model (close to cellular automata and comparable
>decoded dynamic multiplicities) and RPG-type
>narrative games is really vast.

Yes, the latter is tied to narrative, building a 'realistic' world by "imagination" (massive amount of mutual indulgence required, so flaky that you always need a gamesmaster=God to peremptorily decide what's "allowed"); whereas the former simply puts effective machineries in place that need no more than participation to become compelling. I'm not at all interested in RPGs in this context, except for the reasons Reza mentioned - the typology of powers, different levels and traits that differentiate between players. But these would be numerically defined, so it would be a different (ball)game. If anything, hyperstition and its comments box is the RPG, with huge semantic bandwidth - this is something totally different but hopefully complementary.

That's not to say that unsystematisable social dynamics 'outside the game' (treaties, betrayals, trading) cannot take place - in fact I think it's necessary to build a messaging-system into the game so this can be assured. But the aim is that these twisted allegiances emerge from the firm foundation of the axiomatic, not from an imposed 'metanarrative' (might as well model it on planetary plague of global capitalist axiomatic, nothing to lose after all ;)

> escape from 'real time'

I'm not so concerned with escaping from realtime as with making sure the game has a time (or "weather") of its own that is external to players' control. Something like growth, decay, compound interest, whatever, has to be happening (or maybe not, I'm open to argument...maybe we should try it without first)

>auto-emergence of the game itself - immanent
>'teleology' and even 'a-life.'

yes, but you need some basic principle of numerical competition (brute territoriality being an obvious contender) in order to get things happening, don't you? Otherwise we're in Montessori wonderland (or am I being too binary between head-to-head competition / liberal goo?). Of course, it is quite likely that the experiment fails and we have to decide on something different. On your last point, maybe there should be some 'archiving' function so that old hypotheses can have a second existence as instructive vectors-of-experiment.

ludochemical it is...

Posted by: u/c at January 23, 2005 12:50 PM

another huge possible development : I just accidentally used a fractional quantity for the starting number and realised that there could be the possibility of highly-powered players jumping into these interstitial realms and causing huge problems for the others ;) Can't imagine what the continuum would look like, however - just a homogenous blob, from which you could emerge anywhere...?

Posted by: u/c at January 23, 2005 02:10 PM

"I think it's necessary to build a messaging-system into the game" - this seems an excellent idea, since such a machinery could develop begin mutating in unexpected ways on a parallel track

"But the aim is that these twisted allegiances emerge from the firm foundation of the axiomatic" - 'simplicity' being a key criterion here IMHO (sorry, can't remember whether it was on your original list)

"escaping from realtime" - using real time in the game sense, rather than the wider VR sense (we have to abandon 'real time' in the sense of 'real time strategy' - so agreeing, game needs its own 'chronos')

last point also unobjectionable - you're right, crude goals essential to interfacing 'human' players with the machinery (the cruder the better - brute domination probably best), but longer-term attachment will have to come from something more - from the sense that something is happening that exceeds the winning/losing of human competitiors



Posted by: nick at January 23, 2005 02:18 PM

v0.2 coming up...another thought...what happens if someone 'captures' a group of numbers that includes the one you're presently occupying (say, if you're on 17 and they capture 8) ?

Posted by: u/c at January 23, 2005 02:43 PM

the realtime thing is more problematic than it looks : if you want to refuse any possibility of gaining advantage by acting quicker in realtime than other players, that means instituting a 'turns' system. Which makes it extremely difficult to avoid things getting frustrating at the diachronic level (ie people having to wait for each other to get up/finish work before the game can continue). This is why I think the 'energy supply' issue is crucial because it diagonalises between the two limit cases of cut-throat realtime action and tedious metric turn-taking.

Posted by: u/c at January 23, 2005 02:46 PM

a messaging system could also be adapted for trading.

Posted by: u/c at January 23, 2005 02:47 PM

time issue really complex - agree it needs to somehow be 'economized' - turns better than real time, and to do better still requires a major conceptual leap in game design - but let's see ... (isolating a Time Problem topic for discussion may be one essential step)

Posted by: nick at January 23, 2005 03:20 PM

Robin, this is a huge breakthrough. Thank you!

A few questions to grasp the game (and before suggesting anything usefyl):

>>> No two players can occupy the same number.

I know this smoothes the flow of the game and without it, there is so much trouble to build a functional dynamic game but is there any possibility to transgress this rather traditional idea in some places / points / numbers. Why should an entity be replaced by another entity in a game, why not sometimes ‘overlapping’ (Taghieh, Kurtz-gradient, The Thing) without replacement?

>>> When a player fully controls a number, he also controls all numbers
that decimally reduce to it - hence, the lower numbers are most
valuable.

So what is the starting point for the game, where does it begin? Which series of numbers should we occupy in the first place? There are 8 numbers (1-9) that monopolizes the whole game; for example if someone succeeds in capturing 5, every number that reduces to 5 is captured; isn’t it a bit too spoiling in terms of power and resource. Maybe we should use some restrictions here (not all numbers that decimally reduce to it but for example even numbers or even a more restricted series of numbers) ... also, what about numbers in the negative territory ([...]>> -- decadance : digitally reduce (a much coveted power :)

Can you explain a bit more? When does this power become available?

think the game should include alphabetic quantities of some sort (words, letters, etc) ... merely working with numbers is excellent but might be boring for some players (don’t forget that Numophobia is quite an epidemic).

Posted by: reza at January 23, 2005 03:50 PM

Sorry the last part of my post got scrambled (+ some updates):

So what is the starting point for the game, where does it begin? Which series of numbers should we occupy in the first place? There are 8 numbers (1-9) that monopolizes the whole game; for example if someone succeeds in capturing 5, every number that reduces to 5 is captured; isn’t it a bit too spoiling in terms of power and resource. Maybe we should use some restrictions here (not all numbers that decimally reduce to it but for example even numbers or even a more restricted series of numbers); or maybe we should use the profile suggestion about accessing to these resources, each player based on its skills (accessibility / inaccessibility to power and resource) can harvest an exclusive set of numbers which correspond to its skills (here some fusion of role-playing with Abstract engineering) ... also, what about numbers in the negative territory ([...]>0) in regard to this rule?

>>> -- decadance : digitally reduce (a much coveted power :)

Can you explain a bit more? When does this power become available?

think the game should include alphabetic quantities of some sort (words, letters, etc) ... merely working with numbers is excellent but might be boring for some players (don’t forget that Numophobia is quite an epidemic).

Posted by: reza at January 23, 2005 04:20 PM

>>> however - just a homogenous blob, from which you could emerge anywhere...?

teleporters? is this available in the current version of the game?

Posted by: reza at January 23, 2005 04:23 PM

v0.2 (same place) still technically shaky but adds network connectivity/messaging/ability to see other players. Brain exhausted now so better give it a rest for a while...
Reza, the only problem with your suggestions is that they contribute to the ruleset and thus reduce the unknowns: I think we should start as 'pure' as possible. Every rule has to be numerically defensible, that's the only way I can think to stop it becoming totally arbitrary.

Posted by: u/c at January 23, 2005 05:26 PM

btw my conception of 'occupation' - the player is a wandering subject, who 'in body' occupies just one number at a time, but by doing so they also occupy others (the decimally-reduced set). But there should additionally be some mechanism for them to 'reserve' numbers they are not currently occupying.
The fact that someone captures 5 and thus occupies the whole set of decimal-reductions-to-5 is IMHO an interesting factor (sieving).

Posted by: u/c at January 23, 2005 05:36 PM

for instance : it would be pointless to introduce 'teleportation' as an arbitrary and absolute power, when there are already so many interesting planes of consistency which one could have access to (teleportation via decaplexing, square-rooting, across prime-series, etc.)

Posted by: u/c at January 23, 2005 05:40 PM

perhaps it's better the other way round - if you occupy n, you occupy all numbers that n digitally reduces _to_.

Posted by: u/c at January 23, 2005 09:05 PM

To stimulate discussion:

Decaplex rule set (Brutal Swarms)

1) ‘Board’ – Standard Decaplex space.

2) ‘Pieces’ – decoded swarm counters (perhaps also fractional to one decimal place). A group of swarm counters with an allegience (under the control of a player) in any space = a ‘cloud’. Different clouds can exist in same space (Reza’s suggestion).

3) Moves. Two types:
a) Shift (change space (creep etc.)).
b) Attack.

Each Shift/Attack, by whichever swarm, counts as 1 move within game time. At regular intervals (10 turns? More?) a metabolic 'build' function augments all clouds. Hence ‘Build’ (not a deliberate move, but rather an unconscious simultaneous function of the game).

Formulae
Attack: (simultaneous/reciprocal combat function): Attacker (sqr-rt cloud size)/3 , deducted from enemy cloud. Defender (sqr-rt (cloud size + terrain (space) number) /3, deducted from attacker.
Notes: a) this makes high numbers more defensible (rough). Corrollary should be that they are less productive for builds.
b) ‘/3’ a guestimate of reasonable modulator (raw square roots probably too high)
c) hostile clouds must co-exist in same space to fight.

Shift: terrain itself resists move as if defender in combat, hence, Shift attrites moving force as if defensive reaction by sqr-rt (terrain + alien clouds in both origin and destination space) /3. Making shift erosive helps to reduce benefit to initiative (making lots of moves), to aid of relatively passive cloud populations.

Build: add sqr-rt (Cloud size / (sqr-rt terrain)) … perhaps also modulated down (by ‘/3’?).
Best build spaces worst (most hazardous) to defend.

Other notes.
With shift, player may want to divide a cloud – constraints on this? Should active/inactive fractions always break 2:1, or should player be free to decide?
Can player choose to make moves from anywhere (like Go – my preferred option) or is there constraint on this?

Starting – 100 free cloud particles at beginning (whenever a new player wants to enter).

Posted by: nick at January 23, 2005 11:49 PM

PS. Square-rooting will lead to problems with negative numbers. Point of sqr-rts is:
a) to ensure distributed cloud systems build faster than concentrated ones (thus 'compelling' expansionist aggression)
b) grunging up combat, so numerical superiority leads only to relatively minor swap-off rate benefits.
Of course, game also might be called Counter Insurgency.

Posted by: nick at January 24, 2005 12:22 AM

PPS. Point of this demo just to gain an idea of how large a consistent rule set needs to be. IMHO this one 'playable' already (with minor glitches e.g. negative 'terrain' etc.)

Posted by: nick at January 24, 2005 12:26 AM

PPPS. If u/c prefers this approach:
"my conception of 'occupation' - the player is a wandering subject, who 'in body' occupies just one number at a time, but by doing so they also occupy others (the decimally-reduced set). But there should additionally be some mechanism for them to 'reserve' numbers they are not currently occupying." then a 'subject' ('commander') would provide initiative to just one privileged cloud of each 'tribe' (player) - wandering the map picking up and depositing swarm pellets of the same tribe. Uncommanded clouds would still grow and defend themselves automatically.
Think if Decaplex goes this route, then a supplementary automatic reflex should be added, with all co-existing (space-sharing non-aligned) clouds nibbling at each other during build catastrophes (perhaps at rate (sgr-rt size)/9).

Posted by: nick at January 24, 2005 12:32 AM

http://www.well.com/user/mmcadams/gointro.html
"a full-size Go board must have a grid of 19 horizontal and 19 vertical lines ... The lines are thin and black, drawn on the wood by hand for a top-notch board, and the grid contains 361 intersections."

ah! 361 = INTERSTELLAR DUST = OAMOSGRBMCONNNIIII = SPHERE OF SENSATION = PEACE - TRANQUILITY

"Fearful Asymmetry ... two players use their respective stones to compete for territory ... forming a map of the contest of two minds."

AQ 352 = FEARFUL ASYMMETRY = WILLIAM BURROUGHS
AQ 53 = GOD = 19X19 = DOG = EAT = LIE = NU = EACH = BACK
AQ 199 = GO PROVERB = DUST-FLUX = GREAT WORK = KCQUABBALLAH
AQ 141 = GAME OF GO = KURTZ = ENOCHIAN
AQ 171 = GO PLAYER = AZATHOTH = SHOGGOTH
AQ 217 = SET STONES = DREAD WALKING

Posted by: northanger at January 24, 2005 06:10 AM

nick - sounds viable, will have to spend some time working out the details and get back with any questions

Posted by: u/c at January 24, 2005 10:34 AM

Decaplex Counterinsurgency Ruleset

My rewriting/interpretation/questions (being DoGon-literal never hurt anyone, so suggest we should work this into a 'proper' axiomatic formulation):

Each number in the decaplex board constitutes a singular 'terrain'.

Each player begins the game with a number of deployable counters. Counters can be deployed in any quantity into any terrain. A quantity of counters is a 'population' ('clouds' too fluffy-sounding?)

Any subset of a players resident population within a given terrain can be split off by that player and moved to a terrain adjacent to it.

'Adjacency' (vectors of population movement) covers all modes of terrain-linkage such as creeping, plumbing, decaplexing, etc.

A player has a set of powers/traits that determine which modes of adjacency they are able to exercise.

A player's set of powers depends on the total population _deployed_ by that player at any given time.

Thus, powers can be revoked as well as earned, in line with deployed population size.[nb the earning/revocation of powers adds a catastrophic-event element into the game over and above the continuous vectors of growth]

It also follows that a player is free to keep undeployed counters 'in hand', but these counters do not count in terms of awarding new powers to a player. Undeployed counters do not 'exist' in the game but constitute a virtual cache whose value will diminish over time. [global inflation]

Terrains can accomodate mixed populations. That is, populations can be deployed by all players within the same terrain.

If a player's population is present in a mixed-population terrain, he can decide to attack one of these other populations.

In case of attack, the defenders population is diminished by (sqr-rt attackers population size)/3 , a loss proportional to the disparity in population size. The attackers cloud is diminished by (sqr-rt (defenders population size + terrain (space) number) /3, a loss proportional to the 'value' of the terrain they are attempting to take.

[[The modulation of these two diminishment values should make possible different rates of 'ratcheting' towards inassailable cloud strengths, and different levels of differentiation between terrains.]]

A player can also deploy or move a population into a terrain with already-resident populations. In that case,
their population is dimished as if in combat (the resident populations not so). sqr-rt (terrain + alien clouds in both origin and destination space) /3. [nick - not sure about logic of this - why both origin and destination???]


Deployed populations grow periodically, proportionately to existing population size AND terrain value: add sqr-rt (Pop size / (sqr-rt terrain))/n

questions:

-would this work ok in the current interface, or would you need to see a larger frame of reference (or maybe we could just have the present 9-square, then a huge overview)

-should we just get rid of the negatives? although sqrt -1 could get interesting, not sure whether we can cope with it quite yet, lol!

-(purely ludaesthetically driven, this one) could there be an awari-like function where a proportion of resident populations were 'spilled out' (maybe by an interesting route, say decaplexing) by incoming immigrants?

- given the above, do we still need turns ? It would only be in the initial deployment phase that this would make any difference (not even then, given that the game should be tuned so that new players can enter at any time). After this, all movement is limited by growth/dimishment.

Posted by: u/c at January 24, 2005 03:04 PM

just realised how practical the idea of basing it on squareing/rooting is - this means that whilst massive warlord amass huge amounts of power and move into the hundreds/thousands, this will still leave the unit foothills free for newcomers to squabble over...

Posted by: u/c at January 24, 2005 04:28 PM

realise I'm overstepping boundaries of parsimony here, but we can always reduce down later: what about powers - ie a population of 150 on terrain 5 = 5 to the 150th power or 150th prime even - surely some interesting Kurt(z)ian cryptovectors can be made of this; reducing monoinvestment of the gameboard as territory of 'ultimate reality' since by deploying populations in terrains you are in effect accessing a huger but sparser second-level space whose apparently disconnected and magical teleportations correspond to continuous movements 'on the ground' (second level derivative)....

Posted by: u/c at January 24, 2005 04:39 PM

u/c - need some digestion time, but some of these points prompt immediate response.
1) (most important) think my failure of expression has led to misunderstanding on 'turns' - rather, my suggestion eliminate turns. Instead, any player at any time can make any number of moves, and when some set cycle of these (as i ask, 10? 20? more?) are registered by the game itself, a periodic 'growth catstrophe' is triggered affecting all populations. So rules must at least substantially restrain advantages of 'initiative' (otherwise 'the unleeping one' wins every time).
2) your deployment axioms seem very (= over?) liberal. 'fanning out' potentially an important dynamic, so letting players disperse fully from beginning might be too generous (but counter-arguments definitely possible here, perhaps some intermediate, partially constrained equilibrium point?). also, why the 'hold back' ('in hand') option? don't understand why this important enough to justify addition of private and invulnerable transcendent spaces.
3) "('clouds' too fluffy-sounding?)" LOL!
4) ludaesthetic additions - let's (at least virtually) map out some parallel machineries, each intially governed by a simplicity criterion - your last (4:39) suggestion especially interesting, should be taken as inducer for phyletic branch-node into region of alternative rule-packets (with more rigorously numerical (rather than merely) quantitive inter-relations, and thus more unpredictable effects). Why i would argue for the slow-tracking of these momentarily is that i suspect they'll come into violent collision with time-management regime (1) above, since the more sophisticated tactical possibilities they raise will hypervalorize initiative and make passive populations into sitting ducks.
5) oh yes, negative numbers - kill for now, they will inevitably complicate this stage of the process - bring back when they actually have a function pre-allotted by a rule-set

Posted by: nick at January 24, 2005 11:11 PM

"A player has a set of powers/traits that determine which modes of adjacency they are able to exercise. ... A player's set of powers depends on the total population _deployed_ by that player at any given time."
- this has plenty of milage, adding a dimension of immanent 'emergence'. Still wonder whether it would be better to treat it as a further step, to be grafted on after an elementary version demonstrably functional. To make 'space' for it, original movement potentialities could be maximally constrained, allowing more complex locomotion to be introduced as an upgrade.

"why both origin and destination???" [movement attition from 'hostile' populations] - assuming a kind of guerrilla war model, movement is easiest when no hostiles involved, most difficult when entire route of movement infested with enemy forces [not a key axiom in any case, important thing is that movement has an attrition cost, to reduce initiative advantages and give relatively passive players some chance of survival [thus allowing 'turns' to be dispensed with]]

Posted by: nick at January 25, 2005 01:13 AM

you understand - only prevaricating because turing-realisation of any ruleset means a significant investment of time...
(1)I think there is some possible confusion between two senses of movement ; firstly, the 'wandering subject' or player monitoring progress of the game; secondly, populations within the game and their movements. My suggestion is that the former have no effect on gameplay whatever (as is traditional) - clean break with the v.01-2 model here.
(2)I had thought of the growth period as being linked to realtime, but I see advantage of it being linked to 'turns taken' : that way, there's nothing to stop the unsleeping taking initiative, but they also consume game-time and grow enemy-populations proportionately
(3)'In hand' issue - what I had meant was that, _were_ we to allow players to keep undeployed counters in hand, they would have to be worthless. If it's not allowed, there's no problem! Maybe a player should just have to deploy their 100 counters in one terrain to begin with.
(4)Can't see any reason not to be liberal with splittings - if a player sieves their forces too thinly they'll only have themselves to blame as they melt into nothingness...
(5)Kill negative spaces, agreed.
(6)Movement limited to creep&plumb initially, agreed; but have a soft spot for decaplexing, and think it could easily be incorporated (say, for populations>500 or something, so it was linked to population size rather than overarching 'player' strength (players should only exist through their populations))
(7)Understand origin-destination point, agreed.
(8)Concretely : I think we need a player interface that shows at a quick glance a range (probably needs to be more than a 9-square to make sure the player has some idea of the 'big picture') showing the terrains and at-a-glance info on their constituent populations (ie: "TERRAIN 109: your population 105, other populations 500). Then the player move to this space and get more detail (ie: "TERRAIN 109: your population 105, reza population 500, nick population 440,.....").
Alongside this, there should be a 'codex' on the server, where every event that happens in the game is recorded (this way returning players can make sense of changed circumstances, and there can be no disputes).
Also, perhaps would benefit from a 'league table' showing overall populations deployed by all players?

Posted by: u/c at January 25, 2005 10:27 AM

do you agree it makes no sense to set an upper limit on terrains? Because spreading to higher values will be a smooth function of the progress of the game (since every player starts with the same number of counters)

Posted by: u/c at January 25, 2005 10:31 AM

u/c - total agreement with all your numbered points.
the terrain limit question is hard to address a priori. conceptually your case is irresistable, but because there should be substantial 'dispersion pressure' emerging out of the intrinsic growth incentives it might be wise to constrain the total space initially, in case it shoots uncontrollably towards galactic-scale colonization. (note here, if all the squared formulae are made result n-1, it will clip the extreme priviliging of very small populations (rt 1 = 1) - again hard to anticipate playability stakes here a priori - but imagine this modification especially meritorious in unlimited space, since it reins in the benefits of a radically dispersive growth strategy)

Posted by: nick at January 25, 2005 10:45 AM

PS. sorry, n-1 point very unclear.
think this operation only makes sense if one is subtracted directly following the extraction of the square root, so ((rt n) -1)/z, where z is quasi-arbitrary divisor (as in '/3' so far). This makes (rt 1) - 1 = 0, which seems to neatly deduct the bottom from a potentially excessive superminimalism.

Posted by: nick at January 25, 2005 11:00 AM

PPS. whole n-1 issue principally of relevance to build machinery (perhaps also combat - far more questionable).

Posted by: nick at January 25, 2005 12:35 PM

here I've tried to separate basic axiomatic from implementation variables.
[deleted, see updated version below...]

Posted by: u/c at January 25, 2005 12:48 PM

(fully understand point about 'escaping realtime' now - gametime only proceeds when things are happening in the game - much better than peremptory decay-vector of 'realtime' invading gamespace regardless.
But think it needs to be supplemented with principle of historical transparency:as an example, a snippet of HISTORY would look something like:)

---

CLICK [787] Player ROBIN Terrain 25 :
A population of 100 was deployed

CLICK [788] Player ROBIN Terrain 26 :
A population of 100 crept from Terrain 25 - Attrition 3

CLICK [789] Player ROBIN Terrain 26 :
A population of 97 attacked Player NICK's population of 24.
Attrition ROBIN 4 NICK 23.

CLICK [790] A growth catastrophe occurred.
Total population of decaplex is now 3622.
Diaspora totals are as follows:
ROBIN 232 counters in 5 populations
NICK 134 counters in 3 populations

----

Posted by: u/c at January 25, 2005 12:55 PM

forgot to include in axiomatic (most necessary for growth of smaller populations):

POPULATIONS may include fractional values, but these will be invisible (will not appear in DIAGRAM or HISTORY), and cannot be moved.

If a fractional POPULATION is left on its own in a TERRAIN it immediately diminishes to nothing.

Posted by: u/c at January 25, 2005 01:04 PM

final observations - (1) we could remove the growth/attack rules entirely from the ruleset and make them a matter of implementation (rather than just the divisor). Not sure whether this is decidable pre-experimental-phase.
and (2) beginning to look increasingly likely that we need a more minimalist GO-like implementation for the interface to the DIAGRAM of DECAPLEX (ie. less high-gloss all-action than versions 0.1-2)

Posted by: u/c at January 25, 2005 01:25 PM

updated axiomatic (screwed up all the equations in the first draft, sorry about narrative-mangling effects on above 3 comments...):

here I've tried to separate basic axiomatic from implementation variables.


COUNTER-INSURGENCY AXIOMATIC

0.
The following axioms constitute the RULESET of the GAME

1.
The PARAMETERS of the GAME are U (terrain upper limit) L (terrain lower limit) D (process divisor) T (catastrophe-periodicity) S (Number of counters to start with)

2.
The GAME consists of the PARAMETERS, several PLAYERS, POPULATIONS, and the GAMESPACE.

3.
IMPLEMENTATIONS of the GAME consist of the GAME together with PARAMETER VALUES, MODES OF ADJACENCY, rules for the granting and revocation of access to MODES OF ADJACENCY to PLAYERS, and a DIAGRAM.

4.
Any number of PLAYERS may join at any CLICK in the game.

5.
Each PLAYER who joins the GAME begins with a virtual population of quantity S.

6.
The first dimension of GAMESPACE are a series of TERRAINS indexed by numbers beginning with L and generated by the rule n'=n+1 where n'<U

7.
A TERRAIN has the capacity to contain any number of POPULATIONS of any quantity

8.
ADJACENT TERRAINS are those terrains which are related one to the other by the PRIMARY MODE OF ADJACENCY T2=T1+1 or by any MODE OF ADJACENCY introduced in a given IMPLEMENTATION.

9.
Every PLAYER has access to some or all of the available MODES OF ADJACENCY and MODES OF ADJACENCY may be granted to or revoked from PLAYERS.

10.
The second dimension of GAMESPACE is articulated as a series of CLICKS indexed by numbers beginning at 1, generated by the rule n'=n'+1, and with no upper limit.

11.
The passage from one CLICK to its successor is effected by the discrete occurrence of an ACTION or a CATASTROPHE within the TERRAINS, resulting in a transformation of the GAMESPACE.

12.
ACTIONS are either DEPLOYMENTS, MIGRATIONS, or ATTACKS.

13.
A DEPLOYMENT occurs when a PLAYER places his POPULATION of S COUNTERS into a TERRAIN, thereby creating a POPULATION occupying that TERRAIN.

14.
A MIGRATION occurs when a PLAYER moves some or all of a POPULATION from one TERRAIN to another ADJACENT TERRAIN. When a POPULATION MIGRATES from TERRAIN A to ADJACENT TERRAIN B, it constitutes a new POPULATION. The results of a MIGRATION are:
- the POPULATION suffers an attrition of sqr-rt ((TERRAIN A number + total alien POPULATION OF TERRAIN A)+(TERRAIN B number + total alien POPULATION OF TERRAIN B))/D

15.
Only one POPULATION per PLAYER may occupy a TERRAIN at a given CLICK. Further POPULATIONS moved or deployed into the TERRAIN will merge with the PLAYER'S resident POPULATION in that TERRAIN.

16.
Any number of PLAYERS may occupy a TERRAIN with their POPULATIONS at a given CLICK.

17.
A player can ATTACK an alien POPULATION in a given TERRAIN with his own POPULATION within that TERRAIN. The results of an ATTACK are:
- The defenders POPULATION will suffer an attrition of (sqr-rt attackers POPULATION size)/D
- The attackers POPULATION will suffer an attrition of (sqr-rt (defenders POPULATION size + TERRAIN number) /D

18.
CATASTROPHES are of one type only, the GROWTH CATASTROPHE. The GROWTH CATASTROPHE occurs after the occurrence of T ACTIONS. During the GROWTH CATASTROPHE, all POPULATIONS occupying a TERRAIN within the GAMESPACE are augmented by sqr-rt (POPULATION size / (sqr-rt TERRAIN number)-1)/D

19.POPULATIONS augmented by CATASTROPHES or diminished by ACTIONS may include fractional values. These fractional values will not be counted in ATTACK ACTIONS and cannot be MIGRATED. They will, however, be counted in further CATASTROPHES.

20.If a fractional POPULATION is left on its own in a TERRAIN it immediately diminishes to nothing.

21.
At any time a PLAYER may broadcast a freeform MESSAGE using ASCII characters to all other PLAYERS. The MESSAGE has no immediate effect on any dimension of the GAMESPACE.

22.
Every PLAYER has access to the HISTORY which details the ACTIONS and CATASTROPHES that occur in all CLICKS previous to the current CLICK, along with their numerical outcomes. HISTORY does not, however, include MESSAGES.

23.
This ends the RULESET for the GAME

24.The following axioms constitute the IMPLEMENTATION known as DECAPLEX-1

25.
The PARAMETER-VALUES are U=1000 L=0 D=3 T=9 S=100.

26.
The MODES OF ADJACENCY are : T2=T1+1 ("Creep +") T2=T1-1 ("Creep -") T2=T1+10 ("Plumb +") T2=T1-10 ("Plumb -")

27.
PLAYERS are granted access to all MODES OF ADJACENCY. There is no revocation of MODES OF ADJACENCY.

28.
The DIAGRAM for this IMPLEMENTATION articulates the first dimension of the GAMESPACE as a grid of numbered TERRAINS set out as follows:

n+9 n+10 n+11

n-1 n n+1

n-11 n-10 n-9

29.
This ends the IMPLEMENTATION conditions for DECAPLEX-1

Posted by: u/c at January 25, 2005 03:09 PM

This format very helpful. ... digesting ...
two immediate points:

1) migration attrition: "sqr-rt ((TERRAIN A number + total alien POPULATION OF TERRAIN A)+(TERRAIN B number + total alien POPULATION OF TERRAIN B))/D"
might be adjusted to:
(sqr-rt ((TERRAIN A total alien POPULATION OF TERRAIN A)+(TERRAIN B number + total alien POPULATION OF TERRAIN B)))/D
(i.e. exempt TERRAIN A itself from the formula)

2) possible to anticipate sneaky possibility viz 'abuse' of new player option by using multiple avatars (of one empirical human player) to launch 'miraculous' 100 counter suicide squads to screw over opponents - divine intervention - nothing at present (?) to prevent meteorite bombardments by thousands of such assaults - realize blocking this might violate a wide variety of principles, hyperstitional and other, but worth preparing for (maybe ethical injunction against it would suffice?)

Posted by: nick at January 26, 2005 01:23 AM

lol, "ethical injunction"?

Posted by: northanger at January 26, 2005 01:50 AM

did you mean:

(sqr-rt ((total alien POPULATION OF TERRAIN A)+(TERRAIN B number + total alien POPULATION OF TERRAIN B)))/D

?

in the absence of an actual monetary charge to join the game(the only real bar to spammers&trolls, add some reality-weight to the game and guarantee that only truly interested parties get involved, but bound to raise ideological 'debates'), I think 'community policing' is probably the only way to combat that sort of ludomilitaristic trolling. Or else, operate a 'manual' joining policy (people have to email requesting a login/password) - that could work.

Posted by: u/c at January 26, 2005 10:16 AM

besides, wouldn't gamewide damage with 100 counters only be possible in early phases of the game (principle of click-inflation)?
In any case, I'd propose an addition to the deployment rules - deployment can only happen in empty terrains?

Posted by: u/c at January 26, 2005 10:31 AM

anyone have an opinion on the optimum size (or rather, smallest practicable size) of player-interface 'window' onto gamespace (3x3,4x4...?)

Posted by: u/c at January 26, 2005 10:34 AM

"did you mean ...?" - yeah, just copied and pasted your mode of expression, so don't blame me ;)

"I'd propose an addition to the deployment rules - deployment can only happen in empty terrains?" - excellent (partial?) solution

"anyone have an opinion on the optimum size ...?" - should probably be odd numbers, but 3 (vertical) x 5 (horizontal) within range of imaginable candidates (assuming most screens aren't square)
5 x 7 would be more informative (if it could be tweaked to fill most of the screen)

Posted by: nick at January 26, 2005 11:23 AM