- This topic has 333 replies, 11 voices, and was last updated 12 years, 2 months ago by
.
-
Posts
-
Every officer has a compatibility stat; loyalties depend on how close they are to the ruler's compatibility. Liu Bei, for example, has 50 compatibility, so people like Zhao Yun (50 compat) and Jiang Wei (49 compat) are very loyal. Cao Bao is 70 compatibility, so he wouldn't do that well with Liu Bei (50) and Sun Jian (100), but he'd be pretty loyal to Yuan Shu and Liu Yan (both 75).
As for battles, have the army placement markers user-defined, BUT also add an option to place them automatically.
Automatic suggestion:
* Defender gets the castle and every fort.
* Defender gets the every spot adjacent to the castle.
* Defender gets every spot two tiles form the castle except water
* Attacker gets five spots on (or very close to) the edge in the direction they attacked form.
Remember, easy-to-use editors are awesome.
Editors have to be easy to use. After all, it's what *I* use.
Feature complete, hell no, but bare functionality definitely.
I can easily offer auto-generated spots, and also let the person hand place some… perhaps this way it'd be less work for people to edit their own maps.
Lastly — 'attacker gets fives pots' … lies! attacker gets 2350235098 spots. No limits damnit! :)
I've seen some of the loyalty numbers mentioned in faq's for the other games, but haven't really dug into it much.
While I was debating a lot of stuff, I decided that for all numbers, I was going to stick to the '100' thing that ROTK2 has in prevalence.
After the RPN, i really do think it'll need to be some UI work and other stuff to start making the game functional and more wholly interactive so it's easier to start figuring out 'whats next' as well as getting other people involved in the dev process (being that the game is going to be completely free).
This way it'll also move me away from just screen testing stuffs etc….
There's no reason to limit attackers to five spots — or to limit the current map size. While my gemfire AI sucks (and is limited to units that move one square/turn and attack adjacent units), it can handle a battle with 100 units of 10,000 soldiers each on a 100×100 field just fine. Not bad seeing as the vanilla version is five units of up to 255 soldiers on an 8×10 field. Similkarly, we should be able to handle battle fields larger than that.
And compatibility numbers are indeed 1-100. Later RoTKs, though, tend to use 1-150 (with the big three being 25, 75, and 125).
I was thinking about the 1-100 thing (outside of that general you can bug heh) … and pondering useful items per general (ie: rotk3 or 4 introduced special weapons to get you over 100?) … but… I think i prefer 1-100.
With having more generals (the 450 or so named and then the auto-promote that was discussed earlier), I don't think there will be a need to go over 100 for anything.
Map sizes being more dynamic: I dunno. I gave some thought to that a bit a while back. Was thinking about say, rotk1 vs rotk2 vs rotk3 etc… and how 2 is the only one that shows everything all at once and that scrolling across the map was a tad annoying. Granted, we could just zoom the map out….
Larger map sizes also beg the question of 'how long does it take to trek from starting point to castle ?'. Again, I dunno.
After things get interactive we can tackle that.
RPN processor appears to be working:
"1 9 + ( 2 ( 3 2 * ) + ) *"
correctly calculates to "80"
time to ponder what's next.
Go with 1-100 for base stats; items can boost things slightly past 100, but only the best one counts.
Also I'll go with standard math for my pseudocode; I've never used RPN before, and PEMDAS (Please Excuse My Dear An Sha…?) works fine.
items to go beyond 100 — we'll see.
RPN – 'reverse polish notation'. its kind of like how Yoda would speak.
you give two numbers, and then an operator. the operator causes an immediate evaluation.
or maybe, 'noun noun verb' if you prefer yoda.
sooooo…
instead of: 2 + 5
you get: 2 5 +
instead of: 9 / 3
you get: 9 3 /
Now, lets say you wanna do more than one mathematical operation. Well, RPN is "left to right" in its entirety… there is no 'order of operations' (unless you consider left to right as being one).
You would do your first operation as above, and then append another number and operator.
Lets start with normal math of: 5 + 3 – 6
RPN for the first calculation would be: 5 3 +
now we want to subtract 6 from this, so we would append: 6 –
Which gives us a final answer of: 5 3 + 6 –
Given that there's no order of operations… if you have:
6 + 3 * 8
In normal math you'd end up with 6 + ( 3 * 8 ) = 30.
If you just translated 6 + 3 * 8 into direct rpn without considering order of operations, you would get:
6 3 + 8 *
Which would evaluate as (6 + 3) * 8 = 72.
Soooooooo…. i've added parenthesis support to the RPN so that you can more or less write it so it forces certain operations to happen first.
Now, you could just rewrite the above as: 3 8 * 6 +
But with the parenthesis, you could keep the numbers in the same order:
6 (3 8 *) +
While this is kinda trivial as described, being able to nest parenthesis or similar is kinda handy (and yes, it somewhat defeats the purpose of RPN).
Also note that this isn't completely true original RPN in that the original RPN would be all operands to begin with, followed by all of the operators. Yeah well, fuck that heh.
The idea behind mine is that everything is "number number operator". Or perhaps "term term operator".
Finally, the example i gave above:
1 9 + ( 2 ( 3 2 * ) + ) *
Written in normal math using lots of parenthesis to avoid order of operations, it would have been:
(1 + 9) * (2 + (3 * 2))
As such…. when coming up with formulas, i'd suggest liberal use of parenthesis to avoid order of operations questions, and then work on translating that to the RPN.
When converting to the RPN, start with the inner most parenthesis and work your way out.
Start:
(1 + 9) * (2 + (3 * 2))
Inner most is the 3*2, so convert that to the rpn:
(1 + 9) * (2 + (3 2 *))
Keeping parenthesis where they are move out. Treat the "(3 2 *)" as an entire "term":
(1 + 9) * (2 (3 2 *) +)
With the right set of parenthesis finished, we convert the left hand (1 + 9):
(1 9 +) * (2 (3 2 *) +)
Lastly, we got that multiply between the two parenthesis to take care of.
(1 9 +) (2 (3 2 *) +) *
This doesn't quite match my example above (its got extra parenthesis around 1 9 +), but it'll function the same.
hehehehe. the rpn stuff is only much easier to code / process in code…. and is about the only reason it exists heh.
hell, i might be able to write a tool to convert regular stuff to rpn. which begs why not just allow both. whatever.
butttt – i don't mind doing the conversion by hand for other people's suggestions etc :)
rpn: nope, not gonna try to support "normal math" notation. it'll be rpn :P
it'll be a while before i have an update for this… will be working on actually making it a proper state engine / game / etc. while in general it's simple, it's tedious and *can* get complicated (or rather needs to be exacting).
this will mean:
* a proper state loop with states.
* deciding how to handle gui style objects
* deciding on provincial screen gui
* deciding on general selection gui
* getting the "game state" stuff implemented
* eventually getting to battle screen gui etc
I'll undoubtedly be able to update as each stage progresses, but this is a big chunk to bite off all at once and won't really be feedback friendly. The good news is, once this is done, I can begin implementing actual game logic (ie: it becomes interactive!!)… which would allow for other people to grab it and start submitting patches etc if they felt so inclined.
Somewhere in all of this, the conditional stuff needs to be implemented. That'll require some pondering on my part. Conditional stuff examples would be historical events (yuan shu / sun ce example), generic officer promotion after battle, random treasure after combat, etc.
I'm unsure if randomish based stuff would be conditional or if they'd be math based. IE: if you want to try to recruit an enemy general, does it follow a formula and if the result is greater than some number… it succeeds… or is there a conditional tree it'll follow (which could possibly have some math in it as well) ?
I'll probably try to get the GUI to be somewhat txt/ini based so that it becomes more mod friendly easily. An example would be 'search' — having parameters to the search function call so that it could span more than one province or whatever.
Attempting to write a normal math processor is a pain in the ass.
Maybe down the line, but as it is, learning RPN takes all of 15-30min ya lazy bastards :). Old calculators used to only use it, too etc hehehe.
Also, I tend to answer emails within a few hours / a day, so I have no problems with quickly converting them for people… and eventually they should pick it up.
Lastly, this begs the question, is the game targeting players or modders ? :)
Yes, this may be the first initial 'fuck you' i give to the community at the moment. Basically, the ability is there and requires just a little bit of learning on the modder's part. If there's free time down the line can work on implementing a 'normal math' processor… but definitely not now. So it can go on the list of 'future stuff / wish list'.
- You must be logged in to reply to this topic.